Table Of Contents
MPLS Traffic Engineering and Enhancements
Why Use MPLS Traffic Engineering?
How MPLS Traffic Engineering Works
Enhancement to the SPF Computation
Additional Enhancements to SPF Computation Using Configured Tunnel Metrics
Transitioning an IS-IS Network to a New Technology
New Extensions for the IS-IS Routing Protocol
First Solution for Transitioning an IS-IS Network to a New Technology
Transition Actions During the First Solution
Second Solution for Transitioning an IS-IS Network to a New Technology
Transition Actions During the Second Solution
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Configuring a Device to Support Tunnels
Configuring an Interface to Support RSVP-Based Tunnel Signaling and IGP Flooding
Configuring IS-IS for MPLS Traffic Engineering
Configuring OSPF for MPLS Traffic Engineering
Configuring an MPLS Traffic Engineering Tunnel
Configuring an MPLS Traffic Engineering Tunnel that an IGP Can Use
Configuring MPLS Traffic Engineering Using IS-IS
Router 1—MPLS Traffic Engineering Configuration
Configuring MPLS Traffic Engineering Using OSPF
Router 1—MPLS Traffic Engineering Configuration
Configuring an MPLS Traffic Engineering Tunnel
Router 1—Dynamic Path Tunnel Configuration
Router 1—Dynamic Path Tunnel Verification
Router 1—Explicit Path Configuration
Router 1—Explicit Path Tunnel Configuration
Router 1—Explicit Path Tunnel Verification
Configuring Enhanced SPF Routing Over a Tunnel
Router 1—IGP Enhanced SPF Consideration Configuration
Router 1—Route and Traffic Verification
mpls traffic-eng administrative-weight
mpls traffic-eng attribute-flags
mpls traffic-eng flooding thresholds
mpls traffic-eng link-management timers bandwidth-hold
mpls traffic-eng link-management timers periodic-flooding
mpls traffic-eng logging tunnel
mpls traffic-eng reoptimize events
mpls traffic-eng reoptimize timers frequency
mpls traffic-eng signaling advertise implicit-null
mpls traffic-eng tunnels (configuration)
mpls traffic-eng tunnels (interface)
show ip ospf database opaque-area
show isis mpls traffic-eng adjacency-log
show isis mpls traffic-eng advertisements
show isis mpls traffic-eng tunnel
show mpls traffic-eng autoroute
show mpls traffic-eng link-management admission-control
show mpls traffic-eng link-management advertisements
show mpls traffic-eng link-management bandwidth-allocation
show mpls traffic-eng link-management igp-neighbors
show mpls traffic-eng link-management interfaces
show mpls traffic-eng link-management summary
show mpls traffic-eng topology
show mpls traffic-eng topology path
show mpls traffic-eng tunnels summary
tunnel mpls traffic-eng affinity
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric
tunnel mpls traffic-eng bandwidth
tunnel mpls traffic-eng path-option
tunnel mpls traffic-eng priority
debug ip ospf mpls traffic-eng advertisements
debug isis mpls traffic-eng advertisements
debug isis mpls traffic-eng events
debug mpls traffic-eng autoroute
debug mpls traffic-eng link-management admission-control
debug mpls traffic-eng link-management advertisements
debug mpls traffic-eng link-management bandwidth-allocation
debug mpls traffic-eng link-management errors
debug mpls traffic-eng link-management events
debug mpls traffic-eng link-management igp-neighbors
debug mpls traffic-eng link-management links
debug mpls traffic-eng link-management preemption
debug mpls traffic-eng link-management routing
debug mpls traffic-eng load-balancing
debug mpls traffic-eng topology change
debug mpls traffic-eng topology lsa
debug mpls traffic-eng tunnels errors
debug mpls traffic-eng tunnels events
debug mpls traffic-eng tunnels labels
debug mpls traffic-eng tunnels reoptimize
debug mpls traffic-eng tunnels signalling
debug mpls traffic-eng tunnels state
debug mpls traffic-eng tunnels timers
MPLS Traffic Engineering and Enhancements
This feature module describes MPLS traffic engineering and enhancements for Release 12.1(3)T. The document includes the following sections:
•
Supported Standards, MIBs, and RFCs
Feature Overview
Multiprotocol Label Switching (MPLS) traffic engineering software enables an MPLS backbone to replicate and expand upon the traffic engineering capabilities of Layer 2 ATM and Frame Relay networks. MPLS is an integration of Layer 2 and Layer 3 technologies. By making traditional Layer 2 features available to Layer 3, MPLS enables traffic engineering. Thus, you can offer in a one-tier network what now can be achieved only by overlaying a Layer 3 network on a Layer 2 network.
Traffic engineering is essential for service provider and Internet service provider (ISP) backbones. Such backbones must support a high use of transmission capacity, and the networks must be very resilient so that they can withstand link or node failures.
MPLS traffic engineering provides an integrated approach to traffic engineering. With MPLS, traffic engineering capabilities are integrated into Layer 3, which optimizes the routing of IP traffic, given the constraints imposed by backbone capacity and topology.
MPLS traffic engineering
•
Enhances standard Interior Gateway Protocols (IGPs), such as IS-IS or OSPF, to automatically map packets onto the appropriate traffic flows.
•
Transports traffic flows across a network using MPLS forwarding.
•
Determines the routes for traffic flows across a network based on the resources the traffic flow requires and the resources available in the network.
•
Employs "constraint-based routing," in which the path for a traffic flow is the shortest path that meets the resource requirements (constraints) of the traffic flow. In MPLS traffic engineering, the traffic flow has bandwidth requirements, media requirements, a priority that is compared to the priority of other flows, and so forth.
•
Recovers from link or node failures by adapting to the new constraints presented by the changed topology.
•
Transports packets using MPLS forwarding crossing a multihop label-switched path (LSP).
•
Uses the routing and signaling capability of LSPs across a backbone topology that
–
Understands the backbone topology and available resources
–
Accounts for link bandwidth and for the size of the traffic flow when determining routes for LSPs across the backbone
–
Has a dynamic adaptation mechanism that enables the backbone to be resilient to failures, even if several primary paths are precalculated off-line
•
Includes enhancements to the IGP (IS-IS or OSPF) shortest path first (SPF) calculations to automatically calculate what traffic should be sent over what LSPs.
Why Use MPLS Traffic Engineering?
WAN connections are an expensive item in an ISP budget. Traffic engineering enables ISPs to route network traffic to offer the best service to their users in terms of throughput and delay. By making the service provider more efficient, traffic engineering reduces the cost of the network.
Currently, some ISPs base their services on an overlay model. In the overlay model, transmission facilities are managed by Layer 2 switching. The routers see only a fully meshed virtual topology, making most destinations appear one hop away. If you use the explicit Layer 2 transit layer, you can precisely control how traffic uses available bandwidth. However, the overlay model has numerous disadvantages. MPLS traffic engineering achieves the traffic engineering benefits of the overlay model without running a separate network, and without needing a nonscalable, full mesh of router interconnects.
How MPLS Traffic Engineering Works
MPLS traffic engineering automatically establishes and maintains LSPs across the backbone by using RSVP. The path that an LSP uses is determined by the LSP resource requirements and network resources, such as bandwidth.
Available resources are flooded by means of extensions to a link-state based IGP.
Traffic engineering tunnels are calculated at the LSP head based on a fit between required and available resources (constraint-based routing). The IGP automatically routes the traffic onto these LSPs. Typically, a packet crossing the MPLS traffic engineering backbone travels on a single LSP that connects the ingress point to the egress point.
MPLS traffic engineering is built on the following IOS mechanisms:
•
IP tunnel interfaces
From a Layer 2 standpoint, an MPLS tunnel interface represents the head of an LSP. It is configured with a set of resource requirements, such as bandwidth and media requirements, and priority.
From a Layer 3 standpoint, an LSP tunnel interface is the head-end of a unidirectional virtual link to the tunnel destination.
•
MPLS traffic engineering path calculation module
This calculation module operates at the LSP head. The module determines a path to use for an LSP. The path calculation uses a link-state database containing flooded topology and resource information.
•
RSVP with traffic engineering extensions
RSVP operates at each LSP hop and is used to signal and maintain LSPs based on the calculated path.
•
MPLS traffic engineering link management module
This module operates at each LSP hop, does link call admission on the RSVP signaling messages, and bookkeeping of topology and resource information to be flooded.
•
Link-state IGP (IS-IS or OSPF—each with traffic engineering extensions)
These IGPs are used to globally flood topology and resource information from the link management module.
•
Enhancements to the SPF calculation used by the link-state IGP (IS-IS or OSPF)
The IGP automatically routes traffic onto the appropriate LSP tunnel based on tunnel destination. Static routes can also be used to direct traffic onto LSP tunnels.
•
Label switching forwarding
This forwarding mechanism provides routers with a Layer 2-like ability to direct traffic across multiple hops of the LSP established by RSVP signaling.
One approach to engineering a backbone is to define a mesh of tunnels from every ingress device to every egress device. The MPLS traffic engineering path calculation and signaling modules determine the path taken by the LSPs for these tunnels, subject to resource availability and the dynamic state of the network. The IGP, operating at an ingress device, determines which traffic should go to which egress device, and steers that traffic into the tunnel from ingress to egress.
A flow from an ingress device to an egress device might be so large that it cannot fit over a single link, so it cannot be carried by a single tunnel. In this case, multiple tunnels between a given ingress and egress can be configured, and the flow is load-shared among them.
For more information about MPLS (previously referred to as Tag Switching), see the following Cisco documentation:
•
Cisco IOS Switching Services Configuration Guide, "Multiprotocol Label Switching" chapter
•
Cisco IOS Switching Services Command Reference, "Switching Commands Introduction" chapter
Mapping Traffic into Tunnels
This section describes how traffic is mapped into tunnels; that is, how conventional hop-by-hop link-state routing protocols interact with MPLS traffic engineering capabilities. In particular, this section describes how the shortest path first (SPF) algorithm, sometimes called a Dijkstra algorithm, has been enhanced so that a link-state IGP can automatically forward traffic over tunnels that MPLS traffic engineering establishes.
Link-state protocols, like integrated IS-IS or OSPF, use an SPF algorithm to compute a shortest path tree from the head-end node to all nodes in the network. Routing tables are derived from this shortest path tree. The routing tables contain ordered sets of destination and first-hop information. If a router does normal hop-by-hop routing, the first hop is over a physical interface attached to the router.
New traffic engineering algorithms calculate explicit routes to one or more nodes in the network. The originating router views these explicit routes as logical interfaces. In the context of this document, these explicit routes are represented by LSPs and referred to as traffic engineering tunnels (TE tunnels).
The following sections describe how link-state IGPs can use these shortcuts, and how they can install routes in the routing table that point to these TE tunnels. These tunnels use explicit routes, and the path taken by a TE tunnel is controlled by the router that is the head-end of the tunnel. In the absence of errors, TE tunnels are guaranteed not to loop, but routers must agree on how to use the TE tunnels. Otherwise, traffic might loop through two or more tunnels.
Enhancement to the SPF Computation
During each step of the SPF computation, a router discovers the path to one node in the network.
•
If that node is directly connected to the calculating router, the first-hop information is derived from the adjacency database.
•
If the node is not directly connected to the calculating router, the node inherits the first-hop information from the parent(s) of that node. Each node has one or more parents, and each node is the parent of zero or more downstream nodes.
For traffic engineering purposes, each router maintains a list of all TE tunnels that originate at this head-end router. For each of those TE tunnels, the router at the tail-end is known to the head-end router.
During the SPF computation, the TENT (tentative) list stores paths that are possibly the best paths and the PATH list stores paths that are definitely the best paths. When it is determined that a path is the best possible path, the node is moved from TENT to PATH. PATH is thus the set of nodes for which the best path from the computing router has been found. Each PATH entry consists of ID, path cost, and forwarding direction.
The router must determine the first-hop information. There are several ways to do this:
•
Examine the list of tail-end routers directly reachable by a TE tunnel. If there is a TE tunnel to this node, use the TE tunnel as the first hop.
•
If there is no TE tunnel and the node is directly connected, use the first-hop information from the adjacency database.
•
If the node is not directly connected and is not directly reachable by a TE tunnel, copy the first-hop information from the parent node(s) to the new node.
As a result of this computation, traffic to nodes that are the tail end of TE tunnels flows over the TE tunnels. Traffic to nodes that are downstream of the tail-end nodes also flows over the TE tunnels. If there is more than one TE tunnel to different intermediate nodes on the path to destination node X, traffic flows over the TE tunnel whose tail-end node is closest to node X.
Special Cases and Exceptions
The SPF algorithm finds equal-cost parallel paths to destinations. The enhancement previously described does not change this. Traffic can be forwarded over any of the following:
•
One or more native IP paths
•
One or more traffic engineering tunnels
•
A combination of native IP paths and traffic engineering tunnels
A special situation occurs in the topology shown in Figure 1.
Figure 1
Sample Topology of Parallel Native Paths and Paths Over TE Tunnels
If parallel native IP paths and paths over TE tunnels are available, the following implementations allow you to force traffic to flow over TE tunnels only or only over native IP paths. Assume that all links have the same cost and that a TE tunnel is set up from Router A to Router D.
•
When the SPF calculation puts Router C on the TENT list, it realizes that Router C is not directly connected. It uses the first-hop information from the parent, which is Router B.
•
When the SPF calculation on Router A puts Router D on the TENT list, it realizes that Router D is the tail end of a TE tunnel. Thus Router A installs a route to Router D by the TE tunnel, and not by Router B.
•
When Router A puts Router E on the TENT list, it realizes that Router E is not directly connected, and that Router E is not the tail end of a TE tunnel. Therefore Router A copies the first-hop information from the parents (Router C and Router D) to the first-hop information of Router E.
Traffic to Router E now load balances over
•
The native IP path by Router A to Router B to Router C
•
The TE tunnel Router A to Router D
Additional Enhancements to SPF Computation Using Configured Tunnel Metrics
When traffic engineering tunnels install an IGP route in a router information base (RIB) as next hops, the distance or metric of the route must be calculated. Normally, you could make the metric the same as the IGP metric over native IP paths as if the TE tunnels did not exist. For example, Router A can reach Router C with the shortest distance of 20. X is a route advertised in IGP by Router C. Route X is installed in Router A's RIB with the metric of 20. When a TE tunnel from Router A to Router C comes up, by default the route is installed with a metric of 20, but the next-hop information for X is changed.
Although the same metric scheme can work well in other situations, for some applications it is useful to change the TE tunnel metric (for instance, when there are equal cost paths through TE tunnel and native IP links). You can adjust TE tunnel metrics to force the traffic to prefer the TE tunnel, to prefer the native IP paths, or to load share among them.
Suppose that multiple TE tunnels go to the same destination or different destinations. TE tunnel metrics can force the traffic to prefer some TE tunnels over others, regardless of IGP distances to those destinations.
Setting metrics on TE tunnels does not affect the basic SPF algorithm. It affects only two questions:
1.
Is the TE tunnel installed as one of the next hops to the destination routers?
2.
What is the metric value of the routes being installed into the RIB?
You can modify the metrics for determining the first-hop information in one of the following ways:
•
If the metric of the TE tunnel to the tail-end routers is higher than the metric for the other TE tunnels or native hop-by-hop IGP paths, this tunnel is not installed as the next hop.
•
If the metric of the TE tunnel is equal to the metric of either other TE tunnels or native hop-by-hop IGP paths, this tunnel is added to the existing next hops.
•
If the metric of the TE tunnel is lower than the metric of other TE tunnels or native hop-by-hop IGP paths, this tunnel replaces them as the only next hop.
In each of the above cases, the IGP assigns metrics to routes associated with those tail-end routers and their downstream routers.
The SPF computation is loop free because the traffic through the TE tunnels is basically source routed. The end result of TE tunnel metric adjustment is the control of traffic loadsharing. If there is only one way to reach the destination through a single TE tunnel, then no matter what metric is assigned, the traffic has only one way to go.
You can represent the TE tunnel metric in two different ways: (1) as an absolute (or fixed) metric or (2) as a relative (or floating) metric.
If you use an absolute metric, the routes assigned with the metric are fixed. This metric is used not only for the routes sourced on the TE tunnel tail-end router, but also for each route downstream of this tail-end router that uses this TE tunnel as one of its next hops.
For example, if you have TE tunnels to two core routers in a remote point of presence (POP), and one of them has an absolute metric of 1, all traffic going to that POP traverses this low-metric TE tunnel.
If you use a relative metric, the actual assigned metric value of routes is based on the IGP metric. This relative metric can be positive or negative, and is bounded by minimum and maximum allowed metric values. For example, assume the topology shown in Figure 2.
Figure 2
Topology That Has No Traffic Engineering Tunnel
If there is no TE tunnel, Router A installs routes x, y, and z and assigns metrics 20, 30, and 40 respectively. Suppose that Router A has a TE tunnel T1 to Router C. If the relative metric -5 is used on tunnel T1, the routers x, y, and z have the installed metrics of 15, 25, and 35. If an absolute metric of 5 is used on tunnel T1, routes x, y and z have the same metric 5 installed in the RIB for Router A. The assigning of no metric on the TE tunnel is a special case, a relative metric scheme where the metric is 0.
Transitioning an IS-IS Network to a New Technology
A new flavor of IS-IS includes extensions for MPLS traffic engineering and for other purposes. Running MPLS traffic engineering over IS-IS or taking advantage of these other extensions requires transitioning an IS-IS network to this new technology. This section describes these extensions and discusses two ways to migrate an existing IS-IS network from the standard ISO 10589 protocol towards this new flavor of IS-IS.
Note
Running MPLS traffic engineering over an existing IS-IS network requires a transition to a new flavor of IS-IS. However, running MPLS traffic engineering over OSPF does not require any similar network transition.
New Extensions for the IS-IS Routing Protocol
New extensions for the IS-IS routing protocol serve the following purposes:
•
Remove the 6-bit limit on link metrics.
•
Allow interarea IP routes.
•
Enable IS-IS to carry different kinds of information for traffic engineering. In the future, more extensions might be needed.
To serve these purposes, two new TLVs (type, length, and value objects) have been defined:
•
TLV 22 describes links (or rather adjacencies). It serves the same purpose as the "IS neighbor option" in ISO 10589 (TLV 2).
•
TLV 135 describes reachable IP prefixes. It is similar to the IP Neighbor options from RFC 1195 (TLVs 128 and 130).
Note
For the purpose of briefness, these two new TLVs, 22 and 135, are referred to as "new-style TLVs." TLVs 2, 128, and 130 are referred to as "old-style TLVs."
Both new TLVs have a fixed length part, followed by optional sub-TLVs. The metric space in these new TLVs has been enhanced from 6 bits to 24 or 32 bits. The sub-TLVs allow you to add new properties to links and prefixes. Traffic engineering is the first technology to use this ability to add new properties to a link.
The Problem in Theory
Link-state routing protocols compute loop-free routes. This is guaranteed because all routers calculate their routing tables based on the same information from the link-state database (LSPDB).
There is a problem when some routers look at old-style TLVs and some routers look at new-style TLVs because the routers can base their SPF calculations on different information. This can cause routing loops.
The Problem in Practice
The easiest way to migrate from old-style TLVs towards new-style TLVs would be to introduce a "flag day." A flag day means that you reconfigure all routers during a short period of time, during which service is interrupted. If the implementation of a flag day is not acceptable, a network administrator needs to find a viable solution for modern existing networks.
Network administrators have the following problems related to TLVs:
•
They need to run an IS-IS network where some routers are advertising and using the new-style TLVs and, at the same time, other routers are capable only of advertising and using old-style TLVs.
•
They need to test new traffic engineering software in existing networks on a limited number of routers. They cannot upgrade all their routers in their production networks or in their test networks before they start testing.
The new extensions allow a network administrator to use old-style TLVs in one area, and new-style TLVs in another area. However, this is not a solution for administrators who need or want to run their network in one single area.
The following sections describe two solutions to the network administrator's problems.
First Solution for Transitioning an IS-IS Network to a New Technology
When you migrate from old-style TLVs towards new-style TLVs, you can advertise the same information twice—once in old-style TLVs and once in new-style TLVs. This ensures that all routers can understand what is advertised.
There are three disadvantages to using that approach:
•
Size of the LSPs—During the transition, the LSPs grow to about twice their original size. This might be a problem in networks where the LSPDB is large. An LSPDB might be large because
–
There are many routers, and thus LSPs.
–
There are many neighbors or IP prefixes per router. A router that advertises lots of information causes the LSPs to be fragmented.
•
Unpredictable results—In a large network, this solution can produce unpredictable results. A large network in transition pushes the limits regarding LSP flooding and SPF scaling. During the transition
–
You can expect some extra network instability. At this time, you especially do not want to test how far you can push an implementation.
–
Traffic engineering extensions might cause LSPs to be reflooded frequently.
•
Ambiguity—If a router encounters different information in the old-style TLVs and the new-style TLVs, it may not be clear what the router should do.
These problems can be largely solved easily by using
•
All information in old-style and new-style TLVs in an LSP
•
The adjacency with the lowest link metric if an adjacency is advertised more than once
The main benefit to advertising the same information twice is that network administrators can use new-style TLVs before all routers in the network can understand them.
Transition Actions During the First Solution
When transitioning from using IS-IS with old-style TLVs to new-style TLVs, you can perform the following actions:
•
If all routers run old software, advertise and use only old-style TLVs.
•
Upgrade some routers to newer software.
•
Configure some routers with new software to advertise both old-style and new-style TLVs. They accept both styles of TLVs. Configure other routers (with old software) to continue advertising and using only old-style TLVs.
•
Test traffic engineering in parts of your network; however, new-style TLVs cannot be used yet.
•
If the whole network needs to migrate, upgrade and configure all remaining routers to advertise and accept both styles of TLVs.
•
Configure all routers to advertise and accept only new-style TLVs.
•
Configure metrics larger than 63.
For more information about how to perform these actions, see "TLV Configuration Commands."
Second Solution for Transitioning an IS-IS Network to a New Technology
Routers advertise only one style of TLVs at the same time, but can understand both types of TLVs during migration. There are two main benefits to this approach:
•
LSPs stay approximately the same size during migration.
•
There is no ambiguity when the same information is advertised twice inside one LSP.
This method is useful when you are transitioning the whole network (or a whole area) to use wider metrics (that is, you want a router running IS-IS to generate and accept only new-style TLVs). For more information, see the metric-style wide command.
The disadvantage is that all routers must understand the new-style TLVs before any router can start advertising new-style TLVs. It does not help the second problem, where network administrators want to use the new-style TLVs for traffic engineering, while some routers are capable of understanding only old-style TLVs.
Transition Actions During the Second Solution
If you use the second solution, you can perform the following actions:
•
If all routers run old software, advertise and use only old-style TLVs.
•
Upgrade all routers to newer software.
•
Configure all routers one-by-one to advertise old-style TLVs, but to accept both styles of TLVs.
•
Configure all routers one-by-one to advertise new-style TLVs, but to accept both styles of TLVs.
•
Configure all routers one-by-one to advertise and to accept only new-style TLVs.
•
Configure metrics larger than 63.
TLV Configuration Commands
Cisco IOS has a new router isis command line interface (CLI) subcommand called metric-style. Once you are in the router IS-IS subcommand mode, you have the option to choose the following:
•
Metric-style narrow—Enables the router to generate and accept only old-style TLVs
•
Metric-style transition—Enables the router to generate and accept both old-style and new-style TLVs
•
Metric-style wide—Enables the router to generate and accept only new-style TLVs
For more information about the commands, see the "Command Reference" section in this document.
You can use either of two transition schemes when you are using the metric-style commands:
•
Narrow to transition to wide
•
Narrow to narrow transition to wide transition to wide
Implementation in IOS
IOS implements both transition solutions. Network administrators can choose the solution that suits them best. For test networks, the first solution is ideal (go to "First Solution for Transitioning an IS-IS Network to a New Technology"). For a real transition, both solutions can be used. The first solution requires fewer steps and less configuration. Only the largest networks that do not want to risk doubling their LSPDB during transition need to use the second solution (go to "Second Solution for Transitioning an IS-IS Network to a New Technology").
Benefits
MPLS traffic engineering has the following benefits:
•
Higher return on network backbone infrastructure investment. The best route between a pair of POPs is determined, taking into account the constraints of the backbone network and the total traffic load on the backbone.
•
Reduction in operating costs. Costs are reduced because numerous important processes are automated, including setup, configuration, mapping, and selection of MPLS traffic engineered (MPLS TE) tunnels across a Cisco 12000 series backbone.
Restrictions
The following restrictions apply to MPLS traffic engineering:
•
MPLS traffic engineering currently supports only a single IS-IS level or OSPF area.
•
Currently, MPLS traffic engineering does not support ATM MPLS-controlled subinterfaces.
•
The MPLS traffic engineering feature does not support routing and signaling of LSPs over unnumbered IP links. Therefore, do not configure the feature over those links.
Related Features and Technologies
The MPLS traffic engineering feature is related to the IS-IS, OSPF, RSVP, and MPLS features (formerly referred to as Tag Switching). These features are presented in Cisco product documentation (see the sections on "Related Documents" and "How MPLS Traffic Engineering Works").
Related Documents
•
Cisco IOS IP and IP Routing Configuration Guide, "Configuring Integrated IS-IS" chapter
•
Cisco IOS IP and IP Routing Command Reference, "Integrated IS-IS Commands" chapter
•
Cisco IOS IP and IP Routing Configuration Guide, "Configuring OSPF" chapter
•
Cisco IOS IP and IP Routing Command Reference, "OSPF Commands" chapter
•
Cisco IOS Quality of Service Solutions Command Reference, "RSVP Commands" chapter
•
Cisco IOS Switching Services Configuration Guide, "Multiprotocol Label Switching" chapter
•
Cisco IOS Switching Services Command Reference, "Switching Commands Introduction" chapter
Supported Platforms
•
Cisco 7200 Series
•
Cisco 7500 Series
•
Cisco 12000 Series
Supported Standards, MIBs, and RFCs
Standards
None.
MIBs
There are no MIBs supported by this feature.
RFCs
•
RFC 2205, Resource ReSerVation Protocol (RSVP)
•
RFC 1142, IS-IS
•
RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
•
RFC 2328, OSPF Version 2
•
RFC 2370, The OSPF Opaque LSA Option
Prerequisites
Your network must support the following Cisco IOS features before you enable MPLS traffic engineering:
•
Multiprotocol Label Switching
•
IP Cisco Express Forwarding (CEF)
•
Intermediate System-to-Intermediate System (IS-IS) or Open Shortest Path First (OSPF)
Configuration Tasks
Perform the following tasks before you enable MPLS traffic engineering:
•
Turn on MPLS tunnels
•
Turn on Cisco Express Forwarding (CEF)
•
Turn on IS-IS or OSPF
Perform the following tasks to configure MPLS traffic engineering:
•
Configuring a Device to Support Tunnels
•
Configuring an Interface to Support RSVP-Based Tunnel Signaling and IGP Flooding
•
Configuring IS-IS for MPLS Traffic Engineering
•
Configuring OSPF for MPLS Traffic Engineering
•
Configuring an MPLS Traffic Engineering Tunnel
•
Configuring an MPLS Traffic Engineering Tunnel that an IGP Can Use
Configuring a Device to Support Tunnels
To configure a device to support tunnels, perform the following steps in configuration mode.
Configuring an Interface to Support RSVP-Based Tunnel Signaling and IGP Flooding
To configure an interface to support RSVP-based tunnel signaling and IGP flooding, perform these steps in interface configuration mode:
Note
You must enable the tunnel feature on interfaces that you want to support MPLS traffic engineering.
Configuring IS-IS for MPLS Traffic Engineering
To configure IS-IS for MPLS traffic engineering, perform the steps described below. For a description of the IS-IS commands (excluding the IS-IS traffic engineering commands), see the Cisco IOS IP and IP Routing Command Reference.
Configuring OSPF for MPLS Traffic Engineering
To configure OSPF for MPLS traffic engineering, perform the steps described below. For a description of the OSPF commands (excluding the OSPF traffic engineering commands), see the Cisco IOS IP and IP Routing Command Reference.
Configuring an MPLS Traffic Engineering Tunnel
To configure an MPLS traffic engineering tunnel, perform these steps in interface configuration mode. This tunnel has two path setup options: a preferred explicit path and a backup dynamic path.
Configuring an MPLS Traffic Engineering Tunnel that an IGP Can Use
To configure an MPLS traffic engineering tunnel that an IGP can use, perform these steps in interface configuration mode. This tunnel has two path setup options: a preferred explicit path and a backup dynamic path.
Configuration Examples
This section provides the following configuration examples:
•
Configuring MPLS Traffic Engineering Using IS-IS
•
Configuring MPLS Traffic Engineering Using OSPF
•
Configuring an MPLS Traffic Engineering Tunnel
•
Configuring Enhanced SPF Routing Over a Tunnel
Figure 3 illustrates a sample MPLS topology. This example specifies point-to-point outgoing interfaces. The next sections contain sample configuration commands you enter to implement MPLS traffic engineering and the basic tunnel configuration shown in Figure 3.
Figure 3 Sample MPLS Traffic Engineering Tunnel Configuration
Configuring MPLS Traffic Engineering Using IS-IS
This example lists the commands you enter to configure MPLS traffic engineering with IS-IS routing enabled
(see Figure 3).
Note
You must enter the following commands on every router in the traffic-engineered portion of your network.
Router 1—MPLS Traffic Engineering Configuration
To configure MPLS traffic engineering, enter the following commands:
ip cefmpls traffic-eng tunnelsinterface loopback 0ip address 11.11.11.11 255.255.255.255ip router isisinterface s1/0ip address 131.0.0.1 255.255.0.0ip router isismpls traffic-eng tunnelsip rsvp bandwidth 1000Router 1—IS-IS Configuration
To enable IS-IS routing, enter the following commands:
router isisnetwork 47.0000.0011.0011.00is-type level-1metric-style widempls traffic-eng router-id loopback0mpls traffic-eng level-1Configuring MPLS Traffic Engineering Using OSPF
This example lists the commands you enter to configure MPLS traffic engineering with OSPF routing enabled (see Figure 3).
Note
You must enter the following commands on every router in the traffic-engineered portion of your network.
Router 1—MPLS Traffic Engineering Configuration
To configure MPLS traffic engineering, enter the following commands:
ip cefmpls traffic-eng tunnelsinterface loopback 0ip address 11.11.11.11 255.255.255.255interface s1/0ip address 131.0.0.1 255.255.0.0mpls traffic-eng tunnelsip rsvp bandwidth 1000Router 1—OSPF Configuration
To enable OSPF, enter the following commands:
router ospf 0network 131.0.0.0.0.0.255.255 area 0mpls traffic-eng router-id Loopback0mpls traffic-eng area 0Configuring an MPLS Traffic Engineering Tunnel
This example shows you how to configure a dynamic path tunnel and an explicit path in the tunnel. Before you configure MPLS traffic engineering tunnels, you must enter the appropriate global and interface commands on the specified router (in this case, Router 1).
Router 1—Dynamic Path Tunnel Configuration
In this section, a tunnel is configured to use a dynamic path.
interface tunnel1ip unnumbered loopback 0tunnel destination 17.17.17.17tunnel mode mpls traffic-engtunnel mpls traffic-eng bandwidth 100tunnel mpls traffic-eng priority 1 1tunnel mpls traffic-eng path-option 1 dynamicRouter 1—Dynamic Path Tunnel Verification
This section includes the commands you use to verify that the tunnel is up.
show mpls traffic-eng tunnelsshow ip interface tunnel1Router 1—Explicit Path Configuration
In this section, an explicit path is configured.
ip explicit-path identifier 1next-address 131.0.0.1next-address 135.0.0.1next-address 136.0.0.1next-address 133.0.0.1Router 1—Explicit Path Tunnel Configuration
In this section, a tunnel is configured to use an explicit path.
interface tunnel2ip unnumbered loopback 0tunnel destination 17.17.17.17tunnel mode mpls traffic-engtunnel mpls traffic-eng bandwidth 100tunnel mpls traffic-eng priority 1 1tunnel mpls traffic-eng path-option 1 explicit identifier 1Router 1—Explicit Path Tunnel Verification
This section includes the commands you use to verify that the tunnel is up.
show mpls traffic-eng tunnelsshow ip interface tunnel2Configuring Enhanced SPF Routing Over a Tunnel
This section includes the commands that cause the tunnel to be considered by the IGP's enhanced SPF calculation, which installs routes over the tunnel for appropriate network prefixes.
Router 1—IGP Enhanced SPF Consideration Configuration
In this section, you specify that the IGP should use the tunnel (if the tunnel is up) in its enhanced shortest path first (SPF) calculation.
interface tunnel1tunnel mpls traffic-eng autoroute announceRouter 1—Route and Traffic Verification
This section includes the commands you use to verify that the tunnel is up and that the traffic is routed through the tunnel.
show traffic-eng tunnels tunnel1 briefshow ip route 17.17.17.17show mpls traffic-eng autorouteping 17.17.17.17show interface tunnel1 accountingshow interface s1/0 accountingCommand Reference
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.
•
list
•
mpls traffic-eng administrative-weight
•
mpls traffic-eng attribute-flags
•
mpls traffic-eng flooding thresholds
•
mpls traffic-eng link-management timers bandwidth-hold
•
mpls traffic-eng link-management timers periodic-flooding
•
mpls traffic-eng logging tunnel
•
mpls traffic-eng reoptimize events
•
mpls traffic-eng reoptimize timers frequency
•
mpls traffic-eng signaling advertise implicit-null
•
mpls traffic-eng tunnels (configuration)
•
mpls traffic-eng tunnels (interface)
•
show ip ospf database opaque-area
•
show ip ospf mpls traffic-eng
•
show isis mpls traffic-eng adjacency-log
•
show isis mpls traffic-eng advertisements
•
show isis mpls traffic-eng tunnel
•
show mpls traffic-eng autoroute
•
show mpls traffic-eng link-management admission-control
•
show mpls traffic-eng link-management advertisements
•
show mpls traffic-eng link-management bandwidth-allocation
•
show mpls traffic-eng link-management igp-neighbors
•
show mpls traffic-eng link-management interfaces
•
show mpls traffic-eng link-management summary
•
show mpls traffic-eng topology
•
show mpls traffic-eng topology path
•
show mpls traffic-eng tunnels
•
show mpls traffic-eng tunnels summary
•
tunnel mpls traffic-eng affinity
•
tunnel mpls traffic-eng autoroute announce
•
tunnel mpls traffic-eng autoroute metric
•
tunnel mpls traffic-eng bandwidth
•
tunnel mpls traffic-eng path-option
•
tunnel mpls traffic-eng priority
In Cisco IOS Release 12.0(1)T or later, you can search and filter the output for show and more commands. This functionality is useful when you need to sort through large amounts of output, or if you want to exclude output that you do not need to see.
To use this functionality, enter a show or more command followed by the "pipe" character (|), one of the keywords begin, include, or exclude, and an expression that you want to search or filter on:
command | {begin | include | exclude} regular-expression
Following is an example of the show atm vc command in which you want the command output to begin with the first line where the expression "PeakRate" appears:
show atm vc | begin PeakRate
For more information on the search and filter functionality, refer to the Cisco IOS Release 12.0(1)T feature module titled CLI String Search.
append-after
To insert a path entry after a specified index number, use the append-after IP explicit path subcommand.
append-after index command
Syntax Description
Defaults
No default behavior or values.
Command Modes
IP explicit path subcommand
Command History
Examples
In the following example, the next-address subcommand is inserted after index 5:
Router(config-ip-expl-path)# append-after 5 next-address 3.3.27.3Related Commands
index
To insert or modify a path entry at a specific index, use the index ip explicit path subcommand. Use the no form of this command to disable this feature.
index index command
no index index
Syntax Description
Defaults
No default behavior or values.
Command Modes
IP explicit path subcommand
Command History
Examples
In the following example, the next-address command is inserted at index 6:
Router(cfg-ip-expl-path)# index 6 next-address 3.3.29.3Explicit Path identifier 6:6: next-address 3.3.29.3Related Commands
ip explicit-path
To enter the subcommand mode for Internet Protocol (IP) explicit paths and create or modify the specified path, use the ip explicit-path configuration command. An IP explicit path is a list of IP addresses, each representing a node or link in the explicit path. Use the no form of this command to disable this feature.
ip explicit-path { name word | identifier number } [ {enable | disable } ]
no explicit-path { name word | identifier number }
Syntax Description
Command Modes
Configuration
Command History
Examples
In the following example, the explicit path subcommand mode for IP explicit paths is entered and a path with the number 500 is created:
Router(config)# ip explicit-path identifier 500Router(config-ip-expl-path)#Related Commands
list
To show all or part of the explicit path or paths, use the list ip explicit path subcommand.
list [{ starting index number }]
Syntax Description
starting index number
Index number at which the explicit path(s) will start to be displayed. Valid values are from 1 to 65535.
Defaults
No default behavior or values.
Command Modes
IP explicit path subcommand
Command History
Examples
The following example shows the explicit path starting at index number 2:
Router(cfg-ip-expl-path)# listExplicit Path name Joe:1:next-address 10.0.0.12:next-address 10.0.0.2Router(cfg-ip-expl-path)# list 2Explicit Path name Joe:2:next-address 10.0.0.2Router(cfg-ip-expl-path)#Related Commands
metric-style narrow
To configure a router running IS-IS so that it generates and accepts old-style type, length, and value objects (TLVs), use the metric-style narrow router configuration command. Use the no form of this command to disable this feature.
metric-style narrow [ transition ] [ { level-1 | level-2 | level-1-2 } ]
no metric-style narrow [ transition ] [ { level-1 | level-2 | level-1-2 } ]
Syntax Description
Defaults
The MPLS traffic engineering image generates only old-style TLVs. To do MPLS traffic engineering, a router must generate new-style TLVs that have wider metric fields.
Command Modes
Router configuration
Command History
Examples
In the following example, the router is instructed to generate and accept old-style TLVs on router level 1:
Router(config-router)# metric-style narrow level-1Related Commands
Command DescriptionConfigures a router to generate both old-style and new-style TLVs.
Configures a router to generate and accept only new-style TLVs.
metric-style transition
To configure a router running IS-IS so that it generates and accepts both old-style and new-style type, length, and value objects (TLVs), use the metric-style transition router configuration command. Use the no form of this command to disable this feature.
metric-style transition [ { level-1 | level-2 | level-1-2 } ]
no metric-style transition [ { level-1 | level-2 | level-1-2 } ]
Syntax Description
level-1
Enables this command on routing level 1.
level-2
Enables this command on routing level 2.
level-1-2
Enables this command on routing levels 1 and 2.
Defaults
The MPLS traffic engineering image generates only old-style TLVs. To do MPLS traffic engineering, a router must generate new-style TLVs that have wider metric fields.
Command Modes
Router configuration
Command History
Examples
In the following example, a router is configured to generate and accept both old-style and new-style TLVs on router level 2:
Router(config-router)# metric-style transition level-2Related Commands
Command DescriptionConfigures a router to generate and accept old-style TLVs.
Configures a router to generate and accept only new-style TLVs.
metric-style wide
To configure a router running IS-IS so that it generates and accepts only new-style type, length, and value objects (TLVs), use the metric-style wide router configuration command. Use the no form of this command to disable this feature.
metric-style wide [ transition ] [ { level-1 | level-2 | level-1-2 } ]
no metric-style wide [ transition ] [ { level-1 | level-2 | level-1-2 } ]
Syntax Description
Defaults
The MPLS traffic engineering image generates only old-style TLVs. To do MPLS traffic engineering, a router must generate new-style TLVs that have wider metric fields.
Command Modes
Router configuration
Command History
Usage Guidelines
If you enter the metric-style wide command, a router generates and accepts only new-style TLVs. Therefore, the router uses less memory and other resources than it would if it generated 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 could be appropriate if the new-style TLVs are desired for other reasons. For example, a network might require wider metrics, but might not use traffic engineering.
Examples
In the following example, a router is configured to generate and accept only new-style TLVs on level 1:
Router(config-router)# metric-style wide level-1Related Commands
Command DescriptionConfigures a router to generate and accept old-style TLVs.
Configures a router to generate and accept both old-style and new-style TLVs.
mpls traffic-eng
To configure a router running IS-IS so that is floods MPLS traffic engineering link information into the indicated IS-IS level, use the mpls traffic-eng router configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng { level-1 | level-2 }
no mpls traffic-eng { level-1 | level-2 }
Syntax Description
level-1
Floods MPLS traffic engineering link information into IS-IS level 1.
level-2
Floods MPLS traffic engineering link information into IS-IS level 2.
Defaults
Flooding is disabled.
Command Modes
Router configuration
Command History
Usage Guidelines
This command, which is part of the routing protocol tree, causes link resource information (such as available bandwidth) for appropriately configured links to be flooded in the IS-IS link state database.
Examples
In the following example, MPLS traffic engineering is turned on for IS-IS level 1:
Router(config-router)# mpls traffic-eng level-1Related Commands
Command DescriptionSpecifies that the traffic engineering router identifier for the node is the IP address associated with a given interface.
mpls traffic-eng administrative-weight
To override the Interior Gateway Protocol (IGP) administrative weight (cost) of the link, use the mpls traffic-eng administrative-weight interface configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng administrative-weight weight
no mpls traffic-eng administrative-weight
Syntax Description
Defaults
IGP cost of the link.
Command Modes
Interface configuration
Command History
Examples
In the following example, the IGP cost of the link is overridden, and the cost is set to 20:
Router(config-if)# mpls traffic-eng administrative-weight 20Related Commands
mpls traffic-eng area
To configure a router running Open Shortest Path First (OSPF) MPLS so that it floods traffic engineering for the indicated OSPF area, use the mpls traffic-eng area router configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng area num
no mpls traffic-eng area num
Syntax Description
Defaults
No default behavior or values.
Command Modes
Router configuration
Command History
Usage Guidelines
This command is in the routing protocol configuration tree and is supported for both OSPF and IS-IS. The command affects the operation of MPLS traffic engineering only if MPLS traffic engineering is enabled for that routing protocol instance. Currently, only a single level can be enabled for traffic engineering.
Examples
In the following example, a router running OSPF MPLS is configured to flood traffic engineering for OSPF 0:
Router(config-router)# mpls traffic-eng area 0Related Commands
mpls traffic-eng attribute-flags
To set the user-specified attribute flags for the interface, use the mpls traffic-eng attribute-flags interface configuration command. The interface is flooded globally so that it can be used as a tunnel head-end path selection criterion. Use the no form of this command to disable this feature.
mpls traffic-eng attribute-flags attributes
no mpls traffic-eng attribute-flags
Syntax Description
Defaults
0x0.
Command Modes
Interface configuration
Command History
Usage Guidelines
This command assigns attributes to a link so that tunnels with matching attributes (represented by their affinity bits) prefer this link instead of others that do not match.
Examples
In the following example, the attribute flags are set to 0x0101:
Router(config-if)# mpls traffic-eng attribute-flags 0x0101Related Commands
mpls traffic-eng flooding thresholds
To set a link's reserved bandwidth thresholds, use the mpls traffic-eng flooding thresholds interface configuration command. Use the no form of this command to return to the default settings.
mpls traffic-eng flooding thresholds { down | up } percent [ percent ...]
no mpls traffic-eng flooding thresholds { down | up }
Syntax Description
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.
Command Modes
Interface configuration
Command History
Usage Guidelines
When a threshold is crossed, MPLS traffic engineering link management advertises updated link information. If no thresholds are crossed, changes can be flooded periodically unless periodic flooding was disabled.
Examples
In the following example, the link's reserved bandwidth is set for decreased resource availability (down) and for increased resource availability (up) thresholds:
Router(config-if)# mpls traffic-eng flooding thresholds down 100 75 25Router(config-if)# mpls traffic-eng flooding thresholds up 25 50 100Related Commands
mpls traffic-eng link-management timers bandwidth-hold
To set the length of time that bandwidth is held for an RSVP Path (setup) message while you wait for the corresponding RSVP Resv message to come back, use the mpls traffic-eng link-management timers bandwidth-hold configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng link-management timers bandwidth-hold hold-time
no mpls traffic-eng link-management timers bandwidth-hold
Syntax Description
Defaults
15 seconds.
Command Modes
Configuration
Command History
Examples
In the following example, bandwidth is set to be held for 10 seconds:
Router(config)# mpls traffic-eng link-management timers bandwidth-hold 10Related Commands
mpls traffic-eng link-management timers periodic-flooding
To set the length of the interval for periodic flooding, use the mpls traffic-eng link-management timers periodic-flooding configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng link-management timers periodic-flooding interval
no mpls traffic-eng link-management timers periodic-flooding
Syntax Description
interval
Length of the interval, in seconds, for periodic flooding. Valid values are from 0 to 3600. A value of 0 turns off periodic flooding. If you set this value from 1 to 29, it is treated as 30.
Defaults
180 seconds (3 minutes).
Command Modes
Configuration
Command History
Usage Guidelines
Use this command to set the interval for periodic flooding of TE topology information.
Changes in the MPLS TE topology database are flooded by the link state Interior Gateway Protocol (IGP). Some changes, such as those to link status (up/down) or configured parameters, trigger immediate flooding. Other changes are considered less urgent and are flooded periodically. For example, changes to the amount of link bandwidth allocated to TE tunnels are flooded periodically unless the change causes the bandwidth to cross a configurable threshold.
Examples
In the following example, the interval length for periodic flooding is set to 120 seconds:
Router(config)# mpls traffic-eng link-management timers periodic-flooding 120Related Commands
mpls traffic-eng logging lsp
To log certain traffic engineering label-switched path (LSP) events, use the mpls traffic-eng logging lsp router configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng logging lsp { path-errors | reservation-errors | preemption | setups | teardowns } [ aclnum ]
no mpls traffic-eng logging lsp { path-errors | reservation-errors | preemption | setups | teardowns } [ aclnum ]
Syntax Description
Defaults
Logging of LSP events is disabled.
Command Modes
Router configuration
Command History
Examples
In the following example, path errors are logged for LSPs that match access list 3:
Router(config)# mpls traffic-eng logging lsp path-errors 3Related Commands
mpls traffic-eng logging tunnel
To log certain traffic engineering tunnel events, use the mpls traffic-eng logging tunnel router configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng logging tunnel lsp-selection [ aclnum ]
no mpls traffic-eng logging tunnel lsp-selection [ aclnum ]
Syntax Description
Defaults
Logging of tunnel events is disabled.
Command Modes
Router configuration
Command History
Examples
In the following example, traffic engineering tunnel events associated with access list 3 are logged:
Router(config)# mpls traffic-eng logging tunnel lsp-selection 3Related Commands
mpls traffic-eng reoptimize
To force immediate reoptimization of all traffic engineering tunnels, use the mpls traffic-eng reoptimize EXEC command.
mpls traffic-eng reoptimize
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
In the following example, all traffic engineering tunnels are immediately reoptimized:
Router2# mpls traffic-eng reoptimizempls traffic-eng reoptimize events
To turn on automatic reoptimization of MPLS traffic engineering when certain events occur, such as when 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
Defaults
Event-based reoptimization is disabled.
Command Modes
Router configuration
Command History
Examples
In the following example, automatic reoptimization is turned on whenever an interface becomes operational:
Router(config)# mpls traffic-eng reoptimize events link-upRelated Commands
Command Descriptionmpls traffic-eng reoptimize (EXEC mode)
Reoptimizes all traffic engineering tunnels immediately.
Controls the frequency with which tunnels with established LSPs are checked for better LSPs.
mpls traffic-eng reoptimize timers frequency
To control the frequency with which tunnels with established label-switched paths (LSPs) are checked for better LSPs, use the mpls traffic-eng reoptimize timers frequency configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng reoptimize timers frequency seconds
no mpls traffic-eng reoptimize timers frequency
Syntax Description
Defaults
3600 seconds (1 hour), with a range of 0 to 604800 seconds (1 week).
Command Modes
Configuration
Command History
Usage Guidelines
A device with traffic engineering tunnels periodically 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; if the signaling is successful, the device replaces the old, inferior LSP with the new, better LSP.
Examples
In the following example, the reoptimization frequency is set to 1 day:
Router(config)# mpls traffic-eng reoptimize timers frequency 86400Related Commands
Command DescriptionIf lockdown is specified, does not do a reoptimization check on this tunnel.
mpls traffic-eng reoptimize (EXEC mode)
Reoptimizes all traffic engineering tunnels immediately.
mpls traffic-eng router-id
To specify that the traffic engineering router identifier for the node is the IP address associated with a given interface, use the mpls traffic-eng router-id router configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng router-id interface-name
no traffic-eng router-id
Syntax Description
Defaults
No default behavior or values.
Command Modes
Router configuration
Command History
Usage Guidelines
This router's identifier acts as a stable IP address for the traffic engineering configuration. This IP address is flooded to all nodes. For all traffic engineering tunnels originating at other nodes and ending at this node, you must set the tunnel destination to the destination node's traffic engineering router identifier, because that is the address that the traffic engineering topology database at the tunnel head uses for its path calculation.
Examples
In the following example, the traffic engineering router identifier is specified as the IP address associated with interface Loopback0:
Router(config-router)# mpls traffic-eng router-id Loopback0Related Commands
Command DescriptionTurns on flooding of MPLS traffic engineering link information in the indicated IGP level/area.
mpls traffic-eng signaling advertise implicit-null
To use MPLS encoding for the implicit-null label in signaling messages sent to neighbors that match the specified access list, use the mpls traffic-eng signalling advertise implicit-null configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng signalling advertise implicit-null [ aclname | aclnum ]
no mpls traffic-eng signalling advertise implicit-null
Syntax Description
Defaults
Use the Cisco encoding for the implicit-null label in signaling messages.
Command Modes
Configuration
Command History
Examples
In the following example, the router is configured to use MPLS encoding for the implicit-null label when it sends signaling messages to certain peers:
Router(config)# mpls traffic-eng signalling advertise implicit-nullmpls traffic-eng tunnels (configuration)
To enable MPLS traffic engineering tunnel signaling on a device, use the mpls traffic-eng tunnels configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng tunnels
no mpls traffic-eng tunnels
Syntax Description
This command has no arguments or keywords.
Defaults
The feature is disabled.
Command Modes
Configuration
Command History
Usage Guidelines
This command enables MPLS traffic engineering on a device. For you to use the feature, MPLS traffic engineering must also be enabled on the desired interfaces.
Examples
In the following example, MPLS traffic engineering tunnel signaling is turned on:
Router(config)# mpls traffic-eng tunnelsRelated Commands
mpls traffic-eng tunnels (interface)
To enable MPLS traffic engineering tunnel signaling on an interface (assuming that it is enabled on the device), use the mpls traffic-eng tunnels interface configuration command. Use the no form of this command to disable this feature.
mpls traffic-eng tunnels
no mpls traffic-eng tunnels
Syntax Description
This command has no arguments or keywords.
Defaults
The feature is disabled on all interfaces.
Command Modes
Interface configuration
Command History
Usage Guidelines
To enable MPLS traffic engineering on the interface, MPLS traffic engineering must also be enabled on the device. An enabled interface has its resource information flooded into the appropriate IGP link state database and accepts traffic engineering tunnel signaling requests.
Examples
In the following example, MPLS traffic engineering is enabled on interface Ethernet0/0:
Router(config)# interface Ethernet0/0Router(config-if)# mpls traffic-eng tunnelsRelated Commands
next-address
To specify the next IP address in the explicit path, use the next-address IP explicit path configuration subcommand. Use the no form of this command to disable this feature.
next-address A.B.C.D
no next-address A.B.C.D
Syntax Description
Defaults
No default behavior or values.
Command Modes
IP explicit path configuration
Command History
Examples
In the following example, the number 60 is assigned to the IP explicit path, the path is enabled, and 3.3.27.3 is specified as the next IP address in the list of IP addresses:
Router(config)# ip explicit-path identifier 60 enableRouter(cfg-ip-expl-path)# next-address 3.3.27.3Explicit Path identifier 60:1: next-address 3.3.27.3Router(cfg-ip-exp1-path)#Related Commands
show ip explicit-paths
To display the configured IP explicit paths, use the show ip explicit-paths EXEC command. An IP explicit path is a list of IP addresses, each representing a node or link in the explicit path.
show ip explicit-paths [ { name word | identifier number } ] [ detail ]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show ip explicit-paths command:
Router# show ip explicit-pathsPATH 200 (strict source route, path complete, generation 6)1: next-address 3.3.28.32: next-address 3.3.27.3Table 1 describes the fields displayed in this example.
Related Commands
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
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show ip ospf database opaque-area command:
Router# show ip ospf database opaque-areaOSPF Router with ID (25.3.3.3) (Process ID 1)Type-10 Opaque Link Area Link States (Area 0)LS age: 12Options: (No TOS-capability, DC)LS Type: Opaque Area LinkLink State ID: 1.0.0.0Opaque Type: 1Opaque ID: 0Advertising Router: 24.8.8.8LS Seq Number: 80000004Checksum: 0xD423Length: 132Fragment number : 0MPLS TE router ID: 24.8.8.8Link connected to Point-to-Point networkLink ID : 26.2.2.2Interface Address : 198.1.1.1Table 2 describes the fields displayed in this example.
Related Commands
show ip ospf mpls traffic-eng
To display information about the links available on the local router for traffic engineering, use the show ip ospf mpls traffic-eng EXEC command.
show ip ospf [ process-id [ area-id ] ] mpls traffic-eng [ link ] | [ fragment ]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show ip ospf mpls traffic-eng command:
router# show ip ospf mpls traffic-eng linkOSPF Router with ID (23.0.0.1) (Process ID 1)Area 0 has 2 MPLS TE links. Area instance is 14.Links in hash bucket 8.Link is associated with fragment 1. Link instance is 14Link connected to Point-to-Point networkLink ID :197.0.0.1Interface Address :66.0.0.1Neighbor Address :66.0.0.2Admin Metric :97Maximum bandwidth :128000Maximum reservable bandwidth :250000Number of Priority :8Priority 0 :250000 Priority 1 :250000Priority 2 :250000 Priority 3 :250000Priority 4 :250000 Priority 5 :250000Priority 6 :250000 Priority 7 :212500Affinity Bit :0x0Link is associated with fragment 0. Link instance is 14Link connected to Broadcast networkLink ID :195.1.1.2Interface Address :195.1.1.1Neighbor Address :195.1.1.2Admin Metric :10Maximum bandwidth :1250000Maximum reservable bandwidth :2500000Number of Priority :8Priority 0 :2500000 Priority 1 :2500000Priority 2 :2500000 Priority 3 :2500000Priority 4 :2500000 Priority 5 :2500000Priority 6 :2500000 Priority 7 :2500000Affinity Bit :0x0Table 3 describes the fields displayed in this example.
show ip rsvp host
To display RSVP terminal point information for receivers or senders, use the show ip rsvp host EXEC command.
show ip rsvp host { senders | receivers} [ hostname | A.B.C.D ]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show ip rsvp host receivers command:
Router# show ip rsvp host receiversTo From Pro DPort Sport Next Hop I/F Fi Serv BPS Bytes10.0.0.11 10.1.0.4 0 10011 1 SE LOAD 100K 1KTable 4 describes the fields displayed in this example.
Related Commands
show isis database verbose
To display more information about the database, use the show isis database verbose EXEC command.
show isis database verbose
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show isis database verbose command:
Router# show isis database verboseIS-IS Level-1 Link State DatabaseLSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OLdtp-5.00-00 * 0x000000E6 0xC9BB 1042 0/0/0Area Address:49.0001NLPID: 0xCCHostname:dtp-5Router ID: 5.5.5.5IP Address: 172.21.39.5Metric:10 IP 172.21.39.0/24dtp-5.00-01 * 0x000000E7 0xAB36 1065 0/0/0Metric:10 IS-Extended dtp-5.01Affinity:0x00000000Interface IP Address:172.21.39.5Physical BW:10000000 bits/secReservable BW:1166000 bits/secBW Unreserved[0]: 1166000 bits/sec, BW Unreserved[1]: 1166000 bits/secBW Unreserved[2]: 1166000 bits/sec, BW Unreserved[3]: 1166000 bits/secBW Unreserved[4]: 1166000 bits/sec, BW Unreserved[5]: 1166000 bits/secBW Unreserved[6]: 1166000 bits/sec, BW Unreserved[7]: 1153000 bits/secMetric:0 ES dtp-5Table 5 describes the fields displayed in this example.
Related Commands
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 EXEC command.
show isis mpls traffic-eng adjacency-log
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show isis mpls traffic-eng adjacency-log command:
Router# show isis mpls traffic-eng adjacency-logIS-IS RRR logWhen Neighbor ID IP Address Interface Status Level04:52:52 0000.0024.0004.02 0.0.0.0 Et0/2 Up level-104:52:50 0000.0026.0001.00 170.1.1.2 PO1/0/0 Up level-104:52:37 0000.0024.0004.02 0.0.0.0 Et0/2 Up level-1Table 6 describes the fields displayed in this example.
Related Commands
show isis mpls traffic-eng advertisements
To display the last flooded record from MPLS traffic engineering, use the show isis mpls traffic-eng advertisements EXEC command.
show isis mpls traffic-eng advertisements
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show isis mpls traffic-eng advertisements command:
Router# show isis mpls traffic-eng advertisementsSystem ID:dtp-5.00Router ID:5.5.5.5Link Count:1Link[1]Neighbor System ID:dtp-5.01 (broadcast link)Interface IP address:172.21.39.5Neighbor IP Address:0.0.0.0Admin. Weight:10Physical BW:10000000 bits/secReservable BW:1166000 bits/secBW unreserved[0]:1166000 bits/sec, BW unreserved[1]:1166000 bits/secBW unreserved[2]:1166000 bits/sec, BW unreserved[3]:1166000 bits/secBW unreserved[4]:1166000 bits/sec, BW unreserved[5]:1166000 bits/secBW unreserved[6]:1166000 bits/sec, BW unreserved[7]:1153000 bits/secAffinity Bits:0x00000000Table 7 describes the fields displayed in this example.
Related Commands
Command DescriptionDisplays a log of 20 entries of MPLS traffic engineering IS-IS adjacency changes.
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 EXEC command.
show isis mpls traffic-eng tunnel
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
EXEC
Command History
Examples
The following is sample output from the show isis mpls traffic-eng tunnel command:
Router# show isis mpls traffic-eng tunnelStation Id Tunnel Name Bandwidth Nexthop Metric Modekangpa-router1.00 Tunnel1022 3333 2.2.2.2 -3 RelativeTunnel1021 10000 2.2.2.2 11 Absolutetomklong-route.00 Tunnel1031 10000 3.3.3.3 -1 RelativeTunnel1032 10000 3.3.3.3Table 8 describes the fields displayed in this example.
Related Commands
Command DescriptionShows tunnels that are announced to IGP, including interface, destination, and bandwidth.
show mpls traffic-eng autoroute
To show tunnels that are announced to the Interior Gateway Protocol (IGP), including interface, destination, and bandwidth, use the show mpls traffic-eng autoroute EXEC command.
show mpls traffic-eng autoroute
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
The enhanced shortest path first (SPF) calculation of the IGP has been modified so that it uses traffic engineering tunnels. This command shows which tunnels IGP is currently using in its enhanced SPF calculation (that is, which tunnels are up and have autoroute configured).
Examples
The following is sample output from the show mpls traffic-eng autoroute command.
Note that the tunnels are organized by destination. All tunnels to a destination carry a share of the traffic tunneled to that destination.
Router# show mpls traffic-eng autorouteMPLS TE autorouting enableddestination 0002.0002.0002.00 has 2 tunnelsTunnel1021 (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 tunnelsTunnel1032 (traffic share 10000, nexthop 3.3.3.3)Tunnel1031 (traffic share 10000, nexthop 3.3.3.3, relative metric -1)Table 9 describes the fields displayed in this example.
Related Commands
show mpls traffic-eng link-management admission-control
To show which tunnels were 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 EXEC command.
show mpls traffic-eng link-management admission-control [ interface-name]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show mpls traffic-eng link-management admission-control command:
Router2# show mpls traffic-eng link-management admission-controlSystem Information::Tunnels Count: 4Tunnels Selected: 4TUNNEL ID UP IF DOWN IF PRIORITY STATE BW (kbps)10.106.0.6 1000_1 AT1/0.2 - 0/0 Resv Admitted 010.106.0.6 2000_1 Et4/0/1 - 1/1 Resv Admitted 010.106.0.6 1_2 Et4/0/1 Et4/0/2 1/1 Resv Admitted 3000 R10.106.0.6 2_2 AT1/0.2 AT0/0.2 1/1 Resv Admitted 3000 RTable 10 describes the fields displayed in this example.
Related Commands
show mpls traffic-eng link-management advertisements
To show local link information that MPLS traffic engineering link management is currently flooding into the global traffic engineering topology, use the show mpls traffic-eng link-management advertisements EXEC command.
show mpls traffic-eng link-management advertisements
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show mpls traffic-eng link-management advertisements command:
Router1# show mpls traffic-eng link-management advertisementsFlooding Status: readyConfigured Areas: 1IGP Area[1] ID:: isis level-1System Information::Flooding Protocol: ISISHeader Information::IGP System ID: 0001.0000.0001.00MPLS TE Router ID: 10.106.0.6Flooded Links: 1Link ID:: 0Link IP Address: 10.1.0.6IGP Neighbor: ID 0001.0000.0001.02Admin. Weight: 10Physical Bandwidth: 10000 kbits/secMax Reservable BW: 5000 kbits/secDownstream::Reservable Bandwidth[0]: 5000 kbits/secReservable Bandwidth[1]: 2000 kbits/secReservable Bandwidth[2]: 2000 kbits/secReservable Bandwidth[3]: 2000 kbits/secReservable Bandwidth[4]: 2000 kbits/secReservable Bandwidth[5]: 2000 kbits/secReservable Bandwidth[6]: 2000 kbits/secReservable Bandwidth[7]: 2000 kbits/secAttribute Flags: 0x00000000Table 11 describes the fields displayed in this example.
Related Commands
Command DescriptionShows current local link information.
Shows IGP neighbors.
Shows per-interface resource and configuration information.
Shows a summary of link management information.
show mpls traffic-eng link-management bandwidth-allocation
To show current local link information, use the show mpls traffic-eng link-management bandwidth-allocation EXEC command.
show mpls traffic-eng link-management bandwidth-allocation [ interface-name ]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
Advertised information might differ from the current information, depending on how flooding was configured.
Examples
The following is sample output from the show mpls traffic-eng link-management bandwidth-allocation command:
Router1# show mpls traffic-eng link-management bandwidth-allocation Et4/0/1System Information::Links Count: 2Bandwidth Hold Time: max. 15 secondsLink ID:: Et4/0/1 (10.1.0.6)Link Status:Physical Bandwidth: 10000 kbits/secMax Reservable BW: 5000 kbits/sec (reserved:0% in, 60% out)BW Descriptors: 1MPLS TE Link State: MPLS TE on, RSVP on, admin-up, floodedInbound Admission: reject-hugeOutbound Admission: allow-if-roomAdmin. Weight: 10 (IGP)IGP Neighbor Count: 1Up 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)Downstream Bandwidth Information (kbits/sec):KEEP PRIORITY BW HELD BW TOTAL HELD BW LOCKED BW TOTAL LOCKED0 0 0 0 01 0 0 3000 30002 0 0 0 30003 0 0 0 30004 0 0 0 30005 0 0 0 30006 0 0 0 30007 0 0 0 3000Table 12 describes the fields displayed in this example.
Related Commands
show mpls traffic-eng link-management igp-neighbors
To show Interior Gateway Protocol (IGP) neighbors, use the show mpls traffic-eng link-management igp-neighbors EXEC command.
show mpls traffic-eng link-management igp-neighbors [{ igp-id { isis isis-address |
ospf ospf-id } | ip A.B.C.D }]Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show mpls traffic-eng link-management igp-neighbors command:
Router# show mpls traffic-eng line-management igp-neighborsLink ID:: Et0/2Neighbor ID: 0000.0024.0004.02 (area: isis level-1, IP: 0.0.0.0)Link ID:: PO1/0/0Neighbor ID: 0000.0026.0001.00 (area: isis level-1, IP: 170.1.1.2)Table 13 describes the fields displayed in this example.
Related Commands
show mpls traffic-eng link-management interfaces
To show interface resource and configuration information, use the show mpls traffic-eng link-management interfaces EXEC command.
show mpls traffic-eng link-management interfaces [ interface-name ]
Syntax Description
Defaults
Displays resource and configuration information for all configured interfaces.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show mpls traffic-eng link-management interfaces command:
Router1# show mpls traffic-eng link-management interfaces Et4/0/1System Information::Links Count: 2Link ID:: Et4/0/1 (10.1.0.6)Link Status:Physical Bandwidth: 10000 kbits/secMax Reservable BW: 5000 kbits/sec (reserved:0% in, 60% out)MPLS TE Link State: MPLS TE on, RSVP on, admin-up, floodedInbound Admission: reject-hugeOutbound Admission: allow-if-roomAdmin. Weight: 10 (IGP)IGP Neighbor Count: 1IGP Neighbor: ID 0001.0000.0001.02, IP 0.0.0.0 (Up)Flooding Status for each configured area [1]:IGP Area[1]: isis level-1: floodedTable 14 describes the fields displayed in this example.
Related Commands
show mpls traffic-eng link-management summary
To show a summary of link management information, use the show mpls traffic-eng link-management summary EXEC command.
show mpls traffic-eng link-management summary [ interface-name ]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show mpls traffic-eng link-management summary command:
Router1# show mpls traffic-eng link-management summarySystem Information::Links Count: 2Flooding System: enabledIGP Area ID:: isis level-1Flooding Protocol: ISISFlooding Status: data floodedPeriodic Flooding: enabled (every 180 seconds)Flooded Links: 1IGP System ID: 0001.0000.0001.00MPLS TE Router ID: 10.106.0.6IGP Neighbors: 1Link ID:: Et4/0/1 (10.1.0.6)Link Status:Physical Bandwidth: 10000 kbits/secMax Reservable BW: 5000 kbits/sec (reserved:0% in, 60% out)MPLS TE Link State: MPLS TE on, RSVP on, admin-up, floodedInbound Admission: reject-hugeOutbound Admission: allow-if-roomAdmin. Weight: 10 (IGP)IGP Neighbor Count: 1Link ID:: AT0/0.2 (10.42.0.6)Link Status:Physical Bandwidth: 155520 kbits/secMax Reservable BW: 5000 kbits/sec (reserved:0% in, 0% out)MPLS TE Link State: MPLS TE on, RSVP onInbound Admission: allow-allOutbound Admission: allow-if-roomAdmin. Weight: 10 (IGP)IGP Neighbor Count: 0Table 15 describes the fields displayed in this example.
Related Commands
show mpls traffic-eng topology
To show the MPLS traffic engineering global topology currently known at this node, use the show mpls traffic-eng topology EXEC command.
show mpls traffic-eng topology [ { A.B.C.D | igp-id { isis nsapaddr | ospf A.B.C.D } ] [ brief ]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show mpls traffic-eng topology command:
Router1# show mpls traffic-eng topology 10.106.0.6IGP Id:0001.0000.0001.00, MPLS TE Id:10.106.0.6 Router Node id 1link[0 ]:Nbr IGP Id:0001.0000.0001.02, nbr_node_id:3, gen:14frag_id 0, Intf Address:10.1.0.6admin_weight:10, attribute_flags:0x0physical_bw:10000 (kbps), max_reservable_bw:5000 (kbps)allocated_bw reservable_bw allocated_bw reservable_bw------------ ------------- ------------ -------------bw[0]:0 5000 bw[1]:3000 2000bw[2]:0 2000 bw[3]:0 2000bw[4]:0 2000 bw[5]:0 2000bw[6]:0 2000 bw[7]:0 2000Table 16 describes the fields displayed in this example.
Related Commands
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 ] ]Syntax Description
Defaults
The specified constraints override any constraints obtained from a reference tunnel.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show mpls traffic-eng topology path command:
Router1# show mpls traffic-eng topology path Tunnel1 bandwidth 1000Query Parameters:Destination:10.112.0.12Bandwidth:1000Priorities: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.12Router1#Table 17 describes the fields displayed in this example.
show mpls traffic-eng tunnels
To show information about tunnels, use the show mpls traffic-eng tunnels EXEC command.
show mpls traffic-eng tunnels tunnel_interface [ brief ]
show mpls traffic-eng tunnels
[ destination address ]
[ source-id {num | ipaddress | ipaddress num } ]
[ role {all | head | middle | tail | remote } ]
[ { up | down } ]
[ name string ]
[ suboptimal constraints {none | current | max } ]
[ { [ interface in phys_intf ] [ interface out phys_intf ] | [interface phys_intf ]} ]
[ brief ]Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show mpls traffic-eng tunnels brief command:
Router1# show mpls traffic-eng tunnels briefSignalling Summary:LSP Tunnels Process: runningRSVP Process: runningForwarding: enabledPeriodic reoptimization: every 3600 seconds, next in 1706 secondsTUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROTRouter1_t1 10.112.0.12 - Et4/0/1 up/uptagsw-r11_t2 10.112.0.12 - unknown up/downtagsw-r11_t3 10.112.0.12 - unknown admin-downtagsw-r11_t1000 10.110.0.10 - unknown up/downtagsw-r11_t2000 10.110.0.10 - Et4/0/1 up/upDisplayed 5 (of 5) heads, 0 (of 0) midpoints, 0 (of 0) tailsTable 18 describes the fields displayed in this example.
Related Commands
show mpls traffic-eng tunnels summary
To show summary information about tunnels, use the show mpls traffic-eng tunnels summary EXEC command.
show mpls traffic-eng tunnels summary
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show mpls traffic-eng tunnels summary command:
Router# show mpls traffic-eng tunnels summarySignalling Summary:LSP Tunnels Process: runningRSVP Process: runningForwarding: enabledHead: 1 interfaces, 1 active signalling attempts, 1 established1 activations, 0 deactivationsMidpoints: 0, Tails: 0Periodic reoptimization: every 3600 seconds, next in 3436 secondsTable 19 describes the fields displayed in this example.
Related Commands
tunnel mode mpls traffic-eng
To set the mode of a tunnel to MPLS for traffic engineering, use the tunnel mode mpls traffic-eng interface configuration command. Use the no form of this command to disable this feature.
tunnel mode mpls traffic-eng
no tunnel mode mpls traffic-eng
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Interface configuration
Command History
Usage Guidelines
This command specifies that the tunnel interface is for an MPLS traffic engineering tunnel and enables the various tunnel MPLS configuration options.
Examples
In the following example, the tunnel's mode is set to MPLS traffic engineering:
Router(config-if)# tunnel mode mpls traffic-engRelated Commands
tunnel mpls traffic-eng affinity
To configure an affinity (the properties the tunnel requires in its links) for an MPLS traffic engineering tunnel, use the tunnel mpls traffic-eng affinity interface configuration command. Use the no form of this command to disable this feature.
tunnel mpls traffic-eng affinity properties [ mask mask value ]
no tunnel mpls traffic-eng affinity properties [ mask mask value ]
Syntax Description
Defaults
properties: 0X00000000
mask value: 0X0000FFFFCommand Modes
Interface configuration
Command History
Usage Guidelines
The affinity determines the attributes of the links that this tunnel will use (that is, the attributes for which the tunnel has an affinity). The attribute mask determines which link attribute the router should check. If a bit in the mask is 0, a link's attribute value or that bit is irrelevant. If a bit in the mask is 1, the link's attribute value and the tunnel's required affinity for that bit must match.
A tunnel can use a link if the tunnel affinity equals the link attributes and the tunnel affinity mask.
Any properties set to 1 in the affinity should also be 1 in the mask. In other words, affinity and mask should be set such that
tunnel_affinity = (tunnel_affinity and tunnel_affinity_mask)
Examples
In the following example, the tunnel's affinity is set:
Router(config-if)# tunnel mpls traffic-eng affinity 0x0101 mask 0x303Related Commands
Command DescriptionSets the attributes for the interface.
Sets the mode of a tunnel to MPLS for traffic engineering.
tunnel mpls traffic-eng autoroute announce
To specify that the IGP should use the tunnel (if the tunnel is up) in its enhanced shortest path first (SPF) calculation, use the tunnel mpls traffic-eng autoroute announce interface configuration command. Use the no form of this command to disable this feature.
tunnel mpls traffic-eng autoroute announce
no tunnel mpls traffic-eng autoroute announce
Syntax Description
This command has no arguments or keywords.
Defaults
The IGP does not use the tunnel in its enhanced SPF calculation.
Command Modes
Interface configuration
Command History
Usage Guidelines
Currently, the only way to forward traffic onto a tunnel is by enabling this feature or by explicitly configuring forwarding (for example, with an interface static route).
Examples
In the following example, the instruction is given that if this tunnel is up, the IGP should use the tunnel in its enhanced SPF calculation:
Router(config-if)# tunnel mpls traffic-eng autoroute announceIn the following example, the instruction is given that if the IGP is using this tunnel in its enhanced SPF calculation, the IGP should give it an absolute metric of 10:
Router(config-if)# tunnel mpls traffic-eng autoroute metric absolute 10In the following example, the tunnel requires 100 Kbps per second of bandwidth:
Router(config-if)# tunnel mpls traffic-eng bandwidth 100Related Commands
Command Descriptionip route
Establishes static routes.
Sets the mode of a tunnel to MPLS for traffic engineering.
tunnel mpls traffic-eng autoroute metric
To specify the MPLS traffic engineering tunnel metric that the IGP enhanced SPF calculation uses, use the tunnel mpls traffic-eng autoroute metric interface configuration command. Use the no form of this command to disable this feature.
tunnel mpls traffic-eng autoroute metric { absolute | relative } value
no tunnel mpls traffic-eng autoroute metric
Syntax Description
Defaults
The default is metric relative 0.
Command Modes
Interface configuration
Command History
Examples
The following example designates that the IGP enhanced SPF calculation will use MPLS traffic engineering tunnel metric negative 1:
Router(config-if)# tunnel mpls traffic-eng autoroute metric relative -1Related Commands
Command DescriptionShows the tunnels announced to IGP, including interface, destination, and bandwidth.
Instructs the IGP to use the tunnel (if it is up) in its enhanced SPF calculation.
tunnel mpls traffic-eng bandwidth
To configure the bandwidth required for an MPLS traffic engineering tunnel, use the tunnel mpls traffic-eng bandwidth interface configuration command. Use the no form of this command to disable this feature.
tunnel mpls traffic-eng bandwidth bandwidth
no tunnel mpls traffic-eng bandwidth bandwidth
Syntax Description
bandwidth
The bandwidth required for an MPLS traffic engineering tunnel. Bandwidth is specified in kilobits per second.
Defaults
Default bandwidth is 0.
Command Modes
Interface configuration
Command History
Examples
In the following example, the bandwidth required for an MPLS traffic engineering tunnel is 1000:
Router(config-if)# tunnel mpls traffic-eng bandwidth 1000 1XwnRelated Commands
tunnel mpls traffic-eng path-option
To configure a path option for an MPLS traffic engineering tunnel, use the tunnel mpls traffic-eng path-option interface configuration command. Use the no form of this command to disable this feature.
tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name |
path-number }} [ lockdown ]no tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name |
path-number }} [ lockdown ]Syntax Description
Defaults
No default behavior or values.
Command Modes
Interface configuration
Command History
Usage Guidelines
You can configure multiple path options for a single tunnel. For example, there can be several explicit path options and a dynamic option for one tunnel. Path setup preference is for lower (not higher) numbers, so option 1 is preferred.
Examples
In the following example, the tunnel is configured to use a named IP explicit path:
Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit name testRelated Commands
tunnel mpls traffic-eng priority
To configure the setup and reservation priority for an MPLS traffic engineering tunnel, use the tunnel mpls traffic-eng priority interface configuration command. Use the no form of this command to disable this feature.
tunnel mpls traffic-eng priority setup-priority [ hold-priority ]
no tunnel traffic-eng priority setup-priority [ hold-priority ]
Syntax Description
Defaults
setup-priority: 7
hold-priority: The same value as the setup priorityCommand Modes
Interface configuration
Command History
Usage Guidelines
When an LSP is being signaled and an interface does not currently have enough bandwidth available for that LSP, the call admission software preempts lower-priority LSPs so that the new LSP can be admitted. (LSPs are preempted if that allows the new LSP to be admitted.)
In the above determination, the new LSP's priority is its setup priority and the existing LSP's priority is its hold priority. The two priorities make it possible to signal an LSP with a low setup priority (so that the LSP does not preempt other LSPs on setup) but a high hold priority (so that the LSP is not preempted after it is established).
Setup priority and hold priority are typically configured to be equal, and setup priority cannot be better (numerically smaller) than the hold priority.
Examples
In the following example, a tunnel is configured with a setup and hold priority of 1.
Router(config-if)# tunnel mpls traffic-eng priority 1Related Commands
Debug Commands
This section documents new or modified debug commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.
•
debug ip ospf mpls traffic-eng advertisements
•
debug isis mpls traffic-eng advertisements
•
debug isis mpls traffic-eng events
•
debug mpls traffic-eng autoroute
•
debug mpls traffic-eng link-management admission-control
•
debug mpls traffic-eng link-management advertisements
•
debug mpls traffic-eng link-management bandwidth-allocation
•
debug mpls traffic-eng link-management errors
•
debug mpls traffic-eng link-management events
•
debug mpls traffic-eng link-management igp-neighbors
•
debug mpls traffic-eng link-management links
•
debug mpls traffic-eng link-management preemption
•
debug mpls traffic-eng link-management routing
•
debug mpls traffic-eng load-balancing
•
debug mpls traffic-eng topology change
•
debug mpls traffic-eng topology lsa
•
debug mpls traffic-eng tunnels errors
•
debug mpls traffic-eng tunnels events
•
debug mpls traffic-eng tunnels labels
•
debug mpls traffic-eng tunnels reoptimize
•
debug mpls traffic-eng tunnels signalling
•
debug mpls traffic-eng tunnels state
•
debug mpls traffic-eng tunnels timers
debug ip ospf mpls traffic-eng advertisements
To print information about traffic engineering advertisements in OSPF Link State Advertisement (LSA) messages, use the debug ip ospf mpls traffic-eng advertisements privileged EXEC command. To disable debugging output, use the no form of this command.
[ no ] debug ip ospf mpls traffic-eng advertisements
Syntax Description
This command has no arguments or keywords
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
In the following example, information about traffic engineering advertisements is printed in OSPF LSA messages:
debug ip ospf mpls traffic-eng advertisementsOSPF:IGP delete router node 10.106.0.6 fragment 0 with 0 linksTE Router ID 10.106.0.6OSPF:IGP update router node 10.110.0.10 fragment 0 with 0 linksTE Router ID 10.110.0.10OSPF:MPLS announce router node 10.106.0.6 fragment 0 with 1 linksLink connected to Point-to-Point networkLink ID :10.110.0.10Interface Address :10.1.0.6Neighbor Address :10.1.0.10Admin Metric :10Maximum bandwidth :1250000Maximum reservable bandwidth :625000Number of Priority :8Priority 0 :625000 Priority 1 :625000Priority 2 :625000 Priority 3 :625000Priority 4 :625000 Priority 5 :625000Priority 6 :625000 Priority 7 :625000Affinity Bit :0x0Table 20 describes the fields displayed in this example.
debug isis mpls traffic-eng advertisements
To print information about traffic engineering advertisements in ISIS Link State Advertisement (LSA) messages, use the debug isis mpls traffic-eng advertisements EXEC command. To disable debugging output, use the no form of this command.
[ no ] debug isis mpls traffic-eng advertisements
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
In the following example, information about traffic engineering advertisements is printed in ISIS LSA messages:
debug isis mpls traffic-eng advertisementsSystem ID:Router1.00Router ID:10.106.0.6Link Count:1Link[1]Neighbor System ID:Router2.00 (P2P link)Interface IP address:10.42.0.6Neighbor IP Address:10.42.0.10Admin. Weight:10Physical BW:155520000 bits/secReservable BW:5000000 bits/secBW unreserved[0]:2000000 bits/sec, BW unreserved[1]:100000 bits/secBW unreserved[2]:100000 bits/sec, BW unreserved[3]:100000 bits/secBW unreserved[4]:100000 bits/sec, BW unreserved[5]:100000 bits/secBW unreserved[6]:100000 bits/sec, BW unreserved[7]:0 bits/secAffinity Bits:0x00000000Table 21 describes the fields displayed in this example.
debug isis mpls traffic-eng events
To print information about traffic engineering-related ISIS events, use the debug isis mpls traffic-eng events privileged EXEC command. To disable debugging output, use the no form of this command.
[ no ] debug isis mpls traffic-eng events
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
In the following example, information is printed about traffic engineering-related ISIS events:
debug isis mpls traffic-eng eventsISIS-RRR:Send MPLS TE Et4/0/1 Router1.02 adjacency down:address 0.0.0.0ISIS-RRR:Found interface address 10.1.0.6 Router1.02, building subtlv... 58 bytesISIS-RRR:Found interface address 10.42.0.6 Router2.00, building subtlv... 64 bytesISIS-RRR:Interface address 0.0.0.0 Router1.00 not found, not building subtlvISIS-RRR:LSP Router1.02 changed from 0x606BCD30ISIS-RRR:Mark LSP Router1.02 changed because TLV contents different, code 16ISIS-RRR:Received 1 MPLS TE links flood info for system id Router1.00debug mpls traffic-eng areas
To print information about traffic engineering area configuration change events, use the debug mpls traffic-eng areas privileged EXEC command. To disable debugging output, use the no form of this command.
[ no ] debug mpls traffic-eng areas
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
In the following example, information is printed about traffic engineering area configuration change events:
debug mpls traffic-eng areasTE-AREAS:isis level-1:up eventTE-PCALC_LSA:isis level-1debug mpls traffic-eng autoroute
To print information about automatic routing over traffic engineering tunnels, use the debug mpls traffic-eng autoroute privileged EXEC command. To disable debugging output, use the no form of this command.
[ no ] debug mpls traffic-eng autoroute
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
In the following example, information is printed about automatic routing over traffic engineering tunnels:
debug mpls traffic-eng autorouteTE-Auto:announcement that destination 0001.0000.0003.00 has 1 tunnelsTunnel1 (traffic share 333, nexthop 10.112.0.12)debug mpls traffic-eng link-management admission-control
To print information about traffic engineering LSP admission control on traffic engineering interfaces, use the debug mpls traffic-eng link-management admission-control privileged EXEC command. To disable debugging output, use the no form of this command.
debug mpls traffic-eng link-management admission-control [ detail ] [ aclnum ]
no debug mpls traffic-eng link-management admission-control [ detail ]
Syntax Description
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Release Modification12.05(S)
This command was introduced.
12.1(3)T
The detail keyword and the aclnum option were added.
Examples
In the following example, information is printed about traffic engineering LSP admission control on traffic engineering interfaces:
debug mpls traffic-eng link-management admission-controlTE-LM-ADMIT:tunnel 10.106.0.6 1_10002:created [total 4]TE-LM-ADMIT:tunnel 10.106.0.6 1_10002: "None" -> "New"TE-LM-ADMIT:tunnel 10.106.0.6 1_10002: "New" -> "Admitting 2nd Path Leg"TE-LM-ADMIT:tunnel 10.106.0.6 1_10002: "Admitting 2nd Path Leg" -> "Path Admitted"TE-LM-ADMIT:Admission control has granted Path query for 10.106.0.6 1_10002 (10.112.0.12) on link Ethernet4/0/1 [reason 0]TE-LM-ADMIT:tunnel 10.106.0.6 1_10002: "Path Admitted" -> "Admitting 1st Resv Leg"TE-LM-ADMIT:tunnel 10.106.0.6 1_10002: "Admitting 1st Resv Leg" -> "Resv Admitted"TE-LM-ADMIT:Admission control has granted Resv query for 10.106.0.6 1_10002 (10.112.0.12) on link Ethernet4/0/1 [reason 0]debug mpls traffic-eng link-management advertisements
To print information about resource advertisements for traffic engineering interfaces, use the debug mpls traffic-eng link-management advertisements privileged EXEC command. To disable debugging output, use the no form of this command.
[ no ] debug mpls traffic-eng link-management advertisements [ detail ] [ aclnum ]
Syntax Description
detail
(Optional) Prints detailed debugging information.
aclnum
(Optional) Uses the specified access list to filter the debugging information.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
In the following example, detailed debugging information is printed about resource advertisements for traffic engineering interfaces:
debug mpls traffic-eng link-management advertisements detailTE-LM-ADV:area isis level-1:IGP announcement:link Et4/0/1:info changedTE-LM-ADV:area isis level-1:IGP msg:link Et4/0/1:includes subnet type (2), described nbrs (1)TE-LM-ADV:area isis level-1:IGP announcement:link Et4/0/1:info changedTE-LM-ADV:area isis level-1:IGP msg:link Et4/0/1:includes subnet type (2), described nbrs (1)TE-LM-ADV:LSA:Flooding manager received message:link information change (Et4/0/1)TE-LM-ADV:area isis level-1:*** Flooding node information ***System Information::Flooding Protocol: ISISHeader Information::IGP System ID: 0001.0000.0001.00MPLS TE Router ID: 10.106.0.6Flooded Links: 1Link ID:: 0Link IP Address: 10.1.0.6IGP Neighbor: ID 0001.0000.0001.02Admin. Weight: 10Physical Bandwidth: 10000 kbits/secMax Reservable BW: 5000 kbits/secDownstream::Reservable Bandwidth[0]: 5000 kbits/secReservable Bandwidth[1]: 2000 kbits/secReservable Bandwidth[2]: 2000 kbits/secReservable Bandwidth[3]: 2000 kbits/secReservable Bandwidth[4]: 2000 kbits/secReservable Bandwidth[5]: 2000 kbits/secReservable Bandwidth[6]: 2000 kbits/secAttribute Flags: 0x00000000Table 22 describes the fields displayed in this example.
debug mpls traffic-eng link-management bandwidth-allocation
To print detailed information about bandwidth allocation for traffic engineering LSPs, use the debug mpls traffic-eng link-management bandwidth-allocation privileged EXEC command. To disable debugging output, use the no form of this command.
[ no ] debug mpls traffic-eng link-management bandwidth-allocation [ detail ] [ aclnum ]
Syntax Description
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Release Modification12.05(S)
This command was introduced.
12.1(3)T
The detail keyword and the aclnum option were added.
Examples
In the following example, information is printed about bandwidth allocation for traffic engineering LSPs:
debug mpls traffic-eng link-management bandwidth-allocation
TE-LM-BW:tunnel 10.106.0.6 1_10002:requesting Downstream bw hold (3000000 bps [S]) on link Et4/0/1TE-LM-BW:tunnel 10.106.0.6 1_10002:Downstream bw hold request succeededTE-LM-BW:tunnel 10.106.0.6 1_10002:requesting Downstream bw lock (3000000 bps [S]) on link Et4/0/1TE-LM-BW:tunne




