Expert Reference Series of White Papers

An Overview of
MPLS VPNs:
Overlay; Layer 3; and
PseudoWire

1-800-COURSES www.globalknowledge.com
An Overview of MPLS VPNs:
Overlay; Layer 3; and PseudoWire
Al Friebe, CCDA, CCDP, CCNA, CCNP, A+, CCSI

Introduction
If you understand the big picture when it comes to Multiprotocol Label Switching (MPLS), you then can focus
your attention on what happens when a data packet traverses an MPLS cloud. This white paper will help you do
just that.

Overlay VPNs
It’s in the provider’s best interest to have as many customers as possible, and a large provider may have thou-
sands. Refer to Figure 1, which shows the PVCs for two customers, A (in red) and B (in blue).

Figure 1.

Note that while each customer has three sites, A has a full-mesh, while B has a hub-and-spoke (with site B1 as
the hub), and that although the customers are sharing the same physical infrastructure, their traffic is kept

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 2

separate. Thus, each customer has a Virtual Private Network (VPN), which means that the provider’s network
acts as if there is a private WAN for each customer.

As you can see, Customer A’s site A1 has the same IPv4 address space as does Customer B’s site B1, etc. Since
we’re using VPNs (which act as logically separate networks), there are no address collisions, despite the overlap-
ping address spaces. In fact, the provider’s addressing scheme (Layer-2) is completely independent of those of
the customers’ Layer-3 networks. In other words, the provider doesn’t know or care what IPv4 subnets the cus-
tomers use, or whether the customers are using IPv4 at all (they could just as well be using IPv6, IPX, Appletalk,
DECnet, SNA, or whatever). As long as the packet can be encapsulated using Frame Relay, the provider can get it
where it needs to go.

Also, because the provider doesn’t know what routed protocols the customers are using, the provider has noth-
ing to do with the customer routing protocols, either. The system we’re using is commonly referred to as an
overlay VPN, because we have “overlaid” (superimposed) a VPN for each customer onto the provider’s Layer-2
network.

Considering all of this, we can summarize the advantages of overlay VPNs as follows.
• A common physical infrastructure is shared between customers
• Customers can independently choose any logical topology they want
• Customers can use any combination of Layer-3 protocols they desire
• There are no address collisions between customers
• The provider does not participate in customer routing

Since they offered great flexibility at reasonable cost, overlay VPNs using X25, ATM, and Frame Relay became
very popular over the past few decades.

Disadvantages of Overlay VPNs

Despite the popularity and widespread use of overlay VPNs for WAN service, they do have several disadvan-
tages. Take a look back at Figure 1, in which we have the logical topology for one customer with six sites, con-
nected using a full-mesh of PVCs.

Connecting six sites in a full-mesh requires 15 PVCs. Now consider the fact that some customers have thou-
sands of sites. If a hotel chain with 3,000 properties wanted a full-mesh, over four million PVCs would be
required for this customer alone. If we reduce the logical topology to a hub-and-spoke, 3,000 sites would still
require 2,999 PVCs. These PVCs must be configured one-by-one into the switches in the WAN cloud.

This represents a tremendous time investment for the provider personnel who configure those switches, at a
commensurate cost. For this reason, customers with more than a few sites typically opt for either a hub-and-
spoke or a very sparse partial-mesh. Nevertheless, for a large WAN provider with thousands of customers, it’s a
lot of configuration.

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 3

Layer-3 MPLS VPNs
A Layer-3 MPLS VPNs is a peer-to-peer VPN scheme in which the PE and CE devices are both routers (Layer-3 de-
vices). This is different from the “overlay” VPN we built with Frame Relay, where the CE was a router (Layer-3),
and the WAN cloud was Layer-2.

In this scheme, a PE has a VRF for each customer to which it is attached, and we run MP-BGP to advertise the
customer routes and associated VPN labels from one PE to another. From the customer’s perspective, the WAN
provider’s MPLS cloud appears as a router, as shown in Figure 2.

Figure 2.

Let’s consider a real world example. As you can see, this time we have three customers, A, B, and C. Customers A
and B each have three sites, and Customer C has two sites. Let’s imagine that Customer A wants to send a data
packet from the A2 site to the A3 site (see Figure 3).

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 4

 Figure 3.

The unlabeled data packet leaves CE-A2 and arrives at PE2 (the ingress PE), which looks the packet up in the
Customer A VRF. The VRF tells PE2 that to get the packet to CE-A3, it should forward it towards PE4. The ques-
tion is, “To which router should PE2 forward the packet, P1 or P2?” Let’s assume that the provider is running
OSPF as its IGP, and that the OSPF cost of all links within the provider’s cloud is the same. In this case, the best
(lowest-cost) path from PE2 to PE4 is via P2, so PE2 pushes a label onto the packet, and then forwards the
packet to P2.

When the labeled packet reaches P2, a label swap is performed, and the packet is forwarded to P4. When the
packet reaches P4, another swap is performed, and the packet is forwarded to PE4. So far, so good; we’ve gotten
the data packet to the far side (egress) PE.

