Scaling MPLS VPNs to Multi-AS, Multi-Provider, and Hierarchical Networks

Any VPN technology must scale to a large number of sites per VPN and a large number of VPNs per network. Using a tunneling technology, such as GRE or IPSec, limits the number of sites per VPN or the number of VPNs to a small number due to the number of tunnels a network element supports. Hence, the size of the VPN is dependent on the network elements and their scale numbers. While we will not discuss the details of how MPLS VPNs scale here, it is important to understand that a technology being evaluated for VPN deployment must be able to scale to large (>10000) sites per VPN and a large number (>10000) of VPNs per network. The VPN technology must be capable of accommodating such large routing information easily without a meltdown occurring in the network.

When building an IP network using MPLS, the VPN technology must provide a means to build a VPN across IGP areas, across BGP autonomous systems, and across multiple domains and routing boundaries. These are termed Inter-AS or Carrier Supporting Carrier (also known as Carrier's Carrier) VPNs. Before we discuss the details of each of these VPNs, we have deliberately decided to ignore whether the autonomous system (AS) or a stub network is controlled and managed by the same provider or different providers.

Inter-AS VPNs

RFC 4364 discusses the ability to build MPLS VPNs across the autonomous system boundaries. The three basic models discussed in RFC2547bis for Inter-AS connectivity are as follows:

• Back-to-back VPN connectivity between ASBRs

• VPNv4 exchange of routes and peering between ASBRs

• IPv4 exchange of routes and peering between ASBRs

All three models focus on propagating VPN routes from one AS to the other AS. The first model is a simple one in which the ASBRs connect back to back via logical circuits or VLANs one per VRF. The back-to-back connections enable VPN connectivity and the exchange of routes between ASBRs on a per-VPN basis. For example, if ASBR1 and 2 need to exchange routes for 10 VPNs, 10 logical circuits exist between ASBR1 and ASBR2one for each VPN.

In the second model of connectivity, ASBRs exchange VPNv4 routes among each other. As stated earlier, a VPN can span multiple ASes, the peering points between ASes. ASBRs advertise the VPV4 routes learned from the other AS and use themselves as the next hop for those routes. The PEs then forward the traffic toward the ASBR, which in turn forwards it to the destination. For multiprovider networkseach managing its own set of ASesthe same model of connectivity applies. If the providers are peering just for VPN routes, this mode of connectivity might be sufficient. However, if they are peering for VPN routes and IP routes, the ASBRs here have the additional burden of carrying IPv4 and VPNv4 routes. The third model of IPv4 route exchange solves this problem. In the third model, only the IPv4 routes are exchanged between provider ASBRs and VPNv4 routes are exchanged between the VPN route reflectors in each AS. This frees up the ASBRs to carry only IPv4 routes.

Each method of connectivity has advantages and drawbacks. What we are trying to illustrate is that, irrespective of AS boundaries, MPLS VPNs can be built across them. Some providers choose to partition their networks to make them more manageable from a routing standpoint, such as BGP confederations and so on. MPLS VPNs can work over all such routing paradigms and have the capability to seamlessly connect customer sites no matter in which AS or confederation they reside.

Carrier Supporting Carrier

Another method of scaling MPLS VPNs is to create hierarchical VPNs. Consider a national or international carrier that is selling a VPN service to smaller stub carriers. The smaller stub carriers might in turn be selling another MPLS VPN service to end users (enterprises). By nesting stub carrier VPNs within the core or national carrier VPN, a hierarchical VPN can be built. With the CSC mode described in RFC 2547bis, the stub carrier VPNs and their routes do not show up in the core carrieronly the stub carrier IGP routes are part of the core carrier VPN. So, the core carrier does not need to learn or understand end user routes because the end user of the core carrier is the stub carrier. The core carrier needs only to provide VPN connectivity so that the core carrier's CEs (ironically, they are stub carrier PEs) are reachable. These CEs are called CSCCEs, whereas the PE that connects to the stub carrier and has MPLS enabled on the PE-CE link is called the CSCPE.

Carrier's Carrier can also be used by a single provider. For example, let us assume that the core network of a carrier is managed by a different department from that of the edge network. The edge network might sell services to enterprise customers. The core network might also sell services to other departments (one might provide Internet service, another might provide content-based services, and so on) or even directly to VPN customers. Using the CSC model, the core network need not be aware of the VPN routes of the CE network. The core network in this manner is isolated from the routing changes of customer VPNs. Similarly, this can be extended to the enterprise customers. For example, say an enterprise customer buys a VPN service from a service provider. The enterprise customer wants to build his own VPNs or virtual networks (LANs and so on) within the VPN. By using CSC connectivity, the enterprise can build multiple VPNs within the provider VPN.

The exact details of label forwarding, route exchange, and configurations are beyond the scope of this chapter and can be easily learned from Cisco Press's MPLS and VPN Architectures, Volumes 1 and 2 by I. Pepelnak, J. Guichard,  et al. Our point is to show you how this technology scales and can be used to build large IP VPNs.