Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

Cisco IOS Software Releases 12.1 T

MPLS Traffic Engineering and Enhancements

Downloads

Table Of Contents

MPLS Traffic Engineering and Enhancements

Feature Overview

Why Use MPLS Traffic Engineering?

How MPLS Traffic Engineering Works

Mapping Traffic into Tunnels

Enhancement to the SPF Computation

Special Cases and Exceptions

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

The Problem in Theory

The Problem in Practice

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

TLV Configuration Commands

Implementation in IOS

Benefits

Restrictions

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites

Configuration Tasks

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

Configuration Examples

Configuring MPLS Traffic Engineering Using IS-IS

Router 1—MPLS Traffic Engineering Configuration

Router 1—IS-IS Configuration

Configuring MPLS Traffic Engineering Using OSPF

Router 1—MPLS Traffic Engineering Configuration

Router 1—OSPF 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

Command Reference

append-after

index

ip explicit-path

list

metric-style narrow

metric-style transition

metric-style wide

mpls traffic-eng

mpls traffic-eng administrative-weight

mpls traffic-eng area

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 lsp

mpls traffic-eng logging tunnel

mpls traffic-eng reoptimize

mpls traffic-eng reoptimize events

mpls traffic-eng reoptimize timers frequency

mpls traffic-eng router-id

mpls traffic-eng signaling advertise implicit-null

mpls traffic-eng tunnels (configuration)

mpls traffic-eng tunnels (interface)

next-address

show ip explicit-paths

show ip ospf database opaque-area

show ip ospf mpls traffic-eng

show ip rsvp host

show isis database verbose

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 mode mpls traffic-eng

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 Commands

debug ip ospf mpls traffic-eng advertisements

debug isis mpls traffic-eng advertisements

debug isis mpls traffic-eng events

debug mpls traffic-eng areas

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 path

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

Glossary


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:

•Feature Overview

•Supported Platforms

•Supported Standards, MIBs, and RFCs

•Prerequisites

•Configuration Tasks

•Configuration Examples

•Command Reference

•Debug Commands

•Glossary

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.

 
Command
Purpose

Step 1  

Router(config)# ip cef

Enables standard CEF operation.

For information about CEF configuration and the command syntax, see the Cisco IOS Switching Services Configuration Guide and the Cisco IOS Switching Services Command Reference.

Step 2  

Router(config)# mpls traffic-eng tunnels

Enables the MPLS traffic engineering tunnel feature on a device.

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.

 
Command
Purpose

Step 1  

Router(config-if)# mpls traffic-eng tunnels

Enables MPLS traffic engineering tunnels on an interface.

Step 2  

Router(config-if)# ip rsvp bandwidth bandwidth

Enables RSVP for IP on an interface and specifies the amount of bandwidth that will be reserved.

For a description of the ip rsvp command syntax, see the Cisco IOS Quality of Service Solutions Command Reference.

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.

 
Command
Purpose

Step 1  

Router(config)# router isis

Enables IS-IS routing and specifies an IS-IS process for IP. This command places you in router configuration mode.

Step 2  

Router(config-router)# mpls traffic-eng level-1

Turns on MPLS traffic engineering for IS-IS level 1.

Step 3  

Router(config-router)# mpls traffic-eng router-id 
loopback0

Specifies that the traffic engineering router identifier for the node is the IP address associated with interface loopback0.

Step 4  

Router(config-router)# metric-style wide

Configures a router to generate and accept only new-style TLVs.

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.

 
Command
Purpose

Step 1  

Router(config)# router ospf process-id

Configures an OSPF routing process for IP. You are
placed in router configuration mode.

The process-id is an internally used identification
parameter for an OSPF routing process. It is locally
assigned and can be any positive integer. Assign a
unique value for each OSPF routing process.

Step 2  

Router(config-router)# mpls 
traffic-eng 
area 0

Turns on MPLS traffic engineering for OSPF area 0.

Step 3  

Router(config-router)# mpls 
traffic-eng 
router-id loopback0

Specifies that the traffic engineering router identifier
for the node is the IP address associated with
interface loopback0.

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.

 
Command
Purpose

Step 1  

Router(config)# interface tunnel

Configures an interface type and enters interface configuration mode.

Step 2  

Router(config)# ip unnumbered loopback0

Gives the tunnel interface an IP address.

An MPLS traffic engineering tunnel interface should be unnumbered because it represents a unidirectional link.

Step 3  

Router(config-if)# tunnel destination 
A.B.C.D

Specifies the destination for a tunnel.

Step 4  

Router(config-if)# tunnel mode mpls 
traffic-eng

Sets the tunnel encapsulation mode to MPLS traffic engineering.

Step 5  

Router(config-if)# tunnel mpls 
traffic-eng bandwidth bandwidth

Configures the bandwidth for the MPLS traffic engineering tunnel.

Step 6  

Router(config-if)# tunnel mpls 
traffic-eng

path-option number {dynamic | 

explicit {name path-name | 
path-number}} [lockdown]

