VRF, Route Distinguishers and Route Targets – For communication between Border and Fusion

This article assumes that you have basic working knowledge of BGP neighbor formation, route advertisement, redistribution and address family.

 

VRF – Breaking down single router into multiple virtual routers, with each router having a unique routing table. This can be helpful in many situations for e.g. if you are a service provider and managing multiple customers from a single router and want to keep their routes in a separate table. In our case SDA creates multiple Virtual Networks and each virtual network is equal to a unique VRF.

Route Distinguisher (RD) – It helps keep routes (prefixes) unique in BGP routing table (database). Each VRF is given a route distinguisher,  it helps keeping the prefix unique in the database. RD consists of 64 bit value, first 32 bit can be BGP Autonomous systems number (ASN), second 32 bit can be any number unique to a VRF. In an example below, unique RD are assigned to each VRF A and B respectively.

delete3

Route Targets (RT) – it looks similar to RD, but has a completely different role. Route targets keep route unique when passing through one router to another through a link which is in global or default VRF and when the other router receives it, RT can be used to put route in the right VRF table.

delete4

In this example we will perform following task.

  1. Configure 3 VRFs, A, B, C respectively and their RD
  2. Assigned interfaces in these VRF, configure BGP.
  3. Advertise route into BGP.
  4. Ensure each VRF learn about all the route on both sides (RT usage)
  5. Use route-targets to advertise leak routes from one VRF to another.

Why is matters, because in SDA network, you will require to sync BORDER and FUSION router and leak routes from FUSION global routing table (like DHCP, DNS etc.) into other VRF tables (your VNs) for the VNs to be able to use services like DHCP, DNS etc. so understanding how RD and RT are used is important.

  1. Configure 3 VRFs, A, B, C respectively and their RD

R1

ip vrf A

 rd 65000:1

!

ip vrf B

rd 65000:2

 

R2

ip vrf A

rd 65000:1

!

ip vrf B

rd 65000:2

!

ip vrf C

rd 65000:3

  1. Assigned interfaces in these VRF, configure BGP.

R1

interface Loopback1

ip vrf forwarding A

ip address 1.1.1.1 255.255.255.255

!

interface Loopback2

ip vrf forwarding A

ip address 1.1.1.2 255.255.255.255

!

interface Loopback3

ip vrf forwarding B

ip address 1.1.1.3 255.255.255.255

!

interface Loopback4

ip vrf forwarding B

ip address 1.1.1.4 255.255.255.255

!

interface FastEthernet0/0

ip address 10.10.10.1 255.255.255.0

 

router bgp 65000

bgp log-neighbor-changes

neighbor 10.10.10.2 remote-as 65000

 

R2

interface Loopback1

ip vrf forwarding A

ip address 2.2.2.1 255.255.255.255

!

interface Loopback2

ip vrf forwarding C

ip address 2.2.2.2 255.255.255.255

!

interface Loopback3

ip vrf forwarding C

ip address 2.2.2.3 255.255.255.255

!

interface Loopback4

ip vrf forwarding C

ip address 2.2.2.4 255.255.255.255

!

interface Loopback5

ip vrf forwarding C

ip address 2.2.2.5 255.255.255.255

!

interface FastEthernet0/0

ip address 10.10.10.2 255.255.255.0

duplex auto

speed auto

tag-switching ip

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

router bgp 65000

bgp log-neighbor-changes

neighbor 10.10.10.1 remote-as 65000

R2#sh ip vrf

  Name                             Default RD          Interfaces

  A                                     65000:1             Loopback1

  B                                     65000:2             Loopback2

                                                                     Loopback3

  C                                     65000:3             Loopback4

                                                                     Loopback5

R2#sh ip bgp summary

BGP router identifier 10.10.10.2, local AS number 65000

BGP table version is 1, main routing table version 1

 

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.10.10.1      4 65000     128     132        1    0    0 00:46:42        0

 

  1. Advertise route into BGP.

R1

router bgp 65000

!

address-family ipv4 vrf B

no auto-summary

no synchronization

network 1.1.1.3 mask 255.255.255.255

network 1.1.1.4 mask 255.255.255.255

exit-address-family

!

address-family ipv4 vrf A

no auto-summary

no synchronization

network 1.1.1.1 mask 255.255.255.255

network 1.1.1.2 mask 255.255.255.255

exit-address-family

R2

address-family ipv4 vrf C

no auto-summary

no synchronization

network 2.2.2.4 mask 255.255.255.255

network 2.2.2.5 mask 255.255.255.255

exit-address-family

!

address-family ipv4 vrf B

no auto-summary

no synchronization

network 2.2.2.2 mask 255.255.255.255

network 2.2.2.3 mask 255.255.255.255

exit-address-family

!

address-family ipv4 vrf A

no auto-summary

no synchronization

network 2.2.2.1 mask 255.255.255.255

exit-address-family

R2#sh ip bgp vpnv4 all

BGP table version is 29, local router ID is 10.10.10.2

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal

Origin codes: i – IGP, e – EGP, ? – incomplete

 

   Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 65000:1 (default for vrf A)

*> 2.2.2.1/32       0.0.0.0                  0         32768 i

Route Distinguisher: 65000:2 (default for vrf B)

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

*> 2.2.2.3/32       0.0.0.0                  0         32768 i

Route Distinguisher: 65000:3 (default for vrf C)

*> 2.2.2.4/32       0.0.0.0                  0         32768 i

*> 2.2.2.5/32       0.0.0.0                  0         32768 i

  1. Ensure each VRF learn about all the route on both sides (RT usage)

