Cisco IOS XR Multiprotocol Label Switching Configuration Guide, Release 3.3
Implementing MPLS Traffic Engineering on Cisco IOS XR Software
Downloads: This chapterpdf (PDF - 666.0KB) The complete bookPDF (PDF - 2.59MB) | Feedback

Implementing MPLS Traffic Engineering on Cisco IOS XR Software

Table Of Contents

Implementing MPLS Traffic Engineering on Cisco IOS XR Software

Contents

Prerequisites for Implementing Cisco MPLS Traffic Engineering

Information About Implementing MPLS Traffic Engineering

Overview of MPLS Traffic Engineering

Benefits of MPLS Traffic Engineering

How MPLS-TE Works

Protocol-Based CLI

Differentiated Services Traffic-Engineering

Prestandard DS-TE Mode

IETF DS-TE Mode

Bandwidth Constraint Models

TE Class Mapping

Flooding

Flooding Triggers

Flooding Thresholds

Fast Reroute

Generalized MPLS

GMPLS Benefits

GMPLS Support

GMPLS Protection and Restoration

GMPLS Prerequisites

How to Implement Traffic Engineering on Cisco IOS XR Software

Building MPLS-TE Topology

Prerequisites

Creating an MPLS-TE Tunnel

Prerequisites

Forwarding over the MPLS-TE Tunnel

Prerequisites

Protecting the MPLS Tunnel with Fast Reroute

Prerequisites

Restrictions

Configuring a Prestandard Diff-Serv TE Tunnel

Prerequisites

Configuring an IETF Diff-Serv TE Tunnel Using RDM

Prerequisites

Configuring an IETF Diff-Serv TE Tunnel Using MAM

Prerequisites

Configuring GMPLS on Cisco IOS XR Software

Configuring IPCC Control Channel Information

Configuring Local and Remote TE Links

Configuring Numbered and Unnumbered Optical TE Tunnels

Configuring LSP Hierarchy

Configuring Border Control Model

Configuring Path Protection

Configuration Examples for Cisco MPLS-TE

Configuring Fast Reroute and SONET APS: Example

Building MPLS-TE Topology and Tunnels: Example

Configuring IETF Diff-Serv TE Tunnels: Example

Configuring GMPLS: Example

Configuring Bidirectional Optical Tunnels using TE Links: Example

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance


Implementing MPLS Traffic Engineering on Cisco IOS XR Software


Multiprotocol Label Switching (MPLS) is a standards-based solution driven by the Internet Engineering Task Force (IETF) that was devised to convert the Internet and IP backbones from best-effort networks into business-class transport mediums.

MPLS, with its label switching capabilities, eliminates the need for an IP route look-up and creates a virtual circuit (VC) switching function, allowing enterprises the same performance on their IP-based network services as with those delivered over traditional networks such as Frame Relay or Asynchronous Transfer Mode (ATM).

MPLS traffic engineering (MPLS-TE) 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.

Feature History for Implementing MPLS-TE on Cisco IOS XR Software

Release
Modification

Release 2.0

This feature was introduced on the Cisco CRS-1.

Release 3.0

No modification.

Release 3.2

Support was added for the Cisco XR 12000 Series Router.

Release 3.3.0

Support was added for Generalized MPLS, including conceptual information, procedures, and configuration examples.

Release 3.3.2

Support was added for Generalized MPLS for protection and restoration.

The match (GMPLS) command was modified.


Contents

Prerequisites for Implementing Cisco MPLS Traffic Engineering

Information About Implementing MPLS Traffic Engineering

How to Implement Traffic Engineering on Cisco IOS XR Software

Configuration Examples for Cisco MPLS-TE

Additional References

Prerequisites for Implementing Cisco MPLS Traffic Engineering

The following prerequisites are required:

You must be in a user group associated with a task group that includes the proper task IDs for MPLS-TE commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide.

A router that runs Cisco IOS XR software.

An installed composite mini-image and the MPLS package, or a full composite image.

IGP activated.

Information About Implementing MPLS Traffic Engineering

To implement MPLS-TE you must understand the following concepts:

Overview of MPLS Traffic Engineering

Protocol-Based CLI

Differentiated Services Traffic-Engineering

Flooding

Fast Reroute

Generalized MPLS

Overview of MPLS Traffic Engineering

MPLS-TE 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-TE 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.

Benefits of MPLS Traffic Engineering

MPLS-TE 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-TE achieves the traffic engineering benefits of the overlay model without running a separate network and without needing a non-scalable, full mesh of router interconnects.

How MPLS-TE Works

MPLS-TE automatically establishes and maintains label switched paths (LSPs) across the backbone by using resource reservation protocol (RSVP). The path that an LSP uses is determined by the LSP resource requirements and network resources, such as bandwidth. Available resources are flooded by means of extensions to a link-state-based Interior Gateway Protocol (IGP).

Traffic engineering tunnels are calculated at the LSP head router based on a fit between the required and available resources (constraint-based routing). The IGP automatically routes the traffic to these LSPs.

Typically, a packet crossing the MPLS-TE backbone travels on a single LSP that connects the ingress point to the egress point. MPLS-TE is built on the following mechanisms:

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-TE 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 TE extensions—RSVP operates at each LSP hop and is used to signal and maintain LSPs based on the calculated path.

MPLS-TE link management module—This module operates at each LSP hop, performs link call admission on the RSVP signaling messages, and performs bookkeeping on topology and resource information to be flooded.

