VRF

Why it exists

A router has one routing table, and a routing table can hold one route per prefix. Two tenants both using 10.0.0.0/8 cannot both be in it, and since RFC 1918 space is what everyone uses, that collision arrives with every acquisition and every partner connection. RFC 1918 §3Private Address SpaceRFC 1918 · BEST CURRENT PRACTICE · February 1996

A VRF is a second routing and forwarding table on the same device. Overlapping prefixes coexist because they are never compared, and traffic cannot cross between tenants because there is no route that could carry it. RFC 4364 §4.1The VPN-IPv4 Address FamilyRFC 4364 · PROPOSED STANDARD · February 2006

It is the same mechanism MPLS L3VPN uses at scale. VRF-lite is a VRF without the MPLS transport — the separation is local to the device and carried between devices by a tag, a subinterface or a tunnel instead.

One router, two routing tables that cannot see each other

Two tenants both use 10.0.0.0/8. Without VRFs one of them has to renumber; with them, neither does.

How it works

Interfaces are bound to a VRF, and the interface a packet arrives on selects the table used to forward it. Nothing in the packet says which VRF it belongs to; the binding is the whole mechanism.

Where tables need to share something, route targets do it selectively. A VRF exports its routes with a target and imports the targets it wants, and because import and export are separate lists the relationship can be asymmetric — which is how shared services and hub-and-spoke are both expressed. RFC 4364 §4.3.1The Route Target AttributeRFC 4364 · PROPOSED STANDARD · February 2006

Route targets control which routes are imported. They do not control which packets may be forwarded — a VRF that has imported both tenants can route between them, and stopping that needs a filter where the forwarding happens.

On the wire

Constructed examples, encoded from the field table below them — not captured traffic.

Configure it

When it breaks

Symptom first, because that is what you have when it happens.

1. An interface is put into a VRF and stops working, and its running configuration has no IP address.

   Narrow it down

   1. Compare the configuration before and after the VRF assignment.
   2. Check whether the address line is simply absent rather than wrong.
   3. Look for a warning in the session scrollback, which some platforms emit and some do not.

   Cause

   Assigning a VRF removes the address, because the address belonged to a table the interface has left and may collide in the one it is joining.

   Fix

   Re-apply the address after the assignment. In a change script, always order it that way.

2. A destination is unreachable from the router and reachable from a host on the same segment.

   Narrow it down

   1. Check whether the command named the VRF.
   2. Run the same command with the VRF specified and compare.
   3. Confirm which table the source address belongs to.

   Cause

   The command used the global table. `ping` without a VRF sources from global, finds no route, and reports unreachable — which reads as a network fault rather than a missing keyword.

   Fix

   Name the VRF in every diagnostic. It is the single most common VRF support ticket and it is never a network problem.

3. Two tenants that must not reach each other can, and the route targets appear correct.

   Narrow it down

   1. Check what the shared-services VRF has imported.
   2. Trace whether traffic between tenants transits it.
   3. Look for a filter on the shared VRF — its absence is usually the answer.

   Cause

   The shared VRF imported both tenants, so it holds routes to both and will forward between them. Route targets decided what it learned, not what it may carry.

   Fix

   Filter at the shared VRF, or use a design where the servers never initiate and the tenants never transit.

   RFC 4364 §4.3.1The Route Target AttributeRFC 4364 · PROPOSED STANDARD · February 2006

4. A routing protocol is configured and forms no adjacency on interfaces that are in a VRF.

   Narrow it down

   1. Check whether the protocol instance was configured under the VRF or globally.
   2. Confirm the interface is in the VRF the protocol instance names.
   3. Look at whether the platform requires a separate process per VRF.

   Cause

   The protocol is running in the global table and the interfaces are not. Some platforms need an address family per VRF; others need a separate process entirely.

   Fix

   Configure the protocol under the VRF. The interface binding does not move a globally configured protocol along with it.

5. Two VRFs both advertise 10.0.0.0/8 into BGP and one prefix vanishes or overwrites the other at a PE.

   Narrow it down

   1. Compare the route distinguishers configured on each VRF.
   2. Confirm the routes appear as distinct VPN-IPv4 NLRIs, not as plain IPv4.
   3. Check whether import is filtering by route target rather than by RD.

   Cause

   Identical RDs on overlapping prefixes collapse them into one BGP path. The RD’s job is uniqueness inside BGP, not import selection — that is the route target.

   Fix

   Give every VRF a unique RD. Keep import policy on route targets; never treat the RD as a security boundary.

   RFC 4364 §4.1The VPN-IPv4 Address FamilyRFC 4364 · PROPOSED STANDARD · February 2006

