There is little doubt that cloud computing is becoming the “new normal” for most enterprises. The Cisco Global Cloud Index states “cloud workloads are expected to nearly triple (grow 2.9-fold) from 2013 to 2018 whereas traditional data center workloads are expected to see a global decline”. In order to prepare for this growth, both cloud providers and enterprises are leveraging the capabilities of Multiprotocol Label Switching Virtual Private Networks (MPLS VPNs).
Given the breadth and depth of MPLS, entire books are devoted to the topic. Therefore, it is not possible to cover all aspects in a single post. Rather, I will provide a brief overview of the major components of a MPLS VPN network. For more detailed information, you can consult various references such as the Cisco Press book “MPLS Fundamentals”, Cisco’s “Path Isolation Design Guide”, or the Cisco Live! presentation “CCIE Candidate’s Introduction to MPLS L3VPN Networks”.
For additional cloud computing references, see my previous post on The Challenges of Cloud Computing for details.
MPLS VPNs Use-Cases
MPLS VPNs were first deployed by telcos who used them to achieve economies of scale, and hence reduce costs, by virtualizing their WAN infrastructure. To prevent route leaking between customers, each customer is assigned a unique VPN (Figure 1). This also allows these customers to have overlapping IP addressing schemes even though all traffic is transiting the same telco network.
Figure 1: Telco MPLS VPNs.
In recent years, MPLS VPNs have also gained increasing traction within on-premises private clouds and public clouds. Many large Greenfield networks, being shared by multiple third parties, are now becoming part of the standard network architecture. See Figure 2 for details taken from the CiscoLive! presentation, “A Case Study in Network Infrastructure Virtualization”. For older established networks, however, VPNs are a less popular choice since this will often involve expensive forklift infrastructure upgrades that may not be economically justified.
Figure 2: Network Virtualization
MPLS VPN Topology
A MPLS topology divides the overall network into two parts, a Customer network (C) and a Provider network (P). See Table 1.
|C (Customer) Router|
Resides deep within the customer’s network. It has no visibility of the Provider network.Neither the C, nor the CE routers, are part of the MPLS domain. Therefore, they are not configured to support MPLS VPN functionality.The routing tables of both the C and CE routers are populated with customer routes only.
|Customer Edge (CE) Router|
|Provider Edge (PE) Router|
|P (Provider) Router|
Table 1: Components of a MPLS VPN Network
Refer to Figure 3 for a typical MPLS VPN topology.
Figure 3: MPLS VPN Topology
Carving Up VRFs
Deciding on the number of VRFs and their functions is critical to the success of the overall MPLS VPN deployment. However, from personal experience, it can be both technically and politically challenging. This is not the sole responsibility of the network team; rather it is a shared responsibility with other ICT stakeholders. Some may have limited MPLS experience, such as business application owners. I’ve been in meetings where some people failed to recognize the importance of VRFs and didn’t want any routes removed from the global routing table.
For large networks, don’t underestimate the amount of time required to achieve a Goldilocks VRF design. If it is too broad then this limits the value of deploying VRFs in the first place. The same applies if there are a large number of routes left in the global routing table. On the other hand, if the design is too granular then it becomes too complex to deploy and administer. There is no right or wrong answer to this conundrum – a minimal global routing table and a manageable number of VRFs that meet all your enterprise’s business and technical requirements is the goal.
- When it comes time to implement a particular VRF, people may forget how it is to be used.
- New devices that are to be added to the network in the future can be easily assigned to the correct VRF.
- It helps to prevent expensive rework if some stakeholders suddenly change their minds and want half the routes moved from one VRF to another.
Photo Credit: IBM 7090 computers in a machine room at NASA during Project Mercury, U.S. National Archives and Records Administration