What is VRF-lite, and how does a campus carry separate per-zone routing tables across several routers without MPLS?
answer
- VRFs without labels
- the ingress interface picks the table
- one subinterface per VRF per link
- a routing instance per VRF
- zones times links
basics
~20 sVRF-lite is VRFs without MPLS or MP-BGP: each router keeps a routing table per zone, and every inter-router link carries one 802.1Q subinterface per VRF with its own routing adjacency, so the arriving interface tells each hop which table to use.
solid answer
~50 sA **VRF** is an independent routing and forwarding table on one router; each interface is bound to one VRF, and a packet is looked up only in the table of the interface it arrived on. **VRF-lite** is the industry's name, not an RFC's, for using VRFs **without MPLS labels or MP-BGP**. To stretch a zone across routers, each inter-router link is split into one `802.1Q` subinterface per VRF, each with its own transit subnet, and each VRF runs its own routing instance or session over its own subinterface. A packet arriving on the guest subinterface is looked up in the guest table, and it leaves on the guest subinterface towards the next router, so it never touches another zone's routes. Because the tables are independent, two zones may even reuse the same private prefix. The cost is configuration that grows as zones x links: five VRFs over six links means 30 subinterface pairs, 30 transit subnets and 30 adjacencies.
go deeper
Recall that a VRF is a separate routing table on one router and that the interface a packet arrives on picks the table.
Walk a packet across two routers: subinterface per VRF, transit subnet per VRF, routing instance per VRF. Show that overlapping private prefixes are fine in separate VRFs.
Compute the configuration growth as zones times links and explain how a single misbound subinterface either blackholes a zone or joins two of them.
Say when hop-by-hop VRFs stop paying off and a single control plane carrying all VRFs becomes worth its new protocols, and what that move does to the operations team.
## A VRF, precisely A **VRF** (virtual routing and forwarding instance) is a routing table, plus the forwarding table built from it, that lives beside others on the same router. RFC 7868 defines VRFs as "independent ... routing/forwarding tables that coexist within the same router at the same time". The term comes from RFC 4364, the BGP/MPLS IP VPN specification, whose section 3.1 states the rule every VRF design relies on: each attachment circuit is associated with a VRF, and when a packet arrives on it, "its destination IP address is looked up in the associated VRF". So the **ingress interface chooses the table**. Nothing inside the IP packet names a VRF. ```pseudocode on packet arriving at interface i: table = vrf_bound_to(i) # e.g. GUEST for the guest subinterface route = longest_match(table, packet.destination) if route is none: drop forward(packet, route.next_hop, route.out_interface) # route.out_interface belongs to the same VRF unless a leak was configured ``` ## What "lite" means **VRF-lite** is an industry term with no RFC of its own. It means VRFs used **without** the machinery RFC 4364 adds for a provider backbone: no MPLS labels, no route distinguishers or route targets, no MP-BGP carrying every VRF's routes over one session. Instead, each VRF is extended **hop by hop**, as if every zone had its own physical network. ## Carrying a zone across the campus Take a campus with four zones (`CORP`, `GUEST`, `IOT`, `PAY`) plus a `SHARED` VRF for DNS and DHCP, so five VRFs, and a distribution-core-distribution layout with six routed links between the campus routers. On every one of those links: 1. The physical link becomes an `802.1Q` trunk, and each VRF gets its **own subinterface** on its own VLAN ID (the tag mechanics belong to the Ethernet VLAN topic). 2. Each subinterface is bound to its VRF and given its own **transit subnet**, for example `10.255.1.0/31` for `GUEST` on link 1. 3. Each VRF runs its own **routing instance** over its own subinterface: an OSPF instance per VRF, or a BGP session per VRF, whichever the campus uses. A guest packet entering distribution router D1 on the guest access VLAN is looked up in D1's `GUEST` table, sent out on the `GUEST` subinterface towards the core, looked up there in the core's `GUEST` table because of the subinterface it arrived on, and so on. The VLAN ID on each link identifies the subinterface at the receiving end, and the subinterface identifies the VRF. ## What the separation buys - **Overlapping addresses.** RFC 4364 section 1.3 notes that VPNs with no sites in common may use overlapping address space, typically RFC 1918 space. In a campus, `GUEST` and `IOT` could both use `172.16.0.0/16` without conflict, as long as they never need to reach a common destination (the shared-services problem). - **Independent routing.** A flapping route in `IOT` is computed only in the `IOT` instance; it never appears in `CORP`. - **A default answer of "no route".** One zone reaches another only when someone adds a leak or a firewall path on purpose. ## What it costs The per-link, per-VRF construction multiplies: | Item | Formula | Five VRFs, six links | |---|---|---| | Subinterface pairs (one at each end of a link) | VRFs x links | 30 | | Transit subnets | VRFs x links | 30 | | Routing adjacencies or sessions | VRFs x links | 30 | | Routing instances on each router | VRFs it carries | up to 5 | Adding a sixth zone means touching every link in the campus. Adding a link means building five more adjacencies. That growth, plus the risk of one subinterface bound to the wrong VRF, is why VRF-lite suits a campus with a handful of zones and a modest number of routed links. ## Where it stops scaling - With many zones or many routers, operators move to a design that carries all VRFs over **one** control-plane session per router pair, such as an MPLS L3VPN or a BGP EVPN fabric; those are separate subjects. - With only a few zones, VRF-lite stays attractive precisely because it needs no new protocol: it is ordinary routing, repeated per VRF. In an interview, the core of the answer is the lookup rule (ingress interface selects the table), the hop-by-hop subinterface-and-adjacency construction, and the multiplication that makes it expensive to grow.
- Why can't the core router simply run one routing instance and tell the zones apart by source address?Because the zones may overlap: two VRFs can hold the same prefix, and a single routing table can hold only one route for it. VRF separation also has to survive any packet a host chooses to send, so the table must be selected by something the router controls, the ingress interface, not by a field the sender writes.
- Could two VRFs share one subinterface on a link instead of one each?Not in VRF-lite. An interface is bound to one VRF, and the receiving router uses the arriving interface to pick the table. Sharing would put both zones' packets in one table at the next hop. Carrying several VRFs over one interface needs a per-packet identifier, which is what MPLS labels or a VXLAN network identifier supply.
- What is the most common VRF-lite misconfiguration, and how does it show up?A subinterface or access-VLAN gateway bound to the wrong VRF, or the right VRF on one end and a different one on the other. Either the adjacency never forms and the zone is blackholed beyond that link, or, worse, two zones' tables join at that hop and traffic crosses between them with no filter in the path.
saying these in an interview costs you the question
- The router reads a VRF identifier carried inside each IP packet.
- VRF-lite needs route distinguishers to keep overlapping prefixes apart.
- One routing adjacency per link carries every VRF in VRF-lite.
- VRF-lite is a lightweight standard defined in its own RFC.
- Two VRFs on one router cannot both hold the same private prefix.