26.0. Introduction

Multiprotocol Label Switching (MPLS) is an advanced topic. Before tackling this technology, you should have a good understanding of IP routing, with particular attention to BGP (Chapters 5 and 9, respectively). However, with that caution, MPLS is not as complicated as many of the books on the subject make it appear. There are several basic concepts and protocols that work together to create an MPLS network, and these correspond to the various essential steps required to set up such a network.

And before going into the concepts and protocols of MPLS, it is worth noting that most users of MPLS networks don't ever need to actually configure MPLS. The usual model is that MPLS exists within the core of a network provider's network. The provider delivers some sort of network connection, such as a switched Ethernet port to the customer's premise, and the customer just routes IP traffic into this port. The customer doesn't actually need to know anything about MPLS.

If you are the customer of an MPLS network, there are still some issues worth noting, particularly regarding how to exchange routing protocol information with the MPLS network (Recipes 26.3, 26.5, 26.6, 26.7, and 26.8), and you may be interested in how to use QoS (Recipe 26.9) or how multicast works with MPLS (Recipe 26.11). But in most of these cases, you will need to work with your MPLS network provider to implement the features you want, as everything depends on how they have built their network.

However, there is one important recipe in this chapter that's just for the MPLS customer. Recipe 26.12 talks about how to connect to an MPLS network that doesn't deliver all of the protocols or services you need.

The first basic concept is label switching (sometimes called tag switching) itself. This is essentially just a way of improving routing efficiency through a routed network. In normal IP routing, as a packet bounces along the path from the source to the destination, it passes through a series of routers. Each router receives the packet, opens up the IP header, looks up the destination information in its routing table, and then sends the packet along to the next hop on its path. We have already discussed some of the tricks that routers use to improve the efficiency of this process. For example, the router might generate a fast switching cache so that once it has looked up a destination address in its routing table for one packet, it doesn't need to repeat this process for the next packet in the same data stream.

Label switching takes this concept one step further by marking the packet header with a special number that tells each router how to route the packet. With this information, the router doesn't need to look at the IP packet header at all. It just checks the label and forwards the packet. This may not sound like a significant improvementafter all, how hard is it really to look up an IP address in a routing table? Well, it turns out that in modern high-speed networks where you need to forward billions of packets per second, MPLS offers a significant performance improvement, which is one of the reasons why it has become so popular with network service providers.

MPLS requires the Cisco Express Forwarding (CEF) feature. The routers use CEF to build the MPLS label tables.

The second basic concept of MPLS is the VPN or Virtual Routing and Forwarding (VRF) table. This is particularly important in carrier environments. A network service provider or WAN carrier needs to deliver packets for different customers reliably and flexibly. In the old days, WAN carriers would build large multiplexed networks to provide dedicated leased line bandwidth between customer sites. If they could instead build a simple cost-effective IP network backbone and send all of their customer traffic through this single network, this would clearly save a lot of money and it would be easier to manage.

But there are serious complications to simply attaching all of your customers to the same routed IP network. Suppose two of your customers use the same unregistered IP address ranges? Suppose a customer uses the same IP address range as the network core? You could get around these problems by using NAT at the edges of the network, but then you must rewrite the source and destination addresses of every packet for every customer twice: once when it enters your network and again when it leaves. And that also introduces the management nightmare of maintaining a huge and globally unique address translation table that encompasses the requirements of all of your clients.

MPLS solves this problem in a different way by creating VPNs by means of VRF tables. The VRF is the special routing table that maps a set of MPLS path labels to IP addresses, and associates a set of MPLS edge devices together into VPNs. Thes MPLS VPNs are similar to the VPNs that we discussed in Chapter 12, in that they allow you to segregate and protect traffic as it passes through a network. But most of the VPNs that we discussed in Chapter 12 were point-to-point. The MPLS VRF concept is more of a community of several end points belonging to the same customer network. It provides fully meshed connectivity between all of these end points.

We can share a routing table among these end points and still have complete separation of the customer networks. Customer A can't access Customer B's network, and can't even see his routing table. And, best of all, this all happens transparently without the need to manually configure everything in the carrier network.

