Route Distinguisher and Route Target … what are they for? aren’t they the same thing? why not to use only one of them for VPNs instead of the two? is it really necessary to have those two things? 
I guess many of you got these same questions. At least it happened to me the first time I learned about MPLS VPNs. I will try to explain the difference between them and why it’s necessary to have these two elements for MPLS VPNs environments.
First, let’s have a look at MPLS VPNs technology.
MPLS VPNs gives the opportunity to use the same MPLS backbone for different customers or services without each one interacting with the other. It’s pretty common to find different clients using the same private range of IP addresses. How could an ISP company offer its infrastructure to give connectivity to different remote sites to customer “Cocke” and to customer “Pepsy” without mixing their routing info? Can you imagine the headlines on the news if Cocke Sales Department suddenly gets into the Pepsy Production Department because the ISP mixed their routing? By the way, Cocke and Pepsy are my imaginary Spanish refreshing drinks companies, any similarity with reality is pure coincidence
.
MPLS VPNs gives the opportunity to use the same MPLS backbone for different customers or services without each one interacting with the other. It’s pretty common to find different clients using the same private range of IP addresses. How could an ISP company offer its infrastructure to give connectivity to different remote sites to customer “Cocke” and to customer “Pepsy” without mixing their routing info? Can you imagine the headlines on the news if Cocke Sales Department suddenly gets into the Pepsy Production Department because the ISP mixed their routing? By the way, Cocke and Pepsy are my imaginary Spanish refreshing drinks companies, any similarity with reality is pure coincidence
.
So here comes the first necessary element. I need to make the address of each site unique in the network. Both customers may use the same range of IP addresses (for example the well known 10.0.0.0/8 range), so I need to add something to each address to make it unique and different from each other. That’s what the Route Distinguisher is used for.
With the Route Distinguisher, we transform an IP address of 32 bits length into an address of 96 bits length, unique in the network. So PEs don’t announce 32-bits length IP addresses via multiprotocol BGP, but a 96-bit length prefix.
What is the format of these new 64 extra bits? Well, there are two possible formats, that I describe as follows:
The RD used within a network is entirely up to the discretion of the network administrators. Although there are some best practices such as using the Autonomous System value for the 2 octets of Administrator field if we use the first format, or using the Router ID for the 4 octets of Administrator field if we use the second format . In both cases, the value placed in the Assigned Number field is left to the discretion of the administrator.
PE1(config)#ip vrf Cocke-SiteA PE1(config-vrf)#rd 10.10.10.1:1 PE1(config-vrf)#do sh ip vrf Name Default RD Interfaces Cocke-SiteA 10.10.10.1:1 PE1(config-vrf)#no rd 10.10.10.1:1 PE1(config-vrf)#rd 65002:1 PE1(config-vrf)#do sh ip vrf Name Default RD Interfaces Cocke-SiteA 65002:777
Now the question is: should I use the same Route Distinguisher for all the sites (VRFs) of the same client? or should I use a different Route Distinguisher per site? Well, it depends on what we are looking for.
For example, let’s imagine that Cocke headquarters connect to my MPLS network through two PEs, not only to get redundancy, but also to load balance the traffic from different remote sites.
If I use the same Route Distinguisher at PE1 and PE2 for the Cocke VRF, both PEs would have the same Route Distinguisher, which means they would announce the exact same 96-bits long prefixes to the Route-Reflector. The RR would make a decision of which prefixes to choose, since it got the same prefixes from two different sources (PE1 and PE2). Let’s imagine it chooses the prefixes coming from PE1, so after choosing those prefixes, the RR would announce this final decision to the remote sites, the remote sites would have only the prefixes coming from PE1. I didn’t get load balance with this design.
Ok, let’s try it again, but this time using different Route Distinguisher for PE1 and PE2. Then the RR would receive two different 96-bits long prefixes. As both prefixes are different because they have different Route Distinguisher, the RR doesn’t make any decision. It instead reflects both prefixes to all the remote sites. So eventually the remote sites would have two prefixes for the same site. When importing those prefixes to the VRF, the PE will decide which one to use in order to reach the Headquarters. So, magically, some remote sites would choose PE1 and some others PE2. And here we go, load balancing the traffic.
We have seen that Route Distinguisher is for making the client’s addressing unique in the network and for achieving load balance in some cases. Do I really need something else? Could I use the Route Distinguisher alone to import and export addresses from one VRF to the other? Well, I could, but it wouldn’t give me much flexibility to build some interesting scenarios.
Route Target is a 64-bits BGP community used for tagging prefixes. When exporting prefixes from the VRF, we add to the prefixes a Route-Target community, so when the PE in the remote site has to import prefixes into the VRF, it can easily identify which prefixes to import.
Let’s imagine we are using the same RD for all the Cocke sites, but I don’t want to allow all sites connect to all sites. I mean, I could make Site-2 have visibility of the prefixes of Site-1, but not for Site-3. And the same for Site-3, I could make it has visibility of Site-1 but not to Site-2. How can I make this differentiation if all of them have the same Route Distinguisher? This is a typical scenario where different Route-Targets in the same VPN client apply. I could apply the Route-Target 1:1 for Site-1, 1:2 for Site-2 and 1:3 for Site-3. In that case Site-1 could import Route-Targets 1:2 and 1:3 in order to have connectivity with both sites. But Site-2 would import only Route-Target 1:1 (the one of Site-1), and the same for Site-3. These two sites wouldn’t have connectivity between them.
Another scenario would be when I use different RDs for the same site, in order to achieve load-balance. If I used only the RD for exporting prefixes, I would have to configure two import statements in each PE, each one for each RD I have. With Route-Targets, that’s simpler. Although I have different RDs, I could apply the same Route-Target to all sites when exporting prefixes, so in order to import prefixes, I would have to use only one statement, because all prefixes have the same Route-Target.
PE1(config)#ip vrf Cocke-Site1 PE1(config-vrf)#rd 10.10.10.1:1 PE1(config-vrf)#route-target export 1:1 PE1(config-vrf)#route-target import 1:1
In order to see the Route-Target of a received prefix in a PE, we have to use the command show ip bgp vpnv4 all followed by the prefix.
PE1#sh ip bgp vpnv4 all
BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:100 (default for vrf Cocke-Site1)
*> 100.100.100.0/24 0.0.0.0 0 32768 ?
*>i200.200.200.0 2.2.2.2 0 100 0 ?
Route Distinguisher: 2.2.2.2:200
*>i200.200.200.0 2.2.2.2 0 100 0 ?
PE1#
PE1#sh ip bgp vpnv4 all 200.200.200.0
BGP routing table entry for 1.1.1.1:100:200.200.200.0/24, version 3
Paths: (1 available, best #1, table Cocke-Site1)
Not advertised to any peer
Local, imported path from 2.2.2.2:200:200.200.200.0/24
2.2.2.2 (metric 11) from 2.2.2.2 (2.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:100:1 mpls labels in/out nolabel/17
....
Conclusions
We can conclude that the Route Distinguisher is there for making the prefixes of a VPN unique in the MPLS network, so the issue of having customers with overlapping IP addresses between different VPNs is solved. We can also play with the 64-bits lenght parameter to achieve load-balancing between PEs connected to the same site.
The Route-Target is a 64-bits BGP community used to tag the prefixes exported from an VPN. Tagging the prefixes with a Route-Target allows us to play with complex VPN environments, choosing which prefixes we want to import based on the Route-Target.
