MPLS - TE - Implementation On Cisco IOS

Overview
The MPLS TE Implementation on Cisco IOS module presents the configuration steps needed in MPLS TE implementation. The Cisco IOS commands are explained along with monitoring and troubleshooting guidelines.
Objectives
Upon completing this module, you will be able to:
n n n n n
Explain the implementation details of MPLS-TE List the commands needed in MPLS-TE implementation Configure traffic engineering features in Cisco IOS Deploy advanced MPLS Traffic Engineering features Monitor and troubleshoot MPLS-TE
Configuring MPLS Traffic Engineering on Cisco IOS

Objectives
Upon completing this lesson, you will be able to:
n n n n n
Enable device-level and interface-level support for MPLS Traffic Engineering Configure MPLS TE support in IS-IS or OSPF Create a traffic trunk by defining an MPLS TE tunnel Configure attributes of a traffic trunk Deploy an MPLS traffic trunk through the autoroute mechanism
MPLS TE Implementation on Cisco IOS
Copyright 2001, Cisco Systems, Inc.
Enabling Device-Level MPLS TE Support

router(config)#
ip ip cef cef
Enable IP cef switching

router(config)#
mpls mpls traffic-eng traffic-eng tunnels tunnels
Enable the MPLS traffic engineering tunnel feature on a device
2001, Cisco Systems, Inc.
MPLS TE Implementation on Cisco IOS-5
ip cef
To enable Cisco Express Forwarding (CEF) on the route processor card, use the ip cef command in global configuration mode. ip cef [distributed] Syntax Description distributed (Optional) Enables distributed CEF (dCEF) operation. Distributes CEF information to line cards. Line cards perform express forwarding.
Usage Guidelines This command is not available on the Cisco 12000 series GSR because that router series operates only in distributed CEF mode. CEF is an advanced Layer 3 IP switching technology. CEF optimizes network performance and scalability for networks with dynamic, topologically dispersed traffic patterns, such as those associated with Web-based applications and interactive sessions.
mpls traffic-eng tunnels (configuration)

To enable MPLS traffic engineering tunnel signaling on a device, use the mpls traffic-eng tunnels command in global configuration mode. mpls traffic-eng tunnels
Usage Guidelines Enables the MPLS traffic engineering feature on a device. To use the feature, MPLS traffic engineering must also be enabled on the desired interfaces.
Enabling MPLS TE on an Interface

router(config-if)#
mpls mpls ip ip
Enable the MPLS on an interface

router(config-if)#
mpls mpls traffic-eng traffic-eng tunnels tunnels
Enable the MPLS traffic engineering tunnel feature on an interface

router(config-if)#
ip ip rsvp rsvp bandwidth bandwidth [ [total-flow-kbps total-flow-kbps] ] [ [single-flow-kbps single-flow-kbps] ]
Enable RSVP for IP on an interface and specify amount of bandwidth to be reserved

2001, Cisco Systems, Inc. MPLS TE Implementation on Cisco IOS-6
mpls ip
To enable MPLS forwarding of IPv4 packets along normally routed paths for a particular interface, use the mpls ip command in interface configuration mode. mpls ip Usage Guidelines MPLS forwarding of IPv4 packets along normally routed paths is sometimes called dynamic label switching. Dynamic label switching has been enabled for the platform when this command is issued on an interface, and label distribution begins with the periodic transmission of neighbor discovery Hello messages. When the outgoing label for a destination routed out the interface is known, packets for the destination are labeled with that outgoing label and forwarded out the interface.
mpls traffic-eng tunnels (interface)

To enable MPLS traffic engineering tunnel signaling on an interface, assuming it is enabled for the device, use the mpls traffic-eng tunnels command in interface configuration mode. mpls traffic-eng tunnels Usage Guidelines Enables the MPLS traffic engineering feature on the interface. To use the feature, MPLS traffic engineering must also be enabled on the device globally. An enabled interface has its resource information flooded into the appropriate IGP link state database, and accepts traffic-engineering tunnel signaling requests.
Copyright 2001, Cisco Systems, Inc. MPLS TE Implementation on Cisco IOS 5
ip rsvp bandwidth
To enable Resource Reservation Protocol (RSVP) for IP on an interface, use the ip rsvp bandwidth interface configuration command. ip rsvp bandwidth [interface-kbps [single-flow-kbps]] Syntax Description interface-kbps (Optional) Maximum amount of bandwidth, in kbps, that may be allocated by RSVP flows. The range is from 1 to 10,000,000. (Optional) Maximum amount of bandwidth, in kbps, that may be allocated to a single flow. The range is from 1 to 10,000,000.
single-flow-kbps
Usage Guidelines RSVP is disabled by default to allow backward compatibility with systems that do not implement RSVP. Weighted Random Early Detection (WRED) or fair queuing must be enabled first. RSVP cannot be configured with VIP-Distributed Cisco Express Forwarding (dCEF).
Enabling MPLS TE on an Interface (Cont.)

router(config-if)#
mpls mpls traffic-eng traffic-eng attribute-flags attribute-flags attributes attributes
Assign attributes that will be compared to a tunnel's affinity bits during selection of a path
router(config-if)#
mpls mpls traffic-eng traffic-eng flooding flooding thresholds thresholds { { down down | | up up } } percent percent [ [ percent percent ...] ...]
Set a link's reserved bandwidth thresholds on a interface

router(config-if)#
mpls mpls traffic-eng traffic-eng link-management link-management timers timers periodicperiodicflooding flooding interval interval
Set the length of the interval for periodic flooding

mpls traffic-eng attribute-flags

To set the user-specified attribute-flags for the interface, use the mpls traffic-eng attribute-flags command in interface configuration mode. The interface is flooded globally so that it can be used as a tunnel head-end path selection criterion. mpls traffic-eng attribute-flags 0x0-0xFFFFFFFF Syntax Description 0x0-0xFFFFFFF Usage Guidelines The purpose of this command is to assign attributes to a link in order to cause tunnels with matching attributes (as represented by their affinity bits) to prefer this link to others that do not match. Represents 32 bits. This mask is compared with a tunnel's affinity bits during dynamic path selection.
mpls traffic-eng flooding thresholds

To set the reserved bandwidth thresholds of a link, use the mpls traffic-eng flooding thresholds command in interface configuration mode. If a bandwidth threshold is crossed, the bandwidth information for the link is immediately flooded throughout the network. mpls traffic-eng flooding thresholds {down | up} percent [percent...]
Syntax Description down up percent [percent] Defaults The default for down is 100, 99, 98, 97, 96, 95, 90, 85, 80, 75, 60, 45, 30, 15. The default for up is 15, 30, 45, 60, 75, 80, 85, 90, 95, 97, 98, 99, 100. Usage Guidelines When a threshold is crossed, MPLS traffic engineering link management advertises updated link information. Similarly, if no thresholds are crossed, changes may be flooded periodically unless periodic flooding has been disabled. Sets the thresholds for decreased resource availability. The range is from 0 to 99 percent. Sets the thresholds for increased resource availability. The range is from 1 to 100 percent. Specifies the bandwidth threshold level.
mpls traffic-eng link timers periodic-flooding

To set the length of the interval used for periodic flooding, use the mpls trafficeng link timers periodic-flooding command in global configuration mode. mpls traffic-eng link timers periodic-flooding interval Syntax Description interval Length of interval used for periodic flooding (in seconds). The range is from 0 to 3600. If you set this value to 0, you turn off periodic flooding. If you set this value anywhere in the range from 1 to 29, it is treated as 3 (default is 3 minutes). Usage Guidelines Use this command to set the length of the interval used for periodic flooding to advertise link state information changes that do not trigger immediate action (for example, a change to the amount of bandwidth allocated that does not cross a threshold).
Enabling MPLS TE Support in IS-IS

router(config-router)#
mpls mpls traffic-eng traffic-eng {level-1 {level-1 | | level-2} level-2}
Turn on MPLS traffic engineering for IS-IS level-1 or level-2

mpls mpls traffic-eng traffic-eng router-id router-id { {interface interface} }
Specify the interface to be associated with the traffic engineering router identifier (also end-point of a tunnel)
metric-style metric-style wide wide
Configure a router to generate and accept only new-style TLVs
mpls traffic-eng
To turn on flooding of MPLS traffic engineering link information into the indicated IS-IS level, use the mpls traffic-eng command in router configuration mode. mpls traffic-eng isis-level {level-1 | level-2} Syntax Description level-1 level-2 Usage Guidelines This command appears as part of the routing protocol tree and causes link resource information (for instance, bandwidth available) for appropriately configured links to be flooded in the IS-IS link state database. Flood MPLS traffic engineering link information into IS-IS level 1. Flood MPLS traffic engineering link information into IS-IS level 2.
mpls traffic-eng router-id

To specify the traffic engineering router identifier for the node that is to be the IP address associated with the given interface, use the mpls traffic-eng router-id command in router configuration mode. mpls traffic-eng router-id interface Syntax Description interface The MPLS TE router identifier is taken from the IP address of the supplied interface. This MPLS-TE router identifier should be
MPLS TE Implementation on Cisco IOS 9
configured as the tunnel destination for tunnels originating at other routers and terminating at this router. This interface should be a stable interface that will not go up and down, such as a loopback interface. Usage Guidelines This router identifier acts as a stable IP address for the traffic engineering configuration. This stable IP address is flooded to all nodes. For all traffic engineering tunnels originating at other nodes and ending at this node, the tunnel destination must be set to the destination node's traffic engineering router identifier, because that identifier is the address that the traffic engineering topology database at the tunnel head uses for its path calculation.
metric-style wide
To configure a router to generate and accept only new-style TLVs (TLV stands for type, length, and value object), use the metric-style wide command in router configuration mode. metric-style wide [transition] {level-1 | level-2 | level-1-2} Syntax Description transition level-1 level-2 level-1-2 Usage Guidelines If you enter the metric-wide style command, a router generates and accepts only new-style TLVs. Therefore, the router uses less memory and other resources rather than generating both old-style and new-style TLVs. This style is appropriate for enabling MPLS traffic engineering across an entire network.
Note This discussion of metric-styles and transition strategies is oriented towards traffic engineering deployment. Other commands and models may be appropriate if the new-style TLVs are desired for other reasons. For example, a network may require wider metrics, but may not use traffic engineering.
(Optional) Instructs the router to accept both old and new style TLVs. Enables this command on routing level 1. Enables this command on routing level 2. Enables this command on routing levels 1 and 2.
10
Enabling MPLS TE Support in OSPF

mpls mpls traffic-eng traffic-eng area area area-num area-num
Turn on OSPF traffic engineering for the respective area

mpls mpls traffic-eng traffic-eng router-id router-id { {interface interface} }
Specify the interface to be associated with the traffic engineering router identifier (also end-point of a tunnel)
mpls traffic-eng area

To turn on MPLS traffic engineering for the indicated OSPF area on which MPLS-TE is enabled, use the mpls traffic-eng area command in router configuration mode. mpls traffic-eng area 1-n Syntax Description 1-n Usage Guidelines This command affects the operation of MPLS traffic engineering only if MPLS traffic engineering is enabled for that routing protocol instance. Currently, only a single area may be enabled for traffic engineering. The OSPF area on which MPLS-TE is enabled.
mpls traffic-eng router-id

To specify the traffic engineering router identifier for the node that is to be the IP address associated with the given interface, use the mpls traffic-eng router-id command in router configuration mode. mpls traffic-eng router-id interface Syntax Description interface The MPLS TE router identifier is taken from the IP address of the supplied interface. This MPLS-TE router identifier should be configured as the tunnel destination for tunnels originating at other routers and terminating at this router. This interface should
be a stable interface that will not go up and down, such as a loopback interface. Usage Guidelines This router identifier acts as a stable IP address for the traffic engineering configuration. This stable IP address is flooded to all nodes. For all traffic engineering tunnels originating at other nodes and ending at this node, the tunnel destination must be set to the destination node's traffic engineering router identifier, because that identifier is the address that the traffic engineering topology database at the tunnel head uses for its path calculation.
12
Creating and Configuring a Traffic Trunk

