Route Distinguishers and Route Targets

People new to MPLS VPN are often unclear on what functions route distinguishers and route targets serve, and the difference between the two. Let's see if we can clear up some of that confusion. If you could use a refresher on VRF fundamentals, I encourage you to first check out my earlier articles on the topic, Intro to VRF Lite and Inter-VRF Routing with VRF Lite.

Route Distinguisher

As you know, VRFs allow IP address space to be reused among isolated routing domains. For example, assume you have to connect to three customer sites, all of which are using 192.168.0.0/24 as their local network. We can assign each customer its own VRF so that the overlapping networks are kept isolated from one another in their respective routing domains.

This works well, but we need a way to keep track of which 192.168.0.0/24 route belongs to which customer. This is where route distinguishers come in. As its name implies, a route distinguisher (RD) distinguishes one set of routes (one VRF) from another. It is a unique number prepended to each route within a VRF to identify it as belonging to that particular VRF or customer. An RD is carried along with a route via MP-BGP when exchanging VPN routes with other PE routers.

An RD is 64 bits in length comprising three fields: type (two bytes), administrator, and value. There are currently three defined formats which can be used by a provider:

The choice of format is largely cosmetic: It makes no difference to BGP as the RD is effectively just a flat number prepended to a route. The choice of formats exists solely to allow for flexible administration of the number space.

Here's an example IOS config showing RDs assigned to VRFs using the two-byte AS format. The type is implied by the format in which we've assigned the RD.

ip vrf Site_A
 rd 65000:10
!
ip vrf Site_B
 rd 65000:20
!
ip vrf Site_C
 rd 65000:30

When VPN routes are advertised among PE routers via MP-BGP, the RD is included as part of the route along with the IP prefix. For example, a route for 192.0.2.0/24 in VRF Site_B is effectively advertised as 65000:20:192.0.2.0/24 (ignoring some complexities concerning the actual prefix length).

Route Targets

Whereas route distinguishers are used to maintain uniqueness among identical routes in different VRFs, route targets can be used to share routes among them. We can apply route targets to a VRF to control the import and export of routes among it and other VRFs.

A route target takes the form of an extended BGP community with a structure similar to that of a route distinguisher (which is probably why the two are so easily confused). One or more route targets can be affixed to routes within a VRF using the VRF configuration command route-target export:

ip vrf Customer_A
 rd 65000:100
 route-target export 65000:100

Routes contained within this VRF will be exported with an RT of 65000:100. We can use Wireshark to examine precisely how this information is carried in an MP-BGP update:

In practice, we typically want all instances of a VRF across the network to learn about all other routes within that VRF on neighboring routers. So, we add a second statement to enable importation as well:

ip vrf Customer_A
 rd 65000:100
 route-target export 65000:100
 route-target import 65000:100

(Tip: You can use the shortcut command route-target both as a macro to add both commands simultaneously. Both commands will show up separately in the running configuration.)

Now, this VRF will export its own routes with an RT of 65000:100 as well as import any routes exported from other VRFs tagged with 65000:100. It makes sense to reuse the VRF's RD as a route target here, but this isn't a hard rule. (Remember, route targets are just numeric tags: We can use whatever values we want.)

Next, let's say both customers A and B need to import routes from a third VRF named Shared. We can configure the two customer VRFs to also import routes tagged with the Shared VRF's export RT of 65000:300:

ip vrf Customer_A
 rd 65000:100
 route-target export 65000:100
 route-target import 65000:100
 route-target import 65000:300
!
ip vrf Customer_B
 rd 65000:200
 route-target export 65000:200
 route-target import 65000:200
 route-target import 65000:300
!
ip vrf Shared
 rd 65000:300
 route-target export 65000:300
 route-target import 65000:300

VRFs Customer_A and Customer_B will now import routes exported from VRF Shared in addition to their own "native" routes. To complete our VRF configuration, VRFs Customer_A and Customer_B also need to export their native routes to VRF Shared. But wait a minute. If we configure the customer VRFs to export to 65000:300, they'll end up learning each other's routes, because both are already importing 65000:300. We don't want that!

The solution here is to export using a different RT than the one used for import. You can pick whatever number you want. To illustrate this point, we'll use 65000:1234.

ip vrf Customer_A
 rd 65000:100
 route-target export 65000:100
 route-target export 65000:1234
 route-target import 65000:100
 route-target import 65000:300
!
ip vrf Customer_B
 rd 65000:200
 route-target export 65000:200
 route-target export 65000:1234
 route-target import 65000:200
 route-target import 65000:300
!
ip vrf Shared
 rd 65000:300
 route-target export 65000:300
 route-target import 65000:1234

With this approach, both customers can reach the Shared VRF but not each other, and the Shared VRF can reach both customers.

Alternatively, we could have configured VRF Shared to import routes with tagged with 65000:100 and 65000:200. This would have worked, however this approach doesn't scale well. Imagine if we had a hundred customer VRFs to export to: An additional community would need to be imported for each. Designating a separate RT for export to the Shared VRF allows us to scale to any number of customer VRFs using only a single pair of targets.