Design notes

Assign the VRF before the address, always. Moving an interface into a VRF removes its address on most platforms, and re-applying afterwards is one command against a change window spent looking for a routing fault that is not there.

Name VRFs for the tenant, not the technology. `CUSTOMER-A` survives a migration from VRF-lite to MPLS; `VRF1` tells nobody anything and is what every device ends up with.

A shared-services VRF is a transit risk by construction. It holds routes to everything that imports from it, and the import policy that made that convenient will not stop it forwarding between them. Put an access list on it or make the servers non-initiating.

Budget for the operational cost. Every diagnostic command needs the VRF named, monitoring has to be VRF-aware, and a management session sourced from the wrong table fails in a way that looks like the network. This is the reason not to use VRFs where a subnet would do.

Misconceptions

“A VRF is a VLAN for layer 3.”

A VLAN separates a broadcast domain; a VRF separates a routing table. They solve different problems at different layers and are routinely used together — a VLAN per tenant segment, a VRF holding the routes for all of that tenant’s segments.

“VRFs require MPLS.”

MPLS L3VPN uses VRFs and VRFs do not require it. VRF-lite carries the separation between devices with a tagged subinterface or a tunnel instead, which is how most enterprise deployments work.

“Route targets enforce isolation.”

They control which routes a table imports. Once a VRF holds routes to two tenants it can forward between them, and the import policy has nothing to say about that. Isolation between tenants sharing a VRF is a filtering problem. RFC 4364 §4.3.1The Route Target AttributeRFC 4364 · PROPOSED STANDARD · February 2006

“The route distinguisher decides which VRF a route lands in.”

It makes overlapping prefixes unique inside BGP so two tenants can both advertise 10.0.0.0/8. Import is decided entirely by the route target. This is the single most confused pair in the technology. RFC 4364 §4.1The VPN-IPv4 Address FamilyRFC 4364 · PROPOSED STANDARD · February 2006

More walkthroughs

Terms

VRF

A separate routing and forwarding table on one device. Interfaces are bound to it, and the interface a packet arrives on selects the table — nothing in the packet does.

Route leaking

Importing specific routes from one VRF into another without merging the tables. Import and export lists are separate, so the relationship can be one-way — which is how shared services and hub-and-spoke are both built.

VRF-lite

VRFs without MPLS. The table separation is identical; what differs is that separation is carried between devices by a tagged subinterface or a tunnel rather than by a label.

Check yourself

• What selects which routing table a router uses for an arriving packet?

  • A field in the IP header
  • The interface the packet arrived on
  • The destination prefix
  • The route distinguisher
• Two tenants both use 10.0.0.0/8 on one router. How do VRFs make that work?

  • They renumber one tenant automatically
  • The prefixes live in separate tables and are never compared
  • The longer prefix wins
  • NAT is applied
• Two tenant VRFs both import a shared-services VRF. Can the tenants reach each other?

  • No — route targets prevent it
  • Yes, if the shared VRF forwards between them; route targets control import, not forwarding
  • Only if they import each other’s targets
  • Only over MPLS
• You assign an interface to a VRF and it stops working. What happened?

  • The interface was shut down
  • Its IP address was removed, because the address belonged to the table it just left
  • The VRF name was wrong
  • Spanning tree blocked the port
• What distinguishes VRF-lite from MPLS L3VPN?

  • VRF-lite supports fewer routes
  • VRF-lite carries the separation between devices with tagged subinterfaces or tunnels rather than MPLS
  • VRF-lite has no route targets
  • They are the same thing
• What does the route distinguisher decide?

  • Which VRF imports a route
  • How overlapping prefixes stay unique inside BGP — import is decided by the route target
  • Which interface a packet arrives on
  • The MPLS label pushed on the data plane
• A host on a VRF segment can reach a destination, but ping from the router reports unreachable. What usually happened?

  • The VRF has no default route
  • The diagnostic used the global table because the VRF was not named
  • ICMP is blocked in the VRF
  • The interface lost its address again
• OSPF is configured globally and the interfaces are in a VRF. Why is there no adjacency?

  • OSPF cannot run inside a VRF
  • The protocol instance is still in the global table — interface binding does not move it
  • Hello packets need an MPLS label
  • The VRF name must match the process ID

Related

• L3VPN

  VPN-IPv4 is an RD plus a prefix; import is a Route Target. They are unrelated — and the data plane needs a transport label as well as a VPN label.

• Subnetting

  Divides an address space by moving a boundary through the bits, and decides which route wins by how many of those bits a prefix pins down.

• Redistribution

  Moves routes from one protocol into another, discarding the metric and the loop prevention that made them trustworthy.