router(config)#
interface interface tunnel tunnel number number
Configures a tunnel interface

router(config-if)#
tunnel tunnel destination destination ip-address ip-address
Specifies the destination for the tunnel

router(config-if)#
tunnel tunnel mode mode mpls mpls traffic-eng traffic-eng
Sets the tunnel encapsulation mode to MPLS traffic engineering
interface tunnel
Tunnel interface is used to declare a TSP tunnel interface. The tunnel interface number is in the range of 0 to 2147483647.
tunnel source
To set a tunnel interface's source address, use the tunnel source interface configuring command. To remove the source address, use the no form of the command. tunnel source ip address | interface-type interface-nur Syntax Description ip address IP address to use as the source address for packets in the tunnel. interface-type All types. interface-num Specifies the port, connector, or interface card number. The numbers are assigned at the factory at the time of installation or when added to a system, and can be displayed with the show interfaces command. Usage Guidelines Two tunnels can not use the same encapsulation mode with exactly the same source and destination address. The solution is to create multiple loopback interfaces and source tunnels off each loopback interface. Refer to Cisco IOS
AppleTalk and Novell IPX Configuration Guide for more information on AppleTalk Cayman tunneling.
tunnel destination
To specify the destination for a tunnel interface, use the tunnel destination interface configuration command. tunnel destination {hostname | ip-address} Syntax Description hostname ip-address Usage Guidelines Two tunnels can not use the same encapsulation mode with exactly the same source and destination address. The solution is to create multiple loopback interfaces and source tunnels off each loopback interface. Refer to Cisco IOS AppleTalk and Novell IPX Configuration Guide for more information on AppleTalk Cayman tunneling. Name of the host destination. IP address of the host destination expressed in decimal in fourpart, dotted notation.
tunnel mode mpls traffic-eng

To set the mode of a tunnel to MPLS for traffic engineering, use the tunnel mode mpls traffic-eng command in interface configuration mode. tunnel mode mpls traffic-eng Usage Guidelines This command specifies that the tunnel interface is for an MPLS traffic engineering tunnel and enables the various tunnel MPLS configuration options.
14
Configuring a Traffic Trunk

router(config-if)#
tunnel tunnel mpls mpls traffic-eng traffic-eng bandwidth bandwidth bandwidth bandwidth
Configures the requested bandwidth for the MPLS traffic engineering tunnel
router(config-if)#
tunnel tunnel mpls mpls traffic-eng traffic-eng priority priority setup-priority setup-priority [ [ holdholdpriority priority ] ]
To configure the setup and reservation priority for an MPLS traffic engineering tunnel
router(config-if)#
tunnel tunnel mpls mpls traffic-eng traffic-eng affinity affinity properties properties [ [ mask mask mask mask value value ] ]
To configure an affinity (the properties the tunnel requires in its links) for an MPLS traffic engineering tunnel
tunnel mpls traffic-eng bandwidth

To configure bandwidth required for an MPLS traffic engineering tunnel, use the tunnel mpls traffic-eng bandwidth command in configuration mode. tunnel mpls traffic-eng bandwidth bandwidth Syntax Description bandwidth The bandwidth required for an MPLS traffic engineering tunnel. Bandwidth is specified in kilobits per seconds.
tunnel mpls traffic-eng priority

To configure setup and reservation priority for a tunnel, use the tunnel mpls traffic-eng priority command in interface configuration mode. tunnel mpls traffic-eng priority setup-priority [hold-priority] Syntax Description setup-priority The priority used when signaling an LSP for this tunnel to determine what existing tunnels are eligible for preemption. The range is from 0 to 7, where a lower numeric value indicates a higher priority. Therefore, an LSP with a setup priority of 0 can preempt any LSP with a non-0 priority.
hold-priority
(Optional) The priority associated with an LSP for this tunnel once established to figure out if it should be preempted by other LSPs that are being signaled. The range is from 0 to 7, where a lower numeric value indicates a higher priority.
Usage Guidelines The priority mechanism allows a hard-to-fit LSP to preempt easy-to-fit LSPs so that the easy-to fit LSPs can be reestablished once the hard-to-fit LSP has been placed. Typically, setup and hold priorities are equal. However, a separate hold priority allows a subset on tunnels to not preempt on setup, but to be preempted once established. Setup priority may not be better than (numerically smaller than) hold priority. Defaults setup-priority = 7 hold-priority = 7
tunnel mpls traffic-eng affinity

To configure tunnel affinity (the properties the tunnel requires in its links), use the tunnel mpls traffic-eng affinity command in interface configuration mode. tunnel mpls traffic-eng affinity properties [mask mask] Syntax Description properties mask mask Attribute values required for links carrying this tunnel (values of bits are either 0 or 1). Attribute values that should be checked. If a bit in the mask is 0, a link's attribute value or that bit is irrelevant. If a bit in the masks is 1, the link's attribute value and the tunnel's required affinity for that bit must match.
Defaults properties0X00000000 mask0X0000FFFF
16
Tunnel Configuration Commands (Cont.)

router(config-if)#
tunnel tunnel mpls mpls traffic-eng traffic-eng path-option path-option number number { {dynamic dynamic | | explicit explicit { {name name path-name path-name | | path-number}} path-number}} [ [lockdown lockdown] ] Configures the tunnel to use a named IP explicit path or a path dynamically calculated from the traffic engineering topology database
router(config)#
ip ip explicit-path explicit-path { { name name word word | | identifier identifier number number } } [ [ { {enable enable | | disable disable } } ] ] Enter the subcommand mode for IP explicit paths and create or modify the specified path
router(config-if)#
mpls mpls traffic-eng traffic-eng administrative-weight administrative-weight weight weight Override the Interior Gateway Protocol cost of the link
tunnel mpls traffic-eng path-option

To configure a path option, use the tunnel mpls traffic-eng path-option command in interface configuration mode. tunnel mpls traffic-eng path-option identifier path-number name path-name Syntax Description identifier path-number name path-name Usage Guidelines Multiple path setup options may be configured for a single tunnel. For example, you can configure several explicit paths and a dynamic option for one tunnel. Path setup prefers options with lower numbers to options with higher numbers, so option 1 is the most preferred option. Uses the IP explicit path with the indicated path number. Uses the IP explicit path with the indicated path name.
ip explicit-path
To enter the subcommand mode for IP explicit paths to create or modify the named path, use the ip explicit-path command in global configuration mode. An IP explicit path is a list of IP addresses, each representing a node or link in the explicit path. ip explicit-path {name WORD | identifier number} [{enable | disable}]
17
Syntax Description name WORD identifier number enable disable Specifies explicit path by name. Specifies explicit path by number. You can specify a number from 1 to 65535. Sets the state of the path to be enabled. Prevents the path from being used for routing while it is being configured.
mpls traffic-eng administrative-weight

To override the Internet Gateway Protocol's (IGP) administrative weight (cost) of the link, use the mpls traffic-eng administrative-weight command in interface configuration mode (default matches IGP cost). mpls traffic-eng administrative-weight weight Syntax Description weight Cost of the link.
18
Deploying Traffic Trunk with Autoroute

router(config-if)#
tunnel tunnel mpls mpls traffic-eng traffic-eng autoroute autoroute announce announce
Causes the IGP to use the tunnel in its enhanced SPF

router(config-if)#
tunnel tunnel mpls mpls traffic-eng traffic-eng autoroute autoroute metric metric { { absolute absolute | | relative relative } } value value
To specify the MPLS traffic engineering tunnel metric that the IGP enhanced SPF calculation uses
tunnel mpls traffic-eng autoroute announce

To instruct the IGP to use the tunnel in its SPF/next hop calculation (if the tunnel is up), use the tunnel mpls traffic-eng autoroute announce command in interface configuration mode. tunnel mpls traffic-eng autoroute announce Defaults The tunnel is not used by the IGP in its SPF/next hop calculation. Usage Guidelines Currently, the only way to cause traffic to be forwarded onto a tunnel is by enabling this feature, or for example, by configuring forwarding explicitly with an interface static route.
tunnel mpls traffic-eng autoroute metric

To specify the MPLS traffic engineering tunnel metric used by IGP autoroute, use the tunnel mpls traffic-eng autoroute metric command in interface configuration mode. tunnel mpls traffic-eng autoroute metric {absolute|relative} value Syntax Description metric absolute The MPLS traffic engineering tunnel metric. The MPLS traffic engineering tunnel metric mode absolute: a positive metric value can be supplied.
relative
The MPLS traffic engineering tunnel metric mode relative: a positive, negative, or zero value can be supplied.
Defaults The default is metric relative 0.
20
Summary
After completing this section, you should be able to perform the following tasks:
n n n n n
Enable device-level and interface-level support for MPLS Traffic Engineering Configure MPLS TE support in IS-IS or OSPF Create a traffic trunk by defining MPLS TE tunnel Configure attributes of a traffic trunk Deploy an MPLS traffic trunk through the autoroute mechanism
Lesson Review
1. How is the MPLS-TE support enabled? 2. What modifications are needed to the IS-IS and OSPF to support MPLS-TE? 3. How is the MPLS-TE tunnel configured?
21
Advanced MPLS Traffic Engineering Configuration

Objectives
n
Create explicit paths and create a hierarchy of explicit and dynamic paths for a traffic trunk Assign traffic to an MPLS traffic trunk with static routes Assign traffic to an MPLS traffic trunk with policy-based routing (PBR) Configure MPLS TE policies by changing link and trunk affinity bits Modify MPLS TE metrics to influence link selection Modify autoroute metrics to enable load sharing or primary/backup scenarios between routed and traffic-engineered traffic Deploy the auto-bandwidth feature of MPLS TE Deploy optimization and fast rerouting of MPLS TE traffic trunks
n n n n n
n n
22
Case StudyCompany Network Description

The Company is a Service Provider consisting of:
Core network Core routers in locations are heavily meshed Two permanent connections to the Internet Local or remote access networks Connected to core in a resilient way, allowing a remote access via Point-of-Presence Access networks BGP customers
The example in the figure is a classic ISP architecture based on three levels of hierarchy. The design should bring together some of the aspects of traffic engineering and routing design discussed in this chapter, namely:
n n
Routing protocol choice and interaction between different routing protocols Support for MPLS-TE tunnels
23
Case StudyIGP Design

IS-IS is used for routing inside and between Core and POPs: - A simple flat design using one IS-IS Level-2 backbone - Loopbacks are advertised with 32 bit network mask POP - Use a new flavor of IS-IS TLVs (wide metric)
ISP 1
Core
Core
eBGP
Core
POP
eBGP
IS-IS
Core
ISP 2
Core
Core
POP
eBGP
The network is based on a three-level hierarchy, consisting of:

n
Core network: highly meshed central sites with high bandwidth requirements between them. POP sites: a distribution layer of regional sites, connected back to the core over redundant links and providing access for remote sites. BGP peers: Upstream Internet providers and customer networks connected to the distribution sites via leased lines.
The core and regional networks are a complex mesh of routers, requiring efficient, scalable routing with fast convergence. A Link-State protocol is ideally suited to this situation. Therefore Integrated IS-IS is the choice. The proposed structure of the IS-IS protocol is as follows:
n
Simply enabling Integrated IS-IS on Cisco routers sets their operation as level-2 routers. All IP subnets would be visible individually to all routers on the IS-IS network from their level-2 advertisements. 'Wide metric' is used, which allows for greater granularity of path selection.
24
Case StudyBGP Design

