A Detailed Examination of MPLS Layer 3 VPNs

The preceding section contained an overview of how routing and user packet forwarding work in an MPLS VPN, but now it is time to take a closer look at how each of these elements function.

Distinguishing Customer VPN Prefixes Using Route Distinguishers (RD)

As shown in Figure 4-3, PE routers advertise customer VPN routes and associated VPN labels to each other using MP-BGP. This seems simple enough, but what happens if two customers are using the same IP address space? Specifically, how can the PE routers distinguish between, say, network prefix 10.2.0.0/16 in mjlnet_VPN and network prefix 10.2.0.0/16 in cisco_VPN?

The issue of distinguishing between identical network prefixes in different customer VPNs is resolved by prepending an 8-byte Route Distinguisher (RD) to each route. An RD is simply a unique number that allows PE routers to distinguish between multiple otherwise identical network prefixes. By prepending an RD to an IPv4 network prefix, an entity called a VPN-IPv4 (VPNv4) network prefix is created.

Note

A particular route can have only a single RD.

An RD is specified in three fields, as follows:

Type field (2 bytes) + Administrator field + Assigned Number field

The length and semantics of the Administrator and Assigned Number fields are determined by the value contained in the Type field. If the Type field contains a value of 0, the Administrator field is 2 bytes long and carries an autonomous system number (ASN), and the Assigned Number field is a unique 4-byte value specified by the service provider:

Type (0) + Administrator (2-byte ASN) + Assigned Number (unique 4-byte value)

If the Type field contains a value of 1, the Administrator is 4 bytes long and contains an IP address, and the Assigned Number field contains a unique 2-byte value specified by the service provider:

Type (1) + Administrator (4-byte IP address) + Assigned Number (unique 2-byte value)

Finally, if the Type field contains a value of 2, the Administrator field is 4 bytes long and contains an ASN, and the Assigned Number field is 2 bytes long and contains a unique number assigned by the service provider:

Type (2) + Administrator (4-byte ASN) + Assigned Number (unique 2-byte value)

Figure 4-5 illustrates the use of RDs to distinguish otherwise identical network prefixes.

Figure 4-5. Use of RDs to Distinguish Otherwise Identical Network Prefixes

If you look closely at Figure 4-5, you can see that there are two VPNs: mjlnet_VPN and cisco_VPN. An overlap exists in IP address space in these two VPNs, with network prefix 10.2.0.0/16 being used at both mjlnet_VPN site 2 and cisco_VPN site 2.

Brussels_PE1 advertises the mjlnet_VPN site 2 prefix 10.2.0.0/16 and cisco_VPN site 2 prefix 10.2.0.0/16 as VPN-IPv4 addresses (each prefix has an RD prepended to it).

In this example, the RD 0:64512:100 (Type [0] + Administrator [ASN 64512] + Assigned Number [100]) is prepended to the mjlnet_VPN IPv4 prefix 10.2.0.0/16, giving the address 0:64512:100:10.2.0.0/16. The RD 0:64512:200 (Type [0] + Administrator [ASN 64512] + Assigned Number [200]) is prepended to the cisco_VPN IPv4 prefix 10.2.0.0/16, giving the VPN-IPv4 address 0:64512:200:10.2.0.0/16.

When London_PE1 receives the two VPN-IPv4 addresses, it does not consider the two as comparable addresses because the RDs differ (0:64512:100 versus 0:64512:200).

It is worth emphasizing at this point that an RD gives no indication as to the origin of a particular network prefix or the VRFs into which a prefix should be installed, but instead simply serves to identify separate network prefixes that would otherwise appear to be identical.

Using Route Targets (RT) to Control Customer VPN Route Distribution

So, PE routers use RDs to distinguish otherwise identical network prefixes. But how exactly are customer VPN routes advertised in BGP installed into the correct VRF(s) on the PE router that receives these routes? Customer routes received from other PE routers are installed into the correct VRF(s) based on a BGP extended community attribute called a Route Target (RT). One or more RTs are attached to a customer VPN-IPv4 route before it is advertised by one PE router to another PE router.

The BGP extended community is 8 bytes long and its format is as follows:

Type field + Value field

When the extended community is an RT, the Type field is 2 octets long and is subdivided into high- and low-order octets, with the low octet having a value of 0x02.

The Value field is 6 octets long when the extended community is an RT and is divided into Global Administrator and Local Administrator subfields:

Value field: Global Administrator + Local Administrator

When the high-order Type field octet in an RT is 0x00 or 0x02, the Global Administrator subfield contains an ASN, and the Local Administrator subfield contains a locally defined value.

When the high-order Type field octet is 0x01, the Global Administrator subfield contains an IP address, and the Local Administrator subfield contains a locally defined value.

Figure 4-6 illustrates the installation of customer VPN routes into VRFs based on RTs.

Figure 4-6. Installation of Customer VPN Routes into VRFs Based on RTs

As Figure 4-6 shows, London_PE1 advertises VPN-IPv4 routes 10.1.0.0/16 with export RT 64512:100 and 10.5.0.0/16 with export RT 64512:200 to Brussels_PE1. Export RTs are RTs that are attached to routes before those routes are advertised by one PE router to other PE routers. The RTs in this example are in the format ASN:xx (Global Administrator:Local Administrator).

When Brussels_PE1 receives the VPN-IPv4 routes from London_PE1, it examines the RT(s) attached to each route, and as long as one attached RT matches an RT associated with a VRF, it installs that route into the VRF. The RT associated with a VRF for the purposes of VPN-IPv4 route installation is called an import RT.

So, because route 10.1.0.0/16 has RT 64512:100 attached to it, and import RT 64512:100 is associated with the mjlnet_VPN VRF on Brussels_PE1, route 10.1.0.0/16 is installed into that VRF. Route 10.1.0.0/16 is not, however, installed into the cisco_VPN VRF because the RT attached to the route (64512:100) is not an import RT associated with the cisco_VPN VRF.

Similarly, because route 10.1.0.0/16 has RT 64512:200 attached, it is installed into the cisco_VPN VRF. This is because the cisco_VPN VRF has import RT 64512:200 associated with it. This route is not installed into the mjlnet_VPN VRF, however, because the mjlnet_VPN VRF does not have RT 64512:200 associated with it.

Brussels_PE1 advertises VPN-IPv4 routes 10.2.0.0/16 with RT 64512:100 and 10.6.0.0/16 with RT 64512:200 to London_PE1.

Route 10.2.0.0/16 is installed into mjlnet_VPN VRF on London_PE1 because the RT attached to it (64512:100) is the same as the import RT associated with the mjlnet_VPN VRF. Route 10.6.0.0/16 is installed into the cisco_VPN VRF on London_PE1 because the RT attached to it (64512:200) is the same as the import RT associated with the cisco_VPN VRF on London_PE1.

You might have noticed that the RTs (64512:100 and 64512:200) in Figure 4-6 bear a striking resemblance to the RDs used in Figure 4-5 (0:64512:100 and 0:64512:200). It is quite common to configure the RDs and RTs associated with a particular set of VRFs to be the same in a full-mesh VPN (with any-to-any connectivity) for the sake of consistency. But, be sure to remember that there is no requirement that they be the same, and that, depending on the topology of a particular VPN, they may well differ (more on this later).