The layer-3 approach to creating MPLS-based VPNs offers a routed solution to the problem The de facto standard for implementing such VPNs is described in “RFC 2547”, with a new version, currently, under development referred to as 2547bis which is described in “draft-ietf-ppvpn-rfc2547bis-01.txt”. The approach is also referred to as BGP/MPLS VPNs.
The approach relies on taking customer IP datagrams from a given site, looking up the destination IP address of the datagram in a forwarding table, then sending that datagram to its destination across the provider’s network using an LSP.
In order for the service provider routers to acquire reachability information about a given customer’s networks, the provider edge (PE) routers exchange routes with the customer edge (CE) routers. Hence, the BGP/MPLS VPNs approach follows the peer to peer model of VPNs. These routes are propagated to other PE routers carrying the same VPN(s) via BGP. However, they are never shared with the provider’s core routers (P), since the PEs use LSPs to forward packets from one PE to the other. P routers do not need to know about the customer’s networks in order to perform their label switching functions. A PE router receiving routes of a given VPN site from another PE, propagates the routes to the CE router of the connected site belonging to that same VPN, so that the CE will also learn about the networks in the remote site.
The mechanisms behind BGP/MPLS VPNs were designed to address some of the shortcomings of the pure layer-3 VPNs (without tunneling) that preceded it. Some of the main goals were:
• Supporting globally unique IP addresses on the customer side, as well as private nonunique – and hence, overlapping – addresses.
• Supporting overlapping VPNs, where one site could belong to more than one VPN.
Since this type of VPNs relies on routing, achieving the abovementioned goals could be a challenge. To address the problem of overlapping address spaces in customer VPNs, multiple routing and forwarding tables, referred to as VPN Routing and Forwarding (VRF) tables, are created on each PE router, in order to separate the routes belonging to different VPNs on a PE router.
A VRF table is created for each site connected to the PE, however, if there were multiple sites belonging to the same VPN connected to the same PE, these sites might share a single VRF table on that PE. A site that is a member of multiple VPNs is not a candidate for VRF table sharing with other sites that are not members of exactly the same set of VPNs. Such a site must have its own VRF table, which includes routes from all the VPNs it is a member of.
Another implication of the overlapping address spaces problem is that a PE router receiving BGP updates from its neighbors might receive conflicting or overlapping routes – belonging to different VPNs. In order to identify the advertised routes as belonging to different VPNs, and hence, prevent the BGP process from selecting one – the best – and ignoring the rest, an 8 octet Route Distinguisher (RD) is prepended to each prefix advertised. This is used to distinguish routes belonging to different VPNs on the BGP receiver side. The result of prepending the RD to the 4 octet IP prefix is a 12 octet address for which a new special address family was defined, the VPN-IPv4 family. Hence, to be precise, multi protocol BGP is used to carry such prefixes.
Route Distinguishers provide nothing more than a way of differentiating routes. They play no role in controlling route distribution. An RD is assigned to a VRF, so that prefixes advertised from that VRF will have that RD prepended to them. Typically, it makes sense to assign the same RD to the VRFs of sites belonging to the same VPN, so that all the routes of that VPN will have the same distinguisher. So, it could be said that RDs are typically assigned uniquely to each VPN. However, this should not mean that VRFs of sites that belong to multiple VPNs get multiple RDs. VRFs of such sites need only one RD. For those sites, as well as those that are members of only one VPN, controlling the distribution of routers is performed as described below.
To prevent a PE router from accepting routes of VPNs that it doesn’t carry, and hence, waste its own resources, BGP extended communities are put to use in order to control the distribution of routes within the provider’s network. The extended community attribute Route Target is included with the advertised route(s) to indicate which VPN – or the group of sites in certain topologies – the route belongs too. A unique value for this attribute is assigned to each customer VPN. A PE router keeps track of those Route Target values associated with the VPNs that it carries. Upon receipt of an advertised route, the BGP process checks the Route Target to see if it is equal to the Route Target value of one of the VPNs that it carries. In case of a match, the route is accepted, if not, the route is ignored. This is to avoid having all the PE routers carrying all the routes of all the customer VPNs, which might severely limit the scalability of the solution.
Figure 1 illustrates the main concepts behind the BGP/MPLS VPNs approach.
Figure 1 The BGP/MPLS VPN approach.
From the discussion above, it could be seen that the approach allows for creating overlapping VPNs. This is intended for scenarios like when a customer needs a VPN for their intranet, and another for their extranet with a different set of routes advertised in each to control the accessibility of resources. Such a customer would rely on the service provider to perform the required route control, i.e., route control is shifted from the CE router and delegated to the PE router. In Figure 1, Customer A, Site 1, lies in both VPN 1 and VPN 2. The routes of that site are advertised by the connected PE router with one RD, however, with two Route Target extended community attributes: one for VPN 1, the other for VPN 2. The connected PE router, also, accepts routes from the other PE routers, only if the routes have Route Target values equal to that value of either VPN 1 or VPN 2 – since these are the only VPNs carried by this router in this example.
When advertising a VPN-IPv4 route, the PE also includes an MPLS label – representing the route – in the BGP message, and it sets the BGP NEXT_HOP equal to its own address. The provider network is MPLS enabled, and each PE router should be capable of reaching any of the other PEs via an LSP. Those LSPs could be created by any protocol like LDP or RSVP/TE.
When a PE receives a packet with a destination in a remote site, it attaches two MPLS labels to the packet in order to forward it to its destination. The outer label is for the LSP leading to the BGP NEXT_HOP. The inner label is the label associated with that destination, learned previously from a BGP update received from a peer. The PE, then, sends the frame out the port associated with that LSP. The frame gets label switched all the way to the remote PE, which then, pops the outer label, and examines the inner label. The inner label, in most cases, uniquely identifies the destination, therefore, it is popped and the packet is forwarded to its destination. In some cases, where route summarization is done on the PE, the receiving PE uses the inner label to determine which VRF to look into in order to know where to send the packet.
Figure 2 Two labels are attached to an IP datagram to be forwarded to its destination.