All POP sites are fully meshed with iBGP: -Multi-Protocol Label Switching (MPLS) in the core, but not inside the POP
-Route reftectors are used at POP sites, to ease cofiguration of future access POP routers -Router reflectors are connected in a full mesh
iBGP RR
POP A1 POP A 1M 1M Core 2 2M 2M Core 3 1M 2M
MPLS
ISP 1
iBGP
RR
1M POP C Core 6 POP C1
Client
4M
ISP 2 RR
POP B1 POP B 1M
Core 1 2M 1M 2M Core 4 Core 5 2M
Customer AS
POP C1 is RR Client
Client
The most recent method uses MPLS as a transport mechanism in the core network. Packets are switched through the core of the network at layer-2, bypassing the traditional layer-3 routing process. The issue with the edge-only BGP peer design was that the routers in between the edges needed to have routes to process the packets. If these packets pass through these routers with MPLS tags, they no longer need IP routes to these destinations. In all cases, BGP relies on another protocol to resolve its next-hop address. IGP is required to do this, so IS-IS must contain routes to the edge routers and to their attached (public) subnets. To reduce the number of iBGP sessions required between POPs, Route-Reflectors are used. These tools allow the 'full-mesh' requirement of traditional iBGP operation to be relaxed.
25
Objective: Engineer the Traffic Across the Network

Traffic originating from POP A and POP B destined for POP C are classified into two trunks providing guaranteed bandwith of 250 Kbps. Red TT: from POP-A to POP-C Blue TT: from POP-B to POP-C The traffic between POP-A and POP-B is not subject to MPLS-TE.
RR
1M/20 Core 2
2M/10 Core 3 2M/10 1M/20
RR
POP A1
POP A 1M/20
2M/10
Client
4M/cost 5 Core 1 2M/10 POP B1 POP B 1M /20 2M/10 Core 6 2M/10
1M/20
POP C
POP C1
RR
1M/20
Client
Client
IS-IS Cost
Core 4
Core 5
This sample configuration shows how to implement traffic engineering (TE) on top of an existing Multiprotocol Label Switching (MPLS) network. Our example implements two TE tunnels of 250 Kbps, being either automatically set up by the ingress Label Switch Routers (POP-A, POP-B, POP-C routers) or manually configured with the explicit paths. TE is a generic name corresponding to the use of different technologies to optimize the utilization of a given backbone capacity and topology.
26
MPLS-TE Platform
Provide an underlying platform for MPLS-TE by configuring the extended IS-IS and RSVP for bandwidth assurance - of the bandwidth is reservable for traffic trunks.
#Sample configuration of Core router ip cef mpls ip Support for TE and RSVP Core Core mpls traffic-eng tunnels for TE int s 0/0 bandwidth 2000 mpls traffic-eng tunnels ip rsvp bandwidth 1500 500 ip router isis Bandwidth reservation for TE Total Core reservable bandwidth and Core largest single reservation
IS-IS+MPLS
POP
router isis passive-interface Loopback0 net 49.0001.0000.0001.0001.00 Name of router is-type level-2-only Core Core metric-style wide mpls traffic-eng router-id Loopback0 POP mpls traffic-eng level-2 Traffic engineering within respective area
MPLS TE uses an extension to existing protocols such as Resource Reservation Protocol (RSVP), IS-IS, and Open Shortest Path First (OSPF) to calculate and establish unidirectional tunnels that are set according to the network constraint. Traffic flows are mapped on the different tunnels depending on their destination. With Cisco, MPLS traffic engineering is built on the following IOS mechanisms:
n
A link-state IGP (such as IS-IS) with extensions for the global flooding of resource information, and extensions for the automatic routing of traffic onto LSP tunnels as appropriate. An MPLS traffic engineering path calculation module (Constraint-Based routing CBR), which determines the paths to use for LSP tunnels. Label-switched path (LSP) tunnels, which are signaled through RSVP. LSP tunnels represented as IOS tunnel interfaces are unidirectional. An MPLS traffic engineering link management module that does link admission and bookkeeping of the resource information to be flooded. Label switching forwarding, which provides routers with a Layer 2-like ability to direct traffic across multiple hops as directed by the resource-based routing algorithm.
The meaning of some relevant commands is as follows: Global configuration commands:

n n
ip cef: Enable standard CEF operation. mpls traffic-eng tunnels: Enables the MPLS traffic engineering tunnel feature on a device.
IS-IS configuration mode:

n n
mpls traffic-eng level 2: Turn on MPLS traffic engineering for IS-IS level 2. mpls traffic-eng router-id loopback0: Specify the traffic engineering router identifier for the node to be the IP address associated with interface loopback0. metric-style wide: Configure a router to generate and accept only new-style TLVs. mpls traffic-eng tunnels: Enable the MPLS traffic engineering tunnel feature on an interface. ip rsvp bandwidth [total-reservable-flow] [single-flow]: Enable RSVP for IP on an interface and specify the amount of bandwidth to be reserved.
Interface configuration mode

n
28
Creating Dynamic Path Options for a Traffic Trunk

Sample path setup: - Based on the default parameters and the assumption that the links are free, the best path for both would be the same as computed by IS-IS. - Therefore, the Label Switched Paths for both tunnels use the middle Core-1 and Core-6 routers.
1M/10 Core 2 POP POP A 1M/20 2M/10
2M/10 Core 3 2M/10 1M/10
1M/20 4M/cost 5 1M/20 Core 1 2M/10 POP POP B 1M /10 2M/10 Core 4 Core 5 Core 6 2M/10
POP C
POP
The case in the figure shows how the Constraint-based Routing (CBR) algorithm proposes a path between tunnel end-points that satisfies the initial requests at the head-end of the tunnel. Based on the assumption that all TE links are free, the traffic from POP-A to POP-C and POP-B to POP-C would be directed along the same least-cost path (Core-1 Core-6) as it is used by IS-IS for native IP routing. The reason is very simple; CBR is still a routing process taking into account the following two considerations:
n
The best route is the least-cost route with enough resources. CBR uses its own metric (Administrative Weight or TE cost) which is by default equal to the IGP
In case of a tie, the path with the highest minimum available bandwidth is selected, then with the smallest hop-count, finally a random one.
The result of a CBR is an explicit route, used by RSVP to reserve resources and establish LSP path.
29
Dynamic Path Configuration

#POP-A and POP-B configuration are identical interface Tunnel1 ip unnumbered Loopback0 tunnel source Loopback0 tunnel destination POP-C tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 250 tunnel mpls traffic-eng path-option 1 dynamic
Endpoint of Tunnel (pref. loopback) Tunnel establish and hold priority Bandwidth needed for Tunnel
#POP-C configuration interface Tunnel1 ip unnumbered Loopback0 tunnel source Loopback0 Path computation option tunnel destination POP-A tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 250 tunnel mpls traffic-eng path-option 1 dynamic interface Tunnel2 TTs are unidirectional, so the same ip unnumbered Loopback0 configuration should be applied in the tunnel source Loopback0 tunnel destination POP-B opposite direction tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 250 tunnel mpls traffic-eng path-option 1 dynamic
To set up a dynamic traffic engineering tunnel (assuming that the IGP platform has been prepared), follow these steps in the tunnel interface configuration mode:
n
ip unnumbered loopback0: Gives the tunnel interface an IP address. An MPLS traffic engineering tunnel interface should be unnumbered because it represents a unidirectional link. tunnel source: Specifies the source for a tunnel. The source of the tunnel must be the destination of the tunnel in the opposite direction, usually the local loopback address. tunnel destination: Specifies the destination for a tunnel. The destination of the tunnel must be the source of the tunnel in the opposite direction, usually a loopback address. tunnel mode mpls traffic-eng: Sets the tunnel encapsulation mode to MPLS traffic engineering. tunnel mpls traffic-eng priority: To configure the setup and reservation priority for an MPLS Traffic Engineering tunnel tunnel mpls traffic-eng bandwidth bandwidth: Configures the bandwidth for the MPLS traffic engineering tunnel. tunnel mpls traffic-eng path-option number dynamic: The LSP path is dynamically calculated.
30
Creating Explicit Path Options for a Traffic Trunk

The second option is to explicitly define the desired path as long as there are enough resources available along the path. Example: - The traffic is forwarded along the the upper path (Core-2 Core-3) for the red TT and along the lower path (Core-4 - Core-5) for the blue TT.
2M/10 Core 3 2M/10 1M/20
POP C
POP
The case in the figure shows how to avoid the first step in the Constraint-based Routing (CBR) algorithm, by manually setting the explicit path between tunnel end-points, which might derive from the least-cost path. The best route might not be the least-cost route with enough resources, but might be any sequence of nexthop routers configured at the head-end of the trunk. Such a route as proposed by the system administrator is then checked against the extended link-state database carrying information on currently available resources. If successful, CBR honors the route and RSVP is initiated to reserve some bandwidth and establish an LSP path, otherwise the tunnel stays down.
31
Explicit Path Configuration

#POP-A configuration interface Tunnel1 ip unnumbered Loopback0 tunnel destination POP-C tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 250 tunnel mpls traffic-eng path-option 1 explicit name Core2-3 ! ip explicit-path name Core2-3 enable next-address Core-2 next-address Core-3 next-address POP-C Explicit path represents the Explicit Route
Object, encoded as incoming IP addresses of the routers along the path.
To set up a static traffic engineering tunnel (assuming that the IGP platform has been prepared), use these additional steps: Tunnel interface configuration mode:
n
tunnel mpls traffic-eng path-option number explicit: Configures the tunnel to use a named IP explicit path from the traffic engineering topology database. ip explicit-path: An IP explicit path is a list of IP addresses, each representing a node or link (incoming IP address) in the explicit path.
Global configuration mode:

n
32
Assigning Traffic to Traffic Trunks with Static Routes

After RSVP allocates labels for the traffic trunk, the LSP path is ready for usage. Enabling forwarding over the CBR-LSP : - Static routing and policy routing make tunnels useful by simply borrowing the first label of the LSP path of the tunnel. - Other destinations are still routed to native IP next-hops.
#POP-A Configuration of static route ip route POP-C1 mask tunnel 1 Route to a next-hop (the loopback interface #POP-A Policy routing of the access router) for BGP customer C interface ethernet 0 routes. ip policy-map Tunnel1 ! Note: the tunnel itself does not show up in route-map Tunnel1 permit 10 the routing table. match ip address 100 set interface Tunnel1 access-list 100 permit any Customer-C-prefix mask Customer C
RR
POP A1 POP A
RR
POP C POP C1
eBGP with ISP1
iBGP
iBGP
iBGP
eBGP
When the LSP path is established for the trunk, the MPLS traffic can flow across it. However, the tunnel is not yet useable; it is not a GRE tunnel and does not show up in the routing table. For this reason the engineered tunnels can only be used for IP routing if the tunnel is explicitly specified for routing:
n n
Via static routes that point to the tunnel Via policy routing that sets a next-hop interface to the tunnel
33
Forwarding Traffic over Traffic Trunks Using Static Routing

1. IP Destination Customer C 4. Labeld packet follows the path as encoded by the LSP. The router before the last one removes the label (PHP)
RR
POP A1 POP A
5.IP forwarding toward the next-hop (POP-C1)
eBGP RR
MPLS
iBGP
Cust. C
POP C POP C1
iBGP
iBGP
2. Layer 3 lookup - C is a BGP route, next hop (NH) is POP-C1 3. When packet enters the MPLS network L3 finds the NH (POP-C1) reachable over Tunnel1 (label Imposition)
The figure illustrates how IP packets are propagated over a traffic tunnel across an MPLS domain: Step 1,2. POP-A1 forwards the IP packet as instructed by the routing table Step 3. POP-A labels a packet destined for network C by using the first label of Tunnel1 (POP-C1 is a next-hop of the customer C route, reachable via Tunnel1) Step 4. Intermediate routers swap labels (the one before the last pops the label) Step 5. POP-C forwards the packet towards POP-C1 Expanding the MPLS to the edge of the network, for example, enabling LDP on the link connecting POP-C and POP-C1 routers, creates a need for an additional label for the last hop in the network. In order to achieve this, the unicast LDP session is created across the tunnel advertising a label for the next-hop address (POP C1). This advertisement results in a stack of labels being imposed at POP A, one for the tunnel and another one for the next-hop.
34
Configuring Periodic and EventTriggered Optimization

