Under the Hood of MPLS VPNs 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.

 

Fig1.png

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.

 

Fig2.png

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.

 

 

DeviceFunction
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.
  • 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
    • Represents the boundary of the C network.
    • Advertises customer routes to the directly attached PE router.
    • As stated in RFC 4364, “when the CE device is a router, it is a routing peer of the PE(s) to which it is attached, but it is not a routing peer of CE routers at other sites.”
    Provider Edge (PE) Router
    • Represents the boundary of the MPLS network.
    • Maintains a minimum of two separate routing tables, the default, or what is known as the global routing table in the context of MPLS VPN, and at least one Virtual Routing and Forwarding (VRF) instance.
    • Installs customer routes received from the CE into a VRF.
    • Redistributes the VRF routes into Multiprotocol Internal BGP (MP-iBGP). These are now known as VPNv4 routes and are exchanged with other PE routers via iBGP.
    • Each VPNv4 route is assigned a MPLS label, which is then used to forward the packets across the P network.
    • The global routing table is populated with all the physical and logical interfaces not assigned to VRFs. These routes are exchanged with other P and PE routers. It contains, for example, all the routes necessary for the establishment of an iBGP mesh between all the PE routers.
    P (Provider) Router
    • Resides within the core of the P network.
    • Its primary role is to perform label switching/swapping of MPLS traffic across the P network.
    • It does not carry any customer VPN routes. Therefore it is not configured to support MP-iBGP.
    • Exchanges global routes with other P and PE devices. This, for example, provides a transit path across the P network so that PE routers can become iBGP peers.

     

    Table 1: Components of a MPLS VPN Network

     

    Refer to Figure 3 for a typical MPLS VPN topology.

     

    Fig3.png

    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.

     

    One final piece of advice is to always obtain sign-off for all decisions made concerning VRFs:
    • 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

     

    Sean Evershed is an active contributor to the Cisco Certification Forums and Study Groups of the Cisco Learning Network. You can further connect with Sean here.