At this point lets look at the routing table

R1#sh ip route vrf A

     1.0.0.0/32 is subnetted, 2 subnets

C       1.1.1.1 is directly connected, Loopback1

C       1.1.1.2 is directly connected, Loopback2

R1#sh ip route vrf B

     1.0.0.0/32 is subnetted, 2 subnets

C       1.1.1.3 is directly connected, Loopback3

C       1.1.1.4 is directly connected, Loopback4

R1#sh ip route

     10.0.0.0/24 is subnetted, 1 subnets

C       10.10.10.0 is directly connected, FastEthernet0/0

Notice routes even within same VRF are not learned, and it’s because the link connecting the 2 routers is in global routing table, this is where RT can be helpful, it can carry routes with a TAG between 2 routers and out the routes in the right VRF table. The routes with TAG can be either imported or exported into or from a routing table from one router to another.

R1

ip vrf A

rd 65000:1

route-target export 65000:1

route-target import 65000:1

!

ip vrf B

rd 65000:2

route-target export 65000:2

route-target import 65000:2

!

Router bgp 65000

address-family vpnv4

neighbor 10.10.10.2 activate

R2

ip vrf A

rd 65000:1

route-target export 65000:1

route-target import 65000:1

!

ip vrf B

rd 65000:2

route-target export 65000:2

route-target import 65000:2

!

ip vrf C

rd 65000:3

route-target export 65000:3

route-target import 65000:3

!

Router bgp 65000

address-family vpnv4

neighbor 10.10.10.1 activate

Let’s look at the routing table again.

R1#sh ip route vrf A

     1.0.0.0/32 is subnetted, 2 subnets

C       1.1.1.1 is directly connected, Loopback1

C       1.1.1.2 is directly connected, Loopback2

     2.0.0.0/32 is subnetted, 1 subnets

B       2.2.2.1 [200/0] via 10.10.10.2, 00:02:48

R1#sh ip route vrf B

     1.0.0.0/32 is subnetted, 2 subnets

C       1.1.1.3 is directly connected, Loopback3

C       1.1.1.4 is directly connected, Loopback4

     2.0.0.0/32 is subnetted, 2 subnets

B       2.2.2.2 [200/0] via 10.10.10.2, 00:02:54

B       2.2.2.3 [200/0] via 10.10.10.2, 00:02:54

R2#sh ip route vrf A

     1.0.0.0/32 is subnetted, 2 subnets

B       1.1.1.1 [200/0] via 10.10.10.1, 00:03:14

B       1.1.1.2 [200/0] via 10.10.10.1, 00:03:14

     2.0.0.0/32 is subnetted, 1 subnets

C       2.2.2.1 is directly connected, Loopback1

R2#sh ip route vrf B

     1.0.0.0/32 is subnetted, 2 subnets

B       1.1.1.3 [200/0] via 10.10.10.1, 00:03:18

B       1.1.1.4 [200/0] via 10.10.10.1, 00:03:18

     2.0.0.0/32 is subnetted, 2 subnets

C       2.2.2.2 is directly connected, Loopback2

C       2.2.2.3 is directly connected, Loopback3

R2#sh ip route vrf C

     2.0.0.0/32 is subnetted, 2 subnets

C       2.2.2.4 is directly connected, Loopback4

C       2.2.2.5 is directly connected, Loopback5

5. Use route-targets to advertise leak routes from one VRF to another.

This time routes have been learned within same VRF using RT, for e.g. VRF A is exporting the routes with tag 65000:1 and VRF A is importing routes with tag 65000:1, so it gets into its routing table, by this simple login, if VRF A wanted to get a route from VRF C, all it needs to so is import the routes with tag 65000:3, which is the export tag for VRF C, so lets do that.

R1

ip vrf A

rd 65000:1

route-target export 65000:1

route-target import 65000:1

route-target import 65000:3

R1#sh ip route vrf A

     1.0.0.0/32 is subnetted, 2 subnets

C       1.1.1.1 is directly connected, Loopback1

C       1.1.1.2 is directly connected, Loopback2

     2.0.0.0/32 is subnetted, 3 subnets

B       2.2.2.1 [200/0] via 10.10.10.2, 00:08:26

B       2.2.2.4 [200/0] via 10.10.10.2, 00:00:40

B       2.2.2.5 [200/0] via 10.10.10.2, 00:00:40

2.2.2.4 and 2.2.2.5 are VRF C routes which are imported into VRF A routing table, we have effectively leaked routes from one VRF into another. In SDA context think of importing routes to reach services like DHCP, DNS etc. from one of the virtual networks. We could also have leaked specific route from VRF C into VRF A using route-maps and ACLs.

Once the route are leaked between VRFs the global routing table needs to be leaked into VRF as well for specific services.

R1

ip prefix-list GLOBAL_PREFIX seq 2 permit 10.10.10.0/24

ip prefix-list VRFA_PREFIX seq 2 permit 1.1.1.1/32

ip prefix-list VRFA_PREFIX seq 4 permit 1.1.1.2/32

route-map GLOBAL_MAP 10

match ip add prefix-list GLOBAL_PREFIX

route-map VRFA_MAP 10

match ip add prefix-list VRFA_PREFIX

ip vrf A

import ipv4 unicast map GLOBAL_MAP

export ipv4 unicast map VRFA_PREFIX

Cisco has another documentation which you can refer as well for border and fusion communication, this article compliments Cisco’s document, as this article focuses on RD and RT concepts only.

https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/dna-center/213525-sda-steps-to-configure-fusion-router.html

I hope you enjoyed reading this, as much as I enjoyed writing.