A static tunnel is used to forward traffic and a dynamic backup tunnel provides a backup in case the selected one is down or refuses to honor the reservation. On link down event between Core-2 and Core-3, the LSP path for the red trunk, as directed by constraint-based routing, might use one of these two paths: - POP-A Core-1 Core-6 - POP C - POP-A Core-1 Core-4 - Core-5 Core-6 POP-C
2M/10 Core 3 2M/10 1M/35
POP C
POP
The LSP path is constantly monitored to maintain the network traffic trunk in a desired state. When the path is broken and the tunnel has been set up dynamically, the head-end router tries to find an alternative solution. This process is referred to as rerouting. Re-optimization occurs when a device examines tunnels with established LSPs, to see if better LSPs are available. If a better LSP seems to be available, the device attempts to signal the better LSP and, if successful, replaces the old and inferior LSP with the new and better LSP. This re-optimization might be triggered by a link-up event or might occur at configurable intervals (the default is one hour). Instability and oscillations can result if the re-optimization interval is set too small. However, the network will not react to unexpected shifts in traffic if the interval is too great. One hour is a reasonable compromise. This means that traffic is routed so that it sees the lightest possible loads on the links it traverses. Unfortunately the described technique itself does not bring any improvements for the trunk being established statically. In this case, the path is explicitly determined, which ties the head-end router to strictly follow the explicit path.
35
Configuring Optimization
router(config)#
mpls mpls traffic-eng traffic-eng reoptimize reoptimize events events { {link-up link-up} }
Trigger automatic reoptimization whenever an interface becomes operational

router(config)#
mpls mpls traffic-eng traffic-eng reoptimize reoptimize timers timers frequency frequency seconds seconds
Control the frequency with which tunnels with established label-switched paths (LSPs) are checked for better LSPs
mpls traffic-eng reoptimize events

To trigger automatic re-optimization whenever an interface becomes operational, use the mpls traffic-eng reoptimize events router configuration command. Use the no form of this command to disable this feature. mpls traffic-eng reoptimize events {link-up} no mpls traffic-eng reoptimize events {link-up} Syntax Description link-up Triggers automatic re-optimization whenever an interface becomes operational.
Defaults Event-based re-optimization is disabled. Command Modes Global configuration.
mpls traffic-eng reoptimize timers frequency

To control the frequency at which tunnels with established LSPs are checked for
36 MPLS TE Implementation on Cisco IOS Copyright 2001, Cisco Systems, Inc.
better LSPs, use the mpls traffic-eng reoptimize timers frequency command in global configuration mode. mpls traffic-eng reoptimize timers frequency seconds Syntax Description seconds Sets the frequency of re-optimization, in seconds. A value of 0 disables re-optimization.
Defaults 3600 seconds (1 hour), with a range of 0 to 604800 seconds (1 week). Command Modes Global configuration. Usage Guidelines A device where traffic engineering tunnels periodically examine tunnels with established LSPs to see if better LSPs are available. If a better LSP seems to be available, the device attempts to signal the better LSP and, if successful, replaces the old and inferior LSP with the new and better LSP.
37
Configuring Event-Triggered Optimization

#POP-A and POP-B configuration are identical mpls traffic-eng reoptimize events link-up mpls traffic-eng reoptimize timers frequency 300
The automatic LSP reoptimization is triggered for link change events and periodicaly every 5 min to check for better paths.
interface Tunnel1 ip unnumbered Loopback0 The relative preference of this option tunnel source Loopback0 lower path option numbers are tried before tunnel destination POP C higher path option numbers. tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 250 tunnel mpls traffic-eng path-option 1 explicit name Core2-3 tunnel mpls traffic-eng path-option 2 dynamic ! ip explicit-path name Core2-3 enable next-address Core-2 A second will be used in case the first path will fail next-address Core-3 Note: The second path is NOT pre-established. next-address POP-C
The case in the figure shows how traffic can be engineered across a path in the network and how a backup route for that traffic-engineered path can be established. The primary path is explicit with a manually specified RSVP Explicit Route Object. If this path suddenly cannot be followed, the MPLS TE engine uses the next path option, which in this case is a dynamic route. The drawback of this solution is the time needed to establish a backup traffic engineering route for the lost LSP path and the time needed to revert to a primary path once it becomes available again. Though the search for an alternate path is immediately triggered by the link down event, there is still down time while the alternate path is being built. The convergence back to the primary tunnel may be sped up by configuring the triggering of CB-LSP computation on any LSP change (link up event) or by decreasing the time of periodic LSP checks.
38
Path Selection Restrictions

Although at the moment TT are deployed only for POP to ISP communication, the picture of trunks is becomming too messy. Design improvmenets: E - The trunks to IPS-1 are in general POP preffered over ISP-2. - Prevent POP-A from being used under any circumstances as a transit point for the blue group of tunnels and vice versa.
POP A (ISP 1)
Core
Core
POP C
Core 1
POP B (ISP 2)
IS-IS
Core
Core
Core
POP D
In many cases, some links will need to be excluded from the Constraint-SPF computation. This exclusion can be implemented using the resource class affinity bits of the traffic trunk and resource class bits of the links over which the trunk should pass (following the computed LSP path). A 32-bit resource class affinity string accompanied by a respective resource class mask characterizes each traffic trunk. The zero bits in the mask exclude the respective link resource class bits from being checked. Each link is characterized by its resource class 32-bit string, which is set to 0 by default. The matching of the tunnel trunk resource class affinity string with the resource class string of the link is performed during the LSP path computation.
39
Configuring Affinity Bits on Links

#Links dedicated only to red trunks. int ser 0/0 mpls traffic-eng attribute-flags 0x00000001 int ser 0/1 mpls traffic-eng attribute-flags 0x00000001
POP A (ISP 1)
Core
Black links with attribute flag 0x00000003 allow reservation for Core both group of trunks.
POP C
Core 1
POP B (ISP 2)
IS-IS
Core
#Link dedicated only to blue trunks. int ser 0/0 Core Core mpls traffic-eng attribute-flags 0x00000002 int ser 0/1 D mpls POP traffic-eng attribute-flags 0x00000002
The figure shows a sample network with the trunk resource class affinity bits and link resource bits. The main goal is to force the CBR algorithm to use only links that are explicitly dedicated to certain trunks for its path computation. Since it is desirable to move all blue trunks away from POP-A interfaces and red trunks from POP-B interfaces, different link resource class bits are set: 0x00000001 for red interfaces and 0x00000002 for blue interfaces. Those link resource class attribute bits then become a part of the LSP advertisements allowing all participants to include this information when computing paths for TE tunnels.
40
Configuring Affinity Bits on Trunks

#POP-C configuration interface Tunnel1 description Red trunk ip unnumbered Loopback0 tunnel destination POP-A tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng affinity 0x00000001 mask 0x00000001 ......
Link attributes for Tunnel (mask 1 means it must match)
interface Tunnel2 description Blue trunk ip unnumbered Loopback0 tunnel destination POP-B tunnel mpls traffic-eng priority 2 2 tunnel mpls traffic-eng affinity 0x00000002 mask 0x00000002 ......
In the example for Tunnel 1, the trunk requires a match only on the last bit, whereas Tunnel 2 checks the setting of the second bit from the right hand side. With trunk resource class affinity bits and link resource class bits set, the Constraint-based path computation would consider only the paths where the match is found. Example: Tunnel1 (Red Trunk): affinity bits 0x00000001 mask 0x00000001 The attributes of the red links (POP A interfaces) match (attributes 0x00000001). The black links (Core interfaces) also match (attributes 0x00000011). The blue links (POP B interfaces) marked with the attribute 0x00000002 are being excluded from C-SPF computation as they do not match.
41
Selecting the Path with Administrative Weight

A server farm is attached to Core-7, therefore if possible, try to keep the trunks from Pops off the Core-1 Core-7 Core-6 link. Setup objective: - Assign an administrative weight to links towards Core-7 (link is still addmitted to CBR and RSVP when it is the only alternative path) - Reserve for traffic trunks
2M/10
POP A (ISP 1)
Core2 2M/10
Core3 2M/10
POP C
4M/5
4M/5
Core1
Core7
Core6
POP B (ISP 2)
If not necessary, exclude Core-1 Core-7 Core-6 from CBR.

Core Core
POP D
The Constrained-based path computation selects the path that the dynamic traffic trunk will take, based on the administrative weight (TE cost) of each individual link. This administrative weight is, by default, equal to the IGP link metric (cost). Increase the TE cost on the link if it is desirable to exclude a certain link from any path computation, while keeping the link available in the event that the link represents the only available path.
42
Configuring Administrative Weight

In the absence of a static path due to a failed POP-C Core-3 link, from POP-C perspective, the preffered path for a dynamic tunnel should go through Core-6, Core-3 and Core-2.
2M/10
POP A (ISP 1)
Core2 2M/10
Core3 2M/10
POP C
4M/5 Core1 Core7
4M/5 Core6
POP B (ISP 2) !Core-6 configuration on link trowards Core-7 int ser 0/0 Core bandwidth 4000 mpls traffic-eng administrative-weight 55 POP D ip rsvp bandwidth 2000 1000
Core
The assignment of higher cost only impacts the CSPF calculations.
In the example in the figure, the TE cost of the link between Core-1 and Core-7 is increased to 55, which makes links providing alternative paths more economical and more attractive for backup paths.
43
Improving the Convergence Times in MPLS-TE Networks

The search for an alternative path and its signaling takes too long and has a negative impact on packet forwarding. Solution with two pre-established tunnels to the the same destination: - One tunnel could be configured as backup to another tunnel - LSP for the secondary tunnel is pre-signaled and available if the first tunnel fails - Double reservation can be avoided with make before break mechanism
2M/10
POP A (ISP 1)
Core2 2M/10
Core3 2M/10
POP C
4M/5 Core1 Core7
4M/5 Core6
POP B (ISP 2)
Core
Core
Fast convergence does not seem like an obvious ideal. An option is to use the precomputed path only and establish the LSP path on-demand. However, if the network is too reactive to change, it can become unstable. In a simple case, a flapping link can result in head-end routers being constantly involved in Constraint-based computation. Since the time elapsed between the link failure detection and the new LSP path establishment can cause delays for critical traffic, there is a possibility of using alternative pre-established paths (backups). Therefore, there are two tunnels between the same endpoints at the same time.
n
The requirement is that pre-configured tunnels between the same endpoints must use diverse paths.
As soon as the primary tunnel fails, the traffic is transitioned to the backup tunnel. The traffic is returned back to the primary tunnel if the conditions provide for the re-establishment of traffic.
n
Having two pre-established paths is the simplest form of MPLS-TE path protection. Several preparation steps must be taken in order for effective switching between the tunnels including the routing to the proper tunnel.
44
Configuring Parallel Trunks

#POP-C configuration interface Tunnel1 ip unnumbered Loopback0 tunnel destination POP-A tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 250 tunnel mpls traffic-eng path-option 1 explicit name Core3-2
A lower priority is used and due to the double interface Tunnel2 ip unnumbered Loopback0 counting of reservations, one half of the initial tunnel destination POP-A bandwidth is requested by the backup tunnel. tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 2 2 tunnel mpls traffic-eng bandwidth 125 tunnel mpls traffic-eng path-option 1 dynamic ! ip explicit-path name Core3-2 enable Option: Assign the TT and link affinity bits to next-address Core-3 ensure the usage of the diverse path from next-address Core-2 the primary. next-address POP-A
#A pair of floating static routes for primary/backup selection ip route POP-A1 mask tunnel 1 10 ip route POP-A1 mask tunnel 2 11
The example shows two configured tunnels: Tunel1 (following the LSP path Core-3 - Core-2 - POP-A) and Tunnel2 (using a dynamic path). In the presence of two tunnels, static routing is deployed with two floating static routes pointing to the tunnels. As soon as the primary tunnel (Tunnel1) fails, the static route is gone and the traffic is transitioned to the secondary tunnel. The traffic is returned back to the primary tunnel if the conditions provide for the reestablishment of traffic. Spreading the load proportionally to the requested bandwidth (CEF mechanism) by load balancing, or having one group of static routes pointing to Tunnel 1 and another to Tunnel 2 are other options.
45
Autoroute Forwarding Engine

