Deploying MPLS-Based VPN Backbones

Service providers stand to gain many operational and scalability benefits by deploying value-added services such as virtual private networks (VPNs) over Multiprotocol Label Switching (MPLS) backbones. Here's a technology backgrounder on deploying MPLS-based VPNs

For VPN service providers, the management challenges associated with quickly deploying scalable VPN services using ATM or Frame Relay Layer 2 virtual circuit technologies remain comparable to those of provisioning private WAN lines. Layer 2 deployments are difficult to scale to support hundreds of thousands of closed user groups. The reason is that virtual circuit-based VPNs require service providers to build and manage separate logical paths between each pair of communicating sites within each user group. This requirement equates to building a full mesh of virtual circuits for each customer.

Management Relief
Multiprotocol Label Switching (MPLS) solves these scalability problems by enabling service providers to deploy multiple VPN services across one very large physical network without having to manually configure full logical point-to-point meshes for each customer's VPN. Rather, MPLS makes use of information in IP addresses for building "any-to-any" linkages in a Layer 3 "connectionless" network. A connectionless network, such as an IP network, is one in which no prior action is necessary to establish communication between hosts, making it easy for two parties to communicate.

The peer-oriented model of MPLS-based VPNs requires a customer site to directly exchange routing information with just one provider edge router, as opposed to all other CPE routers that are members of the VPN. This connectionless architecture allows the creation of VPNs in Layer 3, eliminating the need for Layer 2 tunnels or virtual circuits.

Members of each VPN are identified as belonging to a closed user group through the use of MPLS labels. These labels carry next hop switching information for packet forwarding as well as a VPN identifier to keep communications within a VPN private.

The richness of MPLS lies in the labels. Service providers can assign special meanings to labels a simple, powerful way to deploy scalable services across very large networks. The labeling paradigm decouples packet forwarding from the content of IP headers, providing the mechanism for how MPLS confers Layer 3 services into Layer 2 infrastructures. Labels can indicate packet routes, user group, and service attributes. At the ingress into the provider network, incoming packets are processed and labels are selected and applied using VPN routing and forwarding (VRF) instance tables. The core devices merely forward packets based on labels, replacing traditional switching or routing tables. Because forwarding tables are pre-calculated, traffic is classified only once at the service provider's Edge Label Switch Router (ELSR) yet Layer 3 visibility and services can be applied from end to end.

MPLS separates traffic and provides privacy without Layer 2 tunneling
protocols or encryption by putting information into the MPLS label. MPLS makes service provider cores "VPN-aware" by providing Layer 3 visibility even across Layer 2 backbones. This makes it relatively easy to flexibly group users and services; that is, one user can be associated with multiple services or vice versa. Further, all MPLS functionality resides in the provider network, requiring no configuration at the customer premise. This setup promotes simplicity for customers; all they see is an IP connection.

A Word about Security
Connectionless MPLS VPNs offer the same level of security as connection-oriented VPNs. Packets from one VPN do not inadvertently go to another VPN. Security is provided at the edge of a provider network by ensuring that packets received from a customer are placed on the correct VPN.