Link-state IGP (Intermediate System-to-Intermediate System [IS-IS] or Open Shortest Path First [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 shortest path first (SPF) calculation used by the link-state IGP (IS-IS or OSPF)—The IGP automatically routes traffic to the appropriate LSP tunnel, based on tunnel destination. Static routes can also be used to direct traffic to 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-TE 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 distributed using load sharing among the tunnels.

Protocol-Based CLI

Cisco IOS XR software provides a protocol-based command line interface. The CLI provides commands that can be used with the multiple IGP protocols supported by MPLS-TE.

Differentiated Services Traffic-Engineering

MPLS Differentiated Services (Diff-Serv) Aware Traffic Engineering (DS-TE) is an extension of the regular MPLS-TE feature. Regular traffic engineering does not provide bandwidth guarantees to different traffic classes. A single bandwidth constraint is used in regular TE that is shared by all traffic. To support various classes of service (CoS), users can configure multiple bandwidth constraints. These bandwidth constraints can be treated differently based on the requirement for the traffic class using that constraint.

MPLS diff-serv traffic engineering provides the ability to configure multiple bandwidth constraints on an MPLS-enabled interface. Available bandwidths from all configured bandwidth constraints are advertised using IGP. TE tunnel is configured with bandwidth value and class-type requirements. Path calculation and admission control take the bandwidth and class-type into consideration. RSVP is used to signal the TE tunnel with bandwidth and class-type requirements.

Diff-Serv TE can be deployed with either Russian Doll Model (RDM) or Maximum Allocation Model (MAM) for bandwidth calculations.

Cisco IOS XR software supports two DS-TE modes: Prestandard and IETF. Both modes are described in further detail in the sections that follow.

Prestandard DS-TE Mode

Prestandard DS-TE uses the Cisco proprietary mechanisms for RSVP signaling and IGP advertisements. This DS-TE mode does not interoperate with third-party vendor equipment. Note that prestandard DS-TE is enabled only after configuring the sub-pool bandwidth values on MPLS-enabled interfaces.

Prestandard Diff-Serve TE mode supports a single bandwidth constraint model, Russian Doll Model (RDM) with two bandwidth pools, global-pool and sub-pool.


Note TE class map is not used with Prestandard DS-TE mode.


IETF DS-TE Mode

IETF Diff-Serv TE mode uses IETF defined extensions for RSVP and IGP. This mode interoperates with third-party vendor equipment.

IETF mode supports multiple bandwidth constraint models, including the Russian Doll Model (RDM) and the Maximum Allocation Model (MAM) both with two bandwidth pools. Note that in an IETF DS-TE network, identical bandwidth constraint models must be configured on all nodes.

TE class map is used with IETF DS-TE mode and must be configured the same way on all nodes in the network.

Bandwidth Constraint Models

IETF DS-TE mode provides support for the Russian Dolls and Maximum Allocation bandwidth constraints models. Both models support up two bandwidth pools.

Cisco IOS XR provides global configuration for the switching between bandwidth constraint models. Both models can be configured on a single interface to pre-configure the bandwidth constraints before swapping to an alternate bandwidth constraint model.


Note NSF is not guaranteed when you change the bandwidth constraint model or configuration information.


By default, RDM is the default bandwidth constraint model used in both pre-standard and IETF mode.

Maximum Allocation Bandwidth Constraint Model

The MAM constraint model has the following characteristics:

Easy to use and intuitive

Ensures isolation across class types

Simultaneously achieves isolation, bandwidth efficiency, and protection against QoS degradation

Russian Dolls Bandwidth Constraint Model

The RDM constraint model has the following characteristics:

allows greater sharing of bandwidth among different class types

as with MAM, simultaneously ensures bandwidth efficiency and protection against QoS degradation of all class types

can be used in conjunction with preemption to simultaneously achieve isolation across class-types such that each class-type is guaranteed its share of bandwidth, bandwidth efficiency, and protection against QoS degradation of all class types


Note We recommend that RDM not be used in DS-TE environments in which the use of preemption is precluded. While RDM ensures bandwidth efficiency and protection against QoS degradation of class types, it does guarantee isolation across class types.


TE Class Mapping

Each of the eight available bandwidth values advertised in the IGP corresponds to a TE Class. Because the IGP advertises only eight bandwidth values, there can be a maximum of only eight TE classes supported in an IETF DS-TE network.

TE class mapping must be exactly the same on all routers in a DS-TE domain. It is the responsibility of the operator configure these settings properly as there is no way to automatically check or enforce consistency.

The operator must configure TE tunnel class types and priority levels to form a valid TE class. When the TE class map configuration is changed, tunnels already up are brought down. Tunnels in the down state, can be set up if a valid TE class map is found.

Table 2 list the Default TE class and attributes.

Table 2 TE Classes and Priority 

TE Class
Class Type
Priority

0

0

7

1

1

7

2

Unused

 

3

Unused

 

4

0

0

5

1

0

6

Unused

 

7

Unused

 


Note The default mapping includes four class types.


Flooding

Available bandwidth in all configured bandwidth pools is flooded on the network to calculate accurate constraint paths when a new TE tunnel is configured. Flooding uses IGP protocol extensions and mechanisms to determine when to flood the network with bandwidth.

Flooding Triggers

TE Link Management (TE-Link) notifies IGP for both global pool and sub-pool available bandwidth and maximum bandwidth to flood the network in the following events:

The periodic timer expires (this does not depend on bandwidth pool type).

The tunnel origination node has out-of-date information for either available global pool, or sub-pool bandwidth, causing tunnel admission failure at the midpoint.

Consumed bandwidth crosses user configured thresholds. The same threshold is used for both global pool and sub-pool. If one bandwidth crosses the threshold, both bandwidths will be flooded.

Flooding Thresholds

Flooding frequently can burden a network because all routers must send out and process these updates. Infrequent flooding causes tunnel heads (tunnel-originating nodes) to have out-of-date information, causing tunnel admission to fail at the midpoints.

You can control the frequency of flooding by configuring a set of thresholds. When locked bandwidth (at one or more priority levels) crosses one of these thresholds, flooding is triggered.

Thresholds apply to a percentage of the maximum available bandwidth (the global pool), which is locked, and the percentage of maximum available guaranteed bandwidth (the sub-pool), which is locked. If, for one or more priority levels, either of these percentages crosses a threshold, flooding is triggered.


Note Setting up a global pool TE tunnel can cause the locked bandwidth allocated to sub-pool tunnels to be reduced (and hence to cross a threshold). A sub-pool TE tunnel setup can similarly cause the locked bandwidth for global pool TE tunnels to cross a threshold. Thus, sub-pool TE and global pool TE tunnels can affect each other when flooding is triggered by thresholds.


Fast Reroute

Fast Reroute (FRR) provides link protection to LSPs enabling the traffic carried by LSPs that encounter a failed link to be rerouted around the failure. The reroute decision is controlled locally by the router connected to the failed link. The headend router on the tunnel is notified of the link failure through IGP or through RSVP. When it is notified of a link failure, the headend router attempts to establish a new LSP that bypasses the failure. This provides a path to reestablish links that fail, providing protection to data transfer.

FRR (link, node, or path protection) is supported over sub-pool tunnels the same way as for regular TE tunnels. In particular, when link protection is activated for a given link, TE tunnels eligible for FRR get redirected into the protection LSP regardless of whether they are sub-pool or global pool tunnels.


Note The ability to configure FRR on a per-LSP basis, it is possible to effectively provide different levels of fast restoration to tunnels from different bandwidth pools.


Generalized MPLS

Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering (TE) consists of extensions to the MPLS-TE mechanisms to control a variety of device types, including optical switches. When GMPLS-TE is used to control an hierarchical optical network—a network with a core of optical switches surrounded by outer layers of routers—it can provide unified control of devices that have very different hardware capabilities. Other control-plane solutions for such network architectures typically use an overlay model, using separate control-planes to manage the optical core and the routed network, respectively, with little or no knowledge passing between them.

GMPLS-TE protocols and extensions include:

Resource Reservation Protocol (RSVP) for signaling

Interior Gateway Protocols (IGP) such as Open Shortest Path First (OSPF) for routing

Link Management Protocol (LMP) for managing link information

The base protocol definitions for RSVP and OSPF were previously extended for MPLS-TE to provide circuit mechanisms within packet IP networks. These protocols have been extended for GMPLS-TE.

LMP provides facilities similar to Asynchronous Transfer Mode (ATM) Integrated Local Management Interface (ILMI) and Frame Relay Local Management Interface (LMI). LMP also has features addressing the minimal to nonexistent framing support typical of data links on optical switches.

Optical switches differ from packet and cell devices, in that the data links of optical switches typically can carry only transit traffic. This means that traffic entering an optical switch via one data link is required to leave the switch via a different link. For this reason, a data link that connects two neighboring optical devices cannot exchange control frames between the two devices.

Therefore, optical switches typically have separate frame-capable interfaces for sending and receiving control and management traffic. This type of control is referred to as "out-of-band." It contrasts with the in-band control of many non-optical networks where control frames and data frames are intermixed on the same link.

To address this characteristic, the GMPLS protocols have been extended to support out-of-band control.

GMPLS Benefits

GMPLS bridges the Internet Protocol (IP) and photonic layers, thereby making possible interoperable and scalable parallel growth in the IP and photonic dimensions.

This allows for rapid service deployment and operational efficiencies, as well as for increased revenue opportunities. A smooth transition becomes possible from a traditional segregated transport and service overlay model to a more unified peer model.

By streamlining support for multiplexing and switching in a hierarchical fashion, and by utilizing the flexible intelligence of MPLS-TE, optical switching GMPLS becomes very helpful for service providers wanting to manage large volumes of traffic in a cost-efficient manner.

GMPLS Support

GMPLS-TE provides support for:

Open Shortest Path First (OSPF) for bidirectional TE tunnel

Frame, lambda, and port (fiber) labels

Numbered/Unnumbered links

OSPF extensions-Route computation with optical constraints

RSVP extensions-Graceful Restart

Graceful deletion

LSP hierarchy

Peer model

Border model Control plane separation

Interarea/AS-Verbatim

BGP4/MPLS

Restoration-Dynamic path computation

Control channel manager

Link summary

Protection and restoration

GMPLS Protection and Restoration

GMPLS provides protection against failed channels (or links) between two adjacent nodes (span protection) and end-to-end dedicated protection (path protection). After the route is computed, signaling to establish the backup paths is carried out through RSVP-TE or CR-LDP. For span protection, 1+1 or M:N protection schemes are provided by establishing secondary paths through the network. In addition, you can use signaling messages to switch from the failed primary path to the secondary path.


Note Only 1:1 end-to-end path protection is supported.


The restoration of a failed path refers to the dynamic establishment of a backup path. This process requires the dynamic allocation of resources and route calculation. The following restoration methods are described:

Line restoration—Finds an alternate route at an intermediate node.

Path restoration—Initiates at the source node to route around a failed path within the path for a specific LSP.

Restoration schemes provide more bandwidth usage, because they do not preallocate any resource for an LSP.

GMPLS combines MPLS-FRR and other types of protection, such as SONET/SDH, wavelength, and so forth.

In addition to SONET alarms in POS links, protection and restoration is also triggered by bidirectional forwarding detection (BFD).

1:1 LSP Protection

1:1 protection scheme occurs when one specific protecting LSP or span protects one specific working LSP or span. However, normal traffic is transmitted only over one LSP at a time for working or recovery.

1:1 protection with extra traffic refers to the scheme in which extra traffic is carried over a protecting LSP when the protecting LSP is not being used for the recovery of normal traffic. For example, the protecting LSP is in standby mode. When the protecting LSP is required to recover normal traffic from the failed working LSP, the extra traffic is preempted. Extra traffic is not protected, but it can be restored. Extra traffic is transported using the protected LSP resources.

Shared Mesh Restoration and M:N Path Protection

Both shared mesh restoration and M:N (1:N is more practical) path protection offers sharing for protection resources for multiple working LSPs. For 1:N protection, a specific protecting LSP is dedicated to the protection of up to N working LSPs and spans. Shared mesh is defined as preplanned LSP rerouting, which reduces the restoration resource requirements by allowing multiple restoration LSPs to be initiated from distinct ingress nodes to share common resources, such as links and nodes.

End-to-end Recovery

End-to-end recovery refers to an entire LSP from the source for an ingress router endpoint to the destination for an egress router endpoint.

GMPLS Protection Requirements

The GMPLS protection requirements are specific to the protection scheme that is enabled at the data plane. For example, SONET APS or MPLS-FRR are identified as the data level for GMPLS protection.

GMPLS Prerequisites

The following prerequisites are required to implement GMPLS on Cisco IOS XR software:

You must be in a user group associated with a task group that includes the proper task IDs for GMPLS commands.

A router that runs Cisco IOS XR software.

Installation of the Cisco IOS XR software mini-image on the router.

How to Implement Traffic Engineering on Cisco IOS XR Software

Traffic engineering requires coordination among several global neighbor routers, creating traffic engineering tunnels, setting up forwarding across traffic engineering tunnels, setting up FRR, and creating differential service. This section explains the following procedures:

Building MPLS-TE Topology (required)

Creating an MPLS-TE Tunnel (required)

Forwarding over the MPLS-TE Tunnel (required)

Protecting the MPLS Tunnel with Fast Reroute (optional)

Configuring a Prestandard Diff-Serv TE Tunnel(optional)

Configuring an IETF Diff-Serv TE Tunnel Using RDM (optional)

Configuring an IETF Diff-Serv TE Tunnel Using MAM (optional)

Configuring GMPLS on Cisco IOS XR Software (optional)

Building MPLS-TE Topology

Perform this task to configure MPLS-TE topology, which is required for traffic engineering tunnel operations. Building the MPLS-TE topology is done in the following basic steps:

Enabling MPLS-TE on the port interface.

Enabling RSVP on the port interface.

Enabling an IGP such as OSPF or IS-IS for MPLS-TE.

Prerequisites

The following prerequisites are required:

You must have a router ID for the neighboring router.

A stable router ID is required at either end of the link to ensure the link will be successful. If you do not assign a router ID, the system defaults to the global router ID. Default router IDs are subject to change, which can result in an unstable link.

If you are going to use non-default holdtime or intervals, you must decide the values to which they will be set.

SUMMARY STEPS

1. configure

2. router-id {interface-name | ip-address}

3. mpls traffic-eng

4. interface type instance

5. router ospf instance-name

6. router-id {interface-name | ip-address}

7. area area-id

8. interface type instance

9. interface interface-name

10. mpls traffic-eng router-id

11. mpls traffic-eng area area-id

12. rsvp

13. interface type instance

14. bandwidth bandwidth

15. end
or
commit

16. show mpls traffic topology

17. show mpls traffic-eng link-management advertisements

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters the configuration mode.

Step 2 

router id {interface-name | ip-address}

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if)# router id loopback0

Specifies the global router ID of the local node.

The router ID can be specified with an interface name or an IP address. By default, MPLS uses the global router ID.

Step 3 

mpls traffic-eng

Example:

RP/0/RP0/CPU0:router(config)# mpls traffic-eng

Enters the mpls traffic-engineering configuration mode.

Step 4 

interface type instance

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# interface POS0/6/0/0

Enters MPLS traffic-engineering interface configuration mode and enables traffic engineering on a particular interface on the originating node (in this case, PoS interface 0/6/0/0).

Step 5 

router ospf instance-name

Example:

RP/0/RP0/CPU0:router(config)# router ospf 1

Configures an OSPF routing instance.

Enter the IGP submode and configure the area and interface for an IGP such as OSPF or IS-IS.

Step 6 

router-id {interface-name | ip-address}

Example:

RP/0/RP0/CPU0:router(config-router)# router-id 192.168.25.66

Configures a router ID for the OSPF process using an IP address.

Step 7 

area area-id

Example:

RP/0/RP0/CPU0:router(config-router)# area 0

Configures an area for the OSPF process.

Backbone areas have an area ID of 0.

Non-backbone areas have a non-zero area ID.

Step 8 

interface type instance

Example:

RP/0/RP0/CPU0:router(config-ospf-ar)# interface

pos 0/6/0/0

Configures one or more interfaces for the area configured in Step 7.

Step 9 

interface interface-name

Example:

RP/0/RP0/CPU0:router(config-ospf-ar)# interface loopback 0

Enables IGP on the loopback0 MPLS router ID.

Step 10 

mpls traffic-eng router-id loopback 0

Example:

RP/0/RP0/CPU0:router(config-ospf)# mpls traffic-eng router-id loopback 0

Sets the MPLS traffic engineering loopback interface.

Step 11 

mpls traffic-eng area area-id

Example:

RP/0/RP0/CPU0:router(config-ospf)# mpls traffic-eng area 0

Sets the MPLS traffic engineering area.

Step 12 

rsvp

Example:

RP/0/RP0/CPU0:router(config)# rsvp

Enables RSVP and enters RSVP configuration submode.

Step 13 

interface type instance

Example:

RP/0/RP0/CPU0:router(config-rsvp)# interface pos 0/6/0/0

Enters RSVP interface submode, and enables RSVP on a particular interface on the originating node (in this case, on the PoS interface 0/6/0/0).

Step 14 

bandwidth bandwidth

Example:

RP/0/RP0/CPU0:router(config-rsvp-if)# bandwidth 100

Sets the reserved RSVP bandwidth available on this interface.

Note Physical interface bandwidth is not used by MPLS traffic-engineering.

Step 15 

end

or

commit

Example:

RP/0/RP0/CPU0:router(config-rsvp-if)# end

or

RP/0/RP0/CPU0:router(config-rsvp-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Step 16 

show mpls traffic-eng topology

Example:

RP/0/RP0/CPU0:router# show mpls traffic-eng topology

(Optional) Verifies the traffic engineering topology.

Step 17 

show mpls traffic-eng link-management advertisements

Example:

RP/0/RP0/CPU0:router# show mpls traffic-eng link-management advertisements

(Optional) Displays all the link-management advertisements for the links on this node.

Creating an MPLS-TE Tunnel

Perform this task to create an MPLS-TE tunnel. This task is performed after the traffic engineering topology has been created.

Creating an MPLS-TE tunnel is a process of customizing the traffic engineering to fit your network topology.

Prerequisites

The following prerequisites are required:

You must have a router ID for the neighboring router.

A stable router ID is required at either end of the link to ensure the link will be successful. If you do not assign a router ID to the routers, the system defaults to the global router ID. Default router IDs are subject to change, which can result in an unstable link.

If you are going to use non-default holdtime or intervals, you must decide the values to which they will be set.

SUMMARY STEPS

1. configure

2. interface tunnel-te number

3. destination ip-address

4. ipv4 unnumbered loopback number

5. path-option path-id dynamic

6. signaled bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

7. end
or
commit

8. show mpls traffic-eng tunnels

9. show ipv4 interface brief

10. show mpls traffic-eng link-management admission-control

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface tunnel-te number

Example:

RP/0/RP0/CPU0:router(config)# interface tunnel-te 1

Enters MPLS-TE interface configuration mode.

Step 3 

destination ip-address

Example:

RP/0/RP0/CPU0:router(config-if)# destination 192.168.92.125

Assigns a destination address on the new tunnel.

The destination address is the remote node's MPLS traffic-engineering router ID.

Step 4 

ipv4 unnumbered loopback number

Example:

RP/0/RP0/CPU0:router(config-if)# ipv4 unnumbered loopback 0

Assigns a source address so that forwarding can be performed on the new tunnel.

Step 5 

path-option path-id dynamic

Example:

RP/0/RP0/CPU0:router(config-if)# path-option l dynamic

Sets the path option to dynamic and also assigns the path ID.

Step 6 

signaled bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

Example:

RP/0/RP0/CPU0:router(config-if)# signaled bandwidth 100

Sets the CT0 bandwidth required on this interface. Because the default tunnel priority is 7, tunnels use the default TE class map (namely, class-type 1, priority 7).

Step 7 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Step 8 

show mpls traffic-eng tunnels

Example:

RP/0/RP0/CPU0:router# show mpls traffic-eng tunnels

(Optional) Verifies that the tunnel is connected (in the UP state) and displays all configured TE tunnels.

Step 9 

show ipv4 interface brief

Example:

RP/0/RP0/CPU0:router# show ipv4 interface brief

(Optional) Displays all TE tunnel interfaces.

Step 10 

show mpls traffic-eng link-management admission-control

Example:

RP/0/RP0/CPU0:router# show mpls traffic-eng link-management admission-control

(Optional) Displays all the tunnels on this node.

Forwarding over the MPLS-TE Tunnel

Perform this task to enable forwarding over the MPLS-TE tunnel created in the pervious task. This allows MPLS packets to be forwarded on the link between the neighbors in the network.

Prerequisites

The following prerequisites are required:

You must have a router ID for the neighboring router.

A stable router ID is required at either end of the link to ensure the link will be successful. If you do not assign a router ID to the routers, the system defaults to the global router ID. Default router IDs are subject to change, which can result in an unstable link.

SUMMARY STEPS

1. configure

2. interface tunnel-te number

3. ipv4 unnumbered loopback number

4. autoroute announce

5. router static address-family ipv4 unicast prefix mask ip-address interface type

6. end
or
commit

7. ping {ip-address | hostname}

8. show mpls traffic autoroute

9. show ipv4 route

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface tunnel-te number

Example:

RP/0/RP0/CPU0:router(config)# interface tunnel-te 1

Enters MPLS-TE interface configuration mode.

Step 3 

ipv4 unnumbered loopback number

Example:

RP/0/RP0/CPU0:router(config-if)# ipv4 unnumbered loopback 0

Assigns a source address so that forwarding can be performed on the new tunnel.

Step 4 

autoroute announce

Example:

RP/0/RP0/CPU0:router(config)# autoroute announce

Enables messages that notify the neighbor nodes about the routes that are forwarding.

Step 5 

router static address-family ipv4 unicast prefix mask ip-address interface type

Example:

RP/0/RP0/CPU0:router(config-if)# router static address-family ipv4 unicast 2.2.2.2/32 tunnel-te 1

(Optional) Enables a route using IP version 4 addressing, identifies the destination address and the tunnel where forwarding is enabled.

This configuration is used for static routes when autoroute announce config is not used.

Step 6 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Step 7 

ping {ip-address | hostname}

Example:

RP/0/RP0/CPU0:router# ping 192.168.12.52

(Optional) Checks for connectivity to a particular IP address or host name.

Step 8 

show mpls traffic-eng autoroute

Example:

RP/0/RP0/CPU0:router# show mpls traffic-eng autoroute

(Optional) Verifies forwarding by displaying what is advertised to IGP for the traffic-engineering tunnel.

Step 9 

show ipv4 route

Example:

RP/0/RP0/CPU0:router# show ipv4 route

(Optional) Verifies forwarding by displaying the routes for static and autoroute tunnels.

Protecting the MPLS Tunnel with Fast Reroute

Perform this task to protect the MPLS-TE tunnel created in the previous task. Although this task is similar, its importance makes it necessary to present as part of the tasks required for traffic engineering on Cisco IOS XR software.

Prerequisites

The following prerequisites are required:

You must have a router ID for the neighboring router.

A stable router ID is required at either end of the link to ensure that the link will be successful. If you do not assign a router ID to the routers, the system defaults to the global router ID. Default router IDs are subject to change, which can result in an unstable link.

Restrictions

Before you begin, you must configure a primary tunnel and a backup tunnel (see "Creating an MPLS-TE Tunnel" section).

SUMMARY STEPS

1. configure

2. interface tunnel-te number

3. fast-reroute

4. end
or
commit

5. mpls traffic-eng interface type instance

6. backup-path tunnel-te tunnel-number

7. end
or
commit

8. interface tunnel-te tunnel-id

9. backup-bw {bandwidth | sub-pool {bandwidth | unlimited} | global-pool {bandwidth | unlimited}}

10. ipv4 unnumbered loopback number

11. path-option path-id explicit name explicit-path-name

12. destination A.B.C.D

13. end
or
commit

14. show mpls traffic-eng tunnels backup

15. show mpls traffic-eng tunnels protection

16. show mpls traffic-eng fast-reroute database

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface tunnel-te number

Example:

RP/0/RP0/CPU0:router(config)# interface tunnel-te1

Enters MPLS-TE interface configuration mode.

Step 3 

fast-reroute

Example:

RP/0/RP0/CPU0:router(config-if)# fast-reroute

Enables fast reroute.

Step 4 

end

or

commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Step 5 

mpls traffic-eng interface type instance

Example:

RP/0/RP0/CPU0:router(config)# mpls traffic-eng interface pos0/6/0/0

Enters the MPLS-TE configuration mode, and enables traffic engineering on a particular interface on the originating node (in this case, on PoS interface 0/6/0/0).

Step 6 

backup-path tunnel-te tunnel-number

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if)# backup-path tunnel-te 2

Sets the backup path to the backup tunnel to ensure that the backup tunnel outgoing interface is different than PoS interface 0/6/0/0 (for which protection is required).

Step 7 

end

or

commit

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if)# end

