| Next revision | Previous revision |
| en:dpi:dpi_components:router [2024/09/26 15:29] – created - external edit 127.0.0.1 | en:dpi:dpi_components:router [2026/05/21 12:41] (current) – [The Internal Router Architecture] elena.krasnobryzh |
|---|
| | {{tag>Services "Service 254" VRF}} |
| ====== Soft-Router (routing function) ====== | ====== Soft-Router (routing function) ====== |
| {{indexmenu_n>4}} | {{indexmenu_n>4}} |
| ==== The Internal Router Architecture ==== | ==== The Internal Router Architecture ==== |
| |
| {{ :dpi:dpi_components:router:router_architecture.png?direct&700 |}} | {{ :dpi:dpi_components:router:router_architecture.png?nolink&700 |}} |
| |
| Data from the kernel route table is read (rtnetlink) in the router's RIB. RIB is a prefix tree, it is convenient to modify it by kernel route table change events (delete/add entries). But it is impossible to use RIB in routing because it does not support multithreaded access from work threads (it requires locking, which is unacceptable). Therefore, in SSG, RIB is in router thread and unavailable for worker threads. | Data from the kernel route table is read (rtnetlink) in the router's RIB. RIB is a prefix tree, it is convenient to modify it by kernel route table change events (delete/add entries). But it is impossible to use RIB in routing because it does not support multithreaded access from work threads (it requires locking, which is unacceptable). Therefore, in SSG, RIB is in router thread and unavailable for worker threads. |
| | |
| | The synchronization process is performed in at least two passes: synchronization is considered successful if two consecutive reads of the Linux route table return the same number of entries. FastDPI will read the route table until this condition is met, but if four consecutive attempts are unsuccessful, fastDPI will build its RIB/FIB based on the last attempt and schedule a new synchronization after a short period of time (2 seconds). |
| |
| The worker threads use FIB. This structure is designed for multi-threaded search (LPM – longest prefix match), but is not designed for modifications (deletion/addition of new records). FIB can only be built from scratch by RIB and then used for LPM. Therefore, there are two FIBs in SSG – the current one (which is currently used for routing by worker threads) and the 'future one'. SSG checks every ''router_fib_refresh'' seconds to see if there have been any changes to the RIB since the current FIB was built. If there were changes, SSG builds (in router thread) new FIB in place of “future” one, and then switches current FIB to a new one. By doing this, the worker threads will meet any changes that have occurred in the routing table. | The worker threads use FIB. This structure is designed for multi-threaded search (LPM – longest prefix match), but is not designed for modifications (deletion/addition of new records). FIB can only be built from scratch by RIB and then used for LPM. Therefore, there are two FIBs in SSG – the current one (which is currently used for routing by worker threads) and the 'future one'. SSG checks every ''router_fib_refresh'' seconds to see if there have been any changes to the RIB since the current FIB was built. If there were changes, SSG builds (in router thread) new FIB in place of “future” one, and then switches current FIB to a new one. By doing this, the worker threads will meet any changes that have occurred in the routing table. |
| |
| <note important>Subnets for the same port must not overlap.\\ | <note important>Subnets for the same port must not overlap.\\ |
| For example, BGP1 from VRF1 is subnet 10.20.30.0/24, BGP2 from VRF2 is subnet 10.20.30.0/20.</note> | For example, BGP1 from VRF1 is subnet 10.20.30.0/24, BGP2 from VRF2 is subnet 10.20.30.0/20.\\ |
| | Different ''tap'' and ''peer'' interfaces must be specified for each ''router_device''. For example, ''tap=dpi_ospf'' and ''peer=rib_ospf'' for the first one, ''tap=dpi_bgp'' and ''peer=rib_bgp'' for the second one.</note> |
| |
| == VRF subscriber management == | == VRF subscriber management == |
| device=13-00.0 | device=13-00.0 |
| vrf=ROUTER | vrf=ROUTER |
| tap=dpi | tap=dpi_ospf |
| peer=rib | peer=rib_ospf |
| subnet=224.0.0.5/30 | subnet=224.0.0.5/30 |
| subnet=192.168.123.69/32 | subnet=192.168.123.69/32 |
| device=13-00.0 | device=13-00.0 |
| vrf=ROUTER2 | vrf=ROUTER2 |
| tap=dpi | tap=dpi_bgp |
| peer=rib | peer=rib_bgp |
| subnet=192.168.123.70/32 | subnet=192.168.123.70/32 |
| } | } |
| #router_subs_metrics=32 | #router_subs_metrics=32 |
| </code> | </code> |
| {{ :dpi:dpi_options:router:анонс_public_cidr_для_nat-сервиса.png?600 |Public CIDR for NAT Service Announcement}} | {{ :dpi:dpi_options:router:анонс_public_cidr_для_nat-сервиса.png?nolink&600 |Public CIDR for NAT Service Announcement}} |
| NAT public address subnets are announced only towards the inet when the SSG starts and when adding/removing/modifying NAT profiles. | NAT public address subnets are announced only towards the inet when the SSG starts and when adding/removing/modifying NAT profiles. |
| |
| {{ :dpi:dpi_options:router:анонс_public_ip_адресов_после_авторизации.png?600 |Announcement of Public IP addresses after authorization}} | {{ :dpi:dpi_options:router:анонс_public_ip_адресов_после_авторизации.png?nolink&600 |Announcement of Public IP addresses after authorization}} |
| Subscriber addresses can be announced both towards inet and subs side. But if the subscriber's IP address is [[en:dpi:opt_cgnat:сgnat_settings#additional_settings|in the private address range and the service 11 is assigned to it]], the subscriber's address is not announced towards the inet (so be careful when defining private address ranges). The announcement is made to the BIRD routing table for all TAP-devices of the allowed direction, then BIRD picks up the changes and announces them to the appropriate protocols according to its configuration. | Subscriber addresses can be announced both towards inet and subs side. But if the subscriber's IP address is [[en:dpi:opt_cgnat:сgnat_settings#additional_settings|in the private address range and the service 11 is assigned to it]], the subscriber's address is not announced towards the inet (so be careful when defining private address ranges). The announcement is made to the BIRD routing table for all TAP-devices of the allowed direction, then BIRD picks up the changes and announces them to the appropriate protocols according to its configuration. |
| |
