Skip to content
Log in Sign up My account

2.2.a VRF and VRF-Lite

Blueprint 2.2: Configure and verify data path virtualization technologies

  • 2.2.a VRF
  • 2.2.b GRE and IPsec tunneling (covered on the next page)

This is a configure and verify objective. Expect to type a VRF configuration in a lab item, and expect multiple-choice items built around show output where something is in the wrong table. The same skills come back in ENARSI 1.7 (VRF-Lite), so the time you spend here pays twice.

What a VRF is

A Virtual Routing and Forwarding (VRF) instance is a separate routing table and forwarding table (FIB) inside one router. Each interface belongs to exactly one VRF, or to the global table if it is not assigned to any. A packet that arrives on an interface in VRF RED is looked up only in the RED table and can only leave through an interface in RED.

Without VRFs With VRFs
One routing table, every interface can reach every other One table per VRF, interfaces isolated by default
Overlapping IP addresses impossible The same prefix can exist in several VRFs
Separation needs ACLs everywhere Separation is structural, no ACLs needed
One routing protocol instance per process Routing protocol instances (or address families) per VRF

Uses on the exam and in practice:

  • Separate tenants, business units, or guest and corporate traffic on shared hardware.
  • Merge companies with overlapping address space.
  • A management VRF that keeps out-of-band management out of the data plane routing table. Catalyst 9000 switches put the dedicated management port Gi0/0 in a VRF called Mgmt-vrf by default.
  • The handoff between an SD-Access border and a fusion router (one VRF per virtual network), covered in 1.3.

VRF-Lite vs MPLS L3VPN

VRF-Lite is VRFs without MPLS. Each VRF needs its own Layer 3 hop-by-hop path: a separate link, or more often a separate 802.1Q subinterface or SVI per VRF on every link between VRF-aware devices, and a routing protocol instance per VRF on each one.

MPLS Layer 3 VPN (ENARSI 2.2) carries many VRFs across a shared core with labels. The route distinguisher (RD) and route targets (RT) exist for MP-BGP in that design.

graph LR
  subgraph S1 ["Site A"]
    HR["RED host<br/>192.168.1.10"] --- R1
    HB["BLUE host<br/>192.168.1.10"] --- R1
  end
  R1["R1<br/>VRF RED, VRF BLUE"] -- "Gi2.100 VRF RED 10.1.2.0/30" --- R2["R2<br/>VRF RED, VRF BLUE"]
  R1 -- "Gi2.200 VRF BLUE 10.1.2.4/30" --- R2
  R2 --- SR["RED servers<br/>172.16.1.0/24"]
  R2 --- SB["BLUE servers<br/>172.16.1.0/24"]

Both tenants use 192.168.1.0/24 and 172.16.1.0/24. Nothing conflicts, because the prefixes live in different tables.

VRF-Lite MPLS L3VPN
Transport between routers Per-VRF subinterface, SVI, or tunnel Shared MPLS core, labels identify the VRF
RD and RT Not required Required (RD makes prefixes unique in MP-BGP, RT controls import and export)
Scale Fine for a few VRFs and hops Hundreds of VRFs and sites
Config on core routers Every VRF on every hop Core (P) routers know nothing about VRFs

Exam trap

A route distinguisher does not separate traffic and does not control which routes a VRF imports. On VRF-Lite it is optional. If an answer says "configure an RD so the two VRFs cannot see each other's routes", it is wrong: the VRFs are already separate the moment interfaces are assigned to them.

Configuration

Two syntaxes

vrf definition (current, multiprotocol) ip vrf (legacy, IPv4 only)
Create vrf definition RED ip vrf RED
Enable IPv4 address-family ipv4 (required) Implicit
Enable IPv6 address-family ipv6 Not supported
Assign interface vrf forwarding RED ip vrf forwarding RED
Show show vrf show ip vrf

You can convert legacy VRFs with the vrf upgrade-cli multi-af-mode command. Use vrf definition for anything new and on the exam unless the item clearly shows the old syntax.

Building the VRF and assigning interfaces

vrf definition RED
 description Tenant RED
 address-family ipv4
 exit-address-family
 address-family ipv6
 exit-address-family
!
vrf definition BLUE
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet3
 vrf forwarding RED
 ip address 192.168.1.1 255.255.255.0
!
interface GigabitEthernet2.100
 encapsulation dot1Q 100
 vrf forwarding RED
 ip address 10.1.2.1 255.255.255.252
!
interface GigabitEthernet2.200
 encapsulation dot1Q 200
 vrf forwarding BLUE
 ip address 10.1.2.5 255.255.255.252

ip routing
!
vrf definition RED
 address-family ipv4
 exit-address-family
!
interface Vlan100
 vrf forwarding RED
 ip address 10.100.0.1 255.255.255.0
