{{indexmenu_n>3}}
====== 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.

<code>
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
}
</code>

Where:

  * ''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 netns. Default — ''rib'' + device name.
  * ''subnet'' — IPv4 subnet diverted to the TAP interface. There are two in the example: ''10.0.2.0/30'' and ''8.8.8.0/29''.
  * ''subnet6'' — IPv6 subnet diverted to the TAP interface. In the example, ''2001::1/124'' is an IPv6 subnet and ''fe80::82d:cff:fe5f:9453/128'' is the link-local address of the interface BIRD communicates with.

Each subnet is set by a separate ''subnet'' or ''subnet6'' parameter.

<note important>If you use IPv6, keep in mind that link-local addresses play an important role in IPv6 and must also be specified in ''subnet6'' parameters.</note>

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:

<code>
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
}
</code>

<note warning>A ''router_device'' must contain at least one IPv4 or IPv6 subnet.</note>

===== Setting veth interface names =====

All TAP interfaces associated with devices are described in ''fastdpi.conf'':

<code>
router_device {
    device=
    #tap=
    #peer=
}
</code>

Where:

  * ''device'' — device name from ''in_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 the ''router_device'' section name;
  * the closing brace ''}'' must be on a separate line.

For example, for this configuration:

<code>
in_dev=41-00.0
out_dev=41-00.1
</code>

where only ''out_dev'' is connected to the router, the description is:

<code>
in_dev=41-00.0
out_dev=41-00.1

router_device {
    device=41-00.1
    tap=bng-w
    peer=rib-w
}
</code>

Where:

  * ''device=41-00.1'' — the ''out_dev'' device connected to the router. In this example, ''in_dev'' is not connected to the router, so no ''router_device'' section 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:

<code>
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
}
</code>

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 =====

<note>You can also capture TAP interface traffic with ''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.</note>

^ 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

<code>
fdpi_cli help router
</code>

<note>RIB and FIB dump commands output a lot of data, because these structures may contain hundreds of thousands of entries with a BGP full view. We recommend redirecting the output of these commands to a file.</note>

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 ===

<code>
router_vrf {
      id=
      netns=
      kernel_table=
      neighbor_cache=
}
</code>

<code>
router_default_vrf=
</code>

''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_vrf'' sections, the previous operating mode is kept for backward compatibility: SSG has one VRF, which is the default one.
  * If the configuration **has** ''router_vrf'' sections, VRF support mode is used. Exactly one VRF must be the default one, that is, the ''router_default_vrf=id'' option 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:

<code>
router_device {
      device=
      tap=
      peer=
      vrf=
      subnet=
      subnet=
      subnet6=
      subnet6=
}
</code>

''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.

<note important>Subnets for one port must not overlap.\\
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.</note>

=== 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 [[dpi:dpi_components:softrouter:config#full_router_setup_fastdpiconf_birdnetnsconf_bng_routersh|full configuration example]], the RADIUS response passes the attribute:

<code>
VasExperts-Service-Profile = "254:vrf-iptv"
</code>

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.