MPLS-Based VPN Backbones
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
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
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.
Multiprotocol Label Switching (MPLS) solves these
by enabling service providers to deploy multiple
VPN services across one very large physical network
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
across very large networks. The labeling paradigm
decouples packet forwarding from the content of
providing the mechanism for how MPLS confers Layer
3 services into Layer 2 infrastructures. Labels
packet routes, user group, and service attributes.
At the ingress into the provider network, incoming
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
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
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
Configure VRF instances for each VPN.
Choose a routing protocol between customer and
Configure Multiprotocol Border Gateway Protocol
(MP-BGP) between ELSRs.
Identify interfaces going to VPN sites.
Step 1: Configuring VRF Instances for Each
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
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
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:
All routers within a VPN know each other.
Non-VPN interfaces on the router may be used
for other services.
some cases, VPN sites may need Internet connectivity,
meaning the site must be able to reach Internet
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
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
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
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
Predictable performance and policy implementation
Support for multiple levels of service in an
Network traffic is classified and labeled at the
edge of the network before traffic is aggregated.
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 firstname.lastname@example.org.