VRF Basics — Virtual Routing and Forwarding

Mental model

Default routers have one routing table (the global RIB). Every interface, every route, every routing-protocol neighbor lives in it. If two customers both use 10.0.0.0/24 internally, they can’t share that router — the routes would collide.

A VRF (Virtual Routing and Forwarding instance) gives the router multiple parallel routing tables, each completely isolated. Interfaces are bound to a specific VRF. Routes from one VRF aren’t visible to another. Two customers’ overlapping 10.0.0.0/24 can both exist on the same physical router — different VRFs, different tables.

                Physical Router
                ┌───────────────────┐
                │                   │
                │  global RIB       │  (management, traditional routes)
                │  ├─ default       │
                │  ├─ 10.255.0.0/16 │
                │                   │
                │  VRF CUSTOMER-A   │  (isolated)
                │  ├─ 10.0.0.0/24   │  ← these two 10.0.0.0/24 don't conflict
                │  └─ 192.168.1.0   │
                │                   │
                │  VRF CUSTOMER-B   │  (isolated)
                │  ├─ 10.0.0.0/24   │  ← same prefix in different VRF, fine
                │  └─ 172.16.5.0    │
                │                   │
                └───────────────────┘

Conceptually like Linux network namespaces, BSD jails, or virtual routers in a hypervisor — same idea applied to a physical router/switch.

Two flavors — VRF-lite vs MPLS L3VPN

	VRF-lite	MPLS L3VPN
Standalone or networked?	Single device or hop-by-hop across devices that each understand the VRF	Across a provider MPLS backbone
Scope	One organization, a few VRFs	Service provider, thousands of customers
Underlying transport	Plain IP routing	MPLS labels (covered in MPLS Basics)
Routing protocol between sites	Each VRF runs its own per-VRF instance	MP-BGP VPNv4 across PE routers
Complexity	Low — works on any L3 device	Higher — needs full MPLS knowledge
CCNA depth	Recognize and configure basic	Recognize concept

For CCNA, focus on VRF-lite — it’s testable and concrete. MPLS L3VPN is the more powerful big-brother version covered separately.

Use cases

1. Multi-tenant isolation

Two customers share one Layer-3 switch in your data center. You don’t want a misconfigured ACL on Customer A’s side to leak into Customer B’s. VRF gives you a hard wall.

2. Management plane separation

Production traffic in the global table. Management traffic (SSH to all your devices, SNMP, syslog, NTP, AAA, NetFlow) in a dedicated MGMT VRF. Even if production is broken, you can still reach devices via management — a different routing path entirely.

This is the most common enterprise VRF use case in 2026.

3. Overlapping IP space

Two acquired companies both use 192.168.1.0/24 internally. They join your network. You don’t want to renumber 5000 hosts. Put each in its own VRF, and translate between them only where they need to talk.

4. Lab / shared hardware

One physical switch hosts multiple lab environments. Each lab in its own VRF — they can’t accidentally route between each other.

5. PCI / compliance isolation

Card-data network must be isolated from corporate network. VRF + per-VRF firewalls = a hard policy boundary that auditors understand.

VRF-lite configuration

! 1. Create the VRF
R1(config)# vrf definition CUSTOMER-A
R1(config-vrf)# rd 65000:1
R1(config-vrf)# address-family ipv4
R1(config-vrf-af)# exit-address-family

R1(config)# vrf definition CUSTOMER-B
R1(config-vrf)# rd 65000:2
R1(config-vrf)# address-family ipv4
R1(config-vrf-af)# exit-address-family

! 2. Bind interfaces
R1(config)# interface Gi0/1
R1(config-if)# vrf forwarding CUSTOMER-A    ! puts this interface in VRF A
R1(config-if)# ip address 10.0.0.1 255.255.255.0

