Cart
VPN Routing and Forwarding (VRF) separation is a powerful feature of modern network operating systems, including Cisco IOS that can be used to isolate routing domains and create virtual routers, or routing domains. However, sometimes we need to allow these isolated portions of our network to communicate. Doing so in MPLS VPN scenarios is something that almost every CCIE R&S and SP student knows. What if there is no MPLS and we’re dealing with so-called VRF-lite, that is just the routing separation, without MPLS being present.This shouldn’t be too much of a problem to explore and test. Below is the test network that we’ll use.
Here are the relevant configurations from all the routers. We will see that they are very simple indeed.
R2:
ip vrf blue rd 2:206 ! ip vrf red rd 2:205 ! interface Loopback0 ip address 192.168.0.2 255.255.255.255 ! interface Serial0/1/0.204 ip address 192.168.24.2 255.255.255.0 ! interface Serial0/1/0.205 ip vrf forwarding red ip address 10.0.25.2 255.255.255.0 ! interface Serial0/1/0.206 ip vrf forwarding blue ip address 10.0.26.2 255.255.255.0 ! router ospf 1 network 0.0.0.0 255.255.255.255 area 0 ! router ospf 205 vrf red network 0.0.0.0 255.255.255.255 area 0 ! router ospf 206 vrf blue network 0.0.0.0 255.255.255.255 area 0 !
R4:
interface Loopback0 ip address 192.168.0.4 255.255.255.255 ! interface Serial0/0/0.402 ip address 192.168.24.4 255.255.255.0 ! router ospf 1 network 0.0.0.0 255.255.255.255 area 0 !
R5:
interface Loopback0 ip address 10.0.0.5 255.255.255.255 ! interface Serial0/1/0.502 ip address 10.0.25.5 255.255.255.0 ! router ospf 1 network 0.0.0.0 255.255.255.255 area 0 !
R6:
interface Loopback0 ip address 10.0.0.6 255.255.255.255 ! interface Serial0/1/0.602 ip address 10.0.26.6 255.255.255.0 ! router ospf 1 network 0.0.0.0 255.255.255.255 area 0 !
Let’s see how we can make these VRFs reachable.
Route Leaking Between Global Routing Table and VRF
The first scenario I would like to explore here is reachability between the main routing table and a VRF. We will use VRF “red” for this purpose. I.e. the goal is to make Loopback0 interfaces of R4 and R5 reachable.
One approach is to use two static routes on R2. One static route in the main routing table, pointing to an interface in the VRF and the other one in a VRF, pointing to the next-hop in the global routing table. Let’s take a look.
R2:
ip route 10.0.0.5 255.255.255.255 Serial0/1/0.205 10.0.25.5 ip route vrf red 192.168.0.4 255.255.255.255 Serial0/1/0.204 192.168.24.4 global
Please note the use of global keyword on the static route in the VRF. This configuration will create appropriate routes on R2, but we’re still one step short of reachability. We will need to redistribute static routes into appropriate routing processes.
R2:
R2#show ip route static 10.0.0.0/32 is subnetted, 1 subnets S 10.0.0.5 [1/0] via 10.0.25.5, Serial0/1/0.205 R2#show ip route vrf red static 192.168.0.0/32 is subnetted, 1 subnets S 192.168.0.4 [1/0] via 192.168.24.4, Serial0/1/0.204
R2:
router ospf 1 redistribute static subnets ! router ospf 205 redistribute static subnets !
Let’s see if we have the routes on R4 and R5.
R4:
R4#show ip route ospf
10.0.0.0/32 is subnetted, 1 subnets
O E2 10.0.0.5 [110/20] via 192.168.24.2, 00:00:29, Serial0/0/0.402
192.168.0.0/32 is subnetted, 2 subnets
O 192.168.0.2 [110/65] via 192.168.24.2, 00:27:58, Serial0/0/0.402
R5:
R5#show ip route ospf
192.168.0.0/32 is subnetted, 1 subnets
O E2 192.168.0.4 [110/20] via 10.0.25.2, 00:01:02, Serial0/1/0.502
We do, which is good. Let’s test the reachability.
R4:
R4#ping 10.0.0.5 source Loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
Very good! However, things may not be that easy…
CCIE Twist on “Global” Route Leaking
You most likely noticed that I used two static routes. What if we were allowed to use only one? This would be a case when seemingly relatively easy task gets complicated.
The solution still exists, but we need to introduce BGP, more precisely MP-BGP to the mix. We can import routes from the global BGP table (more correctly, from IPv4 unicast BGP table) into the VRF using “import ipv4 unicast map” command in VRF configuration. Don’t be mistaken that this command imports routes from the routing table – it doesn’t! If the route is not in the BGP, it will not be imported. Let’s see.
First, I will remove the static route from the VRF and proceed with the configuration from there.
R2:
no ip route vrf red 192.168.0.4 255.255.255.255 Serial0/1/0.204 192.168.24.4 global ! ip prefix-list R4-Loopback0 seq 10 permit 192.168.0.4/32 ! route-map Global-Import permit 10 match ip address prefix-list R4-Loopback0 ! ip vrf red import ipv4 unicast map Global-Import !
Let’s see what we have in the VRF routing table now.
R2:
R2#show ip route vrf red | begin ^Gateway
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O 10.0.0.5/32 [110/65] via 10.0.25.5, 00:26:53, Serial0/1/0.205
C 10.0.25.0/24 is directly connected, Serial0/1/0.205
We can clearly see that the route for 192.168.0.4/32 is no longer there. We need to ensure it shows up in BGP on R2. Let’s do that.
R2:
router bgp 2 address-family ipv4 unicast redistribute ospf 1 !
R2#show ip bgp BGP table version is 4, local router ID is 192.168.0.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 192.168.0.2/32 0.0.0.0 0 32768 ? *> 192.168.0.4/32 192.168.24.4 65 32768 ? *> 192.168.24.0 0.0.0.0 0 32768 ? R2#show ip route vrf red | begin ^Gateway Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks O 10.0.0.5/32 [110/65] via 10.0.25.5, 00:29:49, Serial0/1/0.205 C 10.0.25.0/24 is directly connected, Serial0/1/0.205 192.168.0.0/32 is subnetted, 1 subnets B 192.168.0.4 [20/65] via 192.168.24.4, 00:00:36, Serial0/1/0.204
We can see the route is there on R2. Now we need to redistribute back from BGP into OSPF inside VRF “red” to ensure it’s reachable visible on R5.
R2:
router ospf 205 redistribute bgp 2 subnets !
Let’s verify.
R5:
R5#show ip route ospf 192.168.0.0/32 is subnetted, 1 subnets O E2 192.168.0.4 [110/1] via 10.0.25.2, 00:00:07, Serial0/1/0.502 R5#ping 192.168.0.4 source Loopback0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2 seconds: Packet sent with a source address of 10.0.0.5 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
Success, as expected!
Route Leaking Between Two VRFs
Route leaking between two VRF’s can be done using two methods. One is to use static routes, similar to what we’ve seen above in the example of VRF and a global table. However, somewhat more elegant solution is to use import and export features of VRFs. Again, I must issue a warning and a reminder here: VRF import applies to routes in MP-BGP. VRF export exports routes to MP-BGP. That is, if we don’t have MP-BGP configured on the router leaking routes between VRFs, import/export operation will fail miserably.
With that knowledge in mind, let’s proceed to make Loopback0 interfaces of R5 and R6 reachable. There are couple of things we need to do here.
- We need to export routes from VRF using appropriate route-targets
- We need to ensure that all VRF routes are in MP-BGP
- We need to import routes into VRF using appropriate route-targets
- We need to redistroibute from MP-BGP into PE-CE routing protocol
Before all of the above, I will remove previously configure global import.
R2:
ip vrf red no import ipv4 unicast map Global-Import route-target export 1:1 route-target import 1:2 ! ip vrf blue route-target export 1:2 route-target import 1:1 ! router bgp 2 address-family ipv4 vrf red redistribute ospf 205 address-family ipv4 vrf blue redistribute ospf 206 ! router ospf 205 redistribute bgp 2 subnets ! router ospf 206 redistribute bgp 2 subnets !
Let’s test. First, let’s examine BGP tables on R2.
R2:
R2#show ip bgp vpnv4 all
BGP table version is 13, local router ID is 192.168.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 2:205 (default for vrf red)
*> 10.0.0.5/32 10.0.25.5 65 32768 ?
*> 10.0.0.6/32 10.0.26.6 65 32768 ?
*> 10.0.25.0/24 0.0.0.0 0 32768 ?
*> 10.0.26.0/24 0.0.0.0 0 32768 ?
Route Distinguisher: 2:206 (default for vrf blue)
*> 10.0.0.5/32 10.0.25.5 65 32768 ?
*> 10.0.0.6/32 10.0.26.6 65 32768 ?
*> 10.0.25.0/24 0.0.0.0 0 32768 ?
*> 10.0.26.0/24 0.0.0.0 0 32768 ?
Next, we will perform reachability test between R5 and R6.
R5:
R5#show ip route ospf 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks O E2 10.0.0.6/32 [110/65] via 10.0.25.2, 00:00:34, Serial0/1/0.502 O E2 10.0.26.0/24 [110/1] via 10.0.25.2, 00:00:34, Serial0/1/0.502 R5#ping 10.0.0.6 source Loopback0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.6, timeout is 2 seconds: Packet sent with a source address of 10.0.0.5 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
There we go, VRF route leaking can’t be simpler!
Happy studies.
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
Tags: CCIE Routing & Switching, CCIE Service Provider, route leaking, VRF
Good approach however, would the vrf unicast import map will import ONLY the prefix mentioned in the prefix-list and deny all other prefixes including the VPNv4 prefixes coming from other VPN SITEs?
The task is relatively easy, but if a limit on static routes is restricted to be only one, then it becomes much complex.
Thanks Marko for this great post !
I tried to lab the “import ipv4 unicast map” solution and it seems that if you have not previously import some routes into this vrf address-family via a redistribute or network command, the “import ipv4 unicast map” will import nothing.
On your exampl I had to ass the following command to make it works :
router bgp 2
address-family ipv4 vrf red
redistribute ospf 205
Like “import ipv4 unicast map” is not enough to activate M-BGP at least on 12.4(15)T10 and dynamips
Hi Marko,
Very nice and to the point article
I was wondering if suppose I want 192.168.0.2 to communicate with 10.0.0.5, would be it be possible? If so, can you please explain.
Thanks
Question about static route failing to install in main routing table.
I go through the lab and hit the point to type in
“ip route 10.0.0.5 255.255.255.255 Serial0/1/0.205 10.0.25.5″ mentioned under “Route Leaking Between Global Routing Table and VRF”
but the route is not installed in routing table. The possible reason is that target Ip address 10.0.25.5 is belonged to VRF, not main routint table. Could you explain how it works?
As you are running MP-BGP on this router and you are adding RT/RDs to the routes in the VRFs.
Does this mean that they will be in the main BGP table?
Does this then mean that these routes will also be exported out of the router if you also have MP-BGP peerings out of the router?
What if you only want route leaking to happen locally and not have the risk of anything sent out of the box.
If you don’t want anything sent out of the box, you can use for example “no-advertise” community in the Import/Export maps to make sure they stay put. The focus on this article was to just show the local behavior, not the interaction with the remote peers.
–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List
Can this be done between 2 routers that needs to share routes between vrf-lite without mpls? Is there a way to carry the Route targets with mpbgp without mpls?
Yes there is. MP-BGP is not dependent on MPLS. However, you may need to manually adjust next-hop attributes on the remote routers, as MP-BGP learned routes will have next-hop set to the peer-address, which will be in the global routing table and in a case of MPLS reachable using the transport label. However, in this scenario, you don’t have MPLS and need to provide reachability from inside the VRF. An interesting question, I have to admit :-)
–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List
Great!!! Clear explanation!!! Fully undertandable!!! Thank you!!!