Upon receipt of the packet, PE4 pops the label, and then says to itself “Now, to which customer does this data
packet belong: A or C?” To be a little more precise, the question is, “In which VRF should PE4 do the packet
lookup, VRF A or VRF C?” Since PE4 doesn’t know, it will drop the packet, creating a big problem!

It appears that we need some mechanism by which the ingress PE can tell the egress PE which VRF to use for a
particular data packet. Well, believe it or not, there is such a mechanism, and it’s called Multi-Protocol BGP (MP-
BGP). Basically, the way it works is that when PE4 (the egress PE) advertises a prefix (IP route) it learned from
CE-A3 over to PE2 (the ingress PE), the MP-BGP update includes a label along with the prefix. Now, when PE2
wants a data packet to be looked up in PE3’s VRF A, it simply includes that label with the data packet, so that
PE3 knows what to do.

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 5

But wait, didn’t PE2 already push a label onto the data packet? Yes, so when forwarding a data packet into the
MPLS cloud, what PE2 has to do is push two labels: an LSP label that is used by the P routers to get the packet
to the egress PE, and a VPN label that is used by the egress PE to determine which VRF is applicable.

We decided that in order for a Layer-3 MPLS VPN to function correctly, the ingress PE is going to need to push
two labels onto each data packet. Let’s say that we have a data packet going from site A2 to site A3, using the
topology shown below in Figure 4.

Figure 4.

When the data packet from CE-A2 arrives at PE2 (the ingress PE), PE2 will push two labels onto the packet: an
LSP label and a VPN label. This is referred to as a label stack. For an example using an Ethernet frame, refer to
the L-3 VPN Label Stack in Figure 5.

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 6

 Figure 5.

As you can see, the arrangement is that the LSP label is adjacent to the EtherType field, and the VPN label fol-
lows that, adjacent to the IP header. Label positions are commonly referred to as top and bottom, as shown in
the Top and Bottom frame in Figure 5. The labels are also sometimes referred to as the inner and outer, as shown
in the Inner and Outer frame in Figure 15. Thus, when doing MPLS Layer-3 VPNs, we use two labels.
• Top = Outer = LSP label (per TDP, LDP or RSVP)
• Bottom = Inner = VPN label (per MP-BGP)

By the way, each four-byte “label” (sometimes called a “shim header”) actually contains four fields, as shown in
Figure 6.

Figure 6.

The four fields are:

• Label (the actual label value) – 20 bits
• EXP (Experimental) – 3 bits
• S (Bottom of Stack) – 1 bit
• TTL (Time to Live) – 8 bits

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 7

What we’ve been calling “the label” is actually the 20-bit label field. Using 20 bits allows for over a million
unique labels (labels 0 through 15 are reserved), which is more than enough for the foreseeable future.

If QoS (Quality of Service) is implemented, the ingress PE would likely set the “EXP” bits to reflect the IPP (IP
Precedence) of the incoming packet.

The S bit is set to 1, if that particular label is the bottom (inner) label in the label stack; otherwise, it is set to 0.

The TTL field fulfills the same function as that in an IP header, eventually dropping any packets that become
caught in routing loops. The label TTL field also allows for traceroute through an MPLS cloud, which displays
the P and PE routers along the LSP (or the routers can be configured to hide the internals of the WAN core).

It’s possible to have more than two labels in a stack, but this is less common (Cisco allows up to six).

Protocols that Make Layer 3 MPLS VPNs Work

Let’s look at some of the behind-the-scenes protocols that make things work. First, we’ll need to make the
routes at the customer sites known to the PE devices. Since the CEs and PEs are routers, we can accomplish this
any of these three methods.
• Static/default routing
• An IGP
• BGP

It’s not required that a particular customer use the same method at all of its sites. For example, a remote sales
office might be set up with static routes (on the PE) and a default (on the CE), whereas regional offices might
use an IGP as the CE-PE protocol, while the corporate HQ uses BGP as the CE-PE protocol.

Now that the routes from a customer’s site are known by a PE router, it needs to advertise the customer routes
across the provider’s cloud to the other PEs. For this, we use MP-BGP. It’s called Multi-Protocol because, in addi-
tion to advertising IPv4 routes (as with standard BGP), it can also advertise other things. In a Layer-3 MPLS VPN
environment, the other things would be:
• VPNv4 routes
• MPLS Route Targets
• MPLS labels

The VPNv4 routes are the IPv4 prefixes for the various customers, modified by prepending a RD (Route Distin-
guisher) to make them customer-specific, thus preventing address collisions. An RT (Route Target) is used to tell
a far-side PE into which VRF to insert a particular customer prefix. The MPLS label is the VPN (inner or bottom)
label that’s pushed by the ingress PE on data packets, so that the egress PE knows which VRF applies to that
data packet.

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 8

To support MP-BGP within the provider’s cloud (specifically, the advertisement of PE loopbacks), an IGP is
needed. This could be one or more of the following.
• OSPF
• IS-IS
• EIGRP

Aside from OSPF and IS-IS being open standards, they have another potential advantage over EIGRP for an
MPLS provider, which is that they support MPLS Traffic Engineering (TE), while EIGRP does not. This means that
for providers planning to do MPLS-TE, EIGRP is not an option.