Autoroute refresher: - The tunnel metric is the IGP cost to the tunnel end-point, regardless of the actually taken path (CBR-LSP computation) - Tune the tunnel metric to prefer one tunnel over the other (Absolute - a positive metric value, Relative - a positive, negative or zero value to the IGP metric) - The tunnel metric must be equal or lower than the native IP path to replace existing next-hops - Traffic directed to prefixes beyond the tunnel tail-end is pushed onto the tunnel (if MPLS is tunneled into the TE tunnel, a stack of labels is used)
2M/10
POP A (ISP 1)
Core2 2M/10
Core3 2M/10
POP C
4M/5 Core1 Core7
4M/5 Core6
POP B (ISP 2)
Core
Core
The autoroute feature enables the head-end routers to see the MPLS-TE tunnel as a directly connected interface and use it in its modified SPF computations. The MPLS-TE tunnel is only used for normal IGP route calculation (at the head-end only) and is not included in any constraint-based path computation. With the autoroute feature the traffic trunk (tunnel):
n n
Appears in the routing table Has an associated IP metric (cost equal to the best IGP metric to the tunnel endpoint) and is also used for forwarding the traffic to destinations behind the tunnel endpoint.
The autoroute feature results in all the prefixes topologically behind the MPLSTE tunnel endpoint (tail-end) to be reachable via the tunnel itself (unlike with static routing where only statically configured destinations were reachable via the tunnel). Even with the autoroute feature, the tunnel itself is not used in link-state updates and the rest of the network still does not have any knowledge of it.
46
Changing Autoroute Metrics

#POP C configuration
interface Tunnel1 Announce the presence of the tunnel to the ip unnumbered Loopback0 routing protocol and select the primary path. tunnel destination POP-A tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng autoroute metric absolute 1 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 250 tunnel mpls traffic-eng path-option 1 explicit name Core3-2 interface Tunnel2 ip unnumbered Loopback0 The metric determines the secondary path. tunnel destination POP-A tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng autoroute metric absolute 2 tunnel mpls traffic-eng priority 2 2 tunnel mpls traffic-eng bandwidth 125 tunnel mpls traffic-eng path-option 1 dynamic ! ip explicit-path name Core3-2 enable next-address Core-3 next-address Core-2 next-address POP-A
Since the autoroute feature includes the MPLS-TE tunnel into the modified SPF path calculation, the metric of the tunnel plays a significant role. The cost of the tunnel is equal to the best IGP metric to the tunnel endpoint, regardless of the LSP path. The tunnel metric is tunable using either relative or absolute metrics, which is the case in the example. When installing the best paths to the destination, the tunnel metric is compared to other existing tunnel metrics and to all the native IGP path metrics. The lower metric is better, and if the MPLS-TE tunnel has a lower metric it is installed as a next hop to the respective destinations. If there are tunnels with equal metrics they are installed in the routing table and provide for load balancing. The load balancing is done proportionally to the configured bandwidth of the tunnel.
47
Auto-bandwidth
Due to the nature of the traffic being sent over MPLS-TE tunnel the load (measured in 5 minute intervals) varies from 100 Kbps to 300Kbps. Autobandwidth objective: - Adjust the bandwidth allocation for traffic engineering tunnels based on their actual measured traffic load.
POP A (ISP 1)
Core
Core
POP C
Core 1
POP B (ISP 2)
IS-IS
Core
Core
Core
POP D
Once initial traffic engineering is complete, administrators may need an effective way to continually adjust tunnel routes and bandwidth reservations without doing any re-designing. Cisco IOS software has a new feature called auto-bandwidth that measures utilization averages and dynamically adjusts tunnel bandwidth reservations to meet actual application resource requirements. This powerful feature creates "self-tuning tunnels," which free administrators from many of the daily hands-on management tasks that are necessary with other traffic engineering techniques.
48
Auto-bandwidth Configuration Commands

router(config)#
mpls mpls traffic-eng traffic-eng auto-bw auto-bw timers timers [ [frequency frequency sec] sec]
Enable automatic bandwidth adjustment and specify the frequency of the sampling interval, in seconds
router(config-if)#
tunnel tunnel mpls mpls traffic-eng traffic-eng [ [frequency frequency n n] ] auto-bw auto-bw max-bw max-bw n n min-bw min-bw n n
Specifies the frequency of adjustments, minimum and maximum automatic bandwidth allocations, in kilobits per second, that can be applied to the tunnel
For every MPLS TE tunnel configured for Cisco MPLS auto-bandwidth, the average output rate is sampled based on various configurable parameters. The tunnel bandwidth is then re-adjusted automatically based on the largest average output rate noticed during a certain interval or a configured maximum bandwidth value. The Cisco MPLS Auto-bandwidth allocator monitors the X minutes (default X = 5 min) average counter, keeping track of the largest average over some configurable interval Y (default = 24 hours), and then re-adjusting a tunnel bandwidth based upon the largest average for that interval. The Cisco MPLS auto-bandwidth feature is implemented with the following commands:
n
mpls traffic-eng auto-bw timers frequency <seconds> This is a global command to define the interval during which to sample the X average for each tunnel. By default this value is set to 300 seconds (5 minutes). clear mpls traffic-eng auto-bw timers This command is used to clear the timers defined by the previous command. tunnel mpls traffic-eng auto-bw {frequency <seconds>} {max-bw <kbs>} {min-bw <kbs>} By default the frequency is 24 hours.
The last command controls the Y interval between bandwidth re-adjustments and is tunnel specific. Setting the max-bw limits the maximum bandwidth a tunnel can adjust to. Similarly, setting the min-bw gives the smallest amount the bandwidth can adjust to. When both max-bw and min-bw are specified, the tunnel bandwidth will remain between these values.
49
Configuring MPLS AutoBandwidth

#POP-A configuration Sample (every 5 min) the output rate for tunnels that have been configured for automatic bandwidth adjustment.
mpls traffic-eng auto-bw timers frequency 300 interface tunnel1 Initial tunnel bandwidth, which will be adjusted ip unnumbered loopback 0 by the auto-bandwidth mechanism. tunnel destination POP-C tunnel mode mpls traffic-eng tunnel mpls traffic-eng bandwidth 2500 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic tunnel mpls traffic-eng auto bw frequency 3600 max-bw 3000 min-bw 1000
Specifies the minimum and maximum automatic bandwidth allocations, in kilobits per second, that can be applied to the tunnel and adjusted via RSVP (every hour).
The example in the figure shows the setting of MPLS traffic-engineered tunnels that can actually tune their own bandwidth requirements to increase or decrease their RSVP reservations, as warranted by changing network conditions. When re-adjusting the LSP with the new bandwidth constraint, a new Resource Reservation Protocol for Traffic Engineering (RSVP-TE) Path request is generated, and if the new bandwidth is not available, the last good LSP will continue to be used. The network experiences no traffic interruptions.
50
Protecting the Link

The Company decided to retain only dynamic tunnels. A new high speed link is introduced between Core-1 and Core-6 to influence CBR and native path selection and speed up transport across the network. Design consideration: - The new high speed link is now heavily used by traffic trunks and may couse a serious disruption. -Fast rerouting: Protect the link (not individual CB-LSP) by configuring a static backup tunnel from Core-6 across Core-7 to Core-1.
2M/10
POP A (ISP 1)
Core2 2M/10
Core3 2M/10 Core7
POP C
4M/5 Core1 8M/cost 3
4M/5 Core6
POP B (ISP 2)
Core
Core
Fast Reroute provides link protection to LSPs by establishing a backup LSP path (tunnel) for the troubled link. This provision enables all traffic carried by LSPs that traverse a failed link to be rerouted around the failure. The reroute decision is completely controlled locally by the router interfacing the failed link. The head-end of the tunnel is notified of the link failure through the IGP and through RSVP. The head-end then attempts to establish a new LSP that bypasses the failure. In the mean time, the head-end router may continue forwarding packets over the broken LSP path, because Fast Rerouting is using a backup tunnel for the packets that would have previously ended up on the failed interface. This procedure gives the head-end of the tunnel time to re-establish the tunnel along a new, optimal route.
51
Link Resilience with Fast Rerouting

Fast rerouting: - The router realizing the link is down, issues an IGP advertisement and RSVP message with session attribute flag 0x01=ON (dont break the tunnel, you may continue to forward packets during the reoptimization) - Any MPLS frame received by Core-6 with an old label refering to the protected interface, will be switched onto the backup tunnel.
- The backup tunnel is used while the head-end tunnels is doing rerouting
2M/10
POP A (ISP 1)
Core2 2M/10
Core3 2M/10
POP C
4M/5 Core1 Core7 8M/cost 3
4M/5 Core6
POP B (ISP 2)
A backup tunnel across Core-7.
Core
Core
POP D
The example in the figure illustrates how Fast Reroute link protection is used to protect traffic carried in a TE tunnel between devices POP-C and POP-A, as it traverses the link between devices Core-6 and Core-1. To protect this link, you create a backup tunnel that runs from Core-6 to Core-1 by way of Core-7. When R2 is notified that the link between it and R3 is no longer available, it simply forwards traffic destined for Core-1 through the backup tunnel. This operation is accomplished by performing a normal swap operation on Core-6, followed by the replacement of the outgoing interface with the backup LSP tunnel (nested LSP), thereby routing traffic around the failed link. The decision to reroute packets from the primary tunnel to the backup tunnel is made solely by Core-6 upon detection of link failure.
52
Fast Rerouting Configuration Commands

router(config-if)#
mpls mpls traffic-eng traffic-eng backup backup tunnel tunnel num num
Configure the interface to use a backup tunnel in the event of a detected failure on the interface
router(config-if)#
tunnel tunnel mpls mpls traffic-eng traffic-eng fast-reroute fast-reroute
Enable a traffic engineering tunnel to use a backup tunnel in the event of a link failure if a backup tunnel exists
mpls traffic-eng backup-path tunnel

To configure the interface to use a backup tunnel in the event of a detected failure on the interface, use the mpls traffic-eng backup tunnel interface command. mpls traffic-eng backup-path tunnel interface Syntax Description interface IP address associated with the given interface.
tunnel mpls traffic-eng fast-reroute

To enable an MPLS traffic engineering tunnel to use a backup tunnel in the event of a link failure if a backup tunnel exists, use the tunnel mpls traffic-eng fastreroute interface configuration command. tunnel mpls traffic-eng fast-reroute
53
Configuring Link Protection with Fast Reroute Capability

#Core-6 configuration interface Tunnel 1000 Adjust the bandwidth to support multuple TT ip unnumbered Loopback0 tunnel destination Core-1 Prevent normal use of tunnel tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 1000 NO tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 1 explicit name Backup-path ! ip explicit-path name Backup-path enable next-address Core-7 Requires a manually configured ERO next-address Core-1 #High-speed interface to be protected towards Core-1 interface ser0/0 mpls traffic-eng backup tunnel 1000
In the event of a link failure, an LSP is rerouted to
the next-hop using a preconfigured backup tunnel #POP-C configuration (nested labels). interface Tunnel1 ip unnumbered Loopback0 tunnel destination POP-A tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng autoroute metric absolute 1 tunnel mode mpls traffic-eng fast-reroute Allow fast reroute for that tunnel tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 250 tunnel mpls traffic-eng path-option 1 explicit name Core3-2
The example in the figure lists both sets of configuration commands needed when provisioning a backup for a link over a tunnel:
n n
POP-C configuration of a Tunnel and fast reroute assignment. Core-6 to provide a backup Tunnel around the protected Link.
54
Guaranteed Bandwidth Service

