# An In-Depth Look at RD and RT, Pt. 2

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 <a href="#id-60a4166a-ea46-4689-9384-1d3c8dfd89b5" id="id-60a4166a-ea46-4689-9384-1d3c8dfd89b5"></a>

As a reminder, here’s our topology:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2Fc7fADuFS9HxIkJfn8o0Q%2Fimage.png?alt=media&#x26;token=6806bce1-3a27-4048-952a-8bfcffaadecc" alt=""><figcaption></figcaption></figure>

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 <a href="#d7294add-3d2a-4667-8b91-cead701f44fb" id="d7294add-3d2a-4667-8b91-cead701f44fb"></a>

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.
