Parameters and values
Mandatory parameters
To enable the router, set the following parameters in fastdpi.conf:
| Parameter | Mandatory | Description | Default | Type |
|---|---|---|---|---|
router | Yes | Enables the router: 1/true/on — enabled, 0/false/off — disabled | 0 | cold |
router_netns | Yes | Name of the network namespace where the routing daemon runs. Used as the default VRF netns | — | cold |
router_kernel_table | Yes | Number of the kernel routing table that the routing daemon builds and fastDPI reads. Used as the default VRF table | — | cold |
bras_arp_mac | Yes | SSG virtual MAC address. Required even if no BNG mode is used | — | |
bras_arp_ip | Yes | SSG virtual IP address. Required even if no BNG mode is used | — | |
bras_ipv6_address | Yes, for IPv6 | SSG global IPv6 address | — | |
bras_ipv6_link_local | No | SSG IPv6 link-local address (FE80::/10 prefix). Used with IPv6 | calculated from bras_arp_mac |
Additional parameters
| Parameter | Description | Default | Type |
|---|---|---|---|
router_max_ip4_route_count | Maximum number of IPv4 routes in one VRF. Memory is allocated at startup; set with a 20–30% margin | 1000000 | cold |
router_max_ip6_route_count | Maximum number of IPv6 routes in one VRF. Memory is allocated at startup; set with a 20–30% margin | 200000 | cold |
router_multipath_page | Maximum number of pages for multi-path routes (64 routes per page) | 8192 | |
router_fib_refresh | Interval for checking changes and rebuilding the FIB, seconds. We do not recommend setting it below 5 seconds | 15 | hot |
router_arp_cache_size | Maximum ARP cache size; SSG keeps separate caches of this size for IPv4 and IPv6. Maximum — 32000 | 1024 | cold |
router_sched_add_prio | Priority boost for the router service thread. Change only as a last resort | 0 | cold |
router_bind_core | CPU core the router thread is bound to -1 — auto-detect. You can bind it to the core of another service thread (ajb, ctl), but never to the core of a worker thread or dispatcher! | -1 | cold |
TAP subnet configuration
For each router_device, you must specify which subnets are diverted to the TAP (in fact, this diverts routing protocol packets to BIRD). SSG extracts traffic to these subnets from the general traffic on the device and sends all such packets to the corresponding TAP interface.
Subnets are set by the subnet (IPv4) and subnet6 (IPv6) parameters in the router_device description. Each subnet is set by a separate subnet/subnet6 parameter. A router_device description can contain up to 16 different subnet parameters and up to 16 different subnet6 parameters. For example, the configuration below sets two IPv4 subnets for device 41-00.1 to be diverted to the bng-w TAP interface, and one IPv6 subnet plus the link-local address of the interface BIRD communicates with.
router_device {
device=41-00.1
tap=bng-w
peer=rib-w
subnet=10.0.2.0/30
subnet=8.8.8.0/29
subnet6=2001::1/124
subnet6=fe80::82d:cff:fe5f:9453/128
}
Where:
device— device name fromin_dev/out_dev.tap— TAP interface name for the device. Default —dpi+ device name.peer— name of the peer TAP interface in the netns. Default —rib+ device name.subnet— IPv4 subnet diverted to the TAP interface. There are two in the example:10.0.2.0/30and8.8.8.0/29.subnet6— IPv6 subnet diverted to the TAP interface. In the example,2001::1/124is an IPv6 subnet andfe80::82d:cff:fe5f:9453/128is the link-local address of the interface BIRD communicates with.
Each subnet is set by a separate subnet or subnet6 parameter.
subnet6 parameters.
OSPF uses the multicast addresses 224.0.0.5 and 224.0.0.6, so if OSPF is used on a router_device, these addresses must also be specified in the router_device description:
router_device {
device=41-00.1
tap=bng-w
peer=rib-w
# OSPF multicast
subnet=224.0.0.5/32
subnet=224.0.0.6/32
}
router_device must contain at least one IPv4 or IPv6 subnet.
Setting veth interface names
All TAP interfaces associated with devices are described in fastdpi.conf:
router_device {
device=
#tap=
#peer=
}
Where:
device— device name fromin_dev/out_dev. Mandatory parameter.tap— TAP interface name for the device. Optional parameter. Default —dpi+ device name.peer— name of the peer TAP interface in the netns. Optional parameter. Default —rib+ device name.
router_device section syntax rules:
- the opening brace
{must be on the same line as therouter_devicesection name; - the closing brace
}must be on a separate line.
For example, for this configuration:
in_dev=41-00.0 out_dev=41-00.1
where only out_dev is connected to the router, the description is:
in_dev=41-00.0
out_dev=41-00.1
router_device {
device=41-00.1
tap=bng-w
peer=rib-w
}
Where:
device=41-00.1— theout_devdevice connected to the router. In this example,in_devis not connected to the router, so norouter_devicesection is set for it.tap=bng-w— TAP interface name on the SSG side.peer=rib-w— peer interface name on the routing daemon side, in the netns.
You may omit the tap and peer names — the default names (‘dpi’/‘rib’ + device) are then used. However, we recommend always setting clear names explicitly, for example:
in_dev=41-00.0
out_dev=41-00.1
# TAP for out_dev:
router_device {
device=41-00.1
tap=bng-w
peer=rib-w
}
# TAP for in_dev
router_device {
device=41-00.0
tap=bng-l
peer=rib-l
}
Recommended TAP interface names (naming standard for all examples):
- for
in_dev(LAN, subscriber side): on the SSG side —bng-l, on the routing daemon side —rib-l; - for
out_dev(WAN, uplink): on the SSG side —bng-w, on the routing daemon side —rib-w.
Debugging and diagnostics
tcpdump by specifying the interface name. However, tcpdump does not work with interfaces in the DOWN state, so it cannot capture traffic at the moment an interface goes from DOWN to UP.
| Parameter | Description | Default | Type |
|---|---|---|---|
router_tap_pcap | pcap capture from TAP interfaces: all captures from all TAP interfaces; alternatively, list TAP interface names separated by ;. A separate pcap file named tap_<interface_name>_xxx.pcap is created for each TAP interface in the directory set by the ajb_udpi_path parameter (default /var/dump/dpi). | — | hot |
router_tap_pcap_dir | Capture direction: 1 — from TAP, 2 — to TAP, 0 or 3 — both | 0 | hot |
router_tap_pcap_rotate | TAP pcap rotation interval, seconds. 0 — taken from ajb_udpi_ftimeout | 0 | hot |
router_rtnl_pcap | Capture of rtnetlink messages to pcap: 1 — yes, 0 — no pcap file names start with the rtnl prefix. In addition, if pcap capture by address mask ( ajb_save_ip) is enabled, the router also writes the resulting packet after routing to pcap. As a result, pcap contains two records for each incoming packet: the original packet and the sent packet. | 0 | hot |
router_trace | Trace flags for router components Bit mask: 0x0001 — rtnetlink processing FSM state transitions (notifications from the routing daemon) 0x0002 — rtnetlink handler FSM events (notifications from the routing daemon) 0x0004 — rtnetlink data dump 0x0010 — RIB (Routing Information Base building) 0x0020 — routing table 0x0040 — FIB 0x0080 — ARP cache 0x0100 — TAP 0x0200 — TAP pcap 0x0400 — announcements | 0 | hot |
CLI commands
SSG provides a set of CLI commands for viewing the current router state. For the full list of commands, see
fdpi_cli help router
Also keep in mind that the routing table is built over BGP, OSPF, etc. by BIRD, which has its own command-line utility birdc and its own configuration file with an advanced command system for filtering, setting static routes, etc.
In addition, the standard Linux ip utility gives full control over the kernel route table. When using ip, remember to specify the correct netns (router_netns) and routing table number (router_kernel_table).
VRF parameters
VRF configuration
The router_netns and router_kernel_table settings define the default VRF and are used as defaults for the corresponding parameters when other VRFs are described.
When preparing fastDPI for router mode, the administrator must create the required netns and TAP interfaces for diverting traffic to the routing daemons. fastdpi.conf refers to netns and TAP interfaces that already exist; only in this case will SSG start.
Each VRF is set by a separate section in the router configuration:
Routing table (VRF) description
router_vrf {
id=
netns=
kernel_table=
neighbor_cache=
}
router_default_vrf=
id — string, unique VRF id. A VRF can be specified for a subscriber in a RADIUS authorization VSA — that is this id. Maximum length — 15 characters.
netns — name of the netns the VRF is read from. If not set, it equals the router_netns option. The peer TAP interfaces for this VRF are located in this netns.
kernel_table — kernel routing table number for this VRF. If not set, it equals the router_kernel_table option.
router_default_vrf — string, id of the default VRF. The default VRF is used for subscribers that have no vrf_id property.
neighbor_cache — string, name of the ARP cache for this VRF. By default, each VRF has its own ARP/Neighbor cache isolated from the others. If several VRFs must share one ARP/Neighbor cache, set the same neighbor_cache value in their descriptions.
Parameters for this VRF:
max_ip4_route_count — maximum number of IPv4 routes.
max_ip6_route_count — maximum number of IPv6 routes.
multipath_page — maximum number of pages for multi-path route distribution. One page holds 64 different multi-path routes. One page can hold routes of several ECMP groups. One group can span several pages (if the group has more than 64 routes and the routing daemon does not limit the number of routes)
fib_refresh — FIB update interval.
arp_cache_size — ARP cache size.
These parameters define the required memory and update frequency for this VRF. You can keep the defaults (taken from the global options) or override them.
- If the configuration has no
router_vrfsections, the previous operating mode is kept for backward compatibility: SSG has one VRF, which is the default one. - If the configuration has
router_vrfsections, VRF support mode is used. Exactly one VRF must be the default one, that is, therouter_default_vrf=idoption of the default VRF must be set.
bras_vrf_isolation — VRF isolation. By default, L2 BNG does not isolate subscribers from different VRFs; if this mode is enabled (1), subscribers from different VRFs are isolated from each other. Default: 0. When this option is enabled:
- subscriber ARP to the gateway — processed by fastDPI only if the subscriber and the gateway are in the same VRF
- gateway ICMP ping — processed by fastDPI only if the subscriber and the gateway are in the same VRF
- local interconnect — applied only if both subscribers are in the same VRF
bras_egress_filtering — filtering of outgoing subs→inet traffic (bit mask). Disabled by default (0). When this option is enabled, a packet is dropped if all of the following conditions are met:
- the subscriber IP address (srcIP) is unknown to L2 BNG
bras_term_by_as=0- the subscriber AS is not local
router_device description
The VRF id is added to the router_device description. Description of one router interface:
router_device {
device=
tap=
peer=
vrf=
subnet=
subnet=
subnet6=
subnet6=
}
device — device name from in_dev/out_dev.
tap — TAP interface name for the device (default — dpi + device name).
peer — name of the peer TAP interface in the VRF netns (default — rib + device name).
vrf — id of the VRF that contains the peer. If not set, the default VRF is used.
subnet and subnet6 — subnets diverted from the general traffic to the TAP device. At least one subnet or subnet6 parameter must be set for a router_device!
subnet — IPv4 subnets diverted from the general traffic to the TAP device.
subnet6 — IPv6 subnets diverted from the general traffic to the TAP device.
Each IPv4 and IPv6 subnet is specified separately in a subnet or subnet6 parameter, respectively. One router_device can have no more than 16 subnet parameters and 16 subnet6 parameters.
For example, this is not allowed: BGP1 from VRF1 — subnet 10.20.30.0/24, BGP2 from VRF2 — subnet 10.20.30.0/20 (the second subnet includes the first).
Each
router_device must have different tap and peer interfaces. For example, tap=dpi_ospf and peer=rib_ospf for the first one, tap=dpi_bgp and peer=rib_bgp for the second one.
Subscriber VRF management
The VRF ID is passed to fastDPI during authorization, in service 254.
VasExperts-Service-Profile = "254:VRF_ID"
Here VRF_ID is the VRF identifier from the id parameter of the router_vrf section.
For example, to place a subscriber in the vrf-iptv VRF from the full configuration example, the RADIUS response passes the attribute:
VasExperts-Service-Profile = "254:vrf-iptv"
If the attribute is not passed, the subscriber is placed in the default VRF (router_default_vrf). After authorization, the subscriber can be moved to another VRF via CoA with the same attribute.
Was this information helpful?