This brings us to the third essential concept, which is Multiprotocol over Border Gateway Protocol (MBGP, sometimes also called MP-BGP). This is a set of extensions to BGP described in RFC 2283. This allows us to define a set of "address families," which correspond to the various customer routing tables included in the VRF tables. Then BGP simply carries the customer routing information between the various customer sites where it can be redistributed into the customer's routing protocol.

In Chapters 6, 7, 8, and 9, we saw that redistributing from one routing protocol to another generally means that the redistributed routes are considered "external." This is a problem, as internal routes are preferred to external routes. So if a customer network intended to use a fast MPLS link as its primary path and some slower leased line or dial backup technology as a backup path, a great deal of unpleasant manual manipulation of the routing protocols and administrative distances would be required. So, in Cisco's implementation, when you redistribute routes from MBGP into an IGP, the IGP considers the routes to be "internal." This sometimes confuses people at first, but it is definitely preferable to the alternative.

Some Terminology

Perhaps the most confusing thing facing experienced IP network engineers who look at MPLS for the first time is the new jargon. In this chapter, we will try to go a little bit easy on the jargon and acronyms, using functional descriptions such as "MPLS router" instead of LSR (for Label Switch Router), valuing greater clarity over compactness. Nonetheless, it is important to review some of the most common terms because many readers will want to refer to other references for information that is beyond the scope of this short chapter:

Label Switch Router (LSR)

This is any router or switch that supports MPLS on one or more of its interfaces.

Label Switch Path (LSP)

This is a path that data might take through the MPLS cloud as it passes from one LSR to another. There might be several LSPs between two LSRs, so it is often important to identify the ingress LSR as the starting point of the LSP and the egress LSR as its end point.

Label Distribution Protocol and Tag Distribution Protocol (LDP and TDP)

These are two functionally similar but incompatible protocols. LDP is an open standard for MPLS, while TDP is a Cisco proprietary standard for Tag Switching. Most Cisco devices are able to automatically sense which protocol the neighboring LSR is using and adapt appropriately.

Both of these protocols perform the critical function of distributing MPLS label or tag information between adjacent LSRs.

Each of the preceding terms apply to MPLS networking in generalthat is, before any VPNs have been overlaid on the network. In a typical MPLS network, however, customer networks are attached at the edges of the network and interconnected by meshes of Virtual Route Forwarding (VRF) VPNs. In such a network the routers break down into four essential functional types. These are shown in Figure 26-1.

Figure 26-1. Types of routers in an MPLS network

C Router

A C, or Customer Internal Router, is a router that is purely internal to a customer's network. The C router connects to other C routers and to the CE router. It does not connect directly to any P or PE routers. This router does not run MPLS.

CE Router

A CE, or Customer Edge Router, is the connection point between the customer's network and the MPLS network. The CE router talks to PE routers and C routers, but not to the P routers. This router also does not run MPLS.

PE Router

The PE, or Provider Edge Router, is where much of actual work takes place. These routers run MPLS and are part of the carrier's MPLS network, but they also communicate with the customer's CE router and may take part in the customer's routing protocol. PE routers are the end points of the VPNs.

P Router

P, or Provider Internal Routers, are purely internal to the carrier's MPLS network. This router runs MPLS to communicate with the rest of the carrier's network and transport customer packets through VPNs. However, the P router does not see the customer routing tables or VRF information. These are the backbone of the MPLS network, and they talk to PE routers and other P routers.

Benefits of MPLS

We have already mentioned one of the key benefits of MPLS, its speed and efficiency in high-speed networks. Because an MPLS network is built on an IP network, it also has the excellent scaling and stability features of IP networks (assuming, of course, a well-designed underlying IP network).

MPLS relies heavily on IP. The MPLS packet header is essentially an IP packet header, but with an additional "tag" or "label" inserted. This tag information defines a path. The association between these MPLS tags and IP routes are predefined and dynamically updated by the network. The net result is that, when a router receives an MPLS packet, it just needs to look at this tag information to know everything it needs to know about how to forward the packet. This greatly improves network efficiency.

The tag information in the MPLS header also includes three bits called the Experimental Field, or EXP. It is customary to use these bits to carry Quality of Service (QoS) information. So, if the EXP field on each packet is set at the ingress point, the MPLS network can use this information to segregate streams of different priority packets without sacrificing any of the speed advantages that we have already discussed.

