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
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:
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:
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.
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
Now let’s advertise the same prefix from CE1 and CE4
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)
What is the result of this? CE2 does not receive the 10.10.10.0/24 prefix from CE4.
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).
Before moving on, we’ll change the RD values back to what they were originally:
Question 3) What happens if we change the VRF for CUSTOMER_A to import 123:100 and export 123:101 on PE1?
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.
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
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:
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.
Last updated