or

RP/0/RP0/CPU0:router(config-mpls-te-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Step 8 

interface tunnel-te number

Example:

RP/0/RP0/CPU0:router(config)# interface tunnel-te2

Enters MPLS-TE interface configuration mode.

Step 9 

backup-bw {bandwidth | sub-pool {bandwidth | unlimited} | global-pool {bandwidth | unlimited}}

Example:

RP/0/RP0/CPU0:router(config-if)# backup-bw global-pool 5000

Sets the CT0 bandwidth required on this interface. Because the default tunnel priority is 7, tunnels use the default TE class map (namely, class-type 1, priority 7).

Step 10 

ipv4 unnumbered loopback number

Example:

RP/0/RP0/CPU0:router(config-if)# ipv4 unnumbered loopback 0

Assigns a source address to set up forwarding on the new tunnel.

Step 11 

path-option path-id explicit name explicit-path-name

Example:

RP/0/RP0/CPU0:router(config-if)# path-option l explicit name backup-path

Sets the path option to explicit with a given name (previously configured) and assigns the path ID.

Step 12 

destination A.B.C.D

Example:

RP/0/RP0/CPU0:router(config-if)# destination 192.168.92.125

Assigns a destination address on the new tunnel.

The destination address is the remote node's MPLS-TE router ID.

The destination address is the merge point between backup and protected tunnels.

Step 13 

end

or

commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Step 14 

show mpls traffic-eng tunnels backup

Example:

RP/0/RP0/CPU0:router# show mpls traffic-eng tunnels backup

(Optional) Displays the backup tunnel information.

Step 15 

show mpls traffic-eng tunnels protection

Example:

RP/0/RP0/CPU0:router# show mpls traffic-eng tunnels protection

(Optional) Displays the tunnel protection information.

Step 16 

show mpls traffic-eng fast-reroute database

Example:

RP/0/RP0/CPU0:router# show mpls traffic-eng fast-reroute database

(Optional) Displays the protected tunnel state (for instance, the tunnel's current ready or active state).

Configuring a Prestandard Diff-Serv TE Tunnel

Perform this task to create a Prestandard Diff-Serv TE tunnel.

Prerequisites

The following prerequisites are required:

You must have a router ID for the neighboring router.

A stable router ID is required at either end of the link to ensure that the link is successful. If you do not assign a router ID to the routers, the system defaults to the global router ID. Default router IDs are subject to change, which can result in an unstable link.

SUMMARY STEPS

1. configure

2. rsvp

3. interface type instance

4. bandwidth [0 - 4294967295] [bc0] [global-pool] [mam {0-4294967295 | max-reservable-bandwidth}] [rdm {0-4294967295 | bc0 | global-pool}]

5. interface tunnel-te number

6. signaled bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

7. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

rsvp

Example:

RP/0/RP0/CPU0:router(config)# rsvp

Enters RSVP configuration mode.

Step 3 

interface type instance

Example:

RP/0/RP0/CPU0:router(config-rsvp)# interface pos0/6/0/0

Selects the RSVP interface.

Step 4 

bandwidth [0 - 4294967295] [bc0] [global-pool] [mam {0-4294967295 | max-reservable-bandwidth}] [rdm {0-4294967295 | bc0 | global-pool}]

Example:

RP/0/RP0/CPU0:router(config-rsvp-if)# bandwidth 100 150 sub-pool 50

Sets the reserved RSVP bandwidth available on this interface.

Note Physical interface bandwidth is not used by MPLS-TE.

Step 5 

interface tunnel-te number

Example:

RP/0/RP0/CPU0:router(config)# interface tunnel-te2

Enters MPLS-TE interface configuration mode.

Step 6 

signaled bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

Example:

RP/0/RP0/CPU0:router(mpls-if)# bandwidth sub-pool 10

Sets the bandwidth required on this interface. Because the default tunnel priority is 7, tunnels use the default TE class map (namely, class-type 1, priority 7).

Step 7 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring an IETF Diff-Serv TE Tunnel Using RDM

Perform this task to create an IETF mode differentiated services traffic engineering tunnel using default RDM model.

Prerequisites

The following prerequisites are required:

You must have a router ID for the neighboring router.

A stable router ID is required at either end of the link to ensure that the link will be successful. If you do not assign a router ID to the routers, the system defaults to the global router ID. Default router IDs are subject to change, which can result in an unstable link.

SUMMARY STEPS

1. configure

2. rsvp

3. interface type instance

4. bandwidth [0 - 4294967295] [bc0] [global-pool] [mam {0-4294967295 | max-reservable-bandwidth}] [rdm {0-4294967295 | bc0 | global-pool}]

5. mpls traffic-eng

6. ds-te mode ietf

7. exit

8. interface tunnel-te number

9. bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

10. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

rsvp

Example:

RP/0/RP0/CPU0:router(config)# rsvp

Enters RSVP configuration mode.

Step 3 

interface type instance

Example:

RP/0/RP0/CPU0:router(config-rsvp)# interface pos0/6/0/0

Selects the RSVP interface.

Step 4 

bandwidth [0 - 4294967295] [bc0] [global-pool] [mam {0-4294967295 | max-reservable-bandwidth}] [rdm {0-4294967295 | bc0 | global-pool}]

Example:

RP/0/RP0/CPU0:router(config-rsvp-if)# bandwidth rdm 100 150 bc1 50

Sets the reserved RSVP bandwidth available on this interface.

Note Physical interface bandwidth is not used by MPLS-TE.

Step 5 

mpls traffic-eng

Example:

RP/0/RP0/CPU0:router(config)# mpls traffic-eng

Enters MPLS-TE configuration mode.

Step 6 

ds-te mode ietf

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# ds-te mode ietf

Enables IETF DS-TE mode and default TE class map. Configure IETF DS-TE mode on all network nodes.

Step 7 

exit

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# exit

Exits the MPLS-TE submode.

Step 8 

interface tunnel-te number

Example:

RP/0/RP0/CPU0:router(config)# interface tunnel-te2

Enters MPLS-TE interface configuration mode.

Step 9 

bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

Example:

RP/0/RP0/CPU0:router(mpls-if)# bandwidth 10 class-type 1

Sets the CT0 bandwidth required on this interface. Because the default tunnel priority is 7, tunnels use the default TE class map (namely, class-type 1, priority 7).

Step 10 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring an IETF Diff-Serv TE Tunnel Using MAM

Perform this task to create an IETF mode differentiated services traffic engineering tunnel when using the MAM bandwidth constraint model.

Prerequisites

The following prerequisites are required:

You must have a router ID for the neighboring router.

A stable router ID is required at either end of the link to ensure the link will be successful. If you do not assign a router ID to the routers, the system defaults to the global router ID. Default router IDs are subject to change, which can result in an unstable link.

SUMMARY STEPS

1. configure

2. rsvp

3. interface type instance

4. bandwidth [0 - 4294967295] [bc0] [global-pool] [mam {0-4294967295 | max-reservable-bandwidth}] [rdm {0-4294967295 | bc0 | global-pool}]

5. mpls traffic-eng

6. ds-te mode ietf

7. ds-te model mam

8. interface tunnel-te number

9. bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

10. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

rsvp

Example:

RP/0/RP0/CPU0:router(config)# rsvp

Enters RSVP configuration mode.

Step 3 

interface type instance

Example:

RP/0/RP0/CPU0:router(config-rsvp)# interface pos0/6/0/0

Selects the RSVP interface.

Step 4 

bandwidth [0 - 4294967295] [bc0] [global-pool] [mam {0-4294967295 | max-reservable-bandwidth}] [rdm {0-4294967295 | bc0 | global-pool}]

Example:

RP/0/RP0/CPU0:router(config-rsvp-if)# bandwidth mam max-reservable-bw 400 bc0 300 bc1 200

Sets the reserved RSVP bandwidth available on this interface.

Note Physical interface bandwidth is not used by MPLS-TE.

Step 5 

mpls traffic-eng

Example:

RP/0/RP0/CPU0:router(config)# mpls traffic-eng

Enters MPLS-TE configuration mode.

Step 6 

ds-te mode ietf

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# ds-te mode ietf

Enables IETF DS-TE mode and default TE class map. Configure IETF DS-TE mode on all nodes in the network.

Step 7 

ds-te mode mam

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# ds-te model mam

Enables the MAM bandwidth constraint model globally.

Step 8 

interface tunnel-te number

Example:

RP/0/RP0/CPU0:router(config)# interface tunnel-te2

Enters MPLS-TE interface configuration mode.

Step 9 

bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

Example:

RP/0/RP0/CPU0:router(mpls-if)# bandwidth 10 class-type 1

Sets the CT0 bandwidth required on this interface. Because the default tunnel priority is 7, tunnels use the default TE class map (namely, class-type 1, priority 7).

Step 10 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring GMPLS on Cisco IOS XR Software

To fully configure GMPLS, you must complete the following high-level tasks in order:

Configuring IPCC Control Channel Information

Configuring Local and Remote TE Links

Configuring Numbered and Unnumbered Optical TE Tunnels

Configuring LSP Hierarchy

Configuring Border Control Model

Configuring Path Protection


Note These high-level tasks are broken down into, in some cases, several subtasks.


Configuring IPCC Control Channel Information

This section includes the following subtasks:

Configuring Router IDs

Configuring OSPF over IPCC


Note You must complete all subtasks on both the headend and tailend routers.


Configuring Router IDs

Perform this task to configure the router ID for the headend and tailend routers.

SUMMARY STEPS

1. configure

2. interface type instance

3. ipv4 address ipv4-address mask

4. commit

5. configure

6. router-id {interface-name | ip-address}

7. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface type instance

Example:

RP/0/RP0/CPU0:router(config)# interface POS0/6/0/0

Enters MPLS-TE interface configuration mode and enables traffic engineering on a particular interface on the originating node.

Step 3 

ipv4 address ipv4-address mask

Example:

RP/0/RP0/CPU0:router(config-if)# ipv4 address

192.168.1.27 255.0.0.0

Specifies a primary or secondary IPv4 address for an interface.

The network mask can be a four-part dotted decimal address. For example, 255.0.0.0 indicates that each bit equal to 1 means the corresponding address bit belongs to the network address.

The network mask can be indicated as a slash (/) and a number (prefix length). The prefix length is a decimal value that indicates how many of the high-order contiguous bits of the address compose the prefix (the network portion of the address). A slash must precede the decimal value, and there is no space between the IP address and the slash.

Step 4 

commit

Example:

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Step 5 

configure

Example:

RP/0/RP0/CPU0:router# configure

Re-enters global configuration mode.

Step 6 

router id {interface-name | ip-address}

Example:

RP/0/RP0/CPU0:router(config-if)# router id loopback 0

Specifies the global router ID of the local node.

The router ID can be specified with an interface name or an IP address. By default, MPLS uses the global router ID.

Step 7 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or
RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring OSPF over IPCC

Perform this task to configure OSPF over IPCC on both the head and tail routers. The IGP instance is configured for control network specifically for the signaling plane in the optical domain.


Note IPCC support is restricted to routed, out-of-fiber, and out-of-band.


SUMMARY STEPS

1. configure

2. router ospf instance-name

3. area area-id

4. interface interface-name

5. mpls traffic-eng router-id {interface-name | ip-address}

6. mpls traffic-eng area area-id

7. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

router ospf instance-name

Example:

RP/0/RP0/CPU0:router(config)# router ospf 1

Configures an OSPF routing instance.

Enter the IGP submode and configure the area and interface for an IGP such as OSPF or IS-IS.

Step 3 

area area-id

Example:

RP/0/RP0/CPU0:router(config-ospf)# area 0

Configures an area for the OSPF process.

Backbone areas have an area ID of 0.

Non-backbone areas have a nonzero area ID.

Step 4 

interface interface-name

Example:

RP/0/RP0/CPU0:router((config-ospf-ar)# interface Loopback 0

Enables IGP on the interface.

Note Use this command to configure any interface included in the control network.

Step 5 

mpls traffic-eng router-id {interface-name | ip-address}

Example:

RP/0/RP0/CPU0:router(config-ospf-ar)# mpls traffic-eng router id 192.168.25.66

Configures a router ID for the OSPF process using an IP address.

Step 6 

mpls traffic-eng area area-id

Example:

RP/0/RP0/CPU0:router(config-ospf)# mpls traffic-eng area 0

Configures the MPLS-TE area.

Step 7 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring Local and Remote TE Links

The subtasks in this section describe how to configure local and remote MPLS-TE link parameters for numbered and unnumbered TE links on both head and tail routers.

This section includes the following subtasks:

Configuring Numbered and Unnumbered Links

Configuring Local Reservable Bandwidth

Configuring Local Switching Capability Descriptors

Configuring Persistent Interface Index

Enabling LMP Message Exchange

Configuring Remote TE Link Adjacency Information for Numbered Links

Configuring Numbered and Unnumbered Links

Perform this task to configure numbered and unnumbered links.


Note Unnumbered TE links use the IP address of the associated interface.


SUMMARY STEPS

1. configure

2. interface type instance

3. ipv4 address ipv4-address mask
or
ipv4 unnumbered interface-type interface-instance

4. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface type instance

Example:

RP/0/RP0/CPU0:router(config)# interface POS0/6/0/0

Enters MPLS-TE interface configuration mode and enables traffic engineering on a particular interface on the originating node.

Step 3 

ipv4 address ipv4-address mask

or

ipv4 unnumbered interface-type interface-instance

Example:

RP/0/RP0/CPU0:router(config-if)# ipv4 address

192.168.1.27 255.0.0.0

Specifies a primary or secondary IPv4 address for an interface.

The network mask can be a four-part dotted decimal address. For example, 255.0.0.0 indicates that each bit equal to 1 means the corresponding address bit belongs to the network address.

The network mask can be indicated as a slash (/) and a number (prefix length). The prefix length is a decimal value that indicates how many of the high-order contiguous bits of the address compose the prefix (the network portion of the address). A slash must precede the decimal value, and there is no space between the IP address and the slash.

or

Enables IPv4 processing on a point-to-point interface without assigning an explicit IPv4 address to that interface.

Note If you configured a unnumbered GigE interface in Step 2 and selected the ipv4 unnumbered interface type option in this step, you must enter the ipv4 point-to-point command to configure point-to-point interface mode.

Step 4 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or
RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring Local Reservable Bandwidth

Perform this task to configure the local reservable bandwidth for the data bearer channels.

SUMMARY STEPS

1. configure

2. rsvp

3. interface type instance

4. bandwidth [0 - 4294967295] [bc0] [global-pool] [mam {0-4294967295 | max-reservable-bandwidth}] [rdm {0-4294967295 | bc0 | global-pool}]

5. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

rsvp

Example:

RP/0/RP0/CPU0:router(config)# rsvp

Enters RSVP configuration mode.

Step 3 

interface type instance

Example:

RP/0/RP0/CPU0:router(config-rsvp)# interface POS0/6/0/0

Enters MPLS-TE interface configuration mode and enables traffic engineering on a particular interface on the originating node.

Step 4 

bandwidth [0 - 4294967295] [bc0] [global-pool] [mam {0-4294967295 | max-reservable-bandwidth}] [rdm {0-4294967295 | bc0 | global-pool}]

Example:

RP/0/RP0/CPU0:router(config-rsvp-if)# bandwidth 2488320 2488320

Sets the reserved RSVP bandwidth available on this interface.

Note MPLS-TE can use only the amount of bandwidth specified using this command on the configured interface.

Step 5 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or
RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring Local Switching Capability Descriptors

Perform this task to configure the local switching capability descriptor.

SUMMARY STEPS

1. configure

2. mpls traffic-eng

3. interface type instance

4. flooding-igp ospf instance area

5. switching key cap

6. encoding {sonet/sdh | ethernet}

7. capability {psc1 | lsc | fsc}

8. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

mpls traffic-eng

Example:

RP/0/RP0/CPU0:router(config)# mpls traffic-eng

Enters MPLS-TE configuration mode.

Step 3 

interface type instance

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# interface POS0/6/0/0

Enters MPLS-TE interface configuration mode and enables traffic engineering on a particular interface on the originating node.

Step 4 

flooding-igp ospf instance area

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if)# flooding-igp ospf 0 1

Specifies the IGP OSPF instance and area where the TE links are to be flooded.

Step 5 

switching key cap

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if)# switching key 0

Specifies the switching configuration for the interface and enters switching key submode where you will configure encoding and capability.

Note The recommended switch key value is 0.

Step 6 

encoding {sonet/sdh | ethernet}

Example:

RP/0/RP0/CPU0:router(config-rsvp-if-sw-0x1)# encoding ethernet

Specifies the interface encoding type, as follows:

sonet/sdh, or POS

ethernet, or GigE

Step 7 

capability {psc1 | lsc | fsc}

Example:

RP/0/RP0/CPU0:router(config-rsvp-if-sw-0x1)# capability psc1

Specifies the interface switching cap type. The recommended switch capability type is psc1.

Step 8 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring Persistent Interface Index

Perform this task to preserve the LMP interface index across all interfaces on the router.

SUMMARY STEPS

1. configure

2. snmp-server ifindex persist

3. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

snmp-server ifindex persist

Example:

RP/0/RP0/CPU0:router(config)# snmp-server ifindex persist

Enables ifIndex persistence globally on all Simple Network Management Protocol (SNMP) interfaces.

Step 3 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Enabling LMP Message Exchange

Perform the following task to enable LMP message exchange.

LMP is enabled by default. You can disable LMP on a per neighbor basis using the lmp static command in LMP protocol neighbor submode.


Note LMP is recommended unless the peer optical device does not support LMP (in which case it is necessary to disable it at both ends).


SUMMARY STEPS

1. configure

2. mpls traffic-eng

3. lmp neighbor name

4. ipcc routed

5. remote node-id node-id

6. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

mpls traffic-eng

Example:

RP/0/RP0/CPU0:router(config)# mpls traffic-eng

Enters MPLS-TE configuration mode.

Step 3 

lmp neighbor name

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# lmp neighbor OXC1

Configures or updates a LMP neighbor and its associated parameters.

Step 4 

ipcc routed

Example:

RP/0/RP0/CPU0:router(config-mpls-te-nbr-OXC1)# ipcc routed

Configures a routable Internet Protocol Control Channel (IPCC).

Step 5 

remote node-id node-id

Example:

RP/0/RP0/CPU0:router(config-rsvp-if-sw-0x1)# remote node-id 2.2.2.2

Configures the remote node ID for an LMP neighbor.

Note The node-id value can also be an IPv4 address

Step 6 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Disabling LMP Message Exchange

Perform the following task to disable LMP message exchange.

LMP is enabled by default. You can disable LMP on a per neighbor basis using the lmp static command in LMP protocol neighbor submode.


Note LMP is recommended unless the peer optical device does not support LMP (in which case it is necessary to disable it at both ends).


SUMMARY STEPS

1. configure

2. mpls traffic-eng

3. lmp neighbor name

4. lmp static

5. ipcc routed

6. remote node-id node-id

7. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

mpls traffic-eng

Example:

RP/0/RP0/CPU0:router(config)# mpls traffic-eng

Enters MPLS-TE configuration mode.

Step 3 

lmp neighbor name

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# lmp neighbor OXC1

Configures or updates a LMP neighbor and its associated parameters.

Step 4 

lmp static

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# lmp static

Disables dynamic LMP procedures for the specified neighbor, including LMP hello and LMP link summary.

Note Use this command for neighbors that do not support dynamic lmp procedures.

Step 5 

ipcc routed

Example:

RP/0/RP0/CPU0:router(config-mpls-te-nbr-OXC1)# ipcc routed

Configures a routable IPCC.

Step 6 

remote node-id node-id

Example:

RP/0/RP0/CPU0:router(config-rsvp-if-sw-0x1)# remote node-id 2.2.2.2

Configures the remote node ID for an LMP neighbor.

Note The node ID value must be an IPv4 address.

Step 7 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring Remote TE Link Adjacency Information for Numbered Links

Perform this task to configure remote TE link adjacency information for numbered links.

To display the assigned value for the local interface identifiers, use the show mpls lmp command.

SUMMARY STEPS

1. configure

2. mpls traffic-eng

3. interface type instance

4. lmp data-link adjacency

5. lmp neighbor name

6. remote te-link-id ipv4

7. remote interface-id unnum

8. remote switching-capability

9. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

mpls traffic-eng

Example:

RP/0/RP0/CPU0:router(config)# mpls traffic-eng

Enters MPLS-TE configuration mode.

Step 3 

interface type instance

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# interface POS0/6/0/0

Enters MPLS-TE interface configuration mode and enables traffic engineering on a particular interface on the originating node.

Step 4 

lmp data link adjacency

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if)# lmp data-link adjacency