Another key benefit of MPLS is Traffic Engineering (TE). Traffic Engineering is a general networking term that simply means that the redundant paths through the network will be used in some more complex way than simply always using the shortest path to the destination.

For example, suppose you have a network that includes two paths between points A and B. By default, if the routing protocol determines that one of these paths has a lower aggregate metric, the network will forward all of the traffic for this destination along this path. Now suppose that this first path is being over-used and packets are being dropped due to congestion. The network engineer may decide to redirect some of this traffic along the second path, reasoning that a slightly greater latency is better than a dropped packet. Whatever the engineer does to achieve this result is generically called Traffic Engineering.

MPLS has a number of built-in features to dynamically facilitate traffic engineering. A detailed discussion of Traffic Engineering would fill several books, so in this chapter we will just show a simple example of a useful Cisco feature called Autoroute, which uses either OSPF or IS-IS to dynamically distribute resource information for Traffic Engineering.

While all of the examples in this chapter use Layer 3 VPNs, MPLS is also capable of running Layer 2 VPNs, which are effectively bridged connections between sites. And MPLS can also do useful things like circuit emulation, in which a legacy medium such as a T1 leased line can be carried through an MPLS network. Cisco implements a feature set called Anything over MPLS (AToM), which allows you to even deliver ATM and Frame Relay circuits to a customer site and transport the traffic through the same MPLS network core.

All of these benefits mean that MPLS is rapidly becoming the underlying architecture of choice for deploying carrier networks for voice and data traffic. In fact, because you can effectively run MPLS over an existing IP network, it is relatively straightforward to convert an existing IP WAN to an MPLS carrier network. It may take a little iterative re-engineering to get the full benefits of MPLS traffic engineering and QoS features in this case, but it inherently provides a mechanism for WAN service providers to phase out old multiplexed carrier networks in favor of more modern and flexible infrastructure.

IOS Versions and Feature Sets

MPLS is not included in all IOS images. The Version 12.4 feature set images are rather complicated, as the names and content depend on the hardware platform. The general rule of thumb is that you need one of the "Advanced," "Service Provider," or "Enterprise" feature sets if you want to use MPLS. For example, for the 2800 series routers, you can run MPLS if you have the "Advanced IP Services" version, any of the "SP Services" versions, or any of the "Enterprise Services" versions (including "Enterprise Services," "Advanced Enterprise Services," "Advanced Enterprise Services with SNA," or "Enterprise Services with Crypto" releases).

If you are unsure, please consult Cisco's Feature Navigator http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp.

Structure of This Chapter

This chapter will work a little bit differently than other chapters in this book. Rather than having, for example, a first recipe that sets up all of the features of a basic MPLS network, we will spend the first several recipes showing how to configure each of the essential types of routers in the same simple network. Then we will examine some interesting and useful variations.

We need to do it this way for two reasons. First, there are so many routers involved in even a simple MPLS network that it's more logical to take them individually and explain the configurations one at a time. Second, some of the individual router configurations, particularly for the PE routers, are rather long, and need to be discussed in some depth.

Consequently, we will use the same basic network, shown in Figure 26-2, for all of the recipes in this chapter. The router names and connections used throughout this chapter will be consistent with this picture, although we won't necessarily talk about every router in every recipe, and we will only show those portions of each router configuration that are relevant to the concept being discussed.

Figure 26-2. Example MPLS network

In this figure, the C and CE routers can be any type of router running essentially any version of IOS, except when we will note that we are using some special feature. None of the C or CE routers run MPLS. The P and PE routers all run MPLS. The only special device in this picture is the P router called Switch-P2, which is actually an ATM switch. In our example, this will be a Cisco Lightstream 1010 that uses OC3 interfaces to connect to Router-PE1 and Router-PE2. The configuration of this device will be discussed in Recipe 26.4. Although we use a Lightstream 1010 for this purpose, any Cisco ATM switch could be readily substituted. We also have the P router called Router-P1, which is a conventional IP router. You don't need ATM for MPLS, although the two protocols do work very well together.

The point of our example is to discuss the issues and features involved in running MPLS over ATM links, which is a relatively common implementation. Because there are so many different varieties of ATM switches, all of which are configured differently, we will not cover configuration of the ATM switch in any detail, and offer the Lightstream 1010 configuration only as a general guide.