In Part 1 of MPLS L3VPN’s we talked about the different components and technologies that form the IP VPN service, the role of the devices in the service provider connection model and how they interact between each other. In this second part, we will look at four design cases that use MPLS L3VPN’s in today’s modern networks.
Case 1: Service provider – VPN Service
The most popular and proven use case of L3VPN is within the service provider network used as a transit VPN service. Typically, the aim of a service provider offering is to meet the requirements of their customers by offering a service that can:
- Support a large number of sites per customer
- Provide customers with a service that can differentiate and transport traffic with end-to-end QoS
- Provide a flexible and single infrastructure that can serve various media access methods for all customers
- Reduce the time to provision new sites or to increase bandwidth throughput
All these goals can be achieved by using the following overlay model, also discussed in Part 1 of this blog:
In this architecture, the provider edge nodes (PE’s) receive the customer traffic from the customer edge nodes (CE’s), carries it across the provider nodes (P’s) to its endpoint PE’s using the relevant VPN and transport MPLS labels to finally inject it into the appropriate CE. In this model, the network is used as a transit service only and does not provide services to the customers themselves.
Case 2: Service Provider – Internet and Application Service
The flexibility provided by MPLS VPN infrastructure allows the provider to offer to the customer multiple additional services like Internet access or Application as a service. There are multiple design options to allow the extension of an application through L3VPN’s but the general model can be seen below:
The PE’s at remote sites will exchange routes and data with the PE’s inside the Service Provider data-center. The PE’s in the service provider data-center can be considered as Autonomous System Boundary Router’s (ASBR’s) as they will be at the edge of the Application or Internet service provided to the customers. This use-case is most popular in providing Internet as an additional service to the already existing transit VPN’s to other sites.
Case 3: Enterprise – WAN and Campus Segmentation/Virtualization
Some enterprise opt to use L3 MPLS over their own WAN or over a Service Provider network to offer L3 segmentation and virtualization up to their Campus networks. This is often done in the case of a merger if there is a need to keep the routing infrastructure separated end to end (due to isolated network for example).
In the case where the enterprise has their own managed WAN network the design will be the same as the service provider network (Case 1) or also called a self-deployed L3 MPLS network. If the enterprise opts instead to use a service provider as transit with a L2 VPN service such as VPLS or EoMPLS, the design will look like the picture below.
From the service provider’s perspective:
From the enterprise perspective:
As you can see, the CE’s from the perspective of the service provider are considered the PE’s for the enterprise. This allows the enterprise to run MPLS and MP-BGP between their PE’s over the WAN of the service provider’s network and extend it inside of the campus network. Using L3 VPN’s and extending them to the campus network from PE1 allows the use of an overlapping infrastructure:
In some cases, the WAN service offered might be a L3 service itself or the enterprise might run a pure IP core backbone and running MPLS natively over the transit network won’t be feasible. In this case, a GRE or mGRE tunnel over MPLS design model can be used as seen below:
One last design option is the MPLS over GRE + IPSEC model or even the MPLS over DMPVN (2548oDMVPN) design with a public network as transit, like the the internet for example. This offers a low cost, scalable MPLS overlay.
In general, L3VPN’s within the enterprise is not as popular due to the lack of MPLS knowledge for enterprise engineers. Another factor contributing to the lack of popularity of this design is that the number of different VPN’s to be maintained within most enterprise networks is often fairly low so scalability is not an issue. If scalability is not a design concern and MPLS is not a familiar technology by the supporting staff, a VRF-lite only design model often becomes a better option in terms of manageability.
Case 4: Data-Center – Multi-Tenancy
In the past few years, the CLOS or Spine/Leaf architecture has been increasing in popularity in the data-center environments due to its several benefits to bandwidth availability and efficiency in east/west traffic patterns. Although a L2 model using TRILL/Fabricpath/SPB could be used, L3 ECMP is another option available that offers most of the same benefits. It is also possible to use L3 ECMP with VRF-lite to create hop-by-hop segmentation with an IP data-plane to provide multi-tenancy, however we will focus on the option of using MPLS with L3VPN’s. In fact, MPLS L3VPN’s offer several benefits that VRF-lite segmentation does not. The first one being scalability which is very important for most host/cloud providers due to the sheer number of customers that they have to support. The second being convergence time due to the availability of MPLS tools like Fast Reroute and Path/Node protection. Lastly, there is more complexity involved with the VRF-lite model due to the requirement from customers to stitch VRF-lite to MPLS segments at the data-center edge. Let’s take a look at the architecture itself:
Comparing to the spine/leaf architecture, the PE’s would be represented by the Leaf nodes and the P’s would be the Spine nodes. As usual, alink-state routing protocol underlay would run between P devices and PE to P devices with an MP-BGP overlay between PE devices. If there is high number of PE’s, it is possible to use a hierarchical model by using two of the devices as Route Reflectors for the VPNv4 peering’s.
In conclusion, in this post we covered different use-cases for L3VPN’s in the service provider, enterprise and data-center environments. In the next post, we will cover several deployment scenarios and issues encountered in different L3VPN’s topologies.