VRFs, or VPN Routing and Forwarding instances, are most commonly associated with MPLS
service providers. In such networks, MPLS encapsulation is used to isolate individual customers’
traffic and an independent routing table (VRF) is maintained for each customer. Most often, MP-BGP
is employed to facilitate complex redistribution schemes to import and export routes to and from VRFs to
provide Internet connectivity.

However, VRF configuration isn’t at all dependent on MPLS (the two components just work well together).
In Cisco terminology, deployment of VRFs without MPLS is known as VRF lite, and this article discusses a
scenario where such a solution could come in handy.

Assume the topology illustrated below is a network owned by an enterprise. As you would expect, normal
company traffic must pass through the firewall so that company policy can be enforced. However, this a
secondary Internet connection has been added to this network: an unrestricted ADSL circuit designated for
guests visiting the company campus.

The 10.0.0.0/16 network is used for trusted traffic
The 192.168.0.0/16 is used for guest traffic.

All router interfaces which provide transport for both types of traffic have been configured with
two subinterfaces performing 802.1Q encapsulation; .

10 for VLAN 10 (blue)
20 for VLAN 20 (red).

Note that although 802.1Q encapsulation is used to tag frames across the link, each link is a
routed segment with an IP interface at either end. For example, here is R1’s F2/0 configuration

 

R1

interface FastEthernet2/0
description R1
no ip address
!
interface FastEthernet2/0.10
encapsulation dot1Q 10
description VRF_BLUE
ip address 10.0.12.1 255.255.255.252

!
interface FastEthernet2/0.20
encapsulation dot1Q 20
description VRF_RED
ip address 192.168.12.1 255.255.255.252
!

We employ VRFs here to segment the single physical infrastructure into two virtual, isolated networks.
VRFs employ essentially the same concept as VLANs and trunking, but at layer three. 

VRF lite is simple: each routed interface (whether physical or virtual) belongs to exactly one VRF.
Unless import/export maps have been applied, routes (and therefore packets) cannot move from one
VRF to another, much like the way VLANs work at layer two.

Packets entering VRF A can only follow routes in routing table A, as we’ll see shortly.

To begin, let’s create VRFs BLUE and RED on R1:

R1(config)# ip vrf BLUE
R1(config-vrf)# description Trusted Traffic
R1(config-vrf)# ip vrf RED
R1(config-vrf)# description Guest Traffic

!

Next, we’ll add interface F1/0 (which connects to the guest-use ADSL uplink) to VRF RED:

R1(config)# int f1/0
R1(config-if)# ip vrf forwarding RED
!
% Interface FastEthernet1/0 IP address 192.168.0.2 removed due to enabling VRF RED
Wait a tick, what just happened?

When assigning an interface to a VRF, IOS automatically deletes any preconfigured IP address
to remove that route from the global table. Now when an IP address is assigned to this interface,
its network gets added to the specific routing table for that VRF.

So, we reapply our IP to F1/0.

R1(config-if)# ip add 192.168.0.2 255.255.255.252


 Current configuration of F1/0
!
interface FastEthernet1/0
description RX
ip vrf forwarding RED
ip address 192.168.0.2 255.255.255.252
!
The 192.168.0.0/30 route is gone from the global table; it now resides in the VRF RED table,
which we have to inspect separately by appending the vrf argument to show ip route:

R1# show ip route vrf RED

[…]

192.168.0.0/30 is subnetted, 1 subnets
C 192.168.0.0 is directly connected, FastEthernet1/0

 As you can imagine, this extra step of reapplying an IP address must be repeated for every interface
we add to a VRF.

Relevant finished configuration of R1:

interface FastEthernet1/0
description RX
ip vrf forwarding RED
ip address 192.168.0.2 255.255.255.252
!
interface FastEthernet1/1
description FW
ip vrf forwarding BLUE
ip address 10.0.0.2 255.255.255.252
!
!
!
interface FastEthernet2/0
description R2
no ip address
!
interface FastEthernet2/0.10
encapsulation dot1Q 10
ip vrf forwarding BLUE
ip address 10.0.12.1 255.255.255.252
!
interface FastEthernet2/0.20
encapsulation dot1Q 20
ip vrf forwarding RED
ip address 192.168.12.1 255.255.255.252
!
!
!
interface FastEthernet2/1
description R3
no ip address
!
interface FastEthernet2/1.10
encapsulation dot1Q 10
ip vrf forwarding BLUE
ip address 10.0.13.1 255.255.255.252
!
interface FastEthernet2/1.20
encapsulation dot1Q 20
ip vrf forwarding RED
ip address 192.168.13.1 255.255.255.252
!
As all interfaces now belong to isolated VRFs, our global routing table is completely empty.
We can verify that all 10.0.0.0/16 routes are stored in VRF BLUE, and all 192.168.0.0/16 routes
are stored in VRF RED:

show ip route vrf BLUE
show ip route vrf RED

At this point, although only R1 has been configured with VRFs, it can still route traffic to R2 and R3
with no problem. This is because, like VLANs, VRFs are only locally significant to the router.

##########################

R2 VRF Configuration :

ip vrf BLUE
description Trusted Traffic
!
ip vrf RED
description GUEST
!
!
interface FastEthernet0/0
no ip address
!

interface FastEthernet0/0.10
encapsulation dot1Q 10
ip vrf forwarding BLUE
ip address 10.0.12.2 255.255.255.252
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip vrf forwarding RED
ip address 192.168.12.2 255.255.255.252
!
!
R3 VRF Configuration :

ip vrf BLUE
description Trusted Traffic
!
ip vrf RED
description GUEST
!
!

interface FastEthernet0/0
no ip address
!
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip vrf forwarding BLUE
ip address 10.0.13.2 255.255.255.252
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip vrf forwarding RED
ip address 192.168.13.2 255.255.255.252
!
!
##########################

Now configure our IGP. For this example, we’ll be running an OSPF instance per VRF.
We do this by appending the vrf argument to each router statement:

R1(config)# router ospf 1 vrf BLUE
R1(config-router)# router-id 0.0.1.1
R1(config-router)# network 10.0.0.0 0.0.255.255 area 0
!
R1(config-router)# router ospf 2 vrf RED
R1(config-router)# router-id 0.0.1.2
R1(config-router)# network 192.168.0.0 0.0.255.255 area 0
!
These are completely independent OSPF processes; as such, a unique router ID must be used for each.
(If you’re used to using IPv4 addresses as router ID, the IDs used above might seem strange.

Remember that the OSPF router ID is in fact an arbitrary 32-bit value simply expressed
in dotted-decimal.

Here, the third “octet” represents the router number and the fourth octet represents the VRF.)

After configuring the other two routers with two OSPF processes each,
we see two adjacencies formed per link, one per VRF:

R1 :

 

router ospf 1 vrf BLUE
router-id 0.0.2.1
log-adjacency-changes
network 10.0.0.0 0.0.255.255 area 0
!
router ospf 2 vrf RED
router-id 0.0.2.2
log-adjacency-changes
network 192.168.0.0 0.0.255.255 area 0

R3 :

router ospf 1 vrf BLUE
router-id 0.0.3.1
log-adjacency-changes
network 10.0.0.0 0.0.255.255 area 0
!
router ospf 2 vrf RED
router-id 0.0.3.2
log-adjacency-changes
network 192.168.0.0 0.0.255.255 area 0


Assuming our edge routers aren’t running OSPF, we’ll also create two static default routes
on R1, one for each VRF:

R1(config)# ip route vrf BLUE 0.0.0.0 0.0.0.0 10.0.0.1
R1(config)# ip route vrf RED 0.0.0.0 0.0.0.0 192.168.0.1


We can verify that our static routes exist along with their OSPF-learned companions in their
respective VRFs:

Finally we just need to advertise a default route in both OSPF processes from R1 so
R2 and R3 can learn them:

R1(config)# router ospf 1
R1(config-router)# default-information originate
!
R1(config-router)# router ospf 2
R1(config-router)# default-information originate

Note that when entering OSPF process configuration, we no longer need to append the
vrf keyword as it has already been applied.

Over to R2 we see that each VRF now has its own complete routing table:

show ip route vrf BLUE
O*E2 0.0.0.0/0 [110/1] via 10.0.12.1, 00:03:33, FastEthernet1/0.10

show ip route vrf RED
 O*E2 0.0.0.0/0 [110/1] via 192.168.12.1, 00:01:41, FastEthernet1/0.20