VRF-lite route leaking

VRF-lite route leakinG

The purpose of VRF-lite is to extend the logical separation of two different networks from a MPLS network down to a single CE router, connected to both these networks. It’s called VRF-lite because it is done without running MPLS (LDP/TDP) or MP-BGP between the PE and CE. Traffic is mapped to the VRF assigned to the ingress interface on the CE router.

But VRF-lite could be used without connecting to a MPLS network entirely! Consider what a VRF is?

A VRF is a mechanism to provide logical separation between routing tables on the same router. It is locally significant to the router. Each interface on a router can only be assigned to one VRF, but a VRF can have multiple interfaces.


Knowing this, VRF-lite could be used to separate multiple networks using the same equipment. (Not exactly something you should ever plan in a design, but it could be useful to know)

Once you have the separation you needed, you might need a way to selectively bridge that separation to allow communication between the VRF’s.

Assume the following scenario:

Router1 (R1) runs VRF-lite with two interfaces, one connecting to VPN5 and the other to VPN7. Originally the intent might have been to keep the two networks entirely separate. But lets assume the goal is to allow routing between VPN5 and VPN7 but only between the ranges and Not the rest! How can it be done?

As always there are options!

  1. Make use of Route-Targets (RTs), or
  2. Take the lazy approach with static routes.


Direct redistribution between VRF-aware IGP’s on the same router, does not work as you would expect. On most the IOS codes that I have seen, IOS does not allow this.

Option 1 – Using RTs

The next technique that might jump to mind is route-target import/export. But what is a route-target and its purpose?

A RD is a 64-bit identifier prepended to a 32-bit IPv4 address which turns a non-unique IPv4 prefix  into a unique 96-bit VPNv4 prefix. A RD is the most basic requirement to activate the VRF and create the VRF tables. A RT or route-target  on the other hand is a BGP extended community which gets attached when a prefix is exported from the VRF RIB table into the VRF-aware BGP table to identify VPN membership. The confusing part is that the RT import/export function in Cisco IOS is defined under the VRF configuration section and not under the BGP section. Thus to use RTs BGP is  required. This means without BGP enabled on Router1, the RT import/export would yield no result.

So for this option to work the following must be considered:

  • The BGP process is required for the creation of the VRF-aware BGP tables. (BGP neighbors are not necessary)
  • From the source VRF the required range must be redistributed into the VRF specific BGP table where the export RT is attached.
  • The destination VRF should then import this exported range, based on the attached RT. And vice versa for bidirectional communication.
  • Lastly since BGP is used the BGP next-hop must be reachable, else the imported routes will not be considered for route-selection.

Here is the config to complete the first option:

01 ip vrf VPN5
02  rd 100:5
03  import map V5-MAP
04  route-target export 1:5
05  route-target import 1:5
06  route-target import 1:7
07 !
08 ip vrf VPN7
09  rd 100:7
10  import map V7-MAP
11  route-target export 1:7
12  route-target import 1:7
13  route-target import 1:5
14 !
15 ip extcommunity-list standard V5 permit rt 1:5
16 ip extcommunity-list standard V7 permit rt 1:7
17 !
18 ip prefix-list IMPORT-5 seq 5 permit
19 ip prefix-list IMPORT-5 seq 15 permit
20 ip prefix-list IMPORT-7 seq 5 permit
21 ip prefix-list IMPORT-7 seq 15 permit
22 !
23 route-map V5-MAP permit 10
24  match ip address prefix-list IMPORT-5
25 route-map V5-MAP permit 20
26  match extcommunity V5
27 !
28 route-map V7-MAP permit 10
29  match ip address prefix-list IMPORT-7
30 route-map V7-MAP permit 20
31  match extcommunity V7
32 !
33 router eigrp 1
34  address-family ipv4 vrf VPN7
35   redistribute bgp 1 metric 1500 10 255 2 1500
36   network
37   autonomous-system 7
38  address-family ipv4 vrf VPN5
39   redistribute bgp 1 metric 1500 10 255 2 1500
40   network
41   autonomous-system 5
42 !
43 router bgp 1
44  address-family ipv4 vrf VPN7
45   redistribute connected
46   redistribute eigrp 7
47  address-family ipv4 vrf VPN5
48   redistribute connected
49   redistribute eigrp 5

The output should yield the following result:


Option 2 – Static Routes

Another, perhaps easier option would be to use static routes within each VRF and in the global VRF. This method will route traffic out the source VRF to the global table and back in the destination VRF. The obvious other bonus is that this method does not need the BGP process to be enabled.

So to test should be allowed to ping but no other 55.5 range.

This is done by using the command “ip route vrf NAME x.x.x.x s.s.s.s nh.nh.nh.nh global“.
The global keyword specifies that the next-hop is reachable via the global routing table instead of the VRF table.

The global table would obviously need a route to each required next-hop in each VRF. For this two routes are needed in the global RIB for the next-hop IPs of VPN5 and VPN7:

01 interface FastEthernet0/0
02  ip vrf forwarding VPN5
03  ip address
04 !
05 interface FastEthernet0/1
06  ip vrf forwarding VPN7
07  ip address
08 !
09 ip route FastEthernet0/0
10 ip route FastEthernet0/1

Then to add the static routes within the respective VRFs are the easy part:

1 ip route vrf VPN5 global
2 ip route vrf VPN7 global

Let me explain, the first line says: For VPN5 to reach the destination (in VPN7) go to the next-hop of which is in the global table. The global table will route traffic to that next-hop into the VPN7 table, as per the first set of static routes.
The second line takes care of the return traffic.