In part two, we’ll play with the RD and RT values in our lab. In doing so, we’ll gain a better understanding of how RD and RT work.
Lab
As a reminder, here’s our topology:
The VRFs on PE1 and PE2 are currently configured as such:
CUSTOMER_A RD, RT=123:100
CUSTOMER_B RD, RT=123:200
For the next series of questions, try to reason through the answer on your own, using what you know about how RD and RT works. Then read on and lab along to prove the answer to yourself.
Question 1) What happens if we make the RD for CUSTOMER_A on PE1 123:1010 and keep the RD on PE2 as 123:100?
Let’s make the change:
#PE1
vrf definition CUSTOMER_A
no rd 123:100
rd 123:1010
! Deleting the RD automatically deleted the RTs and BGP config on CSR1000v
route-target export 123:100
route-target import 123:100
!
router bgp 123
address-family ipv4 vrf CUSTOMER_A
neighbor 100.64.1.2 remote-as 65000
neighbor 100.64.1.2 activate
The purpose of the RD is simply to keep the same prefix from different VRFs from overlapping with each other. Therefore, if PE1 and PE2 use different RD values, it should not matter. Remember, the RD is not used to associate the routes with a VRF. That is the job of the RT.
If we look at P3, we can see three different RDs now:
P3#show bgp vpnv4 uni all | begin Network
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 123:100
*>i 10.0.1.0/24 2.2.2.2 0 100 0 65001 i
Route Distinguisher: 123:200
*>i 10.0.0.0/24 1.1.1.1 0 100 0 65000 i
*>i 10.0.1.0/24 2.2.2.2 0 100 0 65001 i
Route Distinguisher: 123:1010
*>i 10.0.0.0/24 1.1.1.1 0 100 0 65000 i
PE2 still imports the route into the VRF, even though the RD is different. This proves that the RD is not used to import routes, only the RT is.
RP/0/0/CPU0:PE2#show route vrf CUSTOMER_A | begin Gateway
Mon Jul 18 02:34:54.027 UTC
Gateway of last resort is not set
B 10.0.0.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:01:16
B 10.0.1.0/24 [20/0] via 100.64.1.6, 02:41:19
C 100.64.1.4/30 is directly connected, 02:43:34, GigabitEthernet0/0/0/1
L 100.64.1.5/32 is directly connected, 02:43:34, GigabitEthernet0/0/0/1
RP/0/0/CPU0:PE2#show bgp vpnv4 uni vrf CUSTOMER_A 10.0.0.0/24
Mon Jul 18 02:35:30.334 UTC
BGP routing table entry for 10.0.0.0/24, Route Distinguisher: 123:100
Versions:
Process bRIB/RIB SendTblVer
Speaker 14 14
Last Modified: Jul 18 02:33:36.714 for 00:01:53
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65000
1.1.1.1 (metric 3) from 3.3.3.3 (1.1.1.1)
Received Label 19
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 0, version 14
Extended community: RT:123:100
Originator: 1.1.1.1, Cluster list: 3.3.3.3
Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 123:1010
Notice that the RD is 123:100 at the top, because that is the RD that PE2 configured for the VRF under BGP. However at the very bottom, we can see that the source RD is actually 123:1010. Notice the RT of 123:100 on the route from PE1, which is what controls whether the route is imported into the VRF on PE2.
Question 2) What happens if the VRF for CUSTOMER_A on PE1, and CUSTOMER_B on PE2 use the same RD?
Let’s change the RD for the CUSTOMER_A VRF on PE1 to 123:900, and change CUSTOMER_B on PE2 to 123:900
#PE1
vrf definition CUSTOMER_A
no rd 123:1010
! Wait a few seconds for the RD to be deleted
rd 123:900
! Deleting the RD automatically deletes the RTs and BGP config on CSR1000v
route-target export 123:100
route-target import 123:100
!
router bgp 123
address-family ipv4 vrf CUSTOMER_A
neighbor 100.64.1.2 remote-as 65000
neighbor 100.64.1.2 activate
#PE2
! First we must delete the BGP VRF config
no router bgp 123 vrf CUSTOMER_B
commit
router bgp 123
vrf CUSTOMER_B
rd 123:900
address-family ipv4 unicast
!
neighbor 100.64.2.6
remote-as 65001
address-family ipv4 unicast
route-policy PASS_ALL in
route-policy PASS_ALL out
Now let’s advertise the same prefix from CE1 and CE4
#CE1
int lo10
ip address 10.10.10.1 255.255.255.0
!
router bgp 65000
network 10.10.10.0 mask 255.255.255.0
#CE4
int lo10
ip address 10.10.10.1 255.255.255.0
!
router bgp 65001
network 10.10.10.0 mask 255.255.255.0
P3 now has two 10.10.10.0/24 prefixes with the same RD. It has to choose the best route, and chooses the lowest RID (PE1)
P3#show bgp vpnv4 uni all | be Network
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 123:100
*>i 10.0.1.0/24 2.2.2.2 0 100 0 65001 i
Route Distinguisher: 123:200
*>i 10.0.0.0/24 1.1.1.1 0 100 0 65000 i
Route Distinguisher: 123:900
*>i 10.0.0.0/24 1.1.1.1 0 100 0 65000 i
*>i 10.0.1.0/24 2.2.2.2 0 100 0 65001 i
* i 10.10.10.0/24 2.2.2.2 0 100 0 65001 i
*>i 1.1.1.1 0 100 0 65000 i
What is the result of this? CE2 does not receive the 10.10.10.0/24 prefix from CE4.
CE2#show bgp | be Network
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.1.0/24 100.64.2.1 0 123 65001 i
Also, CE3 does not receive the route from CE1. Why is this? Didn’t P3 choose the route from PE1 as best? Yes, but PE2 is also advertising the same exact route, so PE2 prefers its eBGP route and will not import the route from PE1 (which was reflected by P3).
RP/0/0/CPU0:PE2#show bgp vpnv4 uni rd 123:900 | be Network
Mon Jul 18 03:15:53.928 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 123:900 (default for vrf CUSTOMER_B)
*>i10.0.0.0/24 1.1.1.1 0 100 0 65000 i
* i 1.1.1.1 0 100 0 65000 i
*> 10.0.1.0/24 100.64.2.6 0 0 65001 i
* i10.10.10.0/24 1.1.1.1 0 100 0 65000 i
*> 100.64.2.6 0 0 65001 i
Before moving on, we’ll change the RD values back to what they were originally:
#PE1
vrf definition CUSTOMER_A
no rd 123:900
! Wait a few seconds for the RD to be deleted
rd 123:100
! Deleting the RD automatically deletes the RTs and BGP config on CSR1000v
route-target export 123:100
route-target import 123:100
!
router bgp 123
address-family ipv4 vrf CUSTOMER_A
neighbor 100.64.1.2 remote-as 65000
neighbor 100.64.1.2 activate
#PE2
! First we must delete the BGP VRF config
no router bgp 123 vrf CUSTOMER_B
commit
router bgp 123
vrf CUSTOMER_B
rd 123:200
address-family ipv4 unicast
!
neighbor 100.64.2.6
remote-as 65001
address-family ipv4 unicast
route-policy PASS_ALL in
route-policy PASS_ALL out
Question 3) What happens if we change the VRF for CUSTOMER_A to import 123:100 and export 123:101 on PE1?
#PE1
vrf definition CUSTOMER_A
route-target export 123:101
no route-target export 123:100
! import is already 123:100
What does the routing table on CE1 and CE3 look like now?
CE1 still has the same 10.0.1.0/24 prefix learned from CE3. This is because PE2 is still exporting 123:100 which PE1 is importing into the VRF.
However, CE3 has lost all BGP routes.
CE3#show bgp sum | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
100.64.1.5 4 123 5750 6301 14 0 0 3d23h 0
This is because PE2 sees the routes with only an RT of 123:101, and it only imports routes that have an RT of 123:100.
Let’s add 123:100 back in as an additional RT to PE1 for VRF CUSTOMER_A
#PE1
vrf definition CUSTOMER_A
route-target export 123:100
!
PE1#show vrf detail CUSTOMER_A
VRF CUSTOMER_A (VRF Id = 1); default RD 123:100; default VPNID <not set>
New CLI format, supports multiple address-families
Flags: 0x180C
Interfaces:
Gi2
Address family ipv4 unicast (Table ID = 0x1):
Flags: 0x0
Export VPN route-target communities
RT:123:101 RT:123:100
Import VPN route-target communities
RT:123:100
No import route-map
No global export route-map
No export route-map
VRF label distribution protocol: not configured
VRF label allocation mode: per-prefix
Address family ipv6 unicast not active
Address family ipv4 multicast not active
Address family ipv6 multicast not active
As you can see there are now two export RTs. PE1 adds both RTs to all Updates for prefixes originating from the CUSTOMER_A VRF.
On PE2, as long as there is one RT that matches 123:100, it will import the routes into the CUSTOMER_A VRF. We can see BGP routes again on CE3:
CE3#show bgp sum | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
100.64.1.5 4 123 5754 6305 16 0 0 3d23h 2
Conclusion
Hopefully these exercises have hammered the role and function of RD and RT into your head. In the next part, we will play with the RD as a traffic engineering technique.