Configures the tunnel to use a named IP explicit path or a path dynamically calculated from the traffic engineering topology database. A dynamic path is used if an explicit path is currently unavailable.

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.

 
Command
Purpose

Step 1  

Router(config-if)# interface tunnel1

Configures an interface type and enters interface configuration mode.

Step 2  

Router(config-if)# tunnel mpls traffic-eng autoroute 
announce

Causes the IGP to use the tunnel in its enhanced SPF calculation.

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 cef

mpls traffic-eng tunnels

interface loopback 0

ip address 11.11.11.11 255.255.255.255

ip router isis


interface s1/0

ip address 131.0.0.1 255.255.0.0

ip router isis

mpls traffic-eng tunnels

ip rsvp bandwidth 1000

Router 1—IS-IS Configuration

To enable IS-IS routing, enter the following commands: 

router isis

network 47.0000.0011.0011.00

is-type level-1

metric-style wide

mpls traffic-eng router-id loopback0

mpls traffic-eng level-1

Configuring 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 cef

mpls traffic-eng tunnels

interface loopback 0

ip address 11.11.11.11 255.255.255.255


interface s1/0

ip address 131.0.0.1 255.255.0.0

mpls traffic-eng tunnels

  ip rsvp bandwidth 1000

Router 1—OSPF Configuration

To enable OSPF, enter the following commands: 

router ospf 0

network 131.0.0.0.0.0.255.255 area 0

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

Configuring 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 tunnel1

  ip unnumbered loopback 0

  tunnel destination 17.17.17.17

  tunnel mode mpls traffic-eng

tunnel mpls traffic-eng bandwidth 100

  tunnel mpls traffic-eng priority 1 1

  tunnel mpls traffic-eng path-option 1 dynamic

Router 1—Dynamic Path Tunnel Verification

This section includes the commands you use to verify that the tunnel is up. 

show mpls traffic-eng tunnels 

show ip interface tunnel1

Router 1—Explicit Path Configuration

In this section, an explicit path is configured. 

ip explicit-path identifier 1

 next-address 131.0.0.1 

 next-address 135.0.0.1 

 next-address 136.0.0.1 

 next-address 133.0.0.1

Router 1—Explicit Path Tunnel Configuration

In this section, a tunnel is configured to use an explicit path. 

interface tunnel2

  ip unnumbered loopback 0

  tunnel destination 17.17.17.17

  tunnel mode mpls traffic-eng

tunnel mpls traffic-eng bandwidth 100

  tunnel mpls traffic-eng priority 1 1

  tunnel mpls traffic-eng path-option 1 explicit identifier 1

Router 1—Explicit Path Tunnel Verification

This section includes the commands you use to verify that the tunnel is up. 

show mpls traffic-eng tunnels 

show ip interface tunnel2

Configuring 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 tunnel1

tunnel mpls traffic-eng autoroute announce

Router 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 brief

show ip route 17.17.17.17

show mpls traffic-eng autoroute

ping 17.17.17.17

show interface tunnel1 accounting

show interface s1/0 accounting

Command 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.

•append-after

•index

•ip explicit-path

•list

•metric-style narrow

•metric-style transition

•metric-style wide

•mpls traffic-eng

•mpls traffic-eng administrative-weight

•mpls traffic-eng area

•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 lsp

•mpls traffic-eng logging tunnel

•mpls traffic-eng reoptimize

•mpls traffic-eng reoptimize events

•mpls traffic-eng reoptimize timers frequency

•mpls traffic-eng router-id

•mpls traffic-eng signaling advertise implicit-null

•mpls traffic-eng tunnels (configuration)

•mpls traffic-eng tunnels (interface)

•next-address

•show ip explicit-paths

•show ip ospf database opaque-area

•show ip ospf mpls traffic-eng

•show ip rsvp host

•show isis database verbose

•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 mode mpls traffic-eng

•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

index

Previous index number. Valid values are from 0 to 65534.

command

An IP explicit path configuration command that creates a path entry. (For this release you can use only the next-address command, which specifies the next IP address in the explicit path.)


Defaults

No default behavior or values.

Command Modes

IP explicit path subcommand

Command History

Release
Modification

12.0(5)S

This command was introduced.


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.3

Related Commands

Command
Description

index

Inserts or modifies a path entry at a specific index.

ip explicit-path

Enters the subcommand mode for IP explicit paths and creates or modifies the specified path.

list

Displays all or part of the explicit path(s).

next-address

Specifies the next IP address in the explicit path.

show ip explicit-paths

Displays the configured IP explicit paths.


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

index

Index number at which the path entry will be inserted or modified. Valid values are from 0 to 65534.

command

An IP explicit path configuration command that creates or modifies a path entry. (Currently you can use only the next-address command.)


Defaults

No default behavior or values.

Command Modes

IP explicit path subcommand

Command History

Release
Modification

12.0(5)S

This command was introduced.


Examples

In the following example, the next-addre