Unique RD per PE per VRF is a deployment option in MPLS Layer 3 VPN.
I am explaining this topic in deep detail in my “BGP Zero to Hero” course.
In this post I will explain the different RD (Route Distinguisher) assignment options and at the end of the post, you will understand why you should assign unique RD per PE per VRF. Why RD (Route Distinguisher) is used in the first place ? RD is assigned on each and every VRF in MPLS Layer 3 VPN and it is used to make IP prefixes unique.
Let’s look at the below topology.
Figure - Unique RD per PE per VRF
Customer site is attached to two different PEs in the Service Provider network. Connecting the customer location to two different PE is a network best practice because it provides redundancy, thus increase availability of the customer service.
When customer site is connected to PE device in MPLS, customer circuit is placed in a VRF. So dataplane segmentation is achieved, but in addition to that, RD (Route Distinguisher) value is added to IPv4 prefixes to create a unique VPNv4 prefixes.
Imagine that this service provider has another customer which uses exactly the same IP address block with this customer, how service provider would differentiate the two in it’s network.
Same IP address would be problem , thus different addresses are created. But those different addresses are VPN addresses anymore, not the IP.
The rule is IPv4 (32bit) + RD (64bit) = VPNv4 (96bit) Now you understand why RD is used. But why different/unique RD on the different PEs or as a term ‘ Why unique RD per PE per VRF ? ‘ Per VRF mean, per VPN or per customer. All are the same things. In the above topology, I used VPN Route Reflector intentionally to illustrate the possible problem if you wouldn’t use unique RD per PE per VRF. PE 1 and PE 2 is connected to same customer site. Same prefixes will be advertised to both PEs.
When PE1 and PE2 receives IP prefixes, if there is no specific BGP policy (Local Pref- MED etc.), by default both PEs would choose their customer connection link as the best, so PE 1 will tell to BGP that I am the best, PE2 will tell to BGP that I am the best.
When both of these advertisements reach to BGP Route Reflectors, BGP Route Reflector will always choose only one best path and place that best path into the BGP and IP routing table and advertise to Route Reflector clients that path only.
In this case, PE3 would only receive one of the two possible exit point to the customer network. But for many reasons, such as BGP PIC (BGP FRR), IBGP Multipath, Med Oscillation prevention, Hot Potato routing and so on, PE3 would need to have two of those available exit points (PE 1 and PE2 in our topology). But RR doesn’t send unfortunately two of those paths, only one best path after best path calculation.
Unique RD per PE per VRF here comes into play !
When PE1 and PE2 are assigned with different RD values, BGP VPN Route Reflector doesn’t receive the same prefix anymore. Because with different RD, we created different prefixes.Yes we created VPN prefixes, that’s why the Route Reflector in MPLS VPN , is called VPN Route Reflector and it does the best path selection for the VPN prefixes.
Since with the different RDs we have different VPN prefixes, VPN Route Reflector doesn’t do best path selection comparison across this customer prefixes, PE3 receives the customer subnets with both PE1 and PE2 as exit point, next hop to this customer network.
So, as you can understand now, unique RD per PE per vrf (per customer) is used to send the available exit points to the internal BGP speaker when there is route reflector in the MPLS network.
If all these three PEs would be connected in a full mesh topology, then even with same RD per PE wouldn’t be an issue. But RR hides the path and we talked about it in the earlier posts.
Orhan Ergun, CCIE/CCDE Trainer, Author of Many Networking Books, Network Design Advisor, and Cisco Champion 2019/2020/2021
He created OrhanErgun.Net 10 years ago and has been serving the IT industry with his renowned and awarded training.
Wrote many books, mostly on Network Design, joined many IETF RFCs, gave Public talks at many Forums, and mentored thousands of his students.
Today, with his carefully selected instructors, OrhanErgun.Net is providing IT courses to tens of thousands of IT engineers.