VRF-lite route leakingSeptember 13, 2010
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.
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 18.104.22.168, and another CE device in VPN7 with an IP address of 22.214.171.124.
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 126.96.36.199/24 and 188.8.131.52/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 184.108.40.206/24 ip prefix-list IMPORT-5 seq 15 permit 220.127.116.11/24 ip prefix-list IMPORT-7 seq 5 permit 18.104.22.168/24 ip prefix-list IMPORT-7 seq 15 permit 22.214.171.124/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 126.96.36.199 0.0.0.0 autonomous-system 7 address-family ipv4 vrf VPN5 redistribute bgp 1 metric 1500 10 255 2 1500 network 188.8.131.52 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 184.108.40.206/24 should be allowed to ping 220.127.116.11/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 18.104.22.168 255.255.255.0 ! interface FastEthernet0/1 ip vrf forwarding VPN7 ip address 22.214.171.124 255.255.255.0 ! ip route 126.96.36.199 255.255.255.255 FastEthernet0/0 ip route 188.8.131.52 255.255.255.255 FastEthernet0/1
Then to add the static routes within the respective VRFs are the easy part:
ip route vrf VPN5 184.108.40.206 255.255.255.0 220.127.116.11 global ip route vrf VPN7 18.104.22.168 255.255.255.0 22.214.171.124 global
Let me explain, the first line says: For VPN5 to reach the 126.96.36.199/24 destination (in VPN7) go to the next-hop of 188.8.131.52 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: