The Ultimate ISCW Study Guide

Chris Bryant, CCIE #12933 <<back http://www.thebryantadvantage.com/ - index next>>

MultiProtocol Label Switching (MPLS)

Overview
Intro To MPLS Label Switching Routers and Edge LSRs What Is A Label? The Control Plane And Data Plane The MPLS Process Penultimate Hop Popping Who Converges First - IP or MPLS? FIB / LIB / LFIB Comparison Configuring MPLS MPLS VPNs The Route Distinguisher And Virtual Routing Table Hot Spots And Gotchas

If MPLS is new to you, no worries, we'll take care of that! Let's start by breaking the acronym into two parts: MP - "MultiProtocol". Simple enough! LS - "Label Switching". What's this "label" thing? To me, the hardest thing about getting started with MPLS is getting used to the terminology. Most if not all of the processes will seem familiar, but

the terms are very different. Give yourself some time to absorb all of the new terms to follow, and you'll be more than ready for exam day. Before we start learning the terminology and basic operation of MPLS, I should mention there are two modes in which MPLS can run. MPLS can run in Frame or Cell mode. In Frame mode, it's a packet that will have labels applied or removed; in Cell mode, it's an ATM cell. We'll concern ourselves exclusively with Frame mode in this section.

Right off the bat, we've got new router roles in MPLS - the Label Switching Routers (LSR) and the Edge LSRs. As you'd guess, the Edge LSRs are found at the edge of our MPLS network, at both the entry and exit points. Typically, an Edge LSR will not have all of its interfaces enabled for MPLS, but an LSR will have all of its interfaces so enabled. On occasion, LSRs are referred to as Core LSRs, since they're at the core of the MPLS deployment. The major difference between the two is what they use to forward packets. Using the previous illustration, here's how a packet would be sent through the MPLS cloud. The Edge LSR to the left would perform a routing table lookup, and then attach a label to the packet before sending it downstream to a Core LSR. Core LSRs keep a routing table, but these core LSRs do not perform a routing table lookup to determine the next hop. Instead, those LSRs use the contents of the label placed on the packet by the Edge LSR to determine the next hop, and then replace that label with a label of their own before sending the packet downstream (label switching).

When the Edge LSR to the right receives the packet, it removes the label and then perform a routing table lookup to determine the next downstream hop. Packets can have more than one label, called a label stack. MPLS VPNs use label stacks as their form of encapsulation, and we'll talk about that feature later in this section. As we just saw, an Edge LSR will attach a label to the packet at one edge of the network, and another Edge LSR removes the label at the other edge. MPLS uses these terms to describe both actions: Attaching a label is called a push, or label imposition Removing a label is called a pop, or label disposition There is a third action taken with labels, a label swap. Label swaps are performed by a Core LSR before sending the packet to a downstream LSR. From entry to exit, then, you can really sum up the MPLS process in three words: push swap pop We'll go through an example of "push / swap / pop" shortly. A Closer Look At Labels A label is a locally significant value that identifies a packet as belonging to a particular Forwarding Equivalent Class (FEC). An FEC is a group of packets that will be forwarded to the same next-hop IP address and that are assigned the same level of treatment. Each label has four fields, totaling 32 bits. Label (20 bits) Experimental / CoS (3 bits) TTL (8 bits) BOS (bottom-of-stack, 1 bit) RFC 3031, "Multiprotocol Label Switching Architecture", lists those 3 bits as "experimental". In reality, the Cisco IOS uses those bits for Code Of Service. The Time To Live (TTL) bits serve the same purpose as IP TTL bits. The BOS value is referred to in some MPLS documentation as simply

"S". As I mentioned, a packet can have more than one label. The BOS bit will be set to zero on all labels except the very bottom label, which will have a BOS of one. A label stack consists of multiple labels, one on top of the other. Labels in a label stack do not interact in any way. And it wouldn't be Cisco networking without some kind of PID or RID! In this case, it's a PID. The MPLS PID indicates whether labels have been placed on the packet. The Control Plane And Data Plane These planes are the two basic components of MPLS, and they take care of the overall routing operation. Basically, the control plane builds and holds the routing table while the data plane handles the actual forwarding of the packets. The control plane is also where routing protocols operate and the IP routing table is kept. Also, label bindings are exchanged on the control plane, and we'll talk more about that later in this section. The data plane is commonly referred to as the forwarding plane, but most Cisco documentation calls it the data plane. For that reason, that's how we'll refer to it here. That forwarding is based on destination IP addresses or labels, and two separate databases are used to carry out that forwarding. Both the Forwarding Information Base (FIB) and Label Forwarding Information Base (LFIB) are found on the data plane. When the forwarding process uses IP addresses, it's the FIB that performs the forwarding; when the forwarding process uses labels, the LFIB performs the forwarding. The control plane is where we'll find the many routing protocols we've come to know and love: OSPF (popular with MPLS service providers) ISIS (also a popular MPLS SP choice) EIGRP RIP BGP ... and a couple of protocols that may be new to you: LDP, the Label Distribution Protocol TDP, the Tag Distribution Protocol RSVP, the Resource Reservation Protocol Both LDP and TDP are used to carry label information between LSRs. LDP is the industry standard, and can run on both Cisco and non-Cisco

