VRF Explained: One Router, Many Routing Tables

A VLAN splits a network at Layer 2. A VRF splits it at Layer 3. Together they let one set of switches and routers carry several networks that cannot see each other, even when they use the same IP addresses. This article explains what a VRF is, why you would use one instead of a single routing table, how VRFs and VLANs work together, how to configure them on Cisco and Dell switches, and where VRFs stop helping.

VRF in two minutes

A normal router has one routing table. Every interface that has an IP address feeds into that one table, so every connected network can reach every other connected network unless something blocks it.

A VRF (Virtual Routing and Forwarding instance) gives the router extra, separate routing tables. You assign each Layer 3 interface (a routed port, a VLAN interface or a subinterface) to exactly one VRF. From then on:

• a packet that arrives on an interface in VRF A is looked up only in VRF A's table;

• routes learned in VRF A exist only in VRF A;

• VRF A and VRF B can use the same IP subnets without conflict, because they never share a table.

One physical box behaves like several independent routers. Nothing crosses between VRFs unless you deliberately configure it (route leaking, or a firewall that sits in both).

The terms you will meet throughout:

Why VRF? The problem with one routing table

Imagine one core switch serving three groups: corporate users, guest Wi-Fi, and an operational network of controllers and servers that must stay isolated. With normal routing, every VLAN interface on that switch lands in the same routing table. The switch knows a route to every subnet, so by default it will route a guest's packet straight into the operational network. Separation has to be added on top, and every option for adding it has a cost.

The usual alternatives, and where they fall short

What VRF changes

• Isolation by default instead of by exception. With ACLs, everything can talk and you block what should not. With VRFs, nothing can talk across VRFs and you allow what should. A missing line in a VRF design leaves a network unreachable, not exposed.

• Overlapping addresses. Two VRFs can both use 10.0.0.0/24. That matters after a merger, for multiple customers on one platform, or for lab networks that copy production addressing.

• Separate routing behaviour. Each VRF has its own default route, its own static routes and its own routing protocol instances. Guest traffic can follow a default route to an internet firewall while corporate traffic follows a different default route to the data centre, on the same switch.

• Less hardware. One pair of switches can carry networks that would otherwise need separate equipment.

VRF does not replace ACLs or firewalls. It changes the starting point: traffic between VRFs does not flow until you decide where and how it may cross, and that crossing point is usually a firewall (see the section on talking between VRFs).

How VRF works

A VRF is not a protocol. It is a way of dividing one device's routing and forwarding into several independent instances. Three things make it work.

1. Each VRF has its own tables

Each VRF holds its own routing table (RIB), built by the control plane from connected interfaces, static routes and routing protocols, and its own forwarding table (FIB), which the hardware uses to forward packets. ARP entries are also kept per VRF. Two VRFs can therefore hold the same prefix, pointing to different next hops, without any conflict.

2. Each Layer 3 interface belongs to exactly one VRF

You bind each Layer 3 interface to a VRF: a routed port, a VLAN interface (SVI), a subinterface, a loopback or a tunnel. An interface you do not bind stays in the default VRF. One interface cannot be in two VRFs at once; Dell's VRF-Lite guide for its N-Series states it plainly: "Each L3 interface can only belong to one unique VRF instance."

On most platforms, moving an interface into a VRF wipes its existing IP settings. Cisco NX-OS documents this: "When you make an interface a member of an existing VRF, Cisco NX-OS removes all Layer 3 configurations." On Cisco IOS and IOS XE, applying vrf forwarding to an interface removes its IP address, and the switch prints a message saying so. The practical rule on every platform: assign the VRF first, then configure the IP address.

3. The ingress interface decides the table

When a packet arrives on an interface, the device looks up the destination only in the table of that interface's VRF:

1. A packet arrives on VLAN 20, which belongs to VRF GUEST.

2. The switch looks up the destination in the GUEST table and nowhere else.

3. If the GUEST table has a route, the packet leaves through an interface that is also in GUEST.