Further enhancement to satisfy the stricter requirements Separate pools to allow for different limit for the amount of traffic admitted on any given link One sub-pool, for tunnels that carry traffic requiring strict bandwidth guarantees or delay guarantees The global pool, for best-effort or diffserv traffic
Providing Strict QoS Guarantees Using DS-TE Sub--pool Tunnels A tunnel using sub-pool bandwidth can satisfy the stricter requirements if you do all of the following: 1. Select a queueor in DiffServ terminology, select a PHB (per-hop behavior) to be used exclusively by the strict guarantee traffic. This shall be called the "GB queue." If delay/jitter guarantees are sought, the DiffServ Expedited Forwarding queue (EF PHB) is used. On the Cisco Series 12000 that is the "lowlatency" queue. You must configure the bandwidth of the queue to be at least equal to the bandwidth of the sub-pool. If only bandwidth guarantees are sought, the DiffServ Assured Forwarding PHB (AF PHB) is used. On the Cisco 12000 you use one of the existing Modified Deficit Round Robin (MDRR) queues. 2. Ensure that the guaranteed traffic sent through the sub-pool tunnel is placed in the GB queue at the outbound interface of every tunnel hop, and that no other traffic is placed in this queue. You do this by marking the traffic that enters the tunnel with a unique value in the mpls exp bits field, and steering only traffic with that marking into the GB queue. 3. Ensure that this GB queue is never oversubscribed; that is, see that no more traffic is sent into the sub-pool tunnel than the GB queue can handle. You do this by rate-limiting the guaranteed traffic before it enters the subpool tunnel. The aggregate rate of all traffic entering the sub-pool tunnel should be less than or equal to the bandwidth capacity of the sub-pool tunnel. Excess traffic can be dropped (in the case of delay/jitter
guarantees) or can be marked differently for preferential discard (in the case of bandwidth guarantees). 4. Ensure that the amount of traffic entering the GB queue is limited to an appropriate percentage of the total bandwidth of the corresponding outbound link. The exact percentage to use depends on several factors that can contribute to accumulated delay in your network: your QoS performance objective, the total number of tunnel hops, the amount of link fan-in along the tunnel path, burstiness of the input traffic, and so on. You do this by setting the sub-pool bandwidth of each outbound link to the appropriate percentage of the total link bandwidth (that is, by adjusting the z parameter of the ip rsvp bandwidth command). Providing Differentiated Service Using DS-TE Global Pool Tunnels You can configure a tunnel using global pool bandwidth to carry best-effort as well as several other classes of traffic. Traffic from each class can receive differentiated service if you do all of the following: 1. Select a separate queue (a distinct DiffServ PHB) for each traffic class. For example, if there are three classes (gold, silver, and bronze) there must be three queues (DiffServ AF2, AF3, and AF4). 2. Mark each class of traffic using a unique value in the MPLS experimental bits field (for example gold = 4, silver = 5, bronze = 6). 3. Ensure that packets marked as Gold are placed in the gold queue, Silver in the silver queue, and so on. The tunnel bandwidth is set based on the expected aggregate traffic across all classes of service. To control the amount of DiffServ tunnel traffic you intend to support on a given link, adjust the size of the global pool on that link.
56
Configuring Guaranteed Bandwidth Service

router(config-if)#
ip ip rsvp rsvp bandwidth bandwidth interface-kbps interface-kbps single-flow-kbps single-flow-kbps subsubpool pool kbps kbps
The sum of bandwidth used by all tunnels on this interface cannot exceed interface-kbps, and the sum of bandwidth used by all sub-pool tunnels cannot exceed sub-pool kbps
router(config-if)#
tunnel tunnel mpls mpls traffic-eng traffic-eng bandwidth bandwidth {sub-pool {sub-pool | | [global]} [global]} bandwidth bandwidth
Configure the tunnel's bandwidth and assigns it either to the sub-pool or the global pool
ip rsvp bandwidth
To enable Resource Reservation Protocol (RSVP) for IP on an interface, use the ip rsvp bandwidth interface configuration command. ip rsvp bandwidth interface-kbps single-flow-kbps [sub-pool kbps] Syntax Description interface-kbps single-flow-kbps sub-pool kbps Amount of bandwidth (in kbps) on interface to be reserved. The range is 1 to 10000000. Amount of bandwidth (in kbps) allocated to a single flow. [Ignored in DS-TE]. The range is 1 to 10000000. Amount of bandwidth (in kbps) on interface to be reserved to a portion of the total. The range is from 1 to the value of interface-kbps.
tunnel mpls traffic-eng bandwidth

To configure bandwidth required for an MPLS traffic engineering tunnel, use the tunnel mpls traffic-eng bandwidth command in interface configuration mode.
tunnel mpls traffic-eng bandwidth {sub-pool | [global]} bandwidth Syntax Description sub-pool (Optional) Indicates a sub-pool tunnel.
57
global
(Optional) Indicates a global pool tunnel. Entering this keyword is not necessary, for all tunnels are "global pool" in the absence of the keyword sub-pool. But if users of pre-DS-TE images enter this keyword, it will be accepted. The bandwidth, in kilobits per second, set aside for the MPLS traffic engineering tunnel. Range is between 1 and 4294967295.
bandwidth
58
Summary
After completing this lesson, you should be able to:
n
Create explicit paths and create a hierarchy of explicit and dynamic paths for a traffic trunk Assign traffic to an MPLS traffic trunk with static routes Assign traffic to an MPLS traffic trunk with policy-based routing (PBR) Configure MPLS TE policies by changing link and trunk affinity bits Modify MPLS TE metrics to influence link selection Modify autoroute metrics to enable load sharing or primary/backup scenarios between routed and traffic-engineered traffic Deploy the auto-bandwidth feature of MPLS TE Deploy optimization and fast rerouting of MPLS TE traffic trunks
n n n n n
n n
Lesson Review
1. How is the best path for a traffic trunk calculated? 2. Is a static configuration of an explicit path for TE tunnel subject to CBR or any path with the TE support can be used? 3. What is the difference between rerouting and reoptimization? 4. What is achieved by the auto-bandwidth mechanism? 5. How is the rerouting accomplished when using a Fast reroute link protection?
59
Monitoring and Troubleshooting MPLS-TE

Objectives
n n
List the Cisco IOS commands for MPLS-TE monitoring and troubleshooting Describe the major indicators of the MPLS-TE state from the monitoring and debugging output
60
Monitoring MPLS TE trunks

router#
show show mpls mpls traffic-eng traffic-eng tunnels tunnels tunnel_interface tunnel_interface [brief] [brief]
Show summary information about a tunnel

router#
show show mpls mpls traffic-eng traffic-eng tunnels tunnels [ [parameters parameters] ]
Show detailed information about tunnel

router#
show show mpls mpls traffic-eng traffic-eng autoroute autoroute
Show tunnels that are announced to IGP, including interface, destination, and bandwidth
show mpls traffic-eng tunnel

