Theoretical foundations and architecture

Virtual Routing and Forwarding (VRF) virtualizes a single physical routing platform into multiple independent logical routers. Each VRF maintains a segregated Routing Information Base (RIB), Forwarding Information Base (FIB), and dedicated interface bindings. This provides the architectural foundation for multi-tenancy: fully supporting disparate customers with identical, overlapping RFC 1918 private IP address spaces. For instance, Customer A and Customer B can both utilize 192.168.1.0/24 internally without IP collision. The PE binds Customer A's physical port to VRF A and Customer B's port to VRF B. When a packet arrives, the PE identifies the context by ingress interface membership (packets arriving from the MPLS core are mapped to a VRF by their VPN label) and performs the FIB lookup in that tenant's VRF. Routes of different VRFs and of the global table stay separate unless an explicit policy (route targets, route leaking) allows exchange; this is logical routing isolation, not a firewall or encryption.

What a VRF really is

A VRF is not a separate process or a virtual machine. It is a set of four objects inside one router: its own routing table (RIB), its own forwarding table (FIB/CEF), a list of member interfaces and, if needed, its own PE-CE protocol instances (BGP address-family, an OSPF process, static routes). The forwarding context is selected only by the ingress interface (or subinterface/VLAN): a packet that arrives on Gi2 is looked up in the FIB of the VRF that owns Gi2 and nowhere else. The global core table (IGP + LDP) remains a separate context: an interface placed in a VRF stops being a member of the global table, which is why ping 172.16.1.2 without a VRF does not work.

Overlapping addresses: where exactly they "live"

Customers A and B can use the same link 172.16.1.0/30 and the same LAN 192.168.10.0/24. On the PE this is safe because two routes with the same prefix sit in different RIBs. The problem appears only when leaving towards the core: MP-BGP carries routes in one shared table, where two identical IPv4 prefixes would be the same NLRI and the best path would overwrite the second one. The solution is the Route Distinguisher: 8 bytes of RD are prepended to the IPv4 prefix, producing a 12-byte VPN-IPv4 address (VPNv4 NLRI; the prefix length is counted as 64 + the IPv4 prefix length). RD 65000:1 + 192.168.10.0/24 and RD 65000:3 + 192.168.10.0/24 are two different NLRIs, both survive on the BGP RR and do not compete in best-path selection.

There are three RD types: type 0 (2-byte ASN : 4-byte number), type 1 (IPv4 address : 2-byte number), type 2 (4-byte ASN : 2-byte number). The RD does not define the import/export policy - the Route Target does that (next lesson). Practical rule: make the RD unique per (VRF, PE); then the RR sees the route of one customer from two PEs as two different NLRIs and can advertise both to all PEs for multipath and fast convergence.

Labels: what a VRF hides in the data plane

For every exported route the PE allocates a VPN label (20 bits) and carries it in MP_REACH_NLRI together with the VPNv4 NLRI. There are three allocation modes:

  • per-prefix (per-route): one label per prefix. The egress PE learns the next hop and interface straight from the label, so no extra IP lookup is needed. The drawback is label consumption on large tables (on Cisco this is the default mode, on Huawei per-route is the default).
  • per-VRF: one label for the whole VRF. Labels are saved, but after popping the label the egress PE has to perform an IP lookup in the FIB of that VRF (Cisco: mpls label mode vrf A protocol bgp-vpnv4 per-vrf, Huawei: apply-label per-instance, Junos: vrf-table-label).
  • per-next-hop (per-CE): one label per (VRF, CE next hop) pair; this is how Junos works by default without vrf-table-label. It is a compromise between the number of labels and forwarding speed.

A side effect of per-VRF: the egress PE performs a lookup on the destination IP, which makes it possible to apply VRF filters and uRPF, but on older platforms it requires recirculation (Junos: a vt- tunnel interface or a virtual loopback).

Packet path A1 -> A2 across two overlapping VRFs

  1. The packet from CE-A1 arrives on Gi2; the interface belongs to VRF A, so the lookup goes to FIB A.
  2. A BGP route from PE2 is found (RD 65000:2, VPN label 24 + next hop 10.255.0.2). The transport label towards 10.255.0.2 is taken from the global LFIB (LDP).
  3. The ingress PE pushes the stack [LDP label, VPN label]; P1 performs swap/PHP on the outer label without looking at the customer IP.
  4. The egress PE uses the VPN label to identify VRF A (or a specific next hop) and hands the packet to CE-A2. For B the same IP packet arrives with a different VPN label and lands in a different VRF.