4. If the GUEST table has no route, the packet is dropped, even if the default table or another VRF knows the destination. Cisco's Catalyst VRF-Lite guide: "If an incoming packet's destination address is not found in the vrf table, the packet is dropped."

Routing protocols run per VRF

Static routes, OSPF, BGP and other protocols are configured per VRF. An OSPF process in VRF CORP only forms neighbours over CORP interfaces and only installs routes into the CORP table. Two VRFs on the same switch can run completely different routing designs.

The device's own services must know which VRF to use

The switch itself also sends traffic: SSH, SNMP, NTP, syslog, TACACS+ or RADIUS, DNS. Each of these must be told which VRF to use, or it uses the default VRF. A management server reachable only through VRF MGMT will appear "down" to a service that is still looking in the default table. Cisco NX-OS states that every IP-based feature is VRF-aware, and lists AAA, DNS, HSRP, NTP, SNMP, syslog, SSH, TACACS+, TFTP and VRRP among them. Dell OS10 has per-service commands such as ip ssh server vrf, snmp-server vrf and ntp enable vrf.

How VRFs and VLANs work together

VLANs and VRFs solve the same problem at two different layers, and a real network almost always uses both.

The VLAN interface is where a VLAN meets a VRF

A VLAN on its own has no IP routing. Routing starts at the VLAN interface (an SVI, interface Vlan10 on Cisco, interface vlan 10 on Dell OS10), which is the default gateway for the hosts in that VLAN. When you put that VLAN interface in a VRF, every host in the VLAN effectively lives in that VRF:

• VLAN 10's SVI in VRF CORP means corporate PCs are routed only by the CORP table.

• VLAN 20's SVI in VRF GUEST means guest devices are routed only by the GUEST table.

• Several VLANs can share one VRF (for example VLANs 10, 11 and 12 all in CORP). One VLAN interface cannot belong to two VRFs.

Access switches stay simple

A Layer 2 access switch needs no VRF configuration at all. It places each port in a VLAN and trunks those VLANs up to the Layer 3 switch. The separation is carried on the wire by the 802.1Q tag and turned into a routing decision only at the VLAN interface.

Carrying VRFs between Layer 3 switches: transit VLANs

When two Layer 3 switches both route for the same VRFs, the link between them must keep the VRFs apart. In VRF-Lite this is done by giving each VRF its own transit VLAN (or subinterface) on the link, each with a small point-to-point subnet. In the diagram, VLANs 910, 920 and 930 all ride one trunk, but each one is a separate routed link inside its own VRF, with its own static routes or routing protocol adjacency. Adding a VRF later means adding another transit VLAN, another subnet and another adjacency on every link that must carry it.

Two rules that catch people out

• VRF separation is only as good as the VLAN separation under it. If a VLAN is accidentally trunked to the wrong place, or two VLANs are bridged, hosts can talk at Layer 2 without ever reaching a VRF. Prune trunks to the VLANs that belong there.

• A VLAN is not tied to a VRF across the whole network; the VLAN interface is. VLAN 20 could be in GUEST on one switch and in a different VRF on another. Keep a consistent VLAN-to-VRF plan and document it, or troubleshooting becomes guesswork.

VRF-Lite vs MPLS L3VPN vs EVPN

The VRF itself is the same idea everywhere. What changes is how a VRF is carried from one device to the next.

VRF-Lite

VRF-Lite is VRFs without MPLS. Every Layer 3 device in the path is configured with every VRF it must carry, and every link between two such devices carries each VRF separately, as a transit VLAN, a subinterface or a dedicated link. Each VRF runs its own static routes or its own routing protocol instance on every hop.

It needs no special protocols and works on most enterprise Layer 3 switches, which makes it the usual choice for a campus, a small data centre or a single site. The cost grows with the network: as the Wikipedia summary of VRF puts it, VRF-Lite "does not scale to the size required by global enterprises or large carriers" because of "the need to implement each VRF instance on every router, including intermediate routers."

