Ivy Consultants Inc.

Consulting Services for Security, Networking, Wi-Fi and Windows Server

The Route-Distinguisher (RD) & Route-Target (RT) are two different concepts that are both used in an MPLS VPN. The RD is used to keep all prefixes in the BGP table unique, and the RT is used to transfer routes between VRF’s/VPNS. Let’s take a look at an example.

In the diagram below, the orange = customer A, and the red = customer B.  The ISP is creating a VPN for Customer A’s sites between Cambridge and Birmingham, and also creating a VPN between Customer B’s sites in Cambridge and Birmingham.

The problem here, is that in Birmingham, Customer A and Customer B are using the same prefixes (10.1.0.0/24 & 10.2.0.0/24). So how is PE2 going to keep the prefixes in the BGP table unique? The answer is, PE2 needs to create a separate  RD for each customer. An RD is a 64 bit value that gets prepended in front of the 32 bit IP address in order to make a globally unique 96 bit address. On PE2 if we configure Customer A to use an RD of 1:1, and Customer B with an RD of 2:2, then in the BGP vpnv4 unicast table we will see the following entries:

1:1:10.1.0.0/24

1:1:10.2.0.0/24

2:2:10.1.0.0/24

2:2:10.2.0.0/24

So by pre-pending an RD in front of the route, we have created a globally unique set of BGP prefixes in the vpnv4 BGP table that can be shared between peers. The next question is, how does PE1 know which of these routes belong to Customer A, and which of these routes belong to Customer B? All we’ve done so far is just ensure the routes are globally unique in the vpnv4 BGP table. The table currently contains 4 entries that are literally just considerd prefixes (although it’s very wierd to look at). So the answer is; by using a route-target. A route target is kind of like a little tag that is attached to a route. So PE2 may add, let’s say 100:100 to routes from Customer A in Birmingham, then when PE1 checks the vpnv4 BGP table he can choose to pick out (import) routes that have this 100:100 value and put them into a separate Virtual Routing & Forwarding (VRF) table for Customer A. The configuration regarding RD’s and RT’s is displayed below.

PE2

vrf definition CustomerA

 rd 1:1

 route-target import 100:100

 route-target export 100:100

int fa0/0

 description connection to Customer A Birmingham Site

 ip vrf forwarding CustomerA

So from the output, you can see that Customer A routes are made unique by prepending an RD of 1:1 to each prefix. Each route is assigned a route-target of 100:100 because of the VRF association with the interface. PE2 then exports this route target so that each of the routes will have 100:100 attached in the RT field within the BGP extended community attribute as they are sent to PE1.  PE1 can then import the route-target of 100:100 so that it can associate those routes tagged with this value with the Customer A VRF.

Summary

The RD is used purely for the purpose of ensuring routes are unique per VPN.  So 10 different VPN’s could use 10.0.0.0/24, and each instance of this prefix would be globally unique. The route-target is used to identify a subset of routes within the BGP vpnv4 unicast table that should be used in a VRF for a particular customer.