MPLS routers. TDP is Cisco-proprietary, and we know the drill there - it can only run on Cisco routers. Most current Cisco MPLS documentation mentions that TDP is being phased out in favor of LDP. If you have a downstream Cisco router that you have no access to, you may choose to run both LDP and TDP on the interface facing that router. In most real-world networks, though, it'll be LDP all the way. You may be familiar with RSVP from your earlier CCNP studies. The "resource" being reserved with RSVP is bandwidth. RSVP can be used to reserve an end-to-end path for data transmission in advance of the data actually being sent. RSVP is used in MPLS Traffic Engineering (MPLS TE), and since TE is not part of the ISCW blueprint, this is about the only mention I'll make of RSVP. As always, when you see a list of protocols that do the same thing, it's a good idea to know all of them. I will mention MPLS TE just a bit near the end of this section, but you are not required to configure MPLS TE on the ISCW exam. LDP uses UDP port 646; TDP uses TCP port 711. Make sure your network's ACLs allow these ports as needed. From the service provider side, these port numbers can be used in ACLs to block your network from using one or both. You don't see LDP blocked very often, but occasionally you'll see TDP blocked. The MPLS Process Let's take a look at how each router in the earlier example would handle a given packet. For clarity's sake, I've removed the MPLS cloud from the diagram. I've also assigned a number to each router. LER1 and LER2 are our Edge LSRs.

When that packet arrives at LER1, that router will look in its Forwarding Information Base (FIB) for the longest match. That longest match result is used to determine the next-hop IP address for that packet, and that nexthop address determines which Forwarding Equivalence Class (FEC) the packet belongs to.

As mentioned earlier, an FEC is simply a group of packets that will be forwarded to the same next-hop IP address and that are assigned the same level of treatment. The destination IP address is generally the value used to determine the packet's FEC, but it's not the only value we can use. FEC membership can also be assigned according to these values: Incoming or outgoing interface ("ingress" or "egress") IP Precedence or DSCP Source IP address Source or destination port number Layer 2 circuit (especially with Frame Relay MPLS) Using our example, there are two possible next-hop values for packets leaving LER1. Packets that should be sent to LSR1 would be in one FEC, and packets using LSR2 as a next hop would be in another FEC. The end-to-end path through the MPLS domain followed by packets in a given FEC is the label-switched path (LSP). Remember the "push, swap, pop" description earlier in this section? LER1 will now push a label onto the packet - technically called label imposition - and then forward the packet. The label is actually inserted between the L2 and L3 headers, which is why you occasionally hear MPLS referred to as "Layer 2.5 switching". Let's assume that LER1 forwards this packet to LSR1.