MPLS L3VPN

In an MPLS Layer 3 VPN (RFC 4364), only the provider edge (PE) routers hold VRFs. The core routers forward MPLS labels and know nothing about the VRFs. PEs exchange each VRF's routes over MP-BGP, using two values:

• Route distinguisher (RD): an 8-byte value placed in front of each IPv4 prefix to form a 12-byte VPN-IPv4 address, so that the same 10.0.0.0/24 from two VRFs stays unique inside BGP. It only makes routes unique; it does not decide who receives them.

• Route target (RT): a BGP extended community. Each VRF exports its routes with one or more RTs and imports routes carrying the RTs it is configured for. RTs are what decide which VRFs see which routes, including deliberate sharing between VRFs.

EVPN (with VXLAN or MPLS)

In modern data centre fabrics, BGP EVPN does the same job for VXLAN. The leaf switches hold the VRFs (often called IP-VRFs or tenant VRFs) and the spines only forward. In the common symmetric IRB model, each VRF is carried across the fabric with its own Layer 3 VNI. Integrated routing and bridging for EVPN is described in RFC 9135. RD and RT are used in the same way as in MPLS L3VPN.

Which one fits

The rest of this article focuses on VRF-Lite, because it is where most enterprise networks start. The concepts carry over unchanged.

Common scenarios

Scenario 1: A management VRF

The most common VRF of all is the one many switches ship with. A management VRF puts the out-of-band management port in its own routing table, so management traffic (SSH, SNMP, syslog, NTP, software uploads) has its own default route and never mixes with production routing. A routing problem in production then cannot cut you off from the switch, and the production network cannot reach the management plane.

Platforms restrict this VRF:

• Cisco NX-OS: "Only the mgmt 0 interface can be in the management VRF", and "No routing protocols can run in the management VRF (static only)."

• Dell OS10: you create it with ip vrf management and add interface management inside it. Dell's article states that only management interfaces can be assigned to it, and warns to remove all settings, including the IP address, from the management interface before adding it.

Scenario 2: Separating user groups on one campus

A single pair of core switches serves corporate users, guest Wi-Fi, and an operational network (building systems, CCTV, industrial controllers). Each group gets a VRF. Guest has a default route only to the internet firewall. The operational VRF has no default route at all. Corporate routes to the data centre. The only place traffic may cross between them is a firewall, covered in the next section.

Scenario 3: Several tenants with overlapping addresses

A shared data centre or a managed service hosts several customers. Two of them use 10.1.1.0/24 with a gateway of 10.1.1.1. With one routing table that is impossible. With one VRF per tenant it is routine.

Scenario 4: A merger or acquisition

Two companies merge and both use 10.0.0.0/16. Re-addressing takes months. Putting each company's network in its own VRF lets both run on shared infrastructure immediately. Services both sides need (email, file shares, identity) are reached through a firewall that translates addresses (NAT) between the overlapping ranges, until one side is re-addressed.

Scenario 5: A lab or test network that copies production

A test environment can reuse production's exact addressing in its own VRF, so applications are tested with real IPs while the lab cannot accidentally route into production.

Scenario 6: Different internet or WAN paths per group

Because each VRF has its own default route, guest traffic can leave through a low-cost internet line and firewall while corporate traffic uses the WAN to head office, on the same switches, without policy-based routing.

Configuration steps

The examples below build the same small design on each platform: the distribution switch from the VLAN diagram, with two VRFs.

The order of steps is the same on every platform:

1. Create the VLANs (as you would without VRFs).

2. Create the VRFs.

3. On each Layer 3 interface: assign the VRF first, then the IP address.

4. Trunk the transit VLANs toward the next Layer 3 hop.

5. Add routing inside each VRF: static routes or a routing protocol instance per VRF.

6. Point management services (SSH, SNMP, NTP, syslog, AAA) at the right VRF.

7. Verify with the VRF named in every command.

Cisco IOS XE (Catalyst 9000)