In addition, across the backbone VPN, traffic is kept separate among user groups. Malicious spoofing (an attempt to gain access to a service provider's edge router) is nearly impossible, because the packets received from customers are IP packets that must be received on a particular interface or sub interface to be uniquely identified with a VPN label.

Deploying VPN services using MPLS requires the following steps:

Step 1: Configuring VRF Instances for Each VPN

At the provider network edge, an ELSR needs to contain knowledge of each VPN attached to it. First, Label Distribution Protocol (LDP) should be activated and run to verify that packets are forwarded across all interfaces in the MPLS backbone. Then, ELSR devices (usually Cisco routers) need to be configured to contain unique VRF instances and route distinguishers (RDs). VRF instances convert routers into multiple virtual routers by creating a separate forwarding table for each VPN.

The RD is a 64-bit VRF-based header that is added to the beginning of the customer's IPv4 prefixes to change them into globally unique VPN-IPv4 prefixes. While its possible to configure a single RD per VPN, assigning an RD for each VRF enables load-balancing using Interior BGP (IBGP) and also eases VPN management.

The next step is to establish VRF import and export policies based on the route target, which is an extended community identifier of all routers within a VPN. MPLS uses route targets to allow updates to VRF instance tables.

Step 2: Choosing a Routing Protocol

A routing protocol enables network devices to advertise their status and best-route forwarding information to one another. For router-to-router communication between the customer's premise and the provider's network edge, MPLS supports the use of static routes, Routing Information Protocol Version 2 (RIPv2), External Border Gateway Protocol (EBGP), and Open Shortest Path First (OSPF) protocols.

Learned routes populate the VRF associated with the interface where the protocol is configured. Within the MPLS core, there are no restrictions on which routing protocol is used for VPN services; however, certain routing protocols (such as link-state protocols) make it possible to deploy other MPLS-based services.

By associating VRF instances with specific VPNs, MPLS automatically partition each VPN's traffic, enabling one physical network to support thousands of private VPNs. Basing VPN design upon VRF instances lets providers establish multiple VPNs per customer. At the provider edge, incoming packets are associated with a specific VPN according to the incoming interface. The ELSR places a stack of MPLS headers on incoming packets that include a label identifying the exit point in the provider network and a second label denoting the specific VPN. Core devices read the first MPLS header and swap labels to forward packets. The penultimate LSR (last hop before the egress LSR) strips the first label from the MPLS header. The ELSR reads the second label to forward native IP packets to the destination VPN.

Because MPLS networks only read original packet headers at the ingress and egress, customers can use their internal IP addressing scheme across the provider network. They do not have to invoke Network Address Translation (NAT), as long as they do not need Internet access or as long as the address range used by more than one VPN customer of a given service provider does not overlap.

Customers can design their own addressing plans independent of addressing plans for other service provider customers. MPLS VPNs allow customers to continue to use their present address spaces without NAT by providing a public and private view of the address. Customers, then, get to use their own unregistered private addresses while gaining the ability to communicate freely across a public IP network.

Step 3: Configuring MP-BGP between ELSRs

MPLS uses MP-BGP to support extended communities such as route-targets and VPN-IPv4 addresses as defined in IETF RFC 2547. Core LSRs do not run BGP. Instead, BGP is restricted to ELSR devices, and route tables list only edge devices for their own directly connected VPNs without regard to core hops.

MP-BGP distributes information about VPNs only to members of the same VPN, defining which edge devices can talk to which. MP-BGP does this by filtering BGP information at each ELSR using the import policies of each route target. Partitioning route reflectors to store routes for a subset of VPNs substantially reduces the amount of information stored within each ELSR, so that the volume of data in the BGP table is equivalent to that of the attached VRF instances. This approach provides a key scalability feature for very large networks that contain thousands of routes. Lastly, mutual redistribution between MP-BGP and the provider-to-customer routing protocol in use enables interaction between the two networks.

Step 4: Identifying Interfaces to VPN Sites

The last configuration step is to identify interfaces on the ELSRs going to VPN sites according to the VRF instance. This step accomplishes two things:

VPN-to-Internet Routing
In some cases, VPN sites may need Internet connectivity, meaning the site must be able to reach Internet destinations and, conversely be reachable from any Internet source. Naturally, security mechanisms such as firewalls or access control lists (ACLs) must be imposed to protect VPNs from unwanted traffic off the Internet. Internet connectivity can be provided using either one or two interfaces.

The single-interface design
separates VPN and Internet traffic at the provider-edge interface. It typically specifies a single default route in the VRF instance table, and requires NAT to hide a customer's private IP addresses. The Internet gateway specified in the default VRF route does not need to be directly connected to the ELSR, and each VRF can use a different Internet gateway. Note that using a default route for Internet routing does not allow any other default route for intra-VPN routing. A second option uses a full BGP table within the VRF instance table, which adds flexibility but uses more memory.

The dual-interface design separates traffic at the customer edge. The provider edge has one VRF interface for VPN connectivity and a second IP interface for Internet connectivity. This design uses discrete routing tables at each interface, separating traffic for greater VPN privacy. At the customer edge, NAT would be active on the IP interface but not on the VRF interface.

Integrated Class-of-Service Class of service (CoS) is an important requirement for many IP VPN customers. It provides the ability to address two fundamental VPN requirements:

Network traffic is classified and labeled at the edge of the network before traffic is aggregated.

VPN Economics
As with any product or service, lower costs expand market reach. MPLS provides a revolutionary architecture for deploying VPN services in very large networks. By allowing service providers to deploy thousands of VPNs over a single infrastructure, MPLS enables service providers to quickly provision services to keep up with market demand while also lowering their management costs. This combination of benefits enables service providers to reach new markets, especially small and midsize businesses.

MPLS enables network operators to take advantage of such business opportunities by providing an IP VPN infrastructure that enables the quick, low-cost deployment of scalable private network services to businesses over a public infrastructure.

Chandan Mendiratta is a Principal Consultant with Cisco India and can be reached at chandanm@cisco.com.

  <<