Leaking Routes from Global to VRF – BGP

VRFs are an excellent tool for Layer 3 separation on a router. Allowing you to separate routing domains and control where traffic can be routed, much like VLANs on a Switch. VRFs are also required for MPLS L3VPN deployments.

There may be a requirement for you to leak routes from the global routing table or from other VRFs into a VRF. This could be just a default route to allow traffic out of the VRF or specific prefixes for an intranet for example.

In this guide, I will show how this can be achieved for accessing an intranet. In this specific guide, we will look how it can be achieved using BGP. However, some static routes will still be required on R1.

Lets have a look at the topology:

Here we can see two VRFs in use on R1. With R5 in the VRF called 'BLUE' and R6 in the VRF called 'RED'. We can also see on the far right hand side, there is the Intranet Server. This is just a Cisco IOS router so we can test pings once we are done. You can also see all the IP addresses on all of the interfaces too.

Within the network at the moment, all the IP addresses are configured and there is an iBGP peering between R1 and R2. Lets quickly see how this is setup:

R1#sh run | sect bgp
router bgp 65001
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.1.5.2 remote-as 65001
 !
 address-family ipv4
  redistribute static
  neighbor 10.1.5.2 activate
 exit-address-family

R2#sh run | sect bgp
router bgp 65001
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.1.5.1 remote-as 65001
 !
 address-family ipv4
  network 172.16.4.0 mask 255.255.255.0
  neighbor 10.1.5.1 activate
 exit-address-family

We can see that R1 is redistributing static routes. Lets see what those are:

R1#sh ip route static | beg Gate
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
S        10.1.3.0/30 is directly connected, GigabitEthernet0/0
S        10.1.4.0/30 is directly connected, GigabitEthernet1/0
R1#sh run | inc ip route        
ip route 10.1.3.0 255.255.255.252 GigabitEthernet0/0
ip route 10.1.4.0 255.255.255.252 GigabitEthernet1/0

These are the only two static routes we will need for this configuration for leaking the routes. They ensure that the return traffic from the Intranet Server is routed back to the correct VRF. Without these two routes, the return traffic would be dropped on R1 as the global routing table wouldn't know about the /30 networks in the VRFs.

Lets check the routing tables on both R1 and R2:

R1#sh ip route | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
S        10.1.3.0/30 is directly connected, GigabitEthernet0/0
S        10.1.4.0/30 is directly connected, GigabitEthernet1/0
C        10.1.5.0/30 is directly connected, GigabitEthernet2/0
L        10.1.5.1/32 is directly connected, GigabitEthernet2/0
      172.16.0.0/24 is subnetted, 1 subnets
B        172.16.4.0 [200/0] via 10.1.5.2, 00:24:31

R2#sh ip route | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
B        10.1.3.0/30 [200/0] via 10.1.5.1, 00:24:34
B        10.1.4.0/30 [200/0] via 10.1.5.1, 00:24:34
C        10.1.5.0/30 is directly connected, GigabitEthernet2/0
L        10.1.5.2/32 is directly connected, GigabitEthernet2/0
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.4.0/24 is directly connected, GigabitEthernet3/0
L        172.16.4.1/32 is directly connected, GigabitEthernet3/0

So, R1 can see the 172.16.4.0/24 network hanging off R2, as we expect this is a BGP learnt route. Because we redistributed static routes into BGP on R1, we can see that R2 knows about the two /30 networks in the VRFs! These have the correct next hop of R1.

Lets test that R1 can ping the Intranet Server from the global routing table:

R1#ping 172.16.4.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/40/44 ms

From the above output, we can see that pings are succeeding. Now lets see what happens when we try and ping from the VRFs:

R1#ping vrf BLUE 172.16.4.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.100, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping vrf RED 172.16.4.100 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.100, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

As we can see this isn't working. As the VRFs don't have a route to the 172.16.4.0/24 network. Let's fix that!

Lets take a snapshot of the routes in the VRFs first:

R1#sh ip route vrf BLUE | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.3.0/30 is directly connected, GigabitEthernet0/0
L        10.1.3.1/32 is directly connected, GigabitEthernet0/0
R1#sh ip route vrf RED | beg Gateway 
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.4.0/30 is directly connected, GigabitEthernet1/0
L        10.1.4.1/32 is directly connected, GigabitEthernet1/0

Firstly, we need to configure a prefix list to match the Intranet Server subnet:

R1(config)#ip prefix-list PL_INTRANET_SUBNET seq 10 permit 172.16.4.0/24

Next, we need to create a route-map and match on the prefix list:

R1(config)#route-map RM_LEAK_INTRANET permit 10
R1(config-route-map)#match ip address prefix-list PL_INTRANET_SUBNET
R1(config-route-map)#exit

Finally, we need to use this route-map to import the prefix into both VRFs:

R1(config)#vrf definition BLUE
R1(config-vrf)#address-family ipv4
R1(config-vrf-af)#import ipv4 unicast map RM_LEAK_INTRANET
R1(config-vrf-af)#exit-address-family
R1(config-vrf)#exit
R1(config)#vrf definition RED
R1(config-vrf)#address-family ipv4
R1(config-vrf-af)#import ipv4 unicast map RM_LEAK_INTRANET
R1(config-vrf-af)#exit-address-family
R1(config-vrf)#exit

After waiting a few seconds for this to take effect. Lets have a look at the VRF routing tables now:

R1#sh ip route vrf BLUE | beg Gate
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.3.0/30 is directly connected, GigabitEthernet0/0
L        10.1.3.1/32 is directly connected, GigabitEthernet0/0
      172.16.0.0/24 is subnetted, 1 subnets
B        172.16.4.0 [200/0] via 10.1.5.2, 00:20:18
R1#sh ip route vrf RED | beg Gate 
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.4.0/30 is directly connected, GigabitEthernet1/0
L        10.1.4.1/32 is directly connected, GigabitEthernet1/0
      172.16.0.0/24 is subnetted, 1 subnets
B        172.16.4.0 [200/0] via 10.1.5.2, 00:16:24

We can now see that we have a BGP route to 172.16.4.0/24 in both VRF routing tables.

Now lets test those pings again from R1 initally:

R1#ping vrf BLUE 172.16.4.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/36 ms
R1#ping vrf RED 172.16.4.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/24 ms

As we can see, those pings are working from R1! Lets test on R5 and R6:

Note: R5 has a static default route pointing at 10.1.3.1 and R6 has one pointing at 10.1.4.1.

R5#ping 172.16.4.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/41/44 ms
R5#trace 172.16.4.100
Type escape sequence to abort.
Tracing the route to 172.16.4.100
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.3.1 16 msec 8 msec 12 msec
  2 10.1.5.2 20 msec 20 msec 20 msec
  3 172.16.4.100 32 msec 44 msec 40 msec

R6#ping 172.16.4.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/40/44 ms
R6#trace 172.16.4.100
Type escape sequence to abort.
Tracing the route to 172.16.4.100
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.4.1 12 msec 8 msec 8 msec
  2 10.1.5.2 24 msec 20 msec 20 msec
  3 172.16.4.100 32 msec 44 msec 44 msec

We now have connectivity out of the VRF and to the Intranet Server. We will also check to make sure that the VRFs are still unable to communicate with each other:

R5#ping 10.1.4.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.3.2, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)

R6#ping 10.1.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.3.2, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)

The VRFs are still unable to communicate which is what we want.