Okay, into the breech, these next three topics are where we really veer from the R&S Path.
SP Lab Blueprint: Label distribution, LDP/ TDP, Label filtering, Label merging, Multipath, MPLS COS, MPLS Netflow, MPLS over ATM, MPLS Traffic Engineering
- Data can be transferred over any combination of Layer 2 technologies
- Support is offered for all Layer 3 protocols
- Scaling is possible well beyond anything offered in today’s networks.
Specifically, MPLS can efficiently enable the delivery of IP services over an ATM switched network. It supports the creation of different routes between a source and a destination on a purely router-based Internet backbone. Service providers who use MPLS can save money and increase revenue and productivity. Remember that Label switching on a router requires that Cisco Express Forwarding (CEF) be enabled on that router.
Explicit routing capabilities (also called constraint-based routing or traffic engineering)—Explicit routing employs “constraint-based routing,” in which the path for a traffic flow is the shortest path that meets the resource requirements (constraints) of the traffic flow. In MPLS traffic engineering, factors such as bandwidth requirements, media requirements, and the priority of one traffic flow versus another can be taken into account.
Support for IP routing on ATM switches (also called IP and ATM integration)—MPLS enables an ATM switch to perform virtually all of the functions of an IP router. This capability of an ATM switch stems from the fact that the MPLS forwarding paradigm (namely, label swapping) is exactly the same as the forwarding paradigm provided by ATM switch hardware.
Label Switching Function:
In the most common case, the only relevant field in the header is the destination address field, but in some cases other header fields might also be relevant. As a result, the header analysis must be done independently at each router through which the packet passes. A complicated table lookup must also be done at each router.
In label switching, the analysis of the Layer 3 header is done only once. The Layer 3 header is then mapped into a fixed length, unstructured value called a label.
Many different headers can map to the same label, as long as those headers always result in the same choice of next hop. In effect, a label represents a forwarding equivalence class—that is, a set of packets that, however different they may be, are indistinguishable by the forwarding function.
Once a label is assigned, a short label header is added at the front of the Layer 3 packet. This header is carried across the network as part of the packet. At subsequent hops through each MPLS router in the network, labels are swapped and forwarding decisions are made by means of MPLS forwarding table lookup for the label carried in the packet header. Hence, the packet header need not be re-evaluated during packet transit through the network. Because the label is of fixed length and unstructured, the MPLS forwarding table lookup process is both straightforward and fast.
Label Bindings Distribution:
TDP—Used to support MPLS forwarding along normally routed paths
Resource Reservation Protocol (RSVP)—Used to support MPLS traffic engineering
Border Gateway Protocol (BGP)—Used to support MPLS VPNs
When a labelled packet is being sent from LSR A to the neighboring LSR B, the label value carried by the IP packet is the label value that LSR B assigned to represent the forwarding equivalence class of the packet. Thus, the label value changes as the IP packet traverses the network.
This is the setup mechanism of an MPLS network:
1. Routing tables of the different LSRs are computed with an Interior Gateway Protocol (IGP). A link-state protocol, such as Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (IS-IS), is required if you plan to deploy MPLS TE.
2. A label distribution protocol (LDP) advertises the bindings between routes and labels. These bindings are checked against the routing table. If the route (prefix/mask and next hop) learned from the LDP matches the route learned from IGP in the routing table, an entry is created in the label that forwards information bases (LFIB) on the LSR.
Note regarding LDP\TDP – TDP (Tag Distribution Protocol) & LDP (Label Distribution Protocol), Cisco TDP and LDP (MPLS Label Distribution Protocol) are nearly identical in function, but use incompatible message formats and some different procedures. Cisco is changing from TDP to a fully compliant LDP. Other comparisons include ->
Hello Port UDP 646 UDP 711
Adjacency Port TCP 646 TCP 711
Proprietary No Cisco
The LSR uses this forwarding mechanism:
1. Once an edge LSR receives an unlabelled packet, the Cisco Express Forwarding table is checked and a label is imposed on the packet if needed. This LSR is called the ingress LSR.
2. Upon the arrival of a labelled packet at the inbound interface of a core LSR, the LFIB provides the outbound interface and the new label that is associated with the outbound packet.
3. The router before the last LSR (the penultimate hop) pops the label and transmits the packet without the label. The last hop is called the egress LSR.
1. Set up your network as usual. MPLS needs a standard IP connection in order to establish forwarding bases.
2. Ensure that the routing protocol (OSPF or IS-IS) works correctly. These commands are italicized in the configurations in the next section.
3. Enable ip cef, for better performances use ip cef distributed when available, in the general configuration mode. This is shown in bold in the configurations in the next section.
4. Enable mpls ip, or tag-switching ip on older Cisco IOS software releases, in the general configuration mode and in each interface, as shown in bold in the configurations in the next section. Even when the mpls ip command is used, the show running output can still show the command as tag-switching ip in some Cisco IOS software releases.
Note: The LSRs must have (up) Loopback interfaces with an address mask of 32 bits and these interfaces must be reachable with the global IP routing table.
mpls label protocol ldp
Configure MPLS on R1’s ATM connection
interface ATM3/0.1 mpls
mpls label protocol tdp
Label Distribution, configure MPLS on R3
mpls label protocol ldp
sh mpls fowarding-table – Used to check the MPLS forwarding table, which is the label switching equivalent of the IP routing table for standard IP routing. It contains inbound and outbound labels and descriptions of the packets.
sh mpls forwarding-table detail – Used to see MPLS forwarding table details
sh mpls ldp bindings – Used to see the label bindings associated with a particular destination. Both the local as well as the remote bindings can be seen
sh mpls interfaces
sh ip cef detail – Used to check that Cisco Express Forwarding works properly and that tags are swapped correctly
debug mpls events
debug mpls ldp bindings
Label Filtering – Basically this is where you will be told stuff like not to include certain networks to inject labels into other networks for security or some such reason. You can refer to my previous post on filtering routes in the blog but for example –Stop R5 receiving MPLS from other devices on it’s E0 network segment except from R6 which has the 10.1.6.6 & 10.1.36.6 addresses.
ip access-group STOP_LDP in
mpls ldp discovery transport-address 10.1.5.5
ip access-list extended STOP_LDP
permit udp host 10.1.36.6 eq 646 host 188.8.131.52 eq 646
permit tcp host 10.1.6.6 eq 646 host 10.1.5.5
permit tcp host 10.1.6.6 host 10.1.5.5 eq 646
deny udp any any eq 646
deny tcp any any eq 646
deny tcp any eq 646 any
permit ip any any
MPLS CoS functionality enables network administrators to provide differentiated services across an MPLS network. Network administrators can satisfy a wide range of networking requirements by specifying the class of service applicable to each transmitted IP packet. Different classes of service can be established for IP packets by setting the IP precedence bit in the header of each packet. MPLS CoS supports the following differentiated services in an MPLS network:
Packet classification – CoS Function – Committed access rate (CAR). Packets are classified at the edge of the network before labels are assigned. CAR uses the type of service (ToS) bits in the IP header to classify packets according to input and output transmission rates. CAR is often configured on interfaces at the edge of a network in order to control traffic flowing into or out of the network. You can use CAR classification commands to classify or reclassify a packet
Congestion avoidance – Weighted random early detection (WRED) – Packet classes are differentiated based on drop probability. WRED monitors network traffic to anticipate and prevent congestion at common network and internetwork bottlenecks. WRED can selectively discard lower priority traffic when an interface becomes congested; WRED can also provide differentiated performance characteristics for different classes of service.
You realize the following benefits when you use MPLS CoS in a backbone consisting of IP routers running MPLS:
Efficient resource allocation—WFQ is used to allocate bandwidth on a per-class and per-link basis, thereby guaranteeing a percentage of link bandwidth for network traffic.
Packet differentiation—When IP packets traverse an MPLS network, packets are differentiated by mapping the IP precedence bits of the IP packets to the MPLS CoS bits in the MPLS EXP field. This mapping of bits enables the service provider to maintain end-to-end network guarantees and meet the provisions of customer service level agreements (SLAs).
Future service enhancements—MPLS CoS provides building blocks for future service enhancements (such as virtual leased lines) by meeting bandwidth requirements.
ip address 10.10.10.10 255.255.255.255
ip address 184.108.40.206 255.0.0.0
rate-limit input access-group 101 496000 32000 64000 conform-action set-prec-transmit 4
exceed-action set-prec-transmit 0 <- Specifies the action to take on packets during label imposition!
ip address 220.127.116.11 255.0.0.0
mpls label protocol ldp
random-detect <- Configures the interface to use WRED/DWREDclock source internal
router ospf 100
network 10.0.0.0 0.255.255.255 area 100
network 18.104.22.168 0.255.255.255 area 100
network 22.214.171.124 0.255.255.255 area 100
access-list 101 permit ip host 126.96.36.199 any
show interfaces e1/3 rate-limit
Previous to the MPLS Egress NetFlow Accounting feature, you captured NetFlow data only for flows that arrived on the packet in IP format. When an edge router performed MPLS label imposition (received an IP packet and sent it as an MPLS packet), NetFlow data was captured when the packet entered the network. Inside the network, the packet was switched based only on MPLS information, and thus NetFlow information was not captured until after the last label was removed.
One common application of the MPLS egress NetFlow accounting feature allows you to capture the MPLS VPN IP flows that are travelling from one site of a VPN to another site of the same VPN through the service provider backbone.
Previous to the MPLS Egress NetFlow Accounting feature, you captured flows only for IP packets on the ingress interface of a router. You could not capture flows for MPLS encapsulated frames, which were switched through CEF from the input port. Therefore, in an MPLS VPN environment you captured flow information as packets were received from a CE router and forwarded to the backbone. However, you could not capture flow information as packets were sent to a CE router because those packets were received as MPLS frames.
The MPLS egress NetFlow accounting feature lets you capture the flows on the outgoing interfaces.
Benefits to MPLS Egress NetFlow Accounting are as follows:
• Enhanced network monitoring for complete billing solution—You can now capture flows on the egress and ingress router interfaces to provide complete end-to-end usage information on network traffic. The accounting server uses the collected data for various levels of aggregation for accounting reports and API accounting information, thus providing a complete billing solution.
• More accurate accounting statistics—NetFlow data statistics now account for all the packets that are dropped in the core of the service provider network, thus providing more accurate traffic statistics and patterns.
MPLS traffic engineering automatically establishes and maintains LSPs across the backbone by using RSVP. The path that an LSP uses is determined by the LSP resource requirements and network resources, such as bandwidth.
Available resources are flooded by means of extensions to a link-state-based Interior Gateway Protocol (IGP).
Traffic engineering tunnels are calculated at the LSP head based on a fit between required and available resources (constraint-based routing). The IGP automatically routes the traffic onto these LSPs. Typically, a packet crossing the MPLS traffic engineering backbone travels on a single LSP that connects the ingress point to the egress point.
MPLS traffic engineering is built on the following Cisco IOS mechanisms:
- IP tunnel interfaces—From a Layer 2 standpoint, an MPLS tunnel interface represents the head of an LSP. It is configured with a set of resource requirements, such as bandwidth and media requirements, and priority.
- From a Layer 3 standpoint, an LSP tunnel interface is the head-end of a unidirectional virtual link to the tunnel destination.
- MPLS traffic engineering path calculation module—This calculation module operates at the LSP head. The module determines a path to use for an LSP. The path calculation uses a link-state database containing flooded topology and resource information.
- RSVP with traffic engineering extensions—RSVP operates at each LSP hop and is used to signal and maintain LSPs based on the calculated path.
- MPLS traffic engineering link management module—This module operates at each LSP hop, does link call admission on the RSVP signalling messages, and does bookkeeping of topology and resource information to be flooded.
- Link-state IGP (Intermediate System-to-Intermediate System (IS-IS) or OSPF—each with traffic engineering extensions)—These IGPs are used to globally flood topology and resource information from the link management module.
- Enhancements to the SPF calculation used by the link-state IGP (IS-IS or OSPF)—The IGP automatically routes traffic onto the appropriate LSP tunnel based on tunnel destination. Static routes can also be used to direct traffic onto LSP tunnels.
- Label switching forwarding—This forwarding mechanism provides routers with a Layer 2-like ability to direct traffic across multiple hops of the LSP established by RSVP signalling