The last post discussed the forwarding plane of MPLS VPN networks – in particular, how they remain private by maintaining separate information tables at each PE and connecting the traffic related to each of these tables over separate LSPs.
But there is also the control plane: How is the local reachability information contained in each information table advertised to the other PEs?
Keeping in mind that one of the fundamental objectives of MPLS VPNs – and MPLS in general – is to support multiple services over a common, shared infrastructure, in makes sense that the the advertisement of local reachability information among the PEs should also be handled by a single, shared protocol.
And indeed it is, using BGP.
(For Layer 2 VPNs and VPLS you have the alternative of using LDP for this, but in my mind that just adds a protocol unnecessarily; using BGP to support all of the VPN functions makes more sense to me. Perhaps a discussion of the pros and cons of this would be a good follow-up post.)
However, using BGP commonly to communicate all reachability information among all VPNs raises a concern: If all reachability information from each PE goes into a shared BGP table and is advertised using the same BGP Update messages, how is each VPN’s information kept private?
And what about overlapping information? For example, Layer 3 VPN users A, B, and C might all address their networks out of the 10.0.0.0/8 private address space. Let’s say that at PE_1 users A, B, and C each have a connected site, and each of those sites are addressed out of – and individually advertise – 10.1.1.0/24. Within the local PE_1, the three overlapping prefixes are kept separate by the sites’ separate connections and separate information tables. So the 10.1.1.0/24 advertised by user A’s site is kept in user A’s VRF, the 10.1.1.0/24 advertised by user B’s site is kept in user B’s VRF, and the 10.1.1.0/24 advertised by user C’s site is kept in user C’s VRF. You get the picture.
But now PE_1 must advertise these three prefixes – numerically identical, but in actuality different because they belong to three different users – to all other PEs in the network, using a single BGP process. So prefix 10.1.1.0/24 is added to the BGP table from three different VRFs; to make things even more interesting, let’s say users D and E also advertise 10.1.1.0/24 from sites connected to other PEs in the network. From BGP’s viewpoint, it is just receiving five different routes to the same destination, not five different destinations. At every PE, BGP would just pick what it considers the best route to 10.1.1.0/24 and install that in all the local VRFs. That’s obviously not what we want.
We need to meet two requirements in order to support these overlapping addresses:
(1) We need an identification mechanism that takes the identical prefixes and makes them unique, so BGP does not interpret them as simply multiple reachability advertisements to the same destination.
(2) We need a means to set policy around the prefixes, so we can control what prefixes are accepted into what information tables.
The first requirement is met by using a Route Distinguisher (RD). The RD is a 64-bit value that is prepended to a prefix to associate it with a specific VPN user. The VPN service provider assigns a unique RD each user, and possibly to each user site. The RD is prepended to every prefix advertised by each user before the prefix is added to the BGP table.
In our example of five different VPN users advertising 10.1.1.0/24, RDs might be prepended as follows:
- User A, at site 1: 1:1:10.1.1.0/24
- User B, at site 1: 2:1:10.1.1.0/24
- User C, at site 1: 3:1:10.1.1.0/24
- User D, at site 2: 4:2:10.1.1.0/24
- User E, at site 3: 5:3:10.1.1.0/24
You can easily see that because of the RDs, the five prefixes that were numerically identical are now unique.
But they are also no longer IPv4 addresses. The addresses created by prepending an RD belong to an address family called VPN-IPv4. And because BGP must advertise this VPN-IPv4 address family in addition to the default IPv4 address family, we use Multiprotocol BGP (MBGP).
For the second requirement, creating policies to determine what prefixes belong in what information tables, a solution might be to create VPN-IPv4 prefix filters for each local information table. But prefix filters don’t scale well operationally, particularly in the presence of hundreds or thousands of individual VPN users.
Filtering on VPN-IPv4 addresses also isn’t as flexible as we would like. For example, user A and user B might want to create a VPN-based intranet between them, advertising a limited subset of their mutual address spaces to each other.
Fortunately, BGP already has a policy tool created especially for applying flexible policies to large groups of prefixes: Communities. The BGP Communities path attribute is a “tag” that can be applied to BGP prefixes. As the name implies, prefixes sharing the same tag comprise a “community” to which some common policy can be applied.
Communities also provide for wide policy flexibility, because a single prefix can have multiple Communities attached to it. So you can create a policy that applies only if a specific Community is recognized, or if some combination of Communities is recognized.
BGP Communities also come in two “flavors”: Standard Communities are 32-bit values; Extended Communities are 64-bit values. And that brings us back to the VPN discussion.
MPLS VPNs use a 64-bit Extended Community attribute called a Route Target (RT). At a given PE, you create an outgoing policy that attaches an RT to prefixes advertised by a VPN user site attached locally to the PE. You then create an incoming policy at all other PEs where that user has attached sites, recognizing the user’s one or more RTs and accepting the associated prefixes into the user’s local VPN information table.
The difference between Route Distinguishers and Route Targets tends to be a source of confusion for many networkers, primarily because they are both 64-bit values that are formatted in exactly the same way. Each has a 2-byte Type field that specifies one of two format types: Either Type 0 or Type 1. Two fields, the Administrator field and the Assigned Number field, follow the Type field. Type 0 RDs and RTs have a 2-byte Admin field and a 4-byte Assigned Number field; type 1 RDs and RTs have a 4-byte Admin field and a 2-byte Assigned Number field. In both cases the Assigned Number field is some arbitrary number that you define; although the Admin field can also be an arbitrary number if you like, the two types allow you to make that field either a 2-byte AS number or a 4-byte IP address.
The important point, though, is that although RDs and RTs are the same in format they are entirely different animals performing entirely different tricks. Remember that Route Distinguishers serve only to make potentially identical prefixes unique, while Route Targets are a type of BGP Communities attribute that enable distribution of reachability information to the correct information table.