!
interface GigabitEthernet1/0/24
 no switchport
 vrf forwarding RED
 ip address 10.1.2.1 255.255.255.252

Exam trap

vrf forwarding removes every IP address already configured on the interface, with only a console message to warn you: % Interface GigabitEthernet3 IPv4 disabled and address(es) removed due to enabling VRF RED. Always enter vrf forwarding first, then the address. In a sim, re-check show ip interface brief after moving an interface into a VRF.

Routing inside a VRF

Every routing source can be VRF-aware.

! Next hop in the same VRF
ip route vrf RED 172.16.1.0 255.255.255.0 10.1.2.2
!
! Default route in VRF RED that points to a next hop in the GLOBAL table
ip route vrf RED 0.0.0.0 0.0.0.0 203.0.113.1 global

router ospf 10 vrf RED
 router-id 10.255.255.1
 network 10.1.2.0 0.0.0.3 area 0
 network 192.168.1.0 0.0.0.255 area 0
!
router ospf 20 vrf BLUE
 router-id 10.255.254.1
 network 10.1.2.4 0.0.0.3 area 0

Each VRF needs its own OSPF process number. One process cannot serve two VRFs.

router eigrp CORE
 address-family ipv4 unicast vrf RED autonomous-system 100
  network 10.1.2.0 0.0.0.3
  network 192.168.1.0
 exit-address-family

EIGRP and BGP use one process with an address family per VRF.

router bgp 65001
 address-family ipv4 vrf RED
  neighbor 10.1.2.2 remote-as 65002
  neighbor 10.1.2.2 activate
  network 192.168.1.0 mask 255.255.255.0
 exit-address-family

BGP is the exception to "RD optional": IOS XE normally refuses BGP configuration for a VRF until the VRF has an RD, so add rd 65001:1 under vrf definition RED first.

Exam trap

OSPF neighbours in VRF RED form only over interfaces in VRF RED. If one side puts the link in RED and the other leaves it in global, the IP addresses match, ping from the global table fails, and no adjacency forms. show ip vrf interfaces on both routers finds this in seconds.

Talking to a VRF from the CLI

Every IP tool takes a vrf keyword. Without it, the router uses the global table, which is the single most common VRF verification mistake.

Task Command
Ping inside a VRF ping vrf RED 172.16.1.10
Traceroute inside a VRF traceroute vrf RED 172.16.1.10
Routing table show ip route vrf RED
CEF show ip cef vrf RED
ARP show ip arp vrf RED
Protocols show ip protocols vrf RED
OSPF neighbours show ip ospf 10 neighbor (process is already tied to the VRF)
EIGRP neighbours show ip eigrp vrf RED neighbors
BGP show bgp vrf RED summary
SSH or Telnet from the router ssh -vrf RED -l admin 172.16.1.10, telnet 172.16.1.10 /vrf RED

Verification

R1# show vrf
  Name                             Default RD            Protocols   Interfaces
  BLUE                             <not set>             ipv4        Gi2.200
  RED                              <not set>             ipv4,ipv6   Gi3
                                                                     Gi2.100

<not set> for the RD is normal on VRF-Lite. The Protocols column shows which address families are enabled. An interface missing from the list is still in the global table.

R1# show ip vrf interfaces
Interface              IP-Address      VRF                              Protocol
Gi2.200                10.1.2.5        BLUE                             up
Gi3                    192.168.1.1     RED                              up
Gi2.100                10.1.2.1        RED                              up

R1# show ip route vrf RED

Routing Table: RED
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
...
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.2.0/30 is directly connected, GigabitEthernet2.100
L        10.1.2.1/32 is directly connected, GigabitEthernet2.100
      172.16.0.0/24 is subnetted, 1 subnets
O        172.16.1.0 [110/2] via 10.1.2.2, 00:01:12, GigabitEthernet2.100
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, GigabitEthernet3
L        192.168.1.1/32 is directly connected, GigabitEthernet3

The Routing Table: RED header is how you know you are looking at the right table. A plain show ip route on the same router shows none of these prefixes.

Route leaking basics

VRFs are isolated by design, but shared services (DNS, DHCP, internet) often live elsewhere. Moving routes between tables is route leaking.

Method How Notes
Static to global ip route vrf RED 0.0.0.0 0.0.0.0 203.0.113.1 global Sends RED traffic to a global next hop. The return path needs a global route back to the RED prefix through the RED interface
Static between VRFs ip route vrf RED 172.16.50.0 255.255.255.0 GigabitEthernet4 10.50.0.2 Name the exit interface in the other VRF plus its next hop
MP-BGP import and export Route targets on the VRFs, BGP on the router Scales, and the method behind shared-services designs
External fusion router or firewall One VRF-Lite link per VRF, the fusion device routes between them The common SD-Access and data centre design