R1(config)# interface Gi0/2
R1(config-if)# vrf forwarding CUSTOMER-B    ! puts this interface in VRF B
R1(config-if)# ip address 10.0.0.1 255.255.255.0   ← same IP, different VRF — no conflict

! 3. Per-VRF routing
R1(config)# ip route vrf CUSTOMER-A 0.0.0.0 0.0.0.0 10.0.0.2
R1(config)# ip route vrf CUSTOMER-B 0.0.0.0 0.0.0.0 10.0.0.2

! 4. OSPF per VRF (if dynamic routing)
R1(config)# router ospf 100 vrf CUSTOMER-A
R1(config-router)# network 10.0.0.0 0.0.0.255 area 0

R1(config)# router ospf 200 vrf CUSTOMER-B
R1(config-router)# network 10.0.0.0 0.0.0.255 area 0

Two key things to note:

• vrf forwarding under the interface is what binds it to a VRF.
• Same IP address, different VRF, different gateway — both work simultaneously without conflict.

The RD — Route Distinguisher

Each VRF has an RD: an 8-byte identifier prepended to routes to make them globally unique. Format ASN:nn or IP:nn. Example: 65000:1.

In VRF-lite, the RD is only locally meaningful — it doesn’t actually appear in routing protocol messages between VRF-lite devices. But you still need to define it for the platform.

In MPLS L3VPN, the RD travels with the route in MP-BGP — 65000:1:10.0.0.0/24 is the actual NLRI advertised between PEs.

Verification

R1# show vrf
  Name                             Default RD            Protocols   Interfaces
  CUSTOMER-A                       65000:1               ipv4        Gi0/1
  CUSTOMER-B                       65000:2               ipv4        Gi0/2

R1# show ip route vrf CUSTOMER-A
R1# show ip route vrf CUSTOMER-B

R1# show ip interface brief
... global RIB only — VRF interfaces don't show ...

R1# show ip interface brief | section CUSTOMER-A    ! some IOS versions

R1# ping vrf CUSTOMER-A 10.0.0.2
R1# traceroute vrf CUSTOMER-A 10.0.0.2

R1# ssh -vrf CUSTOMER-A 10.0.0.2     ! SSH from inside a VRF

Commands that operate “globally” by default need a vrf keyword when you want them inside a specific VRF.

Inter-VRF route leaking

Sometimes two VRFs DO need to talk — usually one-way, e.g., the MGMT VRF needs to reach all production VRFs for monitoring.

In VRF-lite, this is done with static routes that explicitly cross the VRF boundary:

R1(config)# ip route vrf CUSTOMER-A 192.168.99.0 255.255.255.0 Gi0/3 10.99.99.1 global

The global keyword (or the trailing VRF name) tells the router: “this next-hop is in a different table.”

In MPLS L3VPN, route leaking is done via Route Target import/export — far more elegant, but requires MP-BGP.

VRF-aware services

When you put interfaces in a VRF, many services don’t automatically follow. You must tell them which VRF to use:

! AAA / RADIUS in MGMT VRF
R1(config)# aaa group server radius MGMT-RADIUS
R1(config-sg-radius)# server name ISE-PSN-1
R1(config-sg-radius)# ip vrf forwarding MGMT
R1(config-sg-radius)# ip radius source-interface Loopback0 vrf MGMT

! SSH from MGMT VRF
R1(config)# ip ssh source-interface Loopback0 vrf MGMT

! NTP in MGMT VRF
R1(config)# ntp server vrf MGMT 10.99.99.5

! Syslog in MGMT VRF
R1(config)# logging host 10.99.99.6 vrf MGMT

! DNS lookup in MGMT VRF
R1(config)# ip name-server vrf MGMT 10.99.99.7

! TACACS+ in MGMT VRF
R1(config)# tacacs-server host 10.99.99.8 vrf MGMT

Forgetting any of these means the service silently uses the global table. Common gotcha during VRF rollouts.

Common mistakes

