Class in Session: Cisco

Let’s take a look at some of the things that we can do with MPLS. As we know, one of those things is Layer-3 MPLS VPNs, a peer-to-peer VPN scheme in which the PE and CE devices are both routers. 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 1:

Now let’s imagine that a customer has only two sites which 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 or whatever).

Wouldn’t it be nice if the customer could just run Ethernet to the PE? If so, they wouldn’t need the CE router. Instead 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 “CID” (Circuit ID). 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 TLDP (Targeted LDP) to connect the interfaces on the two PE’s. From the customer’s perspective, the provider’s MPLS cloud appears as a LAN repeater, as in Figure 2:

This arrangement, which is effectively a Layer-1 VPN, is referred to as “Pseudo Wire” (RFC 3916), and it’s very popular with both customers are providers. You might also see it called “VLL” (Virtual Leased Line), “VPWS” (Virtual Private Wire Service), “TLS” (Transparent LAN Service) or “EoMPLS” (Ethernet over MPLS). 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 run 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 3:

Since the MPLS cloud is now functioning as an Ethernet switch, while keeping customer traffic separated, it’s effectively a Layer-2 VPN. This is commonly referred to “VPLS” (Virtual Private LAN Service). 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 “AToM” (Any Transport over MPLS).

What about customers that 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 protocols. Likewise, multicasting can also be supported by making the provider’s MPLS could appear as a Layer-1 or Layer-2 service.

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 configuration on a per-customer basis.

Well, that’s it for MPLS … for now, anyway!

Author: Al Friebe

Having discussed Layer-3 MPLS VPNs, 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, what’s needed is to advertise the customer routes across the provider’s cloud to the other PEs. For this, we use MP-BGP (Multi-Protocol BGP). It’s called “Multi-Protocol” because in addition 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 Distinguisher) to make them customer-specific, and 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.

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 “TE” (Traffic Engineering), 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) is the open-standard replacement for TDP, and it offers additional features. RSVP (RFC 2205) is used by MPLS Traffic Engineering to reserve bandwidth along a particular LSP.

Next time, we’ll examine some of the other things that can be done with MPLS.

Author: Al Friebe

Welcome back! Previously, 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 in Figure 1:

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 2:

As you can see, the arrangement is that the LSP label is adjacent to the “EtherType” field, and the VPN label follows 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 2. The labels are also sometimes referred to as the “inner” and “outer”, as shown in the “Inner and Outer” frame in Figure 2. 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 3:

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

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). Next time, we’ll take a look at the behind-the-scenes protocols that make MPLS work.

Author: Al Friebe

Having looked at the “big picture” when it comes to MPLS, we now need to focus our attention on what happens when a data packet traverses an MPLS cloud.

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.

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 question 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.

Continue reading ‘MPLS – Part 9′

When we left off last time, we were about to examine how MPLS might solve the three major problems that must be overcome in order to use routers within a WAN provider’s cloud. Those three problems are:

• Multiple routing tables in RAM
• Excessive latency
• Address-space collisions

Refer to Figure 1 for an example topology. Note that there are two customers, “A” and “B”, each with three sites, and that they have overlapping IPv4 address space:

The first problem we had to deal with was the amount of RAM required to support the routing tables. As we discussed last time, with MPLS, the PE routers need only the routes for the customers with which they are directly involved, and the P routers do not need any customer routes whatsoever, IPv4 or otherwise. All the P routers need is enough information to get the packets to the proper PE, and we’re using labels for that. The fact that we are shielding the PE and P routers from having to know all of the customer routes means that we’re spending less money on RAM, which solves the first of our three problems.

Continue reading ‘MPLS - Part 8′

We’ve already discussed how the P (Provider) routers swap or exchange labels at each hop within the WAN cloud. The sequence of routers and labels used for a particular path is referred to as the LSP (Label-Switched Path). In general, the LSP going between the sites in the reverse direction does not use the same label values. In fact, unlike a Frame Relay PVC, with MPLS there isn’t even a requirement that the same physical path be used in both directions. In other words, an MPLS LSP is unidirectional, whereas a Frame Relay PVC is bidirectional.

You might be wondering how the PE (Provider Edge) and P routers know which label values to use when doing a “push” or a “swap”. There are three protocols that can be used to advertise LSP labels between routers (TDP, LDP and RSVP), and we’ll discuss them in a later post.

Congratulations … you’re now doing MPLS, or Multi-Protocol Label Switching!

It gets its name from the fact that the P routers are “Label Switching”, and therefore don’t care about the “Multi-Protocols” used by the customer (and therefore should support any routed protocols). The PE  routers only need to know the routes for customers to which they are directly attached, and the P routers do not need to know any customer routes, for any protocol. Finally, the CE (Customer Edge) routers know nothing about labels at all, because they never see one.

Now that we have an idea of how MPLS works, we can define some additional terms. We know that a CE router is located at a customer site, and thus is CPE (Customer Premises Equipment). A CE generally deals with unlabeled packets, sending to and receiving from, a PE router.

A PE is located at one of the provider’s POPs (Points of Presence). A PE pushes labels onto packets it receives from a CE before forwarding the packets to a P router, and “pops” labels from packets received from a P router before forwarding the packets to a CE.

The P routers are located within the core of the provider’s cloud. Because P routers primarily do label swaps, a P router can also be referred to as a LSR (Label-Switch Router). Likewise, a PE can be called an Edge LSR, or LER (Label Edge Router).

Here’s a summary of the terminology when it comes to the provider routers involved with MPLS:

• PE = POP = Edge LSR = LER — they “push” and “pop” labels
• P = LSR = Core — they “swap” labels

Next time, we’ll discuss MPLS in more detail, and see how it deals with LSP labels.

Author: Al Friebe

We have three major issues that we need to deal with in order to successfully use routers within a WAN provider’s cloud:

• Multiple routing tables in RAM
• Excessive latency
• Address-space collisions

Let’s assume that we have a WAN provider with two customers, “A” and “B”, each with three sites, as shown:

Now, let’s say that an IPv4 data packet enters the provider cloud from customer site A1, headed for site A3. When it leaves CE-A1, the packet is encapsulated within some standard Layer-2 frame type. Among others, this might be:

• Ethernet
• HDLC
• PPP
• Frame Relay

An example of an Ethernet frame encapsulating an IPv4 packet appears as the “Unlabeled Packet” below:

As the packet is processed by the PE1 router, the frame header and trailer encapsulating the incoming packet will be stripped, and after the IP header manipulations are complete, the packet will be encapsulated into a new frame, and then forwarded towards CE-A3 via either P1 or P2.

Now, imagine that the packet that is sent from PE1 towards the P router is not a normal packet. Instead, the PE “pushes” a label onto the front of the packet, and then encapsulates the modified packet into the outbound frame. The label will then appear within the frame between the Layer-2 and Layer-3 headers (for IP over Ethernet, this is just after the “EtherType” field, and just before the IP header). When the PE pushes the label, it also changes the EtherType from “0×0800” (unlabeled IP) to “0×8847” (labeled IP). An example appears as the “Labeled Packet” in Figure 2. The process of “pushing” the label is also referred to as “inserting” or “imposing” a label.

Continue reading ‘MPLS – Part 6′