One router, multiple routing tables. That is the entire idea behind VRF (Virtual Routing and Forwarding), and it is the foundation of everything from enterprise network segmentation to service provider L3VPNs. VRF-Lite is the version without MPLS: no label switching, no MP-BGP, just isolated routing tables on a box, each owning its own interfaces. It is how you keep a guest network, an OT network, and a corporate network on the same physical router without any of them seeing each other's routes. This guide configures VRF-Lite on Cisco IOS XE with two VRFs, proves the isolation, and then punches a deliberate, controlled hole between them with static route leaking. It is part of the IP Routing cluster, and it is the conceptual on-ramp to MPLS L3VPN.
What a VRF Actually Is
A VRF is a separate RIB and FIB inside one router, plus a membership list of interfaces. A packet arriving on an interface assigned to VRF RED is looked up in RED's table and only RED's table. Prefixes can overlap freely between VRFs (two customers can both use 10.0.0.0/24), because the tables never meet. The global routing table, the one you have used your whole career, is just the default table that interfaces belong to until you say otherwise.
VRF-Lite specifically means using VRFs hop by hop without MPLS: if the segmentation must span multiple routers, each inter-router link needs a separate subinterface (or VLAN) per VRF. That scales poorly beyond a few boxes, which is precisely the problem MPLS L3VPN solves with labels; the VRF construct itself is identical in both worlds.
The Lab
R1 carries the global table (OSPF toward the rest of the lab, plus the management LAN 192.168.99.0/24 where our Linux VM lives) and two VRFs: RED and BLUE. Each VRF owns a dot1q subinterface toward the VM's segment and a loopback simulating an internal network:
R1(config)# vrf definition RED
R1(config-vrf)# rd 100:1
R1(config-vrf)# address-family ipv4
R1(config-vrf-af)# exit
R1(config-vrf)# exit
R1(config)# vrf definition BLUE
R1(config-vrf)# rd 100:2
R1(config-vrf)# address-family ipv4Two syntax notes that bite people. Modern IOS XE uses vrf definition plus an explicit address-family ipv4; the older ip vrf form is IPv4-only legacy, and configs mixing the two get messy. The route distinguisher (rd) is mandatory before the VRF will accept interfaces; in pure VRF-Lite it is just a local identifier and never leaves the box, but the parser demands it (it becomes meaningful when you graduate to MP-BGP).
Now assign interfaces. Order matters: vrf forwarding strips any IP address already on the interface, so set membership first, address second:
R1(config)# interface Ethernet0/0.10
R1(config-subif)# encapsulation dot1Q 10
R1(config-subif)# vrf forwarding RED
R1(config-subif)# ip address 10.10.10.1 255.255.255.0
!
R1(config)# interface Loopback10
R1(config-if)# vrf forwarding RED
R1(config-if)# ip address 10.10.99.1 255.255.255.0BLUE mirrors it: Ethernet0/0.20 with dot1q 20 and 10.20.20.1/24, Loopback20 with 10.20.99.1/24.
Verification: Separate Tables, Really Separate
show vrf is the inventory view (which VRFs exist, which interfaces they own):
R1# show vrf
Name Default RD Protocols Interfaces
BLUE 100:2 ipv4 Lo20
Et0/0.20
RED 100:1 ipv4 Lo10
Et0/0.10Every familiar command grows a VRF-aware form. The RED routing table contains exactly RED's world and nothing else:
R1# show ip route vrf RED | begin Gateway
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.10.0/24 is directly connected, Ethernet0/0.10
L 10.10.10.1/32 is directly connected, Ethernet0/0.10
C 10.10.99.0/24 is directly connected, Loopback10
L 10.10.99.1/32 is directly connected, Loopback10No OSPF routes, no management LAN, no BLUE prefixes. And the isolation is enforced in forwarding, not just display. Pinging BLUE's loopback from inside RED fails, because RED's table has no route to it:
R1# ping vrf RED 10.20.99.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.99.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)Same router, both addresses locally configured, zero reachability. That is the segmentation guarantee.
Route Leaking: Controlled Holes in the Wall
Pure isolation is rarely the whole requirement; usually some shared service (management, DNS, a jump host) must reach into the VRFs. In VRF-Lite the tool is static routes with an explicit table crossing, one route per direction. Our shared segment is the management LAN in the global table; we leak each VRF loopback into global, and the management subnet into each VRF:
! Global table -> VRF: point the prefix at the VRF interface
ip route 10.10.99.0 255.255.255.0 Loopback10
ip route 10.20.99.0 255.255.255.0 Loopback20
! VRF -> global table: resolve the next hop in the global RIB
ip route vrf RED 192.168.99.0 255.255.255.0 192.168.99.100 global
ip route vrf BLUE 192.168.99.0 255.255.255.0 192.168.99.100 globalThe global keyword is the asymmetry people miss: a static route in a VRF normally resolves its next hop inside that VRF, and this keyword redirects the resolution into the global table. After leaking, RED's table shows the imported route alongside its own:
R1# show ip route vrf RED | begin Gateway
C 10.10.10.0/24 is directly connected, Ethernet0/0.10
C 10.10.99.0/24 is directly connected, Loopback10
S 192.168.99.0/24 [1/0] via 192.168.99.100And the proof from the outside: the VM in the global segment pings into both VRFs, while a VRF-aware ping sourced from inside RED reaches back out:
j@llmbits:~$ ping -c 3 10.10.99.1
3 packets transmitted, 3 received, 0% packet loss ... rtt avg 2.115 ms
j@llmbits:~$ ping -c 3 10.20.99.1
3 packets transmitted, 3 received, 0% packet loss ... rtt avg 2.014 ms
R1# ping vrf RED 192.168.99.100 source 10.10.99.1
!!!!!
Success rate is 100 percent (5/5)One honest lab note: the dot1q subinterfaces above are the standard design for extending VRFs to an external device, but our VM sits behind a hypervisor port group that drops guest-tagged frames, so the working VM pings here traverse the leaked static routes rather than the tagged subinterfaces. The isolation and leaking behavior shown is identical either way; if your host-side VLAN tagging mysteriously fails, check the hypervisor vSwitch before blaming the router (on ESXi standard vSwitches, VLAN 4095 or a trunked port group is required for guest tagging).
Routing Protocols Inside VRFs
Statics scale to a point. Each VRF can also run its own routing protocol instances: OSPF processes are VRF-scoped (router ospf 2 vrf RED), and EIGRP named mode handles VRFs as additional address families (address-family ipv4 unicast vrf RED autonomous-system 100). Neighborships form per VRF over that VRF's interfaces, and everything from show ip ospf neighbor to show ip protocols gains a vrf argument. When the leak requirements outgrow statics entirely, that is the signal you have outgrown VRF-Lite and want MP-BGP route targets doing the import/export, which is the MPLS L3VPN model.
Living on a VRF Router: The Command Reflex
The day-two skill with VRFs is remembering that every tool you reach for has a VRF-scoped form, and the unscoped form silently answers from the global table. The ones that matter daily: ping vrf RED and traceroute vrf RED (with source to pick which VRF address you speak from), show ip arp vrf RED when Layer 2 is in question, show ip cef vrf RED <prefix> to see what forwarding will really do, and telnet /vrf or SSH's -vrf for reaching devices inside a segment. Services need the same treatment: NTP, syslog, TACACS, SNMP traps, and DNS lookups all default to the global table, and each has a vrf keyword or source-interface knob when your management plane lives inside a VRF. The classic symptom of forgetting is a device that routes perfectly but cannot log, resolve, or authenticate.
Dynamic Routing Inside a VRF: A Worked Example
When two VRF-Lite routers share a segmented link (one subinterface per VRF), each VRF typically runs its own IGP instance across its own subinterface. OSPF scopes at the process level:
router ospf 10 vrf RED
router-id 10.10.0.1
!
interface Ethernet0/1.10
encapsulation dot1Q 10
vrf forwarding RED
ip address 10.10.12.1 255.255.255.0
ip ospf 10 area 0EIGRP named mode nests VRFs as address families inside one process (address-family ipv4 unicast vrf RED autonomous-system 100), one of named mode's genuine quality-of-life wins. Verification gains the vrf argument everywhere: show ip ospf neighbor lists per-process (hence per-VRF) adjacencies, show ip route vrf RED ospf shows what arrived. Everything you know about the protocols applies unchanged inside the VRF; only the table changed.
Where VRF-Lite Stops Scaling
Be honest about the growth curve. Each new VRF costs a subinterface on every inter-router link it traverses, an IGP instance (or AF) per hop, and a hand-maintained leak matrix if segments share services. Three VRFs across four routers is comfortable; twelve VRFs across forty routers is a config-generation project with an outage budget. The exit ramp is MP-BGP: VRFs stay exactly as configured here, but route targets automate the import/export decisions and MPLS labels (or VXLAN, in EVPN designs) carry the segmentation between boxes without per-VRF subinterfaces. That architecture is the MPLS pillar's territory; the mental model transfers one-to-one.
FAQ
Can two VRFs use the same IP subnet?
Yes, that is much of the point: tables never meet, so 10.0.0.0/24 can exist in RED, BLUE, and global simultaneously. The corollary is that leaking between VRFs with overlapping space requires NAT, so plan shared-services addressing to be unique across every VRF that must reach it.
Does the RD have to be unique in VRF-Lite?
Locally unique per VRF on the box, yes (the parser enforces it). Between routers it carries no meaning until MP-BGP enters; conventionally you keep a consistent scheme anyway so the eventual migration is a non-event.
Why did my interface lose its IP when I added vrf forwarding?
By design: changing table membership invalidates the address, so IOS XE strips it. Configure vrf forwarding first, then the address, and expect a brief traffic hit when migrating a live interface into a VRF.
Is VRF-Lite a security boundary?
It is a strong routing-plane boundary: no route, no forwarding. But it shares the box's control plane and any misconfigured leak is a bridge, so compliance-grade separation still wants filtering at the leak points and ideally physical or firewall enforcement between zones.
Key Takeaways
A VRF is a self-contained RIB/FIB plus its member interfaces; VRF-Lite is VRFs without MPLS, extended between boxes by per-VRF subinterfaces. Use vrf definition with an address family, set vrf forwarding before the IP address, and expect the RD even though it is locally meaningless in Lite deployments. Isolation is real and mutual by default; cross it only with deliberate leaks (interface-pointing statics into the VRF, global-keyword statics out of it). Verify with show vrf, show ip route vrf, and VRF-aware pings with explicit sources. When leak matrices start looking like spreadsheets, move up to route targets. The wider routing context lives in the IP Routing pillar, with PBR (the other "override the table" tool) covered in the PBR guide.