! 1. VLANs
vlan 10,20,910,920
!
! 2. VRFs
vrf definition CORP
 address-family ipv4
 exit-address-family
!
vrf definition GUEST
 address-family ipv4
 exit-address-family
!
ip routing
!
! 3. VLAN interfaces: VRF first, then IP
interface Vlan10
 vrf forwarding CORP
 ip address 10.10.10.1 255.255.255.0
!
interface Vlan20
 vrf forwarding GUEST
 ip address 10.20.20.1 255.255.255.0
!
interface Vlan910
 vrf forwarding CORP
 ip address 10.255.10.1 255.255.255.252
!
interface Vlan920
 vrf forwarding GUEST
 ip address 10.255.20.1 255.255.255.252
!
! 4. Trunk carrying the transit VLANs to the core
interface TenGigabitEthernet1/1/1
 switchport mode trunk
 switchport trunk allowed vlan 910,920
!
! 5a. OSPF inside VRF CORP
router ospf 10 vrf CORP
 network 10.10.10.0 0.0.0.255 area 0
 network 10.255.10.0 0.0.0.3 area 0
!
! 5b. Static default route inside VRF GUEST
ip route vrf GUEST 0.0.0.0 0.0.0.0 10.255.20.2

Notes for IOS XE:

• vrf definition is the current, multi-protocol form and needs an address-family for each protocol you use (Cisco's guide marks it as required for IPv6). Older IOS configurations use ip vrf NAME and ip vrf forwarding NAME, which are IPv4-only.

• Applying vrf forwarding (or ip vrf forwarding) to an interface that already has an address removes the address, with a message such as % Interface FastEthernet0/0 IP address 192.168.1.254 removed due to enabling VRF Blue. Re-enter the address afterwards.

• An RD is not needed for VRF-Lite. You add rd and route-target only when BGP carries the VRF (MPLS L3VPN, EVPN, or BGP-based route leaking).

• When OSPF runs between a provider edge and a customer device in a VRF, Cisco's guide notes that the capability vrf-lite subcommand under router ospf should be used.

show ip route vrf CORP
show ip arp vrf CORP
show ip protocols vrf CORP
ping vrf CORP 10.255.10.2
ping vrf GUEST 10.255.20.2

Cisco NX-OS (Nexus)

feature interface-vlan
feature ospf
!
vlan 10,20,910,920
!
! VRFs (a static route lives inside the VRF context)
vrf context CORP
vrf context GUEST
  ip route 0.0.0.0/0 10.255.20.2
!
! OSPF instance for VRF CORP
router ospf 10
  vrf CORP
!
! VLAN interfaces: vrf member first, then IP
interface Vlan10
  no shutdown
  vrf member CORP
  ip address 10.10.10.1/24
  ip router ospf 10 area 0.0.0.0
!
interface Vlan20
  no shutdown
  vrf member GUEST
  ip address 10.20.20.1/24
!
interface Vlan910
  no shutdown
  vrf member CORP
  ip address 10.255.10.1/30
  ip router ospf 10 area 0.0.0.0
!
interface Vlan920
  no shutdown
  vrf member GUEST
  ip address 10.255.20.1/30
!
interface Ethernet1/49
  switchport mode trunk
  switchport trunk allowed vlan 910,920

Notes for NX-OS:

• vrf member removes all existing Layer 3 configuration from the interface. Cisco's guide: "You should configure all Layer 3 parameters after adding an interface to a VRF."

• If an interface is configured for a VRF that does not exist yet, "the interface is operationally down until you create the VRF."

• NX-OS always has two built-in VRFs: default and management (mgmt0 only, static routes only).

• routing-context vrf CORP sets the VRF for all following EXEC commands, so you do not have to type vrf CORP each time. routing-context vrf default returns to normal.

show vrf
show vrf CORP interface
show ip route vrf CORP
show ip ospf neighbors vrf CORP
ping 10.255.10.2 vrf CORP

Dell SmartFabric OS10

The commands below are taken from Dell's own OS10 articles and command mapping.

! Create the VRFs
ip vrf CORP
!
ip vrf GUEST
!
! Put a VLAN interface in a VRF: VRF first, then IP
interface vlan10
 ip vrf forwarding CORP
 ip address 10.10.10.1/24
 no shutdown
!
interface vlan20
 ip vrf forwarding GUEST
 ip address 10.20.20.1/24
 no shutdown
!
! Management VRF (only the management interface can join it)
ip vrf management
 interface management

Notes for OS10:

• Dell warns to remove all existing settings, including the IP address, from an interface before adding it to the management VRF. Apply the same order to data interfaces: VRF first, then the address.

• OS10 supports a management VRF, the default VRF and, per Dell's article, up to 512 non-default VRFs. Check the limit for your switch model and release.

• Management services take a VRF argument, for example ip ssh server vrf, snmp-server ... vrf, ntp enable vrf, radius-server vrf and ip http vrf.

• Route leaking between VRFs uses route targets inside the VRF: ip route-import and ip route-export.

• Static routes and OSPF or BGP inside a non-default VRF are documented in the OS10 User Guide topics "Configure a static route for a non-default VRF instance" and "VRF configuration". Use the guide for your exact release; the syntax is not repeated here because it could not be checked against Dell's published text for this article.

show ip vrf CORP
show ip vrf GUEST
show ip vrf management

Verification habits that save time

• Always name the VRF. show ip route without a VRF shows the default table. Many "missing route" problems are a forgotten vrf keyword.

• Ping with the VRF and a source. A ping from the default VRF to a host in a VRF fails even when everything is correct.

• Check interface membership first. show vrf CORP interface on NX-OS, or show ip vrf CORP on OS10, tells you whether an interface is in the VRF you think it is in.

• Check ARP per VRF when a gateway does not answer: ARP entries are kept separately for each VRF.

Talking between VRFs

Isolation is the point of a VRF, but almost every network needs some traffic to cross: users reach shared DNS and DHCP, an operations team reaches the controllers it manages, guests reach the internet. There are three ways to let traffic cross, and they are not equal.

Option 1: A firewall between the VRFs (recommended for security boundaries)

Each VRF gets its own link to a firewall: a transit VLAN or subinterface per VRF. Each VRF's default route (or the specific routes it needs) points at the firewall. The switch itself leaks nothing, so the only path between VRFs runs through the firewall, where rules decide what may cross and every connection can be logged.

This is the cleanest design when the VRFs represent different trust levels. The cost is that all inter-VRF traffic is limited by the firewall's throughput, and the firewall becomes a critical device that needs its own redundancy.

Option 2: Route leaking on the switch

Route leaking copies selected routes from one VRF's table into another, so the switch routes between them directly at hardware speed with no firewall in the path. Two common methods:

• Static route leaking: a static route in VRF A whose next hop or exit interface is in VRF B. Simple, but each leaked prefix is a manual entry, and the return route must be leaked too.

• BGP route-target import and export: each VRF exports its routes with a route target, and the other VRF imports that route target, optionally filtered by a route-map so only chosen prefixes cross. On Cisco NX-OS this happens inside the BGP process: Cisco's route-leaking guide states that leaking between VRFs is done at the BGP process level, so routes must be in BGP (redistributed if needed) before they can be leaked. Dell OS10 uses ip route-import and ip route-export route targets inside the VRF.

Cisco also documents some rules for NX-OS leaking: a route must be leaked directly from its source VRF (a route that was itself leaked from another VRF cannot be leaked again), and with BGP-based leaking, route changes can take a few minutes to appear in the destination VRF.

Route leaking is right for trusted shared services where a firewall adds nothing but cost. It is the wrong tool for a security boundary: once a route is leaked, the switch routes everything to that prefix unless an ACL stops it, which brings back the "open by default" problem VRFs were meant to solve. Filter leaks to the exact prefixes needed, in both directions.

Option 3: A shared services VRF

A common pattern combines the two ideas: put DNS, DHCP, directory and NTP servers in a SHARED VRF. Each user VRF imports only the shared services prefixes, and the SHARED VRF imports only the user subnets it must answer. User VRFs still cannot reach each other, because no routes are leaked between them directly.

When addresses overlap

Route leaking only works when the prefixes are unique. If two VRFs both use 10.1.1.0/24, the shared services VRF cannot hold a return route to both. The answer is NAT: translate one or both ranges as traffic crosses, usually on a VRF-aware firewall or router.

Do not forget the infrastructure services

• DHCP: a VLAN interface in a VRF relays DHCP requests using that VRF's routing table. If the DHCP server sits in another VRF, the relay must be able to reach it, either through a leaked route or with a VRF-aware relay option. Check what your platform supports.

• Management services on the switch itself: SSH, SNMP, NTP, syslog and AAA servers must be configured with the VRF they are reached through.

Limitations and gotchas

VRFs are simple in principle and easy to get subtly wrong in practice. These are the limits to plan for.

None of these is a reason to avoid VRFs. They are reasons to design them deliberately: few VRFs with clear purposes, a firewall at the trust boundaries, and a written plan for which VLAN lives in which VRF on which switch.

Design checklist

Before you build

• Each VRF has a clear purpose (a trust level, a tenant, a function); no VRF exists "just in case"

• VRF names agreed and used identically on every device

• Written plan: which VLANs belong to which VRF, on which switches

• Platform VRF limit, route table (TCAM) capacity and licence checked for every Layer 3 device in the path

• VRF-Lite vs MPLS or EVPN decided based on the number of VRFs and hops

• Inter-VRF policy decided: firewall for trust boundaries, filtered leaking only for trusted shared services

• Overlapping address ranges identified, and NAT planned where they must reach shared services

• Management VRF used for out-of-band management

While you build

• VRF assigned to each interface before its IP address

• Transit VLANs pruned so each trunk carries only the VLANs it needs

• Routing configured per VRF (static or a protocol instance per VRF)

• SSH, SNMP, NTP, syslog, AAA and DHCP relay pointed at the correct VRF

• Migrations of live interfaces done in a change window, with the full interface configuration prepared

Before you sign off

• Every VRF's routing table checked with the VRF named in the command

• Pings from each VRF to its gateway, its upstream and its shared services succeed

• Pings between VRFs that must not talk fail

• Firewall or leak policy tested in both directions

• Monitoring and configuration backup tools reach the switch through the right VRF

• VLAN-to-VRF documentation updated

References

Cisco

• IP Routing Configuration Guide, Cisco IOS XE 17.9 (Catalyst 9400): Configuring VRF-lite

• Cisco Nexus 9000 NX-OS Unicast Routing Configuration Guide 9.x: Configuring Layer 3 Virtualization

• Configure VRF Route Leak on Nexus (Cisco, French-language edition)

• MPLS Multi-VRF (VRF-Lite), Cisco IOS 15.2S

• Why interface IP is removed after applying ip vrf forwarding (Cisco Community)

• VRF Lite Configuration on Cisco IOS (NetworkLessons)

Dell

• Dell EMC Networking OS10: How to Configure Out Of Band Management

• Dell SmartFabric OS10: OS9-to-OS10 Command Mapping, Virtual Routing and Forwarding

• Dell Networking OS10: Introduction to GRE Configuration

• Dell SmartFabric OS10 User Guide 10.5.4: VRF configuration

• Dell SmartFabric OS10 User Guide 10.5.0: Configure a static route for a non-default VRF instance

• VRF lite for Dell Networking N-Series (Deployment and Configuration Guide)

Standards and background

• RFC 4364: BGP/MPLS IP Virtual Private Networks

• RFC 9135: Integrated Routing and Bridging in EVPN

• Virtual routing and forwarding (Wikipedia)

• Route distinguisher (Wikipedia)

Command syntax and limits change between platforms and releases. Check the configuration guide for your exact switch model and software version before deploying.