Configures LMP neighbor remote TE links.

Step 5 

lmp neighbor name

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if-adj)# neighbor OXC1

Configures or updates a LMP neighbor and its associated parameters.

Step 6 

remote te-link-id ipv4 address

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if-adj)# remote te-link-id ipv4 10.10.10.10

Configures the remote LMP MPLS-TE link ID address.

Step 7 

remote interface-id unnum interface identifier

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if-adj)# remote interface-id unnum 7

Configures the unnumbered interface identifier.

Note Identifiers you specify using this command are the values assigned by the neighbor at the remote side.

Step 8 

remote switching-capability {fsc | lsc | psc1}

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if-adj)# remote switching-capability lsc

Configures the remote LMP MPLS-TE interface switching capability.

Step 9 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring Remote TE Link Adjacency Information for Unnumbered Links

Perform this task to configure remote TE link adjacency information for unnumbered links.

To display the assigned value for the local interface identifiers, use the show mpls lmp command.

SUMMARY STEPS

1. configure

2. mpls traffic-eng

3. interface type instance

4. lmp data-link adjacency

5. neighbor name

6. remote te-link-id unnum

7. remote interface-id unnum

8. remote switching-capability

9. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

mpls traffic-eng

Example:

RP/0/RP0/CPU0:router(config)# mpls traffic-eng

