VRF (Virtual Routing and Forwarding instance) is a routing virtualization mechanism. VRF lets you create virtual routers on a single physical device with independent routing tables, interface lists and other parameters. This creates isolated virtual environments and guarantees that each VRF has independent settings and shares no parameters with other VRFs or the physical device. Communication between different VRFs is possible, but it is strictly local to the device, and a VRF on one router is in no way related to a VRF on another.

Each VRF is a separate VPN and does not overlap with other VRFs.

An example is separating traffic from an IPTV set-top box that is in the same L2 domain with the BNG as the CPE (Customer Premises Equipment — network equipment that provides user access to the ISP network). The IPTV set-top box gets access only to local resources, while the CPE gets internet access.

VRF may be called Virtual Routing Instance in Juniper and VRF in Cisco and MikroTik, but all of these are a routing virtualization mechanism with similar functions.

The Lite suffix means that SSG only separates routing tables but does not put the traffic of an individual VRF into a dedicated tunnel (MPLS, VXLAN). VRF Lite lets you isolate the provided services from each other and optimize routing when using different links.

VRF Lite in SSG is implemented with Soft-Router, which builds the RIB table and writes to/reads from it. SSG diverts traffic to the Linux kernel for the routing daemon. fastDPI builds the FIB table.

The routing daemon runs in an isolated space so that the operating system does not become a router. SSG sends all signaling to the router, the router builds the routing rules itself, and then SSG forwards and routes packets according to these rules.

SSG does not support L3VPN and MPLS, but special context routing can be configured if required. VRF Lite in SSG is a separate service 254 that may or may not be enabled for a subscriber. By default, a subscriber is placed in the default VRF specified in SSG. To learn how to assign a VRF to a subscriber via RADIUS, see Subscriber VRF management.

Routing in SSG can be performed by the FRR or BIRD routing daemons — a separate process that exchanges dynamic routing signaling protocols (BGP, OSPF). In the context of VRF Lite on the Linux architecture that SSG runs on, BIRD is a better fit. BIRD can handle route leaking between routing tables.

This section covers options with a single namespace and multiple routing tables, which suits the BIRD routing daemon better. There is also a concept with multiple namespaces and a single table, which is more typical for FRR.

GRT (Global routing table) in this diagram is a conventional name: it is the same kernel route table as the others in the diagram. The table was named this way for testing convenience and to complicate checks. It used its own routing rules from several routers; they can be multiple or have their own contexts.

All rules and filters are configured in the router (in this case, in BIRD). When BIRD starts while SSG is running and a BGP neighborship comes up, some incoming routes are placed in the Kernel_rt N table, others are placed in GRT and then leak to Kernel_rt 1 and Kernel_rt 2 according to the configured rules.

SSG describes the same N VRFs pointing to specific tables with routing rules. Each instance reads from its tables, and isolated FIBs are built from these tables.

SSG has its own ARP cache, which it builds from ARP replies. SSG can have several ARP tables, and several VRFs can share one table.

Due to isolation within SSG, the same subnet can be reachable via different hops and different routers and be routed differently. After the FIB is built and traffic starts flowing, the subscriber is authorized first and placed in the required VRF. The FIB can be updated after the subscriber has been authorized. A subscriber can be moved between VRFs dynamically after authorization using CoA.

Actions for traffic outgoing from the subscriber:

1. Find out which VRF the subscriber belongs to.
2. Find out where the packet is headed.
3. Find in the FIB which hop to terminate the packet to and terminate it. Applies only when a flow is created; after that, the nexthop is remembered for the flow.

Actions for incoming traffic:

1. Analyze dest.
2. Check the subscriber state.
3. Test packet origination.

For other subscriber groups, everything happens in the same isolated way according to the rules. Announcements are made from the VRF the subscriber is in.