There are two possible next-hops from LSR1 as well. To determine the proper next-hop address, LSR1 performs a label lookup on the top label on the incoming packet. (In this case, there's only one.) LSR1 sees the nexthop is LSR3, determines the proper egress interface and label for the packet, replaces the top label with a label of its own, and then forwards the packet. That's the "swap".

A core concept of MPLS is that the core LSRs will examine only the label in making its forwarding decision, not the IP destination. Earlier in this section, I mentioned two values that are exchanged at the control plane: routing information label binding A label binding is a mapping of an FEC to a label. That label binding information exchange allows LSR1 to know what label value LSR3 expects. To review, our three major label exchange information protocols are: LDP TDP RSVP We'll assume that LSR3 was the next hop, and in turn LSR3 forwards the packet to the other edge router, LER2. This Edge LSR is the egress LSR, the LSR through which the packet will leave the MPLS network. By default, the egress LSR will have to perform two lookups. After the initial label lookup, the egress LSR will remove the label (label disposition, or "popping"), "revealing" the destination IP address. The router will then perform a routing table lookup to determine the proper action to take.

That removal of the final label by the edge router is the "pop", and the "push, swap, pop" MPLS process is complete! If that sounds like a lot of work for the egress LSR, you're right. Your Edge LSRs should always be workhorse routers, but even so it would be more efficient if the egress LSR didn't have to perform two lookups. That's where Penultimate Hop Popping comes in. "Penultimate Hop Popping" Not only is it fun to say, but it's also an important concept in MPLS. As we just saw, when an Edge LSR receives a packet from a Core LSR and that packet is exiting the MPLS network, that Edge LSR must actually perform two lookups: a label lookup, resulting in the Edge LSR popping that label, resulting in an unlabeled IP packet a routing table lookup in order to successfully route that IP packet With penultimate hop popping, the Edge LSR can actually request that the downstream MPLS router pop that label. As a result, the Edge LSR receives an unlabeled IP packet, and the Edge LSR must now only perform one lookup - the routing table lookup.

PHP allows us to spread the workload of those last two lookups, and as always, spreading the workload makes for a more efficient process overall. The Importance Of IP Convergence While the LSRs will use labels to forward packets rather than IP prefixes, it's important to remember that these LSRs still have routing tables. Since the LSRs will be assigning labels to the destinations in the routing table, we've got to have IP convergence before we can even begin using MPLS. A stable IP network means a stable MPLS network, and an unstable IP network results in an unstable MPLS network.

Once the IP routing table has converged, an MPLS-enabled router will bind a label to each prefix in its routing table. The router will then use one of the three label distribution protocols mentioned earlier - LDP, TDP, or RSVP - to advertise these bindings to downstream routers. Each LSR will build a Label Information Base (LIB) to store both its locallycreated bindings and the bindings it receives from its neighbors. The LIB is found in the control plane. The information actually used by an LSR to perform label forwarding is the appropriately-named Label Forwarding Information Base (LFIB). The LFIB is found in the data (forwarding) plane. Normally, a labeled packet with no entry in the LFIB will be dropped. Since this is networking, we need an exception to the rule, and that exception is interim packet propagation. The "interim" part of IPP refers to the time between a labeled packet arriving at an LSR and the time the LSR's LFIB actually has an entry for that label. In this case, the LSR will perform CEF switching, which uses the FIB. If there's no entry in the FIB for the destination network, the packet is finally dropped. CEF must be enabled in order to run MPLS. Let's compare the FIB, LIB, and LFIB: FIB: Built by the IGP. This is not the routing table, but contains much the same information - next-hop IP addresses, etc. Located in the data plane. LIB: Built by our label distribution protocol, likely LDP. Contains the bindings of local labels to FECs and sends these bindings to neighbors. Located in the control plane. LFIB: Built by both the IGP and the LDP, this performs the actual forwarding of labeled packets. Located in the data plane. The combination of the FIB, the LIB, and the LFIB allow an Edge LSR to handle both incoming unlabeled and labeled packets appropriately. Why didn't I mention the Core LSRs there? If the MPLS domain is functioning correctly, the Core LSRs will receive only labeled packets and will generally send labeled packets, the exception being if PHP is in effect. Edge LSRs may receive labeled or unlabeled packets, and must be able to send them with or without a label. Let's take a look at some different scenarios an Edge LSR might face.

Here, the Edge LSR is receiving an IP Packet on an interface not enabled with MPLS. As shown in the following illustration, the Edge LSR would first perform a routing table lookup, and if the packet were destined for the non-MPLS network, the packet would simply be forwarded as an IP packet. If destined for the MPLS domain, a label would be attached and the labeled packet forwarded.

The Edge LSR will also receive labeled packets from the MPLS domain, and will generally be forwarding the "popped packets" to the proper destination network. If the Edge LSR has a connection to another MPLS router, though, the Edge LSR will swap the label and forward the labeled packet.

Configuring MPLS Let's take a look at some basic MPLS commands! We'll use this network and create an MPLS adjacency between R1 and R2. R2 is also forming an MPLS adjacency with a router off its serial0/0/0 interface. All routers are running EIGRP.

First things first: always enable Cisco Express Forwarding (CEF).

R1(config)#ip cef R2(config)#ip cef

Cisco's website mentions the following as benefits of CEF: improved performance scalability resilience Cisco also mentions that CEF is designed for "high-performance, highly resilient Layer 3 backbone switching". Better have some serious horsepower on that router! Or rather, those routers, since you can run CEF in distributed mode. Configuring CEF in that scenario is far beyond the scope of the ISCW exam, but suffice to say that using distributed mode allows multiple Cisco devices to share the workload, resulting in even faster switching.

And notice I said "Cisco devices" - CEF is Cisco-proprietary. Now back to the config! We'll enable MPLS on the fast0/1 interface of R1, and both the fast0/1 and serial 0/0/0 interfaces of R2.
R1(config)#int fast 0/1 R1(config-if)#mpls ip ? encapsulate Configure encapsulation with explicit-null label <cr> R1(config-if)#mpls ip R2(config)#int serial 0/0/0 R2(config-if)#mpls ip R2(config-if)#int fast 0/1 R2(config-if)#mpls ip

In just a few seconds, a message appears on both R1 and R2 that an LDP neighbor relationship has been formed with the remote router. R2 has formed an LDP neighbor relationship with the ISP router as well.
R1: 01:16:09: %LDP-5-NBRCHG: LDP Neighbor 10.0.1.2:0 (1) is UP R2: 01:16:11: %LDP-5-NBRCHG: LDP Neighbor 10.0.1.1:0 (1) is UP 01:16:11: %SYS-5-CONFIG_I: Configured from console by console 01:16:11: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.10:0 (2) is UP

You can verify the neighbor relationships with show mpls ldp neighbor.
R1#show mpls ldp neighbor Peer LDP Ident: 10.0.1.2:0; Local LDP Ident 10.0.1.1:0 TCP connection: 10.0.1.2.21750 - 10.0.1.1.646 State: Oper; Msgs sent/rcvd: 25/24; Downstream Up time: 00:14:51 LDP discovery sources: FastEthernet0/1, Src IP addr: 10.2.1.2 Addresses bound to peer LDP Ident: 10.2.1.2 10.5.1.2 10.0.1.2

Note that LDP adjacencies have formed even though we didn't specifically configure LDP to run on any of these interfaces. That's verified by show mpls interface as well.
R1#show mpls interface Interface IP FastEthernet0/1 Yes (ldp) Tunnel No Operational Yes

The detail option with that command gives us this information:

R1#show mpls interface detail

Interface FastEthernet0/1: IP labeling enabled (ldp): Interface config LSP Tunnel labeling not enabled BGP tagging not enabled Tagging operational Fast Switching Vectors: IP to MPLS Fast Switching Vector MPLS Turbo Vector MTU = 1500

We've established LDP is the default for these routers, so let's take a look at how to change this setting. We can do so globally with the mpls label protocol command...
R1(config)#mpls label protocol ? ldp Use LDP (default) tdp Use TDP

... or at the interface level with the exact same command. The command is the same, but note the additional option at the interface level.
R1(config-if)#mpls label protocol ? both Use LDP or TDP (Adapt to peer on multiaccess interface) ldp Use LDP (default) tdp Use TDP

I'm sure you've noticed by now that LDP is the default, so let's move on! R2 has five routes in its routing table, three directly connected routes and two discovered by EIGRP.
C C D D C 10.2.1.0 255.255.255.0 is directly connected, FastEthernet0/1 10.0.1.2 255.255.255.255 is directly connected, Loopback0 10.10.10.0 255.255.255.0 [90/2297856] via 10.5.1.10, 00:37:49, Serial0/0/0 10.0.1.1 255.255.255.255 [90/156160] via 10.2.1.1, 00:37:45, FastEthernet0/1 10.5.1.0 255.255.255.0 is directly connected, Serial0/0/0

There are five matching entries in the LIB, shown by show mpls ldp bindings.
R2#show mpls ldp bindings tib entry: 10.0.1.1 255.255.255.255, rev 8 local binding: tag: 17 remote binding: tsr: 10.0.1.1:0, tag: tib entry: 10.0.1.2 255.255.255.255, rev 4 local binding: tag: imp-null remote binding: tsr: 10.0.1.1:0, tag: tib entry: 10.2.1.0 255.255.255.0, rev 2 local binding: tag: imp-null remote binding: tsr: 10.0.1.1:0, tag: tib entry: 10.5.1.0 255.255.255.0, rev 10 local binding: tag: imp-null remote binding: tsr: 10.0.1.1:0, tag: tib entry: 10.10.10.0 255.255.255.0, rev 6 local binding: tag: 16

imp-null

16

imp-null

18

remote binding: tsr: 10.0.1.1:0, tag: 17

Note that the directly connected routes have a local binding of imp-null, while the EIGRP routes have a numeric value for the local binding. If PHP is in effect, this imp-null binding is an indication to the downstream router that it needs to pop the label for packets destined for that particular prefix. The default ethernet MTU of 1500 must be increased when MPLS is enabled on that interface: For "Pure" MPLS with no VPN or TE - 1504 will do. For MPLS VPNs, the mtu should be set to 1508. When both VPNs and TE are in place, set the mtu to 1512. In the real world, the MTU is regularly set to 1512 when MPLS is configured regardless of whether VPNs or TE are in use, so we'll do just that. Watch this one, though.. you can't use the ip mtu command you've used in the past.
R1(config)#int fast 0/1 R1(config-if)#ip mtu 1512 ^ % Invalid input detected at '^' marker. R1(config-if)#ip mtu ? <68-1500> MTU (bytes)

Instead, use the mpls mtu command.

R1(config-if)#mpls mtu ? <64-65535> MTU (bytes) R1(config-if)#mpls mtu 1512

Verify with show mpls interface detail.

R1#show mpls interface fast 0/1 detail Interface FastEthernet0/1: IP labeling enabled (ldp): Interface config LSP Tunnel labeling not enabled BGP tagging not enabled Tagging operational Fast Switching Vectors: IP to MPLS Fast Switching Vector MPLS Turbo Vector MTU = 1512

MPLS VPNs Before MPLS VPNs came along, we had two basic VPN models, overlay and peer-to-peer. When the service provider provides only virtual circuit connectivity -- Frame Relay, anyone? -- but no routing services, that is the overlay model.

When it comes to the peer-to-peer model, here's the good news: The SP is involved in the routing process And here's the bad news: The SP is involved in the routing process The service provider takes an active role in routing in the peer-to-peer VPN model. The customer routers send their routing information to the closest SP router, the Provider Edge router, and the PE router then distributes those routes to the other Provider (P) routers. Typically, the PE router receives the routes from the customer via an IGP such as OSPF or ISIS and then performs route redistribution to place these routes into BGP to advertise them to the other SP routers. So why is that bad? Any time you hear the phrase "route redistribution", you've got to be wary of routing loops, especially if there's more than one point of entry from the site advertising the route. Consider this example:

We'll cover "C" and "P" in just a moment; the key here is that our customer site has two points of entry, each connected to a separate Provider Edge router. If there's one thing we love in networking, it's redundancy, and we definitely have it here. If one link to a PE goes down, the other is still up! Of course, we want to have all of our links up, and that's where the danger of route redistribution comes in. Since we have multiple points of entry between the two sites, we have to be careful that a route advertised by one of our Customer Edge routers doesn't end up being advertised to the other CE by the other PE.

Here's what we don't want to have happen:

We do have tools at our disposal to prevent this from happening, route filters among them. Configuring route filters is out of the scope of the ISCW exam, but I can tell you that using filters and ACLs to prevent the above from happening isn't always easy. There's another potential issue when we add customer sites to that example. You and I both know of multiple networks that use the same RFC 1918 private address ranges - what happens when two or more customer sites advertise overlapping address ranges to the SP? Sounds to me like we need a separate routing table for each customer, and we'll have those when we use MPLS VPNs. MPLS VPNs To The Rescue Just as with MPLS in general, the configuration of MPLS VPNs brings new terminology along with it. We have four different router roles with MPLS VPNs: Provider Edge (PE) Provider (P) Customer (C) Customer Edge (CE)

These designations simply describe where you can find the router in the overall topology. The PE and P routers are owned by the Service Provider; a PE router is connected to a CE router, and the P routers are not. Both the PE and P routers must be running MPLS. It's the PE that attached an MPLS VPN label to the packet. The CE and C routers are owned by - you guessed it! - the Customer. The CE router has a connection to a PE router, and the C routers do not. The CE router will not run MPLS, but it will run an IGP that will allow it to exchange routes with the PE. In the real world, the SP will obviously have more than two customers (hopefully for them), but even in just this small example we can see one possible issue. How does the SP handle routing if the customer sites are using the same network numbers, or their network IP addressing schemes overlap in any way? The SP will use the following methods to handle overlapping customer address ranges: Route Distinguisher (RD) Virtual Routing and Forwarding Table (VRF) Each customer will be assigned a unique RD. The RD itself is a 64-bit prefix that is attached to the IP address, resulting in a vpnv4 prefix. Using these vpnv4 addresses necessitates the use of Multi-Protocol BGP (MPBGP). In turn, each MPLS VPN will have its own routing table, the Virtual Routing and Forwarding Table (VRF). This ensures that any particular

VPN site will have access to only the routes in that VPN's VRF. BGP routes carry attributes, which indicate certain characteristics of a given BGP route. One such attribute is the route target (RT), assigned to vpnv4 BGP routes when a site is using multiple VPNs. Defined by RFC 4360, "BGP Extended Communities Attribute", the RT attribute indicates the VPN membership of the route. MPLS VPN Protocols The CE will not be configured for MPLS. Rather, it will be configured with an IGP to allow the CE to send routes to the PE. The Provider network will run BGP, the only protocol capable of handling the sheer number of routes that it will have to handle.

Hot Spots And Gotchas Routing protocols run on the control plane, and the IP routing table is found on the control plane as well. The label exchange protocols LDP and TDP run on the control plane as well. The Label Information Base is where an IP prefix is assigned a locally significant label, and the LIB is found on the control plane. The data plane handles the actual forwarding of IP packets via the Forwarding Information Base (FIB) and labeled packets via the Label Forwarding Information Base (LFIB).

If an unlabeled packet is to be switched according to the FIB contents ("CEF switching"), and there is no entry in the FIB, the packet is dropped. An Edge LSR will insert a label into a packet when it's entering the MPLS domain, and by default will "pop" the label from the packet as it leaves the MPLS domain. When the Edge LSR inserts a label, this is label imposition. When the Edge LSR removes a label, this is label disposition. Edge LSRs will typically have some interfaces configured to run MPLS, and others not so configured. This is in contrast to a Core LSR or just plain "LSR", which will have all its interfaces enabled for MPLS. Edge LSRs are also called Provider Edge (PE) routers when MPLS VPNs are in use. Edge LSRs can forward packets based on label or IP destination address, where LSRs will forward them based on the label. LSRs are also called Provider (P) routers when MPLS VPNs are in use. LSRs do keep routing tables and FIBs, but they perform label lookups rather than routing table lookups. However, for MPLS to function correctly, IP convergence must occur before MPLS can converge. The four fields in a 32-bit MPLS label: Label, 20 bits TTL , 8 bits Experimental, 3 bits Bottom-Of-Stack, 1 bit An MPLS Forwarding Equivalence Class (FEC) is a set of packets that have the same next-hop IP address AND that have the same level of importance. The three label exchange protocols: LDP, TDP, and RSVP. RSVP is used when MPLS Traffic Engineering (TE) is in effect. TDP is just about obsolete, but if you have a downstream Cisco router that you have no access to, you may choose to run both LDP and TDP on the interface facing that router. There's no reason to consider that if the downstream router is non-Cisco, since TDP is Cisco-proprietary. To enable MPLS, you must first enable CEF switching with the global ip cef command. With MPLS VPNs, the service provider's network consists of Provider

Edge (PE) and Provider (P) routers. The customer network consists of Customer Edge (CE) and Customer (C) routers. The Provider Edge attaches a special VPN label to a packet that will be traveling across the MPLS VPN. The default ethernet MTU of 1500 must be increased when MPLS is enabled on that interface: For "Pure" MPLS with no VPN or TE - 1504 will do. For MPLS VPNs, the mtu should be set to 1508. When both VPNs and TE are in place, set the mtu to 1512. As we saw in the lab, when you run mpls ip on an interface, LDP is enabled by default. You can hardcode the interface to run LDP if you so choose, and you can run TDP and LDP on the interface simultaneously. MPLS labels are typically mapped to IP destination prefixes, but can also be mapped to QoS values, an L2 circuit value, and CoS values. The Penultimate Hop Popping feature allows an LSR to pop the remaining label and not replace it with another one before sending it to the egress Edge LSR. This does make the overall process more efficient, since the Edge LSR will have to perform two lookups if PHP is not in effect (one label lookup, one routing table lookup). Cisco's website mentions several advantages to using MPLS VPNs, including: Ease of use for customers - no VPN client necessary High level of scalability Connectionless service - no qualifying action necessary to create connection CoS Support High level of security The Service Provider has two methods of keeping customer private address ranges from overlapping: Route Distinguisher (RD) Virtual Routing and Forwarding Table (VRF) We'll finish with some port numbers! LDP uses UDP port 646; TDP uses TCP port 711. Make sure your network's ACLs allow these ports as needed.

Copyright 2008 The Bryant Advantage. All Rights Reserved.