Enters MPLS-TE configuration mode.

Step 3 

interface type instance

Example:

RP/0/RP0/CPU0:router(config-mpls-te)# interface POS0/6/0/0

Enters MPLS-TE interface configuration mode and enables traffic engineering on a particular interface on the originating node.

Step 4 

lmp data link adjacency

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if)# lmp data-link adjacency

Configures LMP neighbor remote TE links.

Step 5 

lmp neighbor name

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if-adj)# neighbor OXC1

Configures or updates a LMP neighbor and its associated parameters.

Step 6 

remote te-link-id unnum

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if-adj)# remote te-link-id unnum 111

Configures the unnumbered interface and identifier.

Step 7 

remote interface-id unnum interface identifier

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if-adj)# remote interface-id unnum 7

Configures the unnumbered interface identifier.

Note Identifiers you specify using this command are the values assigned by the neighbor at the remote side.

Step 8 

remote switching-capability {fsc | lsc | psc1}

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if-adj)# remote switching-capability lsc

Configures emote the LMP MPLS-TE interface switching capability.

Step 9 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring Numbered and Unnumbered Optical TE Tunnels

This section includes the following subtasks:

Configuring an Optical TE Tunnel Using Dynamic Path Option

Configuring an Optical TE Tunnel Using Explicit Path Option