To show information about tunnels, use the show mpls traffic-eng tunnel command. show mpls traffic-eng tunnel [{tunnel_interface | destination address | source-id [{ipaddress | 0-MAX | name name role {all | head | middle | tail | remote} | {up | down}}] [brief] Examples The following example shows output from the show mpls traffic-eng tunnel brief command:
Router#show mpls traffic-eng tunnel brief Signaling Summary: LSP Tunnels Process: RSVP Process: Forwarding: Periodic reoptimization: TUNNEL NAME tagsw-r4_t1 tagsw-r4_t10011 ... al7500-sw12_t20004 Displayed 16 (of 16) heads, 0 (of running running enabled every 180 seconds, DESTINATION 10.0.0.11 10.0.0.11
next in 108 STATUS admin-down up
seconds STATE down up
10.0.0.4 signaled 0) midpoints, 1 (of 1) tails
up
61
show mpls traffic-eng autoroute

To show tunnels that are announced to IGP, including interface, destination, and bandwidth, use the show mpls traffic-eng autoroute command in privileged EXEC mode. show mpls traffic-eng autoroute Usage Guidelines The SPF/nexthop calculation of the IGP has been modified to understand TE tunnels. This command shows which tunnels are currently being used by the IGP in its SPF/nexthop calculation (tunnels that are up and have autoroute configured). Examples The following example shows output from the show mpls traffic-eng autoroute command. Note that the list of tunnels is organized by destination. All tunnels to a destination will carry a share of the traffic tunneled to that destination.
Router#show mpls traffic-eng autoroute MPLS TE autorouting enabled destination 0002.0002.0002.00 has 2 tunnels Tunnel1021 (traffic share 10000, nexthop 2.2.2.2, absolute metric 11) Tunnel1022 (traffic share 3333, nexthop 2.2.2.2, relative metric -3) destination 0003.0003.0003.00 has 2 tunnels Tunnel1032 (traffic share 10000, nexthop 3.3.3.3) Tunnel1031 (traffic share 10000, nexthop 3.3.3.3, relative metric -1)
62
Monitoring MPLS Traffic Engineering

router#
show show mpls mpls traffic-eng traffic-eng link-management link-management summary summary [ [interface-name interface-name] ]
Show a summary of link management information

router#
show show mpls mpls traffic-eng traffic-eng link-management link-management interfaces interfaces [ [interface-name interface-name] ]
Show interface resource and configuration information

router#
show show mpls mpls traffic-eng traffic-eng link-management link-management bandwidthbandwidthallocation allocation [ [interface-name interface-name] ]
Show current local link bandwidth allocation
show mpls traffic-eng link-management summary

To show a summary of link management information, use the show mpls trafficeng link-management summary command in EXEC mode. show mpls traffic-eng link-management summary [interface name] Examples The following example shows output from the show mpls traffic-eng linkmanagement summary command:
Router#show mpls traffic-eng link-management summary atm0/0.1 System Information:: Links Count: 3 Flooding System: enabled IGP Area ID:: isis level-1 Flooding Protocol: ISIS Flooding Status: data flooded Periodic Flooding: enabled (every 180 seconds) Flooded Links: 1 IGP System ID: 0001.0000.0001.00 MPLS TE Router ID: 10.106.0.6 IGP Neighbors: 3 Link ID:: AT0/0.1 (10.32.0.6) Link Status: Physical Bandwidth: 155520000 bits/sec MPLS TE Bandwidth: 5000000 bits/sec (reserved:0% in, 80% out) MPLS TE Link State: MPLS TE on, RSVP on, admin-up, flooded Inbound Admission: allow-all Outbound Admission: allow-if-room Admin. Weight: 10 (IGP) IGP Neighbor Count: 1
63
show mpls traffic-eng link-management interfaces

To show per-interface resource and configuration information, use the show mpls traffic-eng link-management interfaces command in EXEC mode. show mpls traffic-eng link-management interfaces [interface] Syntax Description interface (Optional) Specifies the name of a single interface for which information is to be displayed.
Examples The following example shows output from the show mpls traffic-eng linkmanagement interfaces command:
Router#show mpls traffic-eng link-management interfaces System Information:: Links Count: 3 Link ID:: Et1/1/1 (10.1.0.6) Link Status: Physical Bandwidth: 10000000 bits/sec MPLS TE Bandwidth: 5000000 bits/sec (reserved:0% in, 0% out) MPLS TE Link State: MPLS TE on, RSVP on Inbound Admission: reject-huge Outbound Admission: allow-if-room Admin. Weight: 10 (IGP) IGP Neighbor Count: 2 IGP Neighbor: ID 0000.0000.0000.02, IP 0.0.0.0 (Up) IGP Neighbor: ID 0001.0000.0001.02, IP 0.0.0.0 (Down) Flooding Status for each configured area [1]: IGP Area[1 isis level-1: not flooded (Reason:Interface has been administratively disabled) Link ID:: AT0/0.1 (10.32.0.6) Link Status: Physical Bandwidth: 155520000 bits/sec MPLS TE Bandwidth: 5000000 bits/sec (reserved:0% in, 80% out) MPLS TE Link State: MPLS TE on, RSVP on, admin-up, flooded Inbound Admission: allow-all Outbound Admission: allow-if-room Admin. Weight: 10 (IGP) IGP Neighbor Count: 1 IGP Neighbor: ID 0001.0000.0002.00, IP 10.32.0.10 (Up) Flooding Status for each configured area [1]: IGP Area[1 isis level-1: flooded
show mpls traffic-eng link-management bandwidth-allocation

To show current local link information, use the show mpls traffic-eng linkmanagement bandwidth-allocation command in EXEC mode. show mpls traffic-eng link-management bandwidth-allocation [interface name] Syntax Description interface name (Optional) Shows only those tunnels that have been admitted on the specified interface.
64
Examples The following example shows output from this command:

Router#show mpls traffic-eng link-management bandwidth-allocation atm0/0.1 System Information:: Links Count: 3 Bandwidth Hold Time: max. 15 seconds Link ID:: AT0/0.1 (10.32.0.6) Link Status: Physical Bandwidth: 155520000 bits/sec MPLS TE Bandwidth: 5000000 bits/sec (reserved:0% in, 80% out) BW Descriptors: 1 MPLS TE Link State: MPLS TE on, RSVP on, admin-up, flooded Inbound Admission: allow-all Outbound Admission: allow-if-room Admin. Weight: 10 (IGP) IGP Neighbor Count: 1 Up Thresholds: 15 30 45 60 75 80 85 90 95 96 97 98 99 100 (default) Down Thresholds: 100 99 98 97 96 95 90 85 80 75 60 45 30 15 (default) Outbound Bandwidth Information (bits/second): KEEP PRIORITY BW HELD BW TOTAL HELD BW LOCKED BW TOTAL LOCKED 0 0 0 0 0 1 0 0 4000000 4000000 2 0 0 0 4000000 3 0 0 0 4000000 4 0 0 0 4000000 5 0 0 0 4000000 6 0 0 0 4000000 7 0 0 0 4000000
65

router#
show show mpls mpls traffic-eng traffic-eng link-management link-management advertisements advertisements
Show local link information that MPLS traffic engineering link management is currently flooding into the global traffic engineering topology
router#
show show mpls mpls traffic-eng traffic-eng link-management link-management admission-control admission-control [ [interface-name interface-name] ]
Show which tunnels were admitted locally and their parameters (such as, priority, bandwidth, incoming and outgoing interface, and state)
show mpls traffic-eng link-management advertisements

To show local link information currently being flooded by MPLS traffic engineering link management into the global traffic engineering topology, use the show mpls traffic-eng link-management advertisements command in EXEC mode. show mpls traffic-eng link-management advertisements Examples The following example shows output from the show mpls traffic-eng linkmanagement advertisements command:
Router#show mpls traffic-eng link-management advertisements Flooding Status: ready Configured Areas: 1 IGP Area[1] ID:: isis level-1 System Information:: Flooding Protocol: ISIS Header Information:: IGP System ID: 0001.0000.0001.00 MPLS TE Router ID: 10.106.0.6 Flooded Links: 1 Link ID:: 0 Link IP Address: 10.32.0.6 IGP Neighbor: ID 0001.0000.0002.00, IP 10.32.0.10 Admin. Weight: 10 Physical BW: 155520000 bits/sec Reservable BW: 5000000 bits/sec Output Bandwidth:: BW Unreserved[0]: 5000000 bits/sec BW Unreserved[1]: 1000000 bits/sec BW Unreserved[2]: 1000000 bits/sec
66
BW Unreserved[3]: BW Unreserved[4]: BW Unreserved[5]: BW Unreserved[6]: BW Unreserved[7]: Affinity Bits
1000000 bits/sec 1000000 bits/sec 1000000 bits/sec 1000000 bits/sec 1000000 bits/sec 0x00000000
show mpls traffic-eng link-management admission-control

To show which tunnels have been admitted locally, and their parameters (such as priority, bandwidth, incoming and outgoing interface, and state), use the show mpls traffic-eng link-management admission-control command in EXEC mode. show mpls traffic-eng link-management admission-control [interface name] Syntax Description interface name (Optional) Shows only those tunnels that are admitted on the specified interface.
Examples The following example shows output from the show mpls traffic-eng linkmanagement admission-control command:
Router#show mpls traffic-eng link-management admission-control System Information:: Tunnels Count: 1 Tunnels Selected: 1 TUNNEL ID UP IF 3.3.25.3 1_1 -
DOWN IF PRIORITY STATE PO1/0/0 1/1 Resv Admitted
BANDWIDTH 10000 R
67

router#
show show mpls mpls traffic-eng traffic-eng link-management link-management igp-neighbors igp-neighbors [{ [{ igp-id igp-id {isis {isis isis-address isis-address|ospf |ospf ospf-id ospf-id} } | | ip ip A.B.C.D A.B.C.D }] }]
Show TE IGP neighbors

router#
show show mpls mpls traffic-eng traffic-eng topology topology [ [ { { A.B.C.D A.B.C.D | | igp-id igp-id { { isis A.B.C.D } } ] ] [ [ brief brief ] ] isis nsapaddr nsapaddr | | ospf ospf A.B.C.D
Show the MPLS traffic engineering global topology currently known at this node
router(config)#
show show mpls mpls traffic-eng traffic-eng topology topology path path tunnel-intf tunnel-intf [ [parameters parameters] ]
Show the properties of the best available path to a specified destination that satisfies certain constraints
show mpls traffic-eng link-management igp-neighbors

To show IGP neighbors, use the show mpls traffic-eng link-management igpneighbors command in privileged EXEC mode. show mpls traffic-eng link-management igp-neighbors [{igp-id {isis isisaddress | ospf ospf-id} | ip A.B.C.D}] Syntax Description igp-id isis isis-address ospf ospf-id ip A.B.C.D. Examples The following example shows output from the show mpls traffic-eng linkmanagement igp-neighbors command:
Router#show mpls traffic-eng line-management igp-neighbors Link ID:: Et0/2 Neighbor ID: 0000.0024.0004.02 (area: isis level-1, IP: 0.0.0.0) Link ID:: PO1/0/0
68 MPLS TE Implementation on Cisco IOS Copyright 2001, Cisco Systems, Inc.
Shows the IGP neighbors using a specified IGP identification. Specifies an IS-IS neighbor to display when displaying neighbors by IGP ID. Specifies an OSPF neighbor to display when displaying neighbors by IGP ID. Shows the IGP neighbors using a specified IGP IP address.
Neighbor ID: 0000.0026.0001.00 (area: isis level-1, IP: 170.1.1.2)
show mpls traffic-eng topology

To show the MPLS traffic engineering global topology as currently known at this node, use the show mpls traffic-eng topology command in privileged EXEC mode. show mpls traffic-eng topology [{A.B.C.D | igp-id {isis nsapaddr | ospf A.B.C.D}] [brief] Syntax Description A.B.C.D igp-id isis nsapaddr ospf A.B.C.D brief Examples The following example shows output from the show mpls traffic-eng topology command:
Router#show mpls traffic-eng topology My_System_id: 0000.0025.0003.00 IGP Id: 0000.0024.0004.00, MPLS TE Id:24.4.4.4 Router Node link[0 ]:Intf Address: 150.1.1.4 Nbr IGP Id: 0000.0024.0004.02, admin_weight:10, affinity_bits:0x0 max_link_bw:10000 max_link_reservable: 10000 allocated reservable allocated reservable --------- ------------------ ---------bw[0]: 0 10000 bw[1]: 0 10000 bw[2]: 0 10000 bw[3]: 0 10000 bw[4]: 0 10000 bw[5]: 0 10000 bw[6]: 0 10000 bw[7]: 0 10000
Specifies the node by the IP address (router identifier to interface address). Specifies the node by IGP router identifier. Specifies the node by router identification (nsapaddr) if using IS-IS. Specifies the node by router identifier if using OSPF. (Optional) The brief form of the output gives a less detailed version of the topology.
show mpls traffic-eng topology path

To show the properties of the best available path to a specified destination that satisfies certain constraints, use the show mpls traffic-eng topology path EXEC command. You specify the constraints in this command. show mpls traffic-eng topology path { tunnel-interface [ destination address ] | destination address } [ bandwidth value] [ priority value [ value ] ] [ affinity value [ mask mask ] ]
69
Syntax Description tunnel-interface Name of an MPLS traffic engineering interface (for example, Tunnel1) from which default constraints should be copied. (Optional) IP address specifying the path's destination. (Optional) Bandwidth constraint: the amount of available bandwidth that a suitable path requires. This overrides the bandwidth constraint obtained from the specified tunnel interface. You can specify any positive number.
destination address bandwidth value
priority value [value] (Optional) Priority constraints: the setup and hold priorities used to acquire bandwidth along the path. If specified, this overrides the priority constraints obtained from the tunnel interface. Valid values are from 0 to 7. affinity value (Optional) Affinity constraints: the link attributes for which the path has an affinity. If specified, this overrides the affinity constraints obtained from the tunnel interface. (Optional) Affinity constraints: the mask associated with the affinity specification.
mask mask
Examples The following is sample output from the show mpls traffic-eng topology path command:
Router1#show mpls traffic-eng topology path Tunnel1 bandwidth 1000 Query Parameters: Destination:10.112.0.12 Bandwidth:1000 Priorities:1 (setup), 1 (hold) Affinity:0x0 (value), 0xFFFF (mask) Query Results: Min Bandwidth Along Path:2000 (kbps) Max Bandwidth Along Path:5000 (kbps) Hop 0:10.1.0.6 :affinity 00000000, bandwidth 2000 (kbps) Hop 1:10.1.0.10 :affinity 00000000, bandwidth 5000 (kbps) Hop 2:10.43.0.10 :affinity 00000000, bandwidth 2000 (kbps) Hop 3:10.112.0.12
70
Monitoring MPLS TE Resource Usage on Intermediate Devices

router#
show show ip ip ospf ospf database database opaque-area opaque-area
Display lists of traffic engineering opaque link-state advertisements (LSAs)

router#
show show ip ip ospf ospf [ [ process-id process-id [ [ area-id area-id ] ] ] ] mpls mpls traffic-eng traffic-eng [ [ link link ] ] | | [ [ fragment fragment ] ]
Display information about the links available on the local router for traffic engineering
show ip ospf database opaque-area

To display lists of information related to traffic engineering opaque link-state advertisements (LSAs), also known as Type-10 opaque link area link states, use the show ip ospf database opaque-area EXEC command. show ip ospf database opaque-area Examples The following is sample output from the show ip ospf database opaque-area command:
Router#show ip ospf database opaque-area OSPF Router with ID (25.3.3.3) (Process ID 1) Type-10 Opaque Link Area Link States (Area 0) LS age: 12 Options: (No TOS-capability, DC) LS Type: Opaque Area Link Link State ID: 1.0.0.0 Opaque Type: 1 Opaque ID: 0 Advertising Router: 24.8.8.8 LS Seq Number: 80000004 Checksum: 0xD423 Length: 132 Fragment number : 0 MPLS TE router ID: 24.8.8.8 Link connected to Point-to-Point network Link ID : 26.2.2.2
71
Interface Address : 198.1.1.1
show ip ospf
To display general information about OSPF routing processes, use the show ip ospf EXEC command. show ip ospf [process-id] Syntax Description process-id Examples The following is a sample output from the show ip ospf command when entered without a specific OSPF process ID:
Router#show ip ospf Routing Process "ospf 201" with ID 192.42.110.200 Supports only single TOS(TOS0) route It is an area border and autonomous system boundary router Redistributing External Routes from, igrp 200 with metric mapped to 2, includes subnets in redistribution rip with metric mapped to 2 igrp 2 with metric mapped to 100 igrp 32 with metric mapped to 1 Number of areas in this router is 3 Area 192.42.110.0 Number of interfaces in this area is 1 Area has simple password authentication SPF algorithm executed 6 times
(Optional) Process ID. If this argument is included, only information for the specified routing process is included.
72

router#
show show isis isis database database verbose verbose
To display more information (including sub TLVs) about the database

router(config)#
show show isis isis mpls mpls traffic-eng traffic-eng adjacency-log adjacency-log
To display a log of 20 entries of MPLS traffic engineering IS-IS adjacency changes

router(config)#
show show isis isis mpls mpls traffic-eng traffic-eng advertisements advertisements
show isis mpls traffic-eng advertisements

show isis database verbose

To display more information about the database, use the show isis database verbose command in EXEC mode. show isis database verbose Examples The following example shows output from the show isis database verbose command:
Router#show isis database verbose IS-IS Level-1 Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime dtp-5.00-00 * 0x000000E6 0xC9BB 1042 Area Address:49.0001 NLPID: 0xCC Hostname:dtp-5 Router ID: 5.5.5.5 IP Address: 172.21.39.5 Metric:10 IP 172.21.39.0/24 dtp-5.00-01 * 0x000000E7 0xAB36 1065 Metric:10 IS-Extended dtp-5.01 Affinity:0x00000000 Interface IP Address:172.21.39.5 Physical BW:10000000 bits/sec Reservable BW:1166000 bits/sec BW Unreserved[0]: 1166000 bits/sec, BW Unreserved[1]: 1166000 BW Unreserved[2]: 1166000 bits/sec, BW Unreserved[3]: 1166000 BW Unreserved[4]: 1166000 bits/sec, BW Unreserved[5]: 1166000 BW Unreserved[6]: 1166000 bits/sec, BW Unreserved[7]: 1153000 Metric:0 ES dtp-5
ATT/P/OL 0/0/0
0/0/0
bits/sec bits/sec bits/sec bits/sec
73
show isis mpls traffic-eng adjacency-log

To display a log of 20 entries of MPLS traffic engineering IS-IS adjacency changes, use the show isis mpls traffic-eng adjacency-log command in EXEC mode. show isis mpls traffic-eng adjacency-log Examples The following is a sample output from the show isis mpls traffic-eng adjacencylog command:
Router#show isis mpls traffic-eng adjacency-log IS-IS RRR log
When 04:52:52 04:52:50 04:52:37
Neighbor ID 0000.0024.0004.02 0000.0026.0001.00 0000.0024.0004.02
IP Address 0.0.0.0 170.1.1.2 0.0.0.0
Interface Et0/2 PO1/0/0 Et0/2
Status Up Up Up
Level level-1 level-1 level-1
show isis mpls traffic-eng advertisements

To display the last flooded record from MPLS traffic engineering, use the show isis mpls traffic-eng advertisements command in EXEC mode. show isis mpls traffic-eng advertisements Examples The following is output from the show isis mpls traffic-eng advertisements command:
Router#show isis mpls traffic-eng advertisements System ID:dtp-5.00 Router ID:5.5.5.5 Link Count:1 Link[1] Neighbor System ID:dtp-5.01 (broadcast link) Interface IP address:172.21.39.5 Neighbor IP Address:0.0.0.0 Admin. Weight:10 Physical BW:10000000 bits/sec Reservable BW:1166000 bits/sec BW unreserved[0]:1166000 bits/sec, BW unreserved[1]:1166000 BW unreserved[2]:1166000 bits/sec, BW unreserved[3]:1166000 BW unreserved[4]:1166000 bits/sec, BW unreserved[5]:1166000 BW unreserved[6]:1166000 bits/sec, BW unreserved[7]:1153000 Affinity Bits:0x00000000
bits/sec bits/sec bits/sec bits/sec
74

router#
show show isis isis mpls mpls traffic-eng traffic-eng tunnel tunnel
To display information about tunnels considered in the IS-IS next hop calculation
show isis mpls traffic-eng tunnel

To display information about tunnels considered in the IS-IS next hop calculation, use the show isis mpls traffic-eng tunnel command in EXEC mode. show isis mpls traffic-eng tunnel Examples The following example shows output from this command:
Router#show isis mpls traffic-eng tunnel Station Id kangpa-router1.00 tomklong-route.00 Tunnel Name Tunnel1022 Tunnel1021 Tunnel1031 Tunnel1032 Bandwidth 3333 10000 10000 10000 Nexthop 2.2.2.2 2.2.2.2 3.3.3.3 3.3.3.3 Metric -3 11 -1 Mode Relative Absolute Relative
75
Troubleshooting Device and Link Setup

router#
debug debug mpls mpls traffic-eng traffic-eng areas Area areas Area configuration configuration change change events events autoroute Automatic autoroute Automatic routing routing over over tunnels tunnels link-management link-management Link Link Management Management load-balancing load-balancing Unequal Unequal cost cost load load balancing balancing over over tunnels tunnels path Path path Path calculation calculation events events topology Show topology Show topology topology events events tunnels MPLS tunnels MPLS Traffic Traffic Engineering Engineering tunnels tunnels
Using IS-IS to Support MPLS Traffic Engineering-38
The debug mpls traffic-eng has various options similar to the show commands. The debug mpls traffic-eng tunnels is a useful command to show tunnel events and errors. The path option shows the path calculation and the autoroute option shows the advertisement of the tunnel as a potential route through the network.
76
Summary
After completing this lesson, you should be able to:
n n
List the Cisco IOS commands for MPLS-TE monitoring and troubleshooting Describe the major indicators of MPLS-TE state from the monitoring and debugging output
Lesson Review
1. How is the operation of a TE tunnel verified? 2. List some major steps when troubleshooting TE tunnels. 3. How is the support for MPLS-TE on the intermediate systems verified?
77
Summary
After completing this module, you should be able to:
n n n n n
Explain the implementation details of MPLS-TE List the commands needed in MPLS-TE implementation Configure traffic engineering features in Cisco IOS Deploy advanced MPLS Traffic Engineering features Monitor and troubleshoot MPLS-TE
78
Appendix: Answers to Review Questions

Configuring MPLS Traffic Engineering on Cisco IOS
1. How is the MPLS-TE support enabled? There are a number of steps to configure a network to use MPLS Traffic Engineering: A suitable link-state routing protocol must be configured (IS-IS or OSPF). The CEF switching services must be enabled and MPLS configured on the router and on interfaces. The RSVP environment must be configured to allow bandwidth reservation. MPLS Traffic engineering must be enabled on interfaces and the distribution of reservation information via the IGP must be enabled by configuring support for this inside IS-IS and OSPF.
2. What modifications are needed to the IS-IS and OSPF to support MPLS-TE? Both protocols introduce Constraint-SPF algorithm to calculate best paths in a way to take into account available resources. The information on the resources is advertised with new TLVs in IS-IS LSP and new LSA in OSPF. 3. How is the MPLS-TE tunnel configured? The basic configuration of MPLE-TE tunnel requires the following steps: Configure a tunnel interface, using the address of one of this routers loopback interfaces as the tunnel source and set the tunnel destination address to the loopback address of end-point router. Configure the tunnels to use MPLS Traffic Engineering as its transport. Specify the tunnels bandwidth requirement and priority for establishing and holding session across the network.
Advanced MPLS Traffic Engineering Configuration

4. How is the best path for a traffic trunk calculated? The best route is the least-cost route with enough resources. The result of CBR is an explicit route, used by RSVP to reserve resources and establish LSP path for the trunk. 5. Is a static configuration of an explicit path for TE tunnel subject to CBR or any path with the TE support can be used? A path proposed to TE tunnel must be honored by the constraint-based routing algorithm. 6. What is the difference between rerouting and reoptimization?
79
The rerouting process takes place when the path is broken and the head-end router tries to find an alternative solution. The re-optimization occurs when a device examines tunnels with established LSPs, to see if better LSPs are available. 7. What is achieved by the auto-bandwidth mechanism? Auto-bandwidth measures utilization averages and dynamically adjusts tunnel bandwidth reservations to meet actual application resource requirements. 8. How is the rerouting accomplished when using a Fast reroute link protection? When the head-end router is notified that the protected link is no longer available, it continues forwarding traffic over the troubled LSP while doing rerouting. This operation is accomplished at the router interfacing the protected link by replacing the outgoing interface with the backup LSP tunnel.
80

MPLS - TE - Implementation On Cisco IOS

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

MPLS - TE - Implementation On Cisco IOS

Загружено:

Авторское право:

Доступные форматы

Overview

Configuring MPLS Traffic Engineering on Cisco IOS

MPLS TE Implementation on Cisco IOS

Copyright 2001, Cisco Systems, Inc.

Enabling Device-Level MPLS TE Support

Enable IP cef switching

mpls mpls traffic-eng traffic-eng tunnels tunnels

Enable the MPLS traffic engineering tunnel feature on a device

2001, Cisco Systems, Inc.

MPLS TE Implementation on Cisco IOS-5

mpls traffic-eng tunnels (configuration)

Copyright 2001, Cisco Systems, Inc.

MPLS TE Implementation on Cisco IOS

MPLS TE Implementation on Cisco IOS

Copyright 2001, Cisco Systems, Inc.

Enabling MPLS TE on an Interface

Enable the MPLS on an interface

mpls mpls traffic-eng traffic-eng tunnels tunnels

Enable the MPLS traffic engineering tunnel feature on an interface

ip ip rsvp rsvp bandwidth bandwidth [ [total-flow-kbps total-flow-kbps] ] [ [single-flow-kbps single-flow-kbps] ]

Enable RSVP for IP on an interface and specify amount of bandwidth to be reserved

mpls traffic-eng tunnels (interface)

MPLS TE Implementation on Cisco IOS

Copyright 2001, Cisco Systems, Inc.

Enabling MPLS TE on an Interface (Cont.)

mpls mpls traffic-eng traffic-eng attribute-flags attribute-flags attributes attributes

Set a link's reserved bandwidth thresholds on a interface

Set the length of the interval for periodic flooding

mpls traffic-eng attribute-flags

mpls traffic-eng flooding thresholds

Copyright 2001, Cisco Systems, Inc.

MPLS TE Implementation on Cisco IOS

mpls traffic-eng link timers periodic-flooding

MPLS TE Implementation on Cisco IOS

Copyright 2001, Cisco Systems, Inc.

Enabling MPLS TE Support in IS-IS

mpls mpls traffic-eng traffic-eng {level-1 {level-1 | | level-2} level-2}

Turn on MPLS traffic engineering for IS-IS level-1 or level-2

mpls mpls traffic-eng traffic-eng router-id router-id { {interface interface} }

metric-style metric-style wide wide

Configure a router to generate and accept only new-style TLVs

2001, Cisco Systems, Inc.

MPLS TE Implementation on Cisco IOS-8

mpls traffic-eng router-id

Copyright 2001, Cisco Systems, Inc.

MPLS TE Implementation on Cisco IOS

Copyright 2001, Cisco Systems, Inc.

Enabling MPLS TE Support in OSPF

mpls mpls traffic-eng traffic-eng area area area-num area-num

Turn on OSPF traffic engineering for the respective area

mpls mpls traffic-eng traffic-eng router-id router-id { {interface interface} }

2001, Cisco Systems, Inc.

MPLS TE Implementation on Cisco IOS-9

mpls traffic-eng area

mpls traffic-eng router-id

Copyright 2001, Cisco Systems, Inc.

MPLS TE Implementation on Cisco IOS

Copyright 2001, Cisco Systems, Inc.

Creating and Configuring a Traffic Trunk

interface interface tunnel tunnel number number

Configures a tunnel interface

tunnel tunnel destination destination ip-address ip-address