Speaking of labels, in addition to the VPN label carried by MP-BGP, there is another label used by MPLS – the
LSP (top or outer) label. This is the label that’s used to get the data packet to the egress PE, and is swapped hop-
by-hop by the P routers as a data packet traverses the WAN cloud. This LSP label is advertised using one of the
following protocols.
• TDP (Tag Distribution Protocol)
• LDP (Label Distribution Protocol)
• RSVP (Resource Reservation Protocol)

TDP is Cisco’s proprietary protocol for advertising LSP labels (tags, in the pre-MPLS Cisco jargon) from one
router to another. LDP (RFC 3036, http://www.rfc-editor.org/rfc/rfc3036.txt) is the open-standard replacement for
TDP, and it offers additional features. RSVP (RFC 2205, http://www.rfc-editor.org/rfc/rfc2205.txt) is used by MPLS
Traffic Engineering to reserve bandwidth along a particular LSP.

Pseudo Wire (VPWS)

Now let’s imagine that a customer has only two sites that they’d like to connect using a WAN service provider.
The way this was done in the past would typically be with a leased line. This works, but it requires the customer
to have a CE router at each site that converts between the LAN encapsulation (typically Ethernet) and the WAN
encapsulation (HDLC, PPP, Frame Relay, etc.).

Wouldn’t it be nice if the customer could just run Ethernet to the PE? If so, they wouldn’t need the CE router. In-
stead of setting up a VRF for this customer on the PE, let’s go into the interface on the PE to which the customer
is attached, and assign a unique Circuit ID (CID). On the PE on the far side, we’ll do the same thing, using the
same value for the CID. Then, instead of MP-BGP, we’ll use Targeted LDP (TLDP) to connect the interfaces on the
two PEs. From the customer’s perspective, the provider’s MPLS cloud appears as a LAN repeater, as in Figure 7.

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 9

 Figure 7.

This arrangement, which is effectively a Layer-1 VPN, is referred to as “Pseudo Wire” (RFC 3916, http://www.rfc-
editor.org/rfc/rfc3916.txt), and it’s very popular with both customers and providers. You might also see it called
Virtual Leased Line (VLL), Virtual Private Wire Service (VPWS), Transparent LAN Service (TLS) or Ethernet over
MPLS (EoMPLS). Whatever it’s called, it acts like a private point-to-point link between the two customer sites.

What if the customer has more than two sites? The legacy solution might be Frame Relay, but again, this
requires a router at each customer site to handle the encapsulations. Instead, we could either start running
multiple Pseudo Wires (anything from a hub-and-spoke up to a full mesh), or we could have the provider’s MPLS
cloud emulate a LAN switch, as shown in Figure 8.

Figure 8.

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 10

Since the MPLS cloud is now functioning as an Ethernet switch, while keeping customer traffic separated, it’s ef-
fectively a Layer-2 VPN. This is commonly referred to Virtual Private LAN Service (VPLS). With VPLS, the CIDs can
be advertised using either MP-BGP or TLDP. By the way, Cisco refers to this Layer-1 and Layer-2 MPLS VPN stuff
as Any Transport over MPLS (AToM).

What about customers who are using other Layer-3 protocols, such as IPv6, IPX, AppleTalk, and so forth? Since
the P routers are doing only label switching, they never care about any customer’s routed protocols. The PE
routers would need to understand the customer’s routed protocols for Layer-3 VPNs, but no equipment vendors
(including Cisco) have implemented VRFs for anything but IPv4 and IPv6. How then to handle the other routed
protocols?

The answer is to use Pseudo Wire (VPWS) or VPLS, for which the PEs don’t care about the customers’ routed pro-
tocols. Likewise, multicasting can also be supported by making the provider’s MPLS could appear as a Layer-1 or
Layer-2 service.

Summary
From the provider perspective, MPLS is attractive because all of these services (Layer-1, Layer-2, and Layer-3
VPNs) can all be carried simultaneously over the same infrastructure, with only the PE routers requiring configu-
ration on a per-customer basis.

Learn More
Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge.
Check out the following Global Knowledge courses:
MPLS – Implementing Cisco MPLS v2.2
MPLST – MPLS Traffic Engineering and Other Features
MPLS ENT – Enterprise Networks over Service Provider MPLS

For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to speak with
a sales representative. Our courses offer practical skills, exercises, and tips that you can immediately put to
use. Our expert instructors draw upon their experiences to help you understand key concepts and how to apply
them to your specific work situation. Choose from our more than 1,200 courses, delivered through Classrooms,
e-Learning, and On-site sessions, to meet your IT, project management, and professional skills training needs.

About the Author

Al Friebe (CCDA, CCDP, CCNA, CCNP, A+, CCSI) has taught networking classes since 1995. He previously served
as Global Knowledge’s Course Director for BGP and BSCI, and he is the author of our current ICND2 labs. His
previous experience includes instructor duty in the U.S. Navy’s Nuclear Power School, radio-chemistry, software
engineering, and network management.

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 11