Note Before you can successfully bring optical TE tunnels "up," you must complete the procedures in the preceding sections.


The following characteristics can apply to the head (or, signaling) router:

Tunnels can be numbered or unnumbered.

Tunnels can be dynamic or explicit.

The following characteristics can apply to the tail (or, passive) router:

Tunnels can be numbered or unnumbered.

Tunnels must use the explicit path-option.

Configuring an Optical TE Tunnel Using Dynamic Path Option

Perform this task to configure a numbered or unnumbered optical tunnel on a router; in this example, the dynamic path option on the head router.

The dynamic option does not require that you specify the different hops that need to be taken along the way. The hops are calculated automatically.


Note This section provides two examples that describe how to configure a optical tunnels. It does not include procedures for every option available on the head and tail routers.


SUMMARY STEPS

1. configure

2. interface tunnel-te number

3. ipv4 address ipv4-address mask
or
ipv4 unnumbered interface-type interface-instance

4. switching transit switching type encoding encoding type

5. priority setup-priority hold-priority

6. bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

7. destination A.B.C.D

8. path-option path-id dynamic

9. direction [bidirectional]

10. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface tunnel-te number

Example:

RP/0/RP0/CPU0:router(config)# interface tunnel-te2

Enters MPLS-TE interface configuration mode.

Step 3 

ipv4 address ipv4-address mask
or
ipv4 unnumbered interface-type interface-instance

Example:

RP/0/RP0/CPU0:router(config-if)# ipv4 address

192.168.1.27 255.0.0.0

Specifies a primary or secondary IPv4 address for an interface.

The network mask can be a four-part dotted decimal address. For example, 255.0.0.0 indicates that each bit equal to 1 means the corresponding address bit belongs to the network address.

The network mask can be indicated as a slash (/) and a number (prefix length). The prefix length is a decimal value that indicates how many of the high-order contiguous bits of the address compose the prefix (the network portion of the address). A slash must precede the decimal value, and there is no space between the IP address and the slash.

or

Enables IPv4 processing on a point-to-point interface without assigning an explicit IPv4 address to that interface.

Step 4 

switching transit switching type encoding encoding type

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if)# switching transit lsc encoding sonetsdh

Specifies the switching capability and encoding types for all transit TE links used to signal the optical tunnel.

Step 5 

priority setup-priority hold-priority

Example:

RP/0/RP0/CPU0:router(config-mpls-te-if)# priority 1 1

Configures setup and reservation priorities for MPLS-TE tunnels.

Step 6 

bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

Example:

RP/0/RP0/CPU0:router(mpls-if)# bandwidth 10 class-type 1

Sets the CT0 bandwidth required on this interface. Because the default tunnel priority is 7, tunnels use the default TE class map (namely, class-type 1, priority 7).

Step 7 

destination A.B.C.D

Example:

RP/0/RP0/CPU0:router(config-if)# destination 192.168.92.125

Assigns a destination address on the new tunnel.

The destination address is the remote node's MPLS-TE router ID.

The destination address is the merge point between backup and protected tunnels.

Step 8 

path-option path-id dynamic

Example:

RP/0/RP0/CPU0:router(config-if)# path-option l dynamic

Configures the dynamic path option and path ID.

Step 9 

direction [bidirectional]

Example:

RP/0/RP0/CPU0:router(config-if)# direction bidirection

Configures a bidirectional optical tunnel for GMPLS.

Step 10 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring an Optical TE Tunnel Using Explicit Path Option

Perform this task to configure a numbered or unnumbered optical TE tunnel on a router. This task can apply to both the head and tail router.


Note You cannot configure dynamic tunnels on the tail router.


SUMMARY STEPS

1. configure

2. interface tunnel-te number

3. ipv4 address ipv4-address mask
or
ipv4 unnumbered interface-type interface-instance

4. passive

5. match identifier

6. destination A.B.C.D

7. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface tunnel-te number

Example:

RP/0/RP0/CPU0:router(config)# interface tunnel-te99

Enters MPLS-TE interface configuration mode.

Step 3 

ipv4 address ipv4-address mask
or
ipv4 unnumbered interface-type interface-instance

Example:

RP/0/RP0/CPU0:router(config-if)# ipv4 address 99.99.99.2 255.255.255.254

Specifies a primary or secondary IPv4 address for an interface.

The network mask can be a four-part dotted decimal address. For example, 255.0.0.0 indicates that each bit equal to 1 means the corresponding address bit belongs to the network address.

The network mask can be indicated as a slash (/) and a number (prefix length). The prefix length is a decimal value that indicates how many of the high-order contiguous bits of the address compose the prefix (the network portion of the address). A slash must precede the decimal value, and there is no space between the IP address and the slash.

or

Enables IPv4 processing on a point-to-point interface without assigning an explicit IPv4 address to that interface.

Step 4 

passive

Example:

RP/0/RP0/CPU0:router(config-if)# passive

Configures a passive interface.

Note The tail (passive) router does not signal the tunnel, it simply accepts a connection from the head router. The tail router supports the same configuration as the head router.

Step 5 

match identifier

Example:

RP/0/RP0/CPU0:router(config-if)# match identifier

Configures the match identifier.

You must enter the hostname for the head router then underscore _t, and the tunnel number for the head router. If tunnel-te1 is configured on the head router with a hostname of gmpls1, CLI is match identifier gmpls1_t1.

Note The match identifier must correspond to the tunnel-te number configured on the head router. Together with the address specified using the destination keyword, this identifier uniquely identifies acceptable incoming tunnel requests.

Step 6 

destination A.B.C.D

Example:

RP/0/RP0/CPU0:router(config-if)# destination 192.168.92.125

Assigns a destination address on the new tunnel.

The destination address is the remote node's MPLS-TE router ID.

The destination address is the merge point between backup and protected tunnels.

Step 7 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuring LSP Hierarchy

This section describes the high-level steps required to configure LSP hierarchy. LSP hierarchy allows standard MPLS-TE tunnels to be established over GMPLS-TE tunnels.

Consider the following information when configuring LSP hierarchy:

LSP hierarchy supports numbered optical TE tunnels with IPv4 addresses only.

LSP hierarchy supports numbered optical TE tunnels using numbered or unnumbered TE links.


Note Before you can successfully configure LSP hierarchy, you must first establish a numbered optical tunnel between the headend and tailend routers, as described in Configuring Numbered and Unnumbered Optical TE Tunnels.


To configure LSP hierarchy, you must perform a series of tasks that have been previously described in this GMPLS configuration section. The tasks, which must be completed in the order presented, are as follows:

1. Establish an optical TE tunnel.

2. Configure an optical TE tunnel under IGP.

3. Configure the bandwidth on the optical TE tunnel.

4. Configure the optical TE tunnel as a TE link.

5. Configure an MPLS-TE tunnel.

Configuring Border Control Model

Border model lets you specify the optical core tunnels to be advertised to edge packet topologies. Using this model, the entire topology is stored in a separate packet instance, allowing packet networks where these optical tunnels are advertised to use LSP hierarchy to signal an MPLS tunnel over the optical tunnel.

Consider the following information when configuring protection and restoration:

The GMPLS optical TE tunnel must be numbered and have a valid IPv4 address.

The router ID used IGP area and instance must be consistent in all areas.

The OSPF instance may be a numeric or alphanumeric.


Note Border model control functionality is provided for multiple IGP instances in one area or in multiple IGP areas.


To configure border control model functionality, you will perform a series of tasks that have been previously described in this GMPLS configuration section. The tasks, which must be completed in the order presented, are as follows:

1. Configure two optical tunnels on different interfaces.


Note When configuring IGP, you must keep the optical and packet topology information in separate routing tables.


2. Configure OSPF adjacency on each tunnel.

3. Configure bandwidth on each tunnel.

4. Configure packet tunnels.

Configuring Path Protection

This section provides the following sections to configure path protection:

Configuring an LSP

Forcing Reversion of the LSP

Configuring an LSP

Path protection is enabled on a tunnel by adding an additional path option configuration at the active end. The path can be configured either explicitly or dynamically.

When the dynamic option is used for both working and protecting LSPs, CSPF extensions are used to determine paths with different degrees of diversity. When the paths are computed, they are used over the lifetime of the LSPs. The nodes on the path of the LSP determine if the PSR is or is not for a given LSP. This determination is based on information that is obtained at signaling.

Perform this task to configure an LSP for an explicit path.

SUMMARY STEPS

1. configure

2. interface tunnel-te number

3. ipv4 address ipv4-address mask
or
ipv4 unnumbered interface-type interface-instance

4. signalled-name name

5. switching transit capability switching type encoding encoding type

6. switching endpoint capability switching type encoding encoding type

7. priority setup-priority hold-priority

8. signalled-bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

9. destination A.B.C.D

10. direction [bidirectional]

11. path-option path-id explicit {name pathname | path-number}

12. path-option protecting path-id explicit {name pathname | path-number}

13. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface tunnel-te number

Example:

RP/0/RP0/CPU0:router(config)# interface tunnel-te1

Enters tunnel-te interface configuration mode.

Step 3 

ipv4 address ipv4-address mask
or
ipv4 unnumbered interface-type interface-instance

Example:

RP/0/RP0/CPU0:router(config-if)# ipv4 address

99.99.99.2 255.255.255.254

Specifies a primary or secondary IPv4 address for an interface.

The network mask can be a four-part dotted decimal address. For example, 255.0.0.0 indicates that each bit equal to 1 means the corresponding address bit belongs to the network address.

The network mask can be indicated as a slash (/) and a number (prefix length). The prefix length is a decimal value that indicates how many of the high-order contiguous bits of the address compose the prefix (the network portion of the address). A slash must precede the decimal value, and there is no space between the IP address and the slash.

or

Enables IPv4 processing on a point-to-point interface without assigning an explicit IPv4 address to that interface.

Step 4 

signalled-name name

Example:

RP/0/RP0/CPU0:router(config-if)# signalled-name tunnel-te1

Configures the name of the tunnel required for an MPLS TE tunnel.

Use the name argument to specify that is used to signal the tunnel.

Step 5 

switching transit capability switching type encoding encoding type

Example:

RP/0/RP0/CPU0:router(config-if)# switching transit lsc encoding sonetsdh

Specifies the switching capability and encoding types for all transit TE links used to signal the optical tunnel to configure an optical LSP.

Step 6 

switching endpoint capability switching type encoding encoding type

Example:

RP/0/RP0/CPU0:router(config-if)# switching endpoint psc1 encoding sonetsdh

Specifies the switching capability and encoding types for all endpoint TE links used to signal the optical tunnel that is mandatory to set up the GMPLS LSP.

Step 7 

priority setup-priority hold-priority

Example:

RP/0/RP0/CPU0:router(config-if)# priority 2 2

Configures setup and reservation priorities for MPLS-TE tunnels.

Step 8 

signalled-bandwidth {bandwidth [class-type ct] | sub-pool bandwidth}

Example:

RP/0/RP0/CPU0:router(config-if)# signalled-bandwidth 2488320

Configures the bandwidth required for an MPLS TE tunnel. The signalled-bandwidth command supports two bandwidth pools (class-types) for Diff-Serv Aware TE (DS-TE) feature.

Step 9 

destination A.B.C.D

Example:

RP/0/RP0/CPU0:router(config-if)# destination 24.24.24.24

Assigns a destination address on the new tunnel.

The destination address is the remote node's MPLS-TE router ID.

The destination address is the merge point between backup and protected tunnels.

Step 10 

direction [bidirectional]

Example:

RP/0/RP0/CPU0:router(config-if)# direction bidirection

Configures a bidirectional optical tunnel for GMPLS.

Step 11 

path-option path-id explicit {name pathname | path-number}

Example:

RP/0/RP0/CPU0:router(config-if)# path-option l explicit name po4

Configures the explicit path option and path ID.

Step 12 

path-option protecting path-id explicit {name pathname | path-number}

Example:

RP/0/RP0/CPU0:router(config-if)# path-option protecting 1 explicit name po6

Configures the path setup option to protect a path.

Step 13 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config-if)# end

or

RP/0/RP0/CPU0:router(config-if)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Forcing Reversion of the LSP

Perform this task to allow a forced reversion of the LSPs, which is only applicable to 1:1 LSP protection.

SUMMARY STEPS

1. configure

2. mpls traffic-eng path-protection switchover {tunnel name | number}

3. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

mpls traffic-eng path-protection switchover {tunnel name | number}

Example:

RP/0/RP0/CPU0:router(config)# mpls traffic-eng path-protection switchover 1

Specifies a manual switchover for path protection for a GMPLS optical LSP. The tunnel ID is configured for a switchover.

The mpls traffic-eng path-protection switchover command must be issued on both head and tail router of the GMPLS LSP to achieve the complete path switchover at both ends.

Step 3 

end
or
commit

Example:

RP/0/RP0/CPU0:router(config)# end

or

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

When you enter the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

When you enter the commit command, the system saves the configuration changes to the running configuration file and remains within the configuration session.

Configuration Examples for Cisco MPLS-TE

This section provides the following examples:

Configuring Fast Reroute and SONET APS: Example

Building MPLS-TE Topology and Tunnels: Example

Configuring IETF Diff-Serv TE Tunnels: Example

Configuring GMPLS: Example

Configuring Fast Reroute and SONET APS: Example

When SONET Automatic Protection Switching (APS) is configured on a router, it does not offer protection for tunnels; because of this limitation, fast reroute (FRR) still remains the protection mechanism for MPLS-TE.

When APS is configured in a SONET core network, an alarm might be generated toward a router downstream. If this router is configured with FRR, the hold-off timer must be configured at the SONET level to prevent FRR from being triggered while the core network is performing a restoration. Enter the following commands to configure the delay:

RP/0/RP0/CPU0:Route-3(config)# controller sonet 0/6/0/0 delay trigger line 250 
RP/0/RP0/CPU0:Route-3(config)# controller sonet 0/6/0/0 path delay trigger 300 

Building MPLS-TE Topology and Tunnels: Example

The following examples show how to build an OSPF and ISIS topology:

(OSPF)
...

configure

  mpls traffic-eng

  interface pos 0/6/0/0

  router id loopback 0

  router ospf 1

  router-id 192.168.25.66

  area 0

  interface pos 0/6/0/0

  interface loopback 0

  mpls traffic-eng router-id loopback 0

  mpls traffic-eng area 0

  rsvp

  interface pos 0/6/0/0

  bandwidth 100

  commit

show mpls traffic-eng topology

show mpls traffic-eng link-management advertisement

!

(ISIS)

...

configure
  mpls traffic-eng
  interface pos 0/6/0/0
  router id loopback 0
  router isis lab
  address-family ipv4 unicast
  mpls traffic-eng level 2
  mpls traffic-eng router-id Loopback 0
  !
  interface POS0/0/0/0
  address-family ipv4 unicast
!

The following example shows how to configure tunnel interfaces:

interface tunnel-te1

  destination 192.168.92.125

  ipv4 unnumbered loopback 0

  path-option l dynamic

  bandwidth 100

  commit

show mpls traffic-eng tunnels

show ipv4 interface brief

show mpls traffic-eng link-management admission-control

!

interface tunnel-te1

  autoroute announce

  route ipv4 192.168.12.52/32 tunnel-te1

  commit

ping 192.168.12.52

show mpls traffic autoroute

!

interface tunnel-te1

  fast-reroute

  mpls traffic-eng interface pos 0/6/0/0

  backup-path tunnel-te 2

  interface tunnel-te2

  backup-bw global-pool 5000

  ipv4 unnumbered loopback 0

  path-option l explicit name backup-path

  destination 192.168.92.125

 commit

show mpls traffic-eng tunnels backup

show mpls traffic-eng fast-reroute database

!

rsvp

  interface pos 0/6/0/0

  bandwidth 100 150 sub-pool 50

  interface tunnel-te1

  bandwidth sub-pool 10

commit

Configuring IETF Diff-Serv TE Tunnels: Example

The following example shows how to configure DiffServ-TE.

rsvp

 interface pos 0/6/0/0

 bandwidth rdm 100 150 bc1 50

 mpls traffic-eng

 ds-te mode ietf

 interface tunnel-te 1

 bandwidth 10 class-type 1

 commit

configure

 rsvp interface 0/6/0/0

 bandwidth mam max-reservable-bw 400 bc0 300 bc1 200

 mpls traffic-eng

 ds-te mode ietf

 ds-te model mam

 interface tunnel-te 1bandwidth 10 class-type 1

 commit

Configuring GMPLS: Example

This section includes the following sample configuration example for GMPLS:

Configuring Bidirectional Optical Tunnels using TE Links: Example

Configuring Bidirectional Optical Tunnels using TE Links: Example

This example shows how to set up head- and tail-end routers with bidirectional optical unnumbered tunnels using numbered TE links.

Head-end router

router ospf roswell
 router-id 11.11.11.11
 nsf cisco
 area 23
 !
 area 51
  interface Loopback 0
  !
  interface MgmtEth0/0/CPU0/1
  !
  interface POS0/4/0/1
  !
 !
 mpls traffic-eng router-id Loopback 0
 mpls traffic-eng area 51
!
 
   
rsvp
 interface POS0/2/0/3
  bandwidth 2000
 !
!
interface tunnel-te1
 ipv4 unnumbered Loopback 0
 switching transit fsc encoding sonetsdh
 switching endpoint psc1 encoding packet
 priority 3 3
 signalled-bandwidth 500
 destination 55.55.55.55
 direction bidirectional
 path-option 1 dynamic
!
 
   
mpls traffic-eng
 interface POS0/2/0/3
  flooding-igp ospf roswell area 51
  switching key 1
   encoding packet
   capability psc1
  !
  switching link
   encoding sonetsdh
   capability fsc
  !
  lmp data-link adjacency
   neighbor gmpls5
   remote te-link-id ipv4 10.0.0.5
   remote interface-id unnum 12
   remote switching-capability psc1
  !
 !
 lmp neighbor gmpls5
  ipcc routed
  remote node-id 55.55.55.55
 !
!
 
   

Tail-end router

router ospf roswell
 router-id 55.55.55.55
 nsf cisco
 area 23
 !
 area 51
  interface Loopback 0
  !
  interface MgmtEth0/0/CPU0/1
  !
  interface POS0/4/0/2
  !
 !
 mpls traffic-eng router-id Loopback 0
 mpls traffic-eng area 51
!
 
   
mpls traffic-eng
 interface POS0/2/0/3
  flooding-igp ospf roswell area 51
  switching key 1
   encoding packet
   capability psc1
  !
  switching link
   encoding sonetsdh
   capability fsc
  !
  lmp data-link adjacency
   neighbor gmpls1
   remote te-link-id ipv4 10.0.0.1
   remote interface-id unnum 12
   remote switching-capability psc1
  !
 !
 lmp neighbor gmpls1
  ipcc routed
  remote node-id 11.11.11.11
 !
!
rsvp
 interface POS0/2/0/3
  bandwidth 2000
 !
!
interface tunnel-te1
 ipv4 unnumbered Loopback 0
 passive
 match identifier head_router_hostname_t1
 destination 11.11.11.11
!

Additional References

For additional information related to implementing traffic engineering, refer to the following references:

Related Documents

Related Topic
Document Title

MPLS-TE commands

MPLS Traffic Engineering Commands on Cisco IOS XR Software, Release 3.3.0

Cisco CRS-1 router getting started material

Cisco IOS XR Getting Started Guide, Release 3.3.0

Information about user groups and task IDs

Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.3.0


Standards

Standards 1
Title

Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

1 Not all supported standards are listed.


MIBs

MIBs
MIBs Link

There are no applicable MIBs for this module.

To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL:

http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml


RFCs

RFCs
Title

4124

Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, Ed. June 2005.

(Format: TXT=79265 bytes) (Status: PROPOSED STANDARD)

4125

Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, W. Lai. June 2005.

(Format: TXT=22585 bytes) (Status: EXPERIMENTAL)

4127

Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, Ed. June 2005.

(Format: TXT=23694 bytes) (Status: EXPERIMENTAL)


Technical Assistance

Description
Link

The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/techsupport