1. Configuring an interface without vrf forwarding. It stays in the global table. Easy to do during a migration.

2. Pre-VRF IPs disappear. When you change vrf forwarding on an interface, all its previous IP addresses are wiped. Re-apply with the new VRF binding.

3. Routing protocol “address-family” confusion. Recent IOS versions require address-family ipv4 vrf X blocks inside the routing process. Older syntax router ospf 100 vrf X still works on many platforms.

4. Forgetting global keyword for leak routes. Without it, the route points at a next-hop that doesn’t exist in the source VRF.

5. Management services in wrong VRF. Configured radius-server globally but production interface is in VRF A → AAA never works.

6. Same OSPF process across multiple VRFs. Common to use router ospf 100 vrf A, router ospf 100 vrf B — actually creates separate process instances, despite the same number. Some platforms enforce different numbers. Check your platform’s syntax.

7. VRF count limits. A switch might support 8, 32, 256 VRFs depending on platform. Don’t overcommit.

8. Forgetting that a packet’s VRF context is determined by ingress interface. If a packet hits Gi0/1 (in VRF A), it gets looked up in VRF A’s RIB, period. You cannot mix VRF context within a packet’s path on the same router without explicit leaking.

VRFs vs PVLANs vs VLANs — when to use which

Need	Tool
Separate broadcast domains, separate IP subnets	VLAN
Same subnet, isolated L2 (hotels, MDU)	PVLAN (see Private VLANs)
Separate L3 routing tables, possibly overlapping IP	VRF
Per-tenant isolation across a provider backbone	MPLS L3VPN (VRF + MP-BGP + MPLS)
Mgmt plane separated from data plane	VRF for mgmt

VLAN, PVLAN, VRF are layered tools. You can use all three in the same network for different problems.

Lab to try tonight

1. One router, three interfaces. Create VRF CUSTOMER-A and VRF CUSTOMER-B (RDs 65000:1 and 65000:2).
2. Put Gi0/1 in VRF A (10.0.0.1/24), Gi0/2 in VRF B (10.0.0.1/24 — same IP). Connect a host to each.
3. From the router: ping vrf CUSTOMER-A 10.0.0.2 → reaches Host A. ping vrf CUSTOMER-B 10.0.0.2 → reaches Host B. Two same-IP hosts, no conflict.
4. From Host A, try to reach Host B’s IP. Won’t work — different VRFs.
5. Add a static route on the router to leak VRF A → VRF B for one specific destination. Verify connectivity now works.
6. Configure OSPF inside each VRF (different process numbers). Add a second router. Verify OSPF adjacency forms per-VRF.
7. Bonus: configure a MGMT VRF with a Loopback0. Move SSH, NTP, syslog, AAA to use that loopback / VRF. Verify production traffic doesn’t pollute MGMT and vice versa.
8. Bonus: try a real-world overlay — VRFs A and B both run RIPv2 or OSPF, but you need a “shared services” VRF that A and B both reach. Implement with leak routes.

Cheat strip

Concept	Plain English
VRF	Isolated routing table inside one router
VRF-lite	Standalone VRFs without MPLS — your CCNA-level focus
MPLS L3VPN	VRFs extended across a provider backbone via MP-BGP
vrf definition X	Create a VRF
rd X:Y	Route Distinguisher — required even if locally meaningful
vrf forwarding X	Bind an interface to VRF X (interface mode)
Per-VRF commands	show ip route vrf X, ping vrf X, ssh -vrf X, etc.
MGMT VRF	Most common enterprise use case — separate management plane
Overlapping IPs	Two VRFs can have the same subnet — no conflict
Inter-VRF leak	Use ip route vrf X ... global or route-target import/export
VRF-aware services	RADIUS, NTP, syslog, SSH, DNS — all need explicit VRF binding
Layered with VLAN / PVLAN	VLAN = L2 / PVLAN = L2 isolation in one subnet / VRF = L3 isolation