Route leaking appears again in ENARSI. For ENCOR, know that it exists, that the global keyword is how a static route in a VRF reaches the global table, and that NAT is needed if leaked VRFs overlap.

Lab: VRF-Lite with overlapping addresses

Topology: R1 and R2 (Catalyst 8000v) joined on Gi2 by one cable, with two hosts or loopbacks per side standing in for each tenant.

graph LR
  L1R["Lo10 VRF RED<br/>192.168.1.1/24"] --- R1["R1"]
  L1B["Lo20 VRF BLUE<br/>192.168.1.1/24"] --- R1
  R1 -- "Gi2.100 RED 10.1.2.1/30" --- R2["R2"]
  R1 -- "Gi2.200 BLUE 10.1.2.5/30" --- R2
  R2 --- L2R["Lo10 VRF RED<br/>172.16.1.1/24"]
  R2 --- L2B["Lo20 VRF BLUE<br/>172.16.1.1/24"]
  1. On both routers, create VRFs RED and BLUE with the IPv4 address family.
  2. Create subinterfaces Gi2.100 (VLAN 100, VRF RED) and Gi2.200 (VLAN 200, VRF BLUE) with the addresses shown. R2 uses .2 and .6.
  3. Create Loopback10 in RED and Loopback20 in BLUE on each router. Deliberately give both loopbacks on R1 the same address, 192.168.1.1/24, and both on R2 172.16.1.1/24.
  4. Run OSPF process 10 in VRF RED and OSPF process 20 in VRF BLUE on both routers. Add ip ospf network point-to-point on the loopbacks so the /24 is advertised instead of a /32.
  5. Verify, then try the mistakes below.
! R1
vrf definition RED
 address-family ipv4
 exit-address-family
vrf definition BLUE
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet2
 no shutdown
interface GigabitEthernet2.100
 encapsulation dot1Q 100
 vrf forwarding RED
 ip address 10.1.2.1 255.255.255.252
interface GigabitEthernet2.200
 encapsulation dot1Q 200
 vrf forwarding BLUE
 ip address 10.1.2.5 255.255.255.252
interface Loopback10
 vrf forwarding RED
 ip address 192.168.1.1 255.255.255.0
 ip ospf network point-to-point
interface Loopback20
 vrf forwarding BLUE
 ip address 192.168.1.1 255.255.255.0
 ip ospf network point-to-point
!
router ospf 10 vrf RED
 router-id 1.1.1.10
 network 10.1.2.0 0.0.0.3 area 0
 network 192.168.1.0 0.0.0.255 area 0
router ospf 20 vrf BLUE
 router-id 1.1.1.20
 network 10.1.2.4 0.0.0.3 area 0
 network 192.168.1.0 0.0.0.255 area 0

Expected verification:

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.20          1   FULL/DR         00:00:35    10.1.2.6        GigabitEthernet2.200
2.2.2.10          1   FULL/DR         00:00:33    10.1.2.2        GigabitEthernet2.100

R1# show ip route vrf RED ospf | begin Gateway
Gateway of last resort is not set
      172.16.0.0/24 is subnetted, 1 subnets
O        172.16.1.0 [110/2] via 10.1.2.2, 00:00:41, GigabitEthernet2.100

R1# ping vrf BLUE 172.16.1.1 source Loopback20
!!!!!
R1# ping 172.16.1.1
.....

The same 192.168.1.0/24 exists twice on R1 without an "overlaps with" error, each VRF learns 172.16.1.0/24 through its own subinterface, and the global ping fails because the global table has no route.

Break it:

  • Configure the IP address on R2's Gi2.100 first and vrf forwarding RED second. Watch the address disappear and the RED adjacency drop.
  • Put R2's Gi2.200 in VRF RED instead of BLUE. The subinterface comes up, but neither OSPF process forms a neighbour on it, and show ip vrf interfaces shows the mismatch.
  • Try router ospf 10 vrf BLUE while process 10 is already bound to RED. IOS rejects it.

Quick check

An engineer runs show ip route and does not see 172.16.1.0/24, but users in VRF RED can reach it. Is something broken?

No. show ip route shows only the global table. Use show ip route vrf RED to see the prefix.

Is a route distinguisher required to create a VRF for VRF-Lite with vrf definition?

No. The RD is only needed when MP-BGP carries the VRF's routes, for example in MPLS L3VPN or BGP-based route leaking. The VRF and its isolation work without it.

What does ip route vrf RED 0.0.0.0 0.0.0.0 203.0.113.1 global do?

It installs a default route in VRF RED whose next hop, 203.0.113.1, is resolved in the global routing table. It is a simple way to give a VRF internet access through a global uplink. Return traffic still needs a route in the global table back to the RED prefixes.

References