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 used 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.

So 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 runs VRF-lite with two interfaces, one connecting to VPN5 and the other to VPN7. The is a CE device connected in VPN5 with an IP address of 150.50.15.5, and another CE device in VPN7 with an IP address of 150.50.17.7.

Originally the intent might have been to keep the two networks entirely separate. But lets assume the need arises to allow routing between VPN5 and VPN7 but only between the ranges 55.5.1.0/24 and 17.1.1.0/24. Not the rest! How can it be done?

As always there are options! Make use of Route-Targets (RTs), or 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 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:

ip vrf VPN5
 rd 100:5
 import map V5-MAP
 route-target export 1:5
 route-target import 1:5
 route-target import 1:7
!
ip vrf VPN7
 rd 100:7
 import map V7-MAP
 route-target export 1:7
 route-target import 1:7
 route-target import 1:5
!
ip extcommunity-list standard V5 permit rt 1:5
ip extcommunity-list standard V7 permit rt 1:7
!
ip prefix-list IMPORT-5 seq 5 permit 17.1.1.0/24
ip prefix-list IMPORT-5 seq 15 permit 150.50.17.0/24
ip prefix-list IMPORT-7 seq 5 permit 55.5.1.0/24
ip prefix-list IMPORT-7 seq 15 permit 150.50.15.0/24
!
route-map V5-MAP permit 10
 match ip address prefix-list IMPORT-5
route-map V5-MAP permit 20
 match extcommunity V5
!
route-map V7-MAP permit 10
 match ip address prefix-list IMPORT-7
route-map V7-MAP permit 20
 match extcommunity V7
!
router eigrp 1
 address-family ipv4 vrf VPN7
  redistribute bgp 1 metric 1500 10 255 2 1500
  network 150.50.17.1 0.0.0.0
  autonomous-system 7
 address-family ipv4 vrf VPN5
  redistribute bgp 1 metric 1500 10 255 2 1500
  network 150.50.15.1 0.0.0.0
  autonomous-system 5
!
router bgp 1
 address-family ipv4 vrf VPN7
  redistribute connected
  redistribute eigrp 7
 address-family ipv4 vrf VPN5
  redistribute connected
  redistribute eigrp 5

The output should yield the following:

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 17.1.1.0/24 should be allowed to ping  55.5.1.0/24 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:

interface FastEthernet0/0
 ip vrf forwarding VPN5
 ip address 150.50.15.1 255.255.255.0
!
interface FastEthernet0/1
 ip vrf forwarding VPN7
 ip address 150.50.17.1 255.255.255.0
!
ip route 150.50.15.5 255.255.255.255 FastEthernet0/0
ip route 150.50.17.7 255.255.255.255 FastEthernet0/1

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

ip route vrf VPN5 17.1.1.0 255.255.255.0 150.50.17.7 global
ip route vrf VPN7 55.5.1.0 255.255.255.0 150.50.15.5 global

Let me explain, the first line says: For VPN5 to reach the 17.1.1.0/24 destination (in VPN7) go to the next-hop of 150.50.17.7 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.

Here is the test to confirm: