Using BGP For Inter-VRF Route Leaking

Introduction

I guess you know you are a network geek when a blog post with a title like this gets your juices flowing…indeed I am a network geek and if that title gets you excited as well, you are in the right place.

This will be a short post on how to go about leaking routes between different VRFs.  I will basically be implementing my own version of what is presented here by Cisco.  You may be familiar with route leaking between the global routing table and a VRF using static routes.  This is a simple and easy way to do things, but unfortunately that method does not work when going between two separate VRFs. For that to work, we need to use MP-BGP and it’s properties of route-target import/export as sort of a “middle man”.  In this example, I like to think of BGP as sort of a route launderer…Two routers in two different VRFs need to talk to each other, but the routes have to be “laundered” through our BGP middle man.  Let’s take a look at the topology

Quick explanation of things.  Imagine R2 is a service provider PE router providing services to two different clients, “REDWINGS” and “TIGERS”.  Each organization of course has it’s own VRF instance on R2.  The problem is that R1 wants to be able to talk to R4 over in the other VRF and visa versa.  Since the two networks will exist in different VRFs, we need to introduce BGP to leak the routes between VRFs.  Even though we won’t be configuring any BGP peerings or anything, we need to use BGP to share these routes.

 

Initial Configurations

R1

interface FastEthernet0/0
 ip address 12.12.12.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 12.12.12.2

R2

ip vrf REDWINGS
 rd 100:1
 route-target export 100:1
 route-target import 100:1
 route-target import 100:2
!
ip vrf TIGERS
 rd 100:2
 route-target export 100:2
 route-target import 100:2
 route-target import 100:1
!
!
interface FastEthernet0/0.12
 encapsulation dot1Q 12
 ip vrf forwarding REDWINGS
 ip address 12.12.12.2 255.255.255.0
!
interface FastEthernet0/0.24
 encapsulation dot1Q 24
 ip vrf forwarding TIGERS
 ip address 24.24.24.2 255.255.255.0

R4

interface Ethernet0/0
 ip address 24.24.24.4 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 24.24.24.2

OK, so we threw some IP addresses on R1 and R4 and added a static default route on each pointing to R2.  Simple enough.  R2 is a tad bit more interesting.  We create the VRFs, assign the VRFs to our interfaces, and assign our IP addresses.  The magic part here is in the VRF definition with the route-target command. VRF REDWINGS exports 100:1 but imports both 100:1 and 100:2.  TIGERS does the opposite, exporting 100:2 and importing both 100:2 and 100:1. This logic is what later fits in with BGP to end up sharing the routes between VRFs

 

A Little BGP Magic

 

Here is the finishing touch — We configure BGP on R2 as follows

router bgp 100
 no synchronization
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 no auto-summary
 !
 address-family ipv4 vrf TIGERS
  redistribute connected
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf REDWINGS
  redistribute connected
  no synchronization
 exit-address-family

What we are doing here is telling BGP to run inside each of our VRFs. We then redistribute connected routes from those VRFs into BGP. This is where the real magic happens. Let’s run through the REDWINGS VRF here. In the REDWINGS VRF we have a directly connected route of 12.12.12.0/24 on R2. When we redistribute that directly connected route into the BGP instance running in VRF REDWINGS what happens is the route gets exported from VRF REDWINGS with a RT of 100:1. We can see that here

R2#sh ip bgp vpnv4 vrf REDWINGS 12.12.12.0
BGP routing table entry for 100:1:12.12.12.0/24, version 6
Paths: (1 available, best #1, table REDWINGS)
  Not advertised to any peer
  Local
    0.0.0.0 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:100:1
      mpls labels in/out 17/nolabel(REDWINGS)

Once that happens, R2 looks at the RT 100:1 and says “Do I have any VRFs that want to import routes with that RT?” Indeed, it does as VRF TIGERS is configured to import RT 100:1. So, it goes ahead and does that, bringing 12.12.12.0 into VRF TIGERS as shown below

R2#sh ip bgp vpnv4 vrf TIGERS 12.12.12.0
BGP routing table entry for 100:2:12.12.12.0/24, version 7
Paths: (1 available, best #1, table TIGERS)
  Not advertised to any peer
  Local, imported path from 100:1:12.12.12.0/24
    0.0.0.0 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 0, localpref 100, weight 32768, valid, external, best
      Extended Community: RT:100:1
      mpls labels in/out nolabel/nolabel(TIGERS)

The opposite happens the other way — When R2 redistributes connected from VRF TIGERS it exports the 24.24.24.0/24 route with an RT of 100:2. BGP then imports it into VRF REDWINGS. This is a simple example, but you could also do this between different routing protocols if you wanted instead of just connected routes. Here is another command output. Notice that both routes are in both VRFs at this point

R2#sh ip bgp vpnv4 all
BGP table version is 7, local router ID is 2.2.2.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: 100:1 (default for vrf REDWINGS)
*> 12.12.12.0/24    0.0.0.0                  0         32768 ?
*> 24.24.24.0/24    0.0.0.0                  0         32768 ?

Route Distinguisher: 100:2 (default for vrf TIGERS)
*> 12.12.12.0/24    0.0.0.0                  0         32768 ?
*> 24.24.24.0/24    0.0.0.0                  0         32768 ?

All we have left to do is the obligatory test…

R1#ping 24.24.24.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 24.24.24.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Looking good!

 

Summary

 

So, there you have it — How to leak routes between VRFs using BGP.  The two main things to understand to grasp this concept are VRF route-targets and BGP address families.  Although we didn’t use any actual MPLS here, this technique could certainly be seen in an MPLS VPN scenario.  In essence, we are using BGP as a middle man to move routes from one VRF to another.  One VRF exports it’s routes into BGP (when redistribution happens) with a RT value that is then imported by the other VRF.  By nature of being in BGP and the routing table for the other VRF we have reachability.

 

Tags: , , , , , , , , , , , ,

3 Comments

Leave a Reply