Support for the Cisco 10720 Internet Router and the Cisco 12000 series router engine 3 was added.

12.2(18)SXD1

This feature was integrated into Cisco IOS Release 12.2(18)SX.

This document describes the Fast ReRoute (FRR) enhancements, including Node Protection, in Cisco IOS Release 12.0(24)S. Node Protection can be viewed as a superset of (that is, an enhancement to) FRR Link Protection. The document includes the following sections:

Note If you plan to use or already use MPLS Traffic Engineering Fast ReRoute Link Protection before Release 12.0(24)S, contact Cisco TAC Support for important deployment and upgrade information.

Feature Overview

Fast ReRoute (FRR) is a mechanism for protecting MPLS Traffic Engineering (TE) label-switched paths (LSPs) from link and node failures by locally repairing the LSPs at the point of failure, allowing data to continue to flow on them while their headend routers attempt to establish new end-to-end LSPs to replace them. FRR locally repairs the protected LSPs by rerouting them over backup tunnels that bypass failed links or nodes.

Backup tunnels that bypass only a single link of the LSP's path provide Link Protection. They protect LSPs if a link along their path fails by rerouting the LSP's traffic to the next hop (bypassing the failed link). These are referred to as next-hop (NHOP) backup tunnels because they terminate at the LSP's next hop beyond the point of failure. Figure 1 illustrates a next-hop backup tunnel.

Figure 1 Next-Hop Backup Tunnel

FRR provides Node Protection for LSPs. Backup tunnels that bypass next-hop nodes along LSP paths are called next-next-hop (NNH) backup tunnels because they terminate at the node following the next-hop node of the LSP paths, thereby bypassing the next-hop node. They protect LSPs if a node along their path fails by enabling the node upstream of the failure to reroute the LSPs and their traffic around the failed node to the next-next hop. FRR supports the use of RSVP Hellos to accelerate the detection of node failures. NNHOP backup tunnels also provide protection from link failures, because they bypass the failed link as well as the node.

If an LSP is using a backup tunnel and something changes so that the LSP is no longer appropriate for the backup tunnel, the LSP is torn down. Such changes include the following:

•Backup bandwidth of the backup tunnel is reduced.

•Backup bandwidth type of backup tunnel is changed to a type that is incompatible with the primary LSP.

•Primary LSP is modified so that Fast ReRoute is disabled. (The no mpls traffic-eng fast-reroute command is entered.)

The Fast ReRoute enhancements include the following:

•Backup tunnel support—Backup tunnels can terminate at the next-next hop to support FRR.

•Multiple backup tunnels—There no longer is a limit (except memory limitations) to the number of backup tunnels that can protect a given interface. In many topologies, support for Node Protection requires supporting multiple backup tunnels per protected interface. These backup tunnels can terminate at the same destination or at different destinations. That is, for a given protected interface, you can configure multiple NHOP or NNHOP backup tunnels.This allows redundancy and load balancing (see "Benefits").

•Bandwidth protection on backup tunnels—NHOP and NNHOP backup tunnels can be used to provide bandwidth protection for rerouted LSPs. This is referred to as backup-bandwidth.You can associate backup-bandwidth with NHOP or NNHOP backup tunnels. This informs the router of the amount of backup-bandwidth a particular backup tunnel can protect. When a router maps LSPs to backup tunnels, bandwidth protection ensures that an LSP uses a given backup tunnel only if there is sufficient backup-bandwidth. The router selects which LSPs use which backup tunnels in order to provide maximum bandwidth protection. That is, the router determines the best way to map LSPs onto backup tunnels in order to maximize the number of LSPs that can be protected. For information about mapping tunnels and assigning backup-bandwidth, see "Backup Tunnel Selection Procedure".

•Bandwidth pool restrictions for backup tunnels—You can restrict the types of LSPs that can use a given backup tunnel. Backup tunnels can be restricted so that only LSPs using sub-pool bandwidth can use them or only LSPs that use global-pool bandwidth can use them. This allows different backup tunnels to be used for voice and data. Example: The backup tunnel used for voice could provide bandwidth protection, and the backup tunnel used for data could (optionally) not provide bandwidth protection.

•Semi-dynamic backup tunnel paths—The path of a backup tunnel can be configured to be determined dynamically. This can be done by using the IP explicit address exclusion feature that was added in Release 12.0(14)ST. Using this feature, semi-dynamic NHOP backup tunnel paths can be specified simply by excluding the protected link; semi-dynamic NNHOP backup tunnel paths can be configured simply by excluding the protected node.

•RSVP Hello—RSVP Hello enables RSVP nodes to detect when a neighboring node is not reachable. This feature is useful when next-hop node failure is not detectable by link layer mechanisms, or when notification of link-layer failures is not available (for example, Gigabit Ethernet).

Benefits

Node Protection

Backup tunnels that terminate at the next-next hop protect both the downstream link and node. This provides protection for link and node failures.

Multiple Backup Tunnels Can Protect the Same Interface

In addition to being required for Node Protection, this enhancement provides the following benefits:

•Increased backup capacity—If the protected interface is a high-capacity link and no single backup path exists with an equal capacity, multiple backup tunnels can protect that one high-capacity link. The LSPs using this link will fail over to different backup tunnels, allowing all of the LSPs to have adequate bandwidth protection during failure (rerouting). If bandwidth protection is not desired, the router spreads LSPs across all available backup tunnels (that is, there is load balancing across backup tunnels). For a more detailed explanation, see "Backup Tunnel Selection Procedure".

Bandwidth Protection

Rerouted LSPs not only have their packets delivered during a failure, but the quality of service can also be maintained.

Scalability

A backup tunnel can protect multiple LSPs. Furthermore, a backup tunnel can protect multiple interfaces. This is called many-to-one (N:1) protection. N:1 protection has significant scalability advantages over one-to-one (1:1) protection, where a separate backup tunnel must be used for each LSP needing protection. N:1 protection is not new with Node Protection; it existed with Link Protection.

Example of 1:1 protection: When 5,000 backup tunnels protect 5,000 LSPs, each router along the backup path must maintain state for an additional 5,000 tunnels.

Example of N:1 protection: When one backup tunnel protects 5,000 LSPs, each router along the backup path maintains one additional tunnel.

RSVP Hello

RSVP Hello allows a router to detect when its neighbor has gone down but its interface to that neighbor is still operational. When Layer 2 link protocols are unable to detect that the neighbor is unreachable, Hellos provide the detection mechanism; this allows the router to switch LSPs onto its backup tunnels and avoid packet loss.

When a router's link or neighboring node fails, the router often detects this failure by an interface down notification. On a GSR Packet Over SONET (POS) interface, this notification is very fast. When a router notices that an interface has gone down, it switches LPSs going out that interface onto their respective backup tunnels (if any).

RSVP Hellos can also be used to trigger Fast ReRoute. If RSVP Hellos are configured on an interface, messages are periodically sent to the neighboring router. If no response is received, Hellos declare that the neighbor is down. This causes any LSPs going out that interface to be switched to their respective backup tunnels.

Backup Tunnels Terminating at Different Destinations

Figure 3 illustrates an interface that has multiple backup tunnels terminating at different destinations and demonstrates why, in many topologies, support for Node Protection requires supporting multiple backup tunnels per protected interface.

Figure 3 Backup Tunnels that Terminate at Different Destinations

In this illustration, a single interface on R1 requires multiple backup tunnels. LSPs traverse the following routes:

•R1, R2, R3

•R1, R2, R4

To provide protection if node R2 fails, two NNHOP backup tunnels are required: one terminating at R3 and one terminating at R4.

Backup Tunnels Terminating at the Same Destination

Figure 4 shows how backup tunnels terminating at the same location can be used for redundancy and load balancing. Redundancy and load balancing work for both NHOP and NNHOP backup tunnels.

Figure 4 Backup Tunnels that Terminate at the Same Destination

In this illustration, there are three routers: R1, R2, and R3. At R1, there are two NNHOP backup tunnels (T1 and T2) that go from R1 to R3 without traversing R2.

Redundancy—If R2 fails or the link from R1 to R2 fails, either backup tunnel can be used. If one backup tunnel is down, the other can be used. LSPs are assigned to backup tunnels when the LSPs are first established. This is done before a failure.

Load balancing—If neither backup tunnel has enough bandwidth to back up all LSPs, both tunnels can be used. Some LSPs will use one backup tunnel, other LSPs will use the other backup tunnel. The router decides the best way to fit the LSPs onto the backup tunnels.

Backup Tunnel Selection Procedure

When an LSP is signaled, each node along the LSP path that provides FRR protection for the LSP selects a backup tunnel for the LSP to use if either of the following events occurs:

•The link to the next hop fails.

•The next hop fails.

By having the node select the backup tunnel for an LSP before a failure occurs, the LSP can be rerouted onto the backup tunnel quickly if there is a failure.

For an LSP to be mapped to a backup tunnel, all of the following conditions must exist:

•The LSP is protected by FRR; that is, the LSP is configured with the tunnelmpls traffic-eng fast-reroute command.

•The backup tunnel is up.

•The backup tunnel is configured to have an IP address, typically a loopback address.

•The backup tunnel is configured to protect this LSP's outgoing interface; that is, the interface is configured with the mpls traffic-eng backup-path command.

•The backup tunnel does not traverse the LSP's protected interface.

•The backup tunnel terminates at the LSP's NHOP or NNHOP. If it is an NNHOP tunnel, it does not traverse the LSP's NHOP.

•The bandwidth protection requirements and constraints, if any, for the LSP and backup tunnel are met. For information about bandwidth protection considerations, see "Bandwidth Protection".

Bandwidth Protection

A backup tunnel can be configured to protect two types of backup-bandwidth:

•Limited backup-bandwidth—A backup tunnel provides bandwidth protection. The sum of the bandwidth of all LSPs using this backup tunnel cannot exceed the backup tunnel's backup-bandwidth. When assigning LSPs to this type of backup tunnel, sufficient backup-bandwidth must exist.

•Unlimited backup-bandwidth—The backup tunnel does not provide any bandwidth protection (that is, best-effort protection exists). There is no limit to the amount of bandwidth used by the LSPs that are mapped to this backup tunnel. LSPs that allocate zero bandwidth can only use backup tunnels that have unlimited backup-bandwidth.

Load-balancing on Limited-bandwidth Backup Tunnels

There may be more than one backup tunnel that has sufficient backup-bandwidth to protect a given LSP. In this case, the router chooses the one that has the least amount of backup-bandwidth available. This algorithm limits fragmentation, maintaining the largest amount of backup-bandwidth available.

Specifying limited backup bandwidth does not "guarantee" bandwidth protection if there is a link or node failure. For example, the set of NHOP and NNHOP backup tunnels that gets triggered when an interface fails may all share some link on the network topology, and this link may not have sufficient bandwidth to support all LSPs using this set of backup tunnels.

In Figure 5, both backup tunnels traverse the same links and hop. When the link between routers R1 and R4 fails, backup tunnels for primary tunnel 1 and primary tunnel 2 are triggered simultaneously. The two backup tunnels may share a link in the network.

Figure 5 Backup Tunnels Share a Link

In Figure 6, the backup tunnel for primary tunnel 1 may traverse routers R1-R2-R3-R4, and the backup tunnel for primary tunnel 2 may traverse routers R4-R2-R3-R1. In this case, the link R2-R3 may get overloaded if R1-R4 fails.

Figure 6 Overloaded Link

Load-balancing on Unlimited-bandwidth Backup Tunnels

More than one backup tunnel, each having unlimited backup-bandwidth, can protect a given interface. In this case, when choosing a backup tunnel for a given LSP, the router chooses the backup tunnel that has the least amount of backup-bandwidth in use. This algorithm evenly distributes the LSPs across backup tunnels based on LSP's bandwidth. If an LSP is requesting zero bandwidth, the router chooses the backup tunnel that is currently protecting the fewest LSPs.

Pool Type and Backup Tunnels

By default, a backup tunnel provides protection for LSPs that allocate from any pool (that is, global or sub-pool). However, a backup tunnel can be configured to protect only LSPs that use global-pool bandwidth, or only those that use sub-pool bandwidth.

Next-hop Versus Next-next Hop Backup Tunnels

More than one backup tunnel can protect a given LSP, where one backup tunnel terminates at the LSP's NNHOP, and the other terminates at the LSP's NHOP. In this case, the router chooses the backup tunnel that terminates at the NNHOP (that is, Fast ReRoute prefers NNHOP over NHOP backup tunnels).

Table 1 lists the tunnel selection priorities. The first choice is an NNHOP backup tunnel that acquires its bandwidth from a sub-pool or global-pool, and has limited bandwidth. If there is no such backup tunnel, the next choice (2) is a next-next hop backup tunnel that acquires a limited amount of bandwidth from any pool. The preferences go from 1 (best) to 8 (worst), where choice 3 is for an NNHOP backup tunnel with an unlimited amount of sub-pool or global-pool bandwidth.

Table 1 Tunnel Selection Priorities

Preference

Backup Tunnel Destination

Bandwidth Pool

Bandwidth Amount

1 (Best)

Next-next hop

Sub-pool or global-pool

Limited

2

Next-next hop

Any

Limited

3

Next-next hop

Sub-pool or global-pool

Unlimited

4

Next-next hop

Any

Unlimited

5

Next-hop

Sub-pool or global-pool

Limited

6

Next-hop

Any

Limited

7

Next-hop

Sub-pool or global-pool

Unlimited

8 (Worst)

Next-hop

Any

Unlimited

Figure 7 shows an example of the backup tunnel selection procedure based on the designated amount of global-pool and sub-pool bandwidth currently available.

Figure 7 Choosing from Among Multiple Backup Tunnels

In this example, an LSP requires 20 units (kilobits per second) of sub-pool backup-bandwidth. The best backup tunnel is selected as follows:

1. Backup tunnels T1 through T4 are considered first because they terminate at the NNHOP.

2. Tunnel T4 is eliminated because it only has 10 units of sub-pool backup-bandwidth.

3. Tunnel T1 is eliminated because it protects only LSPs using global-pool bandwidth.

4. Tunnel T3 is chosen over T2 because, although both have sufficient backup-bandwidth, T3 has the least backup-bandwidth available (leaving the most backup-bandwidth available on T2).

5. Tunnels T5 and T6 need not be considered because they terminate at an NHOP, and therefore are less desirable than T3, which terminates at an NNHOP.

Promotion

After a backup tunnel has been chosen for an LSP, conditions may change that will cause us to reevaluate this choice. This reevaluation, if successful, is called promotion. Such conditions may include:

1. A new backup tunnel comes up.

2. The currently chosen backup tunnel for this LSP goes down.

3. A backup tunnel's available backup-bandwidth increases. For example, an LSP protected by the tunnel has been reoptimized by the headend to use another path.

For cases 1 and 2, above, the LSP's backup tunnel is evaluated immediately. Case 3 is addressed by periodically reevaluating LSP-to-backup tunnel mappings. By default, background reevaluation is performed every 5 minutes. This interval is configurable via the mpls traffic-eng fast-reroute timers command.

Bandwidth Protection Considerations

There are numerous ways in which bandwidth protection can be ensured. Table 2 describes the advantages and disadvantages of two methods.

Table 2 Bandwidth Protection Methods

Method

Advantages

Disadvantages

Reserve bandwidth for backup tunnels explicitly.

It is simple.

It is a challenge to allow bandwidth sharing of backup tunnels protecting against independent failures.

Use backup tunnels that are signaled with zero bandwidth.

It provides a way to share bandwidth used for protection against independent failures, so it ensures more economical bandwidth usage.

It may be complicated to determine the proper placement of zero bandwidth tunnels.

Cisco implementation of FRR does not mandate a particular approach, and it provides the flexibility to use either of the above approaches. However, given a range of configuration choices, be sure that the choices constant with a particular bandwidth protection strategy.

The following sections describe some important issues in choosing an appropriate configuration:

The signaled bandwidth is used by the LSRs on the path of the backup tunnel to perform admission control and do appropriate bandwidth accounting.

The backup-bandwidth is used by the PLR (the head-end of the backup tunnel) to decide how much primary traffic can be rerouted to this backup tunnel if there is a failure.

Both parameters need to be set to ensure proper operation. The numerical value of the signaled bandwidth and the backup-bandwidth should be the same.

Protected Bandwidth Pools and the Bandwidth Pool from which the Backup Tunnel Reserves its Bandwidth

The tunnel mpls traffic-eng bandwidth command allows you to configure the following:

•Amount of bandwidth a backup tunnel reserves

•The DS-TE bandwidth pool from which the bandwidth needs to be reserved

Note Only one pool can be selected (that is, the backup tunnel can explicitly reserve bandwidth from either the global pool or the sub-pool, but not both).

The tunnel mpls traffic-eng backup-bwcommand allows you to specify the bandwidth pool to which the traffic must belong for the traffic to use this backup tunnel. Multiple pools are allowed.

There is no direct correspondence between the bandwidth pool that is protected and the bandwidth pool from which the bandwidth of the backup tunnel draws its bandwidth.

Example: In this example, assume the following:

•Bandwidth protection is desired only for sub-pool traffic, but the best-effort traffic using the global pool does not require bandwidth protection.

•Scheduling is configured so that sub-pool traffic uses the priority queue, and global pool traffic is served at a lower priority.

Bandwidth protection for 10 Kbps of sub-pool traffic on a given link can be achieved by any of the following combinations:

•tunnel mpls traffic-eng bandwidth sub-pool 10

tunnel mpls traffic-eng backup-bw sub-pool 10

•tunnel mpls traffic-eng bandwidth global-pool 10

tunnel mpls traffic-eng backup-bw sub-pool 10 global-pool unlimited

•tunnel mpls traffic-eng bandwidth global-pool 40

tunnel mpls traffic-eng backup-bw sub-pool 10 global-pool 30

Using Backup Tunnels Signaled with Zero Bandwidth

Frequently is desirable to use backup tunnels with zero signaled bandwidth, even when bandwidth protection is required. It may seem that if no bandwidth is explicitly reserved, no bandwidth guarantees can be provided. However, that is not necessarily true.

In the following situation:

•Only link protection is desired

•Bandwidth protection is desired only for sub-pool traffic

For each protected link AB with a max reservable sub-pool value of S, there may be a path from node A to node B such that the difference between max reservable global and max reservable sub-pool is at least S. If it is possible to find such paths for each link in the network, you can establish all the backup tunnels along such paths without any bandwidth reservations. If there is a single link failure, only one backup tunnel will use any link on its path. Since that path has at least S of available bandwidth (in the global pool), assuming that marking and scheduling is configured to classify the sub-pool traffic into a priority queue, the sub-pool bandwidth is guaranteed.

The above approach allows sharing of the global pool bandwidth between backup tunnels protecting independent link failures. The backup tunnels are expected to be used for only a short period of time after a failure (until the head-ends of affected LSPs reroute those LSPs to other paths with available sub-pool bandwidth). The probability of multiple unrelated link failures is very small (in the absence of node or SRLG failures, which result in multiple link failures). Therefore, it is reasonable to assume that link failures are in practice independent with high probability. This "independent failure assumption" in combination with backup tunnels signaled without explicit bandwidth reservation enables efficient bandwidth sharing that yields substantial bandwidth savings.

Backup tunnels protecting the sub-pool traffic do now draw bandwidth from any pool. Primary traffic using the global pool can use the entire global pool, and primary traffic using the sub-pool can use the entire sub-pool. Yet, sub-pool traffic has a complete bandwidth guarantee if there is a single link failure.

A similar approach can be used for node and SRLG protection. However, the decision of where to put the backup tunnels is more complicated because both node and SRLG failures effectively result in the simultaneous failure of several links. Therefore, the backup tunnels protecting traffic traversing all affected links cannot be computed independently of each other. The backup tunnels protecting groups of links corresponding to different failures can still be computed independently of each other, which results in similar bandwidth savings.

Signaled Bandwidth versus Backup-Bandwidth

Backup-bandwidth is used locally (by the router that is the head-end of the backup tunnel) to determine which, and how many, primary LSPs can be rerouted on a particular backup tunnel. The router ensures that the combined bandwidth requirement of these LSPs does not exceed the backup-bandwidth.

Therefore, even when the backup tunnel is signaled with zero bandwidth, the backup-bandwidth must be configured with the value corresponding to the actual bandwidth requirement of the traffic protected by this backup tunnel. Unlike the case when bandwidth requirements of the backup tunnels are explicitly signaled, the value of the signaled bandwidth (which is zero) is not the same value as the backup-bandwidth.

RSVP Hello Operation

RSVP Hello enables RSVP nodes to detect when a neighboring node is not reachable. This provides node-to-node failure detection. When such a failure is detected, it is handled in a similar manner as a link-layer communication failure.

RSVP Hello can be used by FRR when notification of link-layer failures is not available (for example, with Ethernet), or when the failure detection mechanisms provided by the link layer are not sufficient for the timely detection of node failures.

A node running Hello sends a Hello Request to a neighboring node every interval. If the receiving node is running Hello, it responds with Hello Ack. If four intervals pass and the sending node has not received an Ack or it receives a bad message, the sending node declares that the neighbor is down and notifies FRR.

•Number of acknowledgment messages that are missed before the sending node declares that the neighbor is down, by using the ip rsvp signalling hello refresh misses command

Note RSVP Hellos must be enabled on most Ethernet interfaces on Cisco Catalyst 6500 series switches and Cisco 7600 series routers to enable FRR operation. The only exception is the 4-port OSM-2+4GE-WAN+ Gigabit Ethernet WAN Optical Services Module, which does not require RSVP Hellos to be enabled.

Hello Instance

A Hello instance implements RSVP Hello for a given router interface address and remote IP address. A Hello instance is expensive because of the large number of Hello requests that are sent and the strains they put on the router resources. Therefore, create a Hello instance only when it is necessary and delete it when it is no longer needed.

If there is a Hello instance with no LSPs for an unreachable neighbor, do not delete the Hello instance. Convert the active Hello instance to a passive Hello instance because there may be an active instance on the neighboring router that is sending Hello requests to this instance.

Passive Hello Instances

Passive Hello instances respond to Hello Request messages (sending Ack messages), but do not initiate Hello Request messages and do not cause LSPs to be fast rerouted. A router with multiple interfaces can run multiple Hello instances to different neighbors or to the same neighbor.

A passive Hello instance is created when a Hello Request is received from a neighbor with a source IP address/destination IP address pair in the IP header for which a Hello instance does not exist.

Delete passive instances if no Hello messages are received for this instance within 10 minutes.

•debug ip rsvp hello—Verifies that a Hello instance has been created, a Hello instance has been deleted, and when communication with a neighbor has been lost.

Restrictions

•Interfaces must use MPLS Global Label Allocation.

•Backup tunnel headend and tailend routers must implement Fast ReRoute as described in this document and in draft-pan-rsvp-fastreroute-00.txt.

•Backup tunnels are not protected. If an LSP is actively using a backup tunnel and the backup tunnel fails, the LSP is torn down.

•LSPs that are actively using backup tunnels are not considered for promotion. So, if an LSP is actively using a backup tunnel and a better backup tunnel becomes available, the active LSP is not switched to the better backup tunnel.

•RSVP Hellos must be enabled on most Ethernet interfaces on Cisco Catalyst 6500 series switches and Cisco 7600 series routers to enable FRR operation. The only exception is the 4-port OSM-2+4GE-WAN+ Gigabit Ethernet WAN Optical Services Module, which does not require RSVP Hellos to be enabled.

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Standards, MIBs, RFCs, and Drafts

Standards

•draft-ietf-mpls-rsvp-lsp-tunnel-09.txt

•draft-pan-rsvp-fastreroute-00.txt

MIBs

No new or modified MIBs are supported by this feature.

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

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

RFCs and Drafts

This feature complies with draft-swallow-rsvp-bypass-label-03.txt.

Prerequisites

•Your network must support the following Cisco IOS features in order to support features described in this document:

–IP Cisco Express Forwarding (CEF)

–MPLS

•Your network must support at least one of the following protocols:

–IS-IS

–OSPF

•Cisco Catalyst 6500 series switches and Cisco 7600 series routers have the following additional prerequisites:

–You must also enable the MPLS Label Distribution Protocol (LDP), both globally and on at least one interface (preferably the TE tunnel interface). To globally enable LDP, use the mpls ip command in global configuration mode. To enable LDP on an interface, use the mpls ip command in interface configuration mode.

–RSVP Hellos must be enabled on most Ethernet interfaces to enable FRR operation. The only exception is the 4-port OSM-2+4GE-WAN+ Gigabit Ethernet WAN Optical Services Module, which does not require RSVP Hellos to be enabled.

Configuration Tasks

This section assumes that you want to add Fast ReRoute protection to a network in which MPLS TE LSPs are configured.

Before performing the configuration tasks, it is assumed that you have done the following tasks but you do not have to already have configured MPLS TE tunnels:

Enabling Fast ReRoute on LSPs

LSPs can use backup tunnels only if they have been configured as fast reroutable. To do this, enter the following commands, beginning in global configuration mode, at the headend of each LSP:

Command

Purpose

Step 1

Router(config)# interface tunnel number

Enters interface configuration mode for the specified tunnel.

Step 2

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

Enables the tunnel to use a backup tunnel if there is a link or node failure.

Creating a Backup Tunnel to the Next Hop or to the Next-Next Hop

To create a backup tunnel to the next hop or to the next-next hop, enter the following commands on the node that will be the headend of the backup tunnel (that is, the node whose downstream link or node may fail). The node on which you enter these commands must be a supported platform. See "Supported Platforms and Interfaces".

Creating a backup tunnel is basically no different from creating any other tunnel. None of the commands below is new.

Note When using the exclude-address command to specify the path for a backup tunnel, the exclude-address must exclude an interface address to avoid a link (for creating an NHOP backup tunnel), or a router-ID address to avoid a node (for creating an NNHOP backup tunnel).

Command

Purpose

Step 1

Router(config)# interface tunnel number

Creates a new tunnel interface and enters interface configuration mode.

Step 2

Router(config-if)# ip unnumbered loopback0

Gives the tunnel interface an IP address which is the same as that of interface Loopback0.

Note This command is not effective until Lookback0 has been configured with an IP address.

Step 3

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

Specifies the IP address of the device where the tunnel will terminate. This address should be the router-id of the device which is the NHOP or NNHOP of LSPs to be protected.

The backup tunnel's path will be computed by using the topology database to find the shortest path to the destination (A.B.C.D) that meets the constraints. The only constraint we have configured (via the explicit-path, below) is that the path should avoid the protected link or node.

Step 6

Router(config)# ip explicit-path name name

Enters the subcommand mode for IP explicit paths to create the named path.

Step 7

Router(cfg-ip-expl-path)# exclude-address address

For Link Protection, specify the IP address of the link to be protected. For Node Protection, specify the router-ID of the node to be protected.

Note Backup tunnel paths can be dynamic or explicit and they do not have to use exclude-address. Because backup tunnels must avoid the protected link or node, it is convenient to use an exclude-address.

Assigning Backup Tunnels to a Protected Interface

To assign one or more backup tunnels to a protected interface, enter the following commands on the node that will be the headend of the backup tunnel (that is, the node whose downstream link or node may fail). The node on which you enter these commands must be a supported platform. See "Supported Platforms and Interfaces".

Note You must configure the interface to have an IP address and to enable the MPLS Traffic Engineering tunnel feature.

Command

Purpose

Step 1

Router(config)# interfacetype slot/port

Moves configuration to the physical interface level, directing subsequent configuration commands to the specific physical interface identified by the type. The slot and port identify the slot and port being configured. The interface must be a supported interface. See "Supported Platforms and Interfaces".

Step 2

Router(config-if)# mpls traffic-eng backup-path tunnel tunnel-id

Allows LSPs going out this interface to use this backup tunnel if there is a link or node failure.

Note You can enter this command multiple times to associate multiple backup tunnels with the same protected interface.

Associating Backup-Bandwidth and Pool Type with a Backup Tunnel

To associate backup-bandwidth with a backup tunnel and designate the type of LSP that can use a backup tunnel, enter the following command:

Command

Purpose

Router(config-if)# tunnel mpls traffic-eng backup-bw {bandwidth |

[sub-pool {bandwidth | Unlimited}]

[global-pool {bandwidth | Unlimited}]}

[any {bandwidth | Unlimited}]}

Associates bandwidth with a backup tunnel and designates whether LSPs that allocatebandwidth from the specified pool can use the tunnel.

Configuring an Interface for Fast Link and Node Failure Detection

To configure pos ais-shut, enter the following commands:

interface pos0/0

pos ais-shut

To configure pos report lrdi on OS interfaces, enter the following commands:

interface pos0/0

pos report lrdi

Verifying That Fast ReRoute Is In Place

To ensure that Fast ReRoute can function, do the following:

•Determine if Fast ReRoute has been configured correctly.

•Verify that certain conditions exist so that backup tunnels can be operational.

•Enter the show mpls traffic-eng fast-reroute database command.

•Enter the show mpls traffic tunnel backup command.

•Enter the show ip rsvp sender command, with the detail keyword specified.

•Enter the show ip rsvp reservation command, with the detail keyword specified.

Fast ReRoute Configuration

To determine if Fast ReRoute has been configured correctly, do the following:

•Verify that backup tunnels are up. To do so, enter the show mpls traffic-eng tunnels brief command.

•Verify that LSPs are protected by the appropriate backup tunnels. To do so, enter the show ip rsvp sender command with the detail keyword.

Conditions that Must Exist for Backup Tunnels to be Operational

If you created LSPs and performed the required configuration tasks but do not have operational backup tunnels (that is, the backup tunnels are not up or the LSPs are not associated with those backup tunnels), verify that all the following conditions exist:

•LSP is reroutable—At the headend of the LSP, enter the show run int tunnel tunnel-number command.The output should include the tunnel mpls traffic-eng fast-reroute command. If it does not, enter this command for the tunnel.

On the router where the backup tunnels originate, enter the show mpls traffic-eng tunnels backup command.The command output will allow you to verify the following:

•Backup tunnel exists—Verify that there is a backup tunnel that terminates at this LSP's NHOP or NNHOP. Look for the LSP's NHOP or NNHOP in the Dest field.

•Backup tunnel is up—To verify that the backup tunnel is up, look for "Up" in the State field.

•Backup tunnel is associated with LSP's I/F—Verify that the interface for the LSP is allowed to use this backup tunnel. Look for the LSP's output interface in the "protects" field list.

•Backup tunnel has sufficient bandwidth—If you restricted the amount of bandwidth a backup tunnel can hold, verify that the backup tunnel has sufficient bandwidth to hold the LSPs that would use this backup tunnel if there is a failure. The bandwidth of an LSP is defined by the line tunnel mpls traffic-eng bandwidthat the headend of the LSP. To determine the available bandwidth on a backup tunnel, look at the "cfg" and "inuse" fields. If there is insufficient backup-bandwidth to accommodate the LSPs that would use this backup tunnel in the event of a failure, create an additional backup tunnel or increase the backup-bandwidth of the existing tunnel by using the tunnel mpls traffic-eng backup-bwcommand.

Note To determine how much bandwidth is sufficient, offline capacity planning may be required.

•Backup tunnel has appropriate bandwidth type—If you restricted the type of LSPs (sub-pool or global-pool) that can use this backup tunnel, verify that the LSP is the appropriate type for the backup tunnel. The type of the LSP is defined by the line tunnel mpls traffic-eng bandwidthat the headend of this LSP. If this line contains the word "sub-pool", then it uses sub-pool bandwidth; otherwise, it uses global-pool bandwidth. Verify that the type matches the type the backup tunnel can hold by looking in the output of the above command.

If none of the above actions works, enable debug by entering the debug ip rsvp fast-reroute command and the debug mpls traffic-eng fast-reroute command on the router that is the headend of the backup tunnel. Then do the following:

Note•If LDP is not enabled, separate prefix items are not shown because all prefixes then use a single rewrite. To confirm that a particular IP prefix is FRR protected, even though it is not shown in this display, enter it within the show mpls forwarding-table ip_address detail command. The final line of the display will tell whether that prefix is protected:

The command shows the following information for a given backup tunnel:

•Tunnel ID

•Tunnel destination

•Tunnel state—Up designates the status of the backup tunnel

•Backup-bandwidth configured for each pool this tunnel protects

•Backup-bandwidth in use for each pool

•Number of LSPs currently using this backup tunnel

•Protected interfaces that are using the backup tunnel

show ip rsvp sender command

Following is sample output from the show ip rsvp sender detail command when the command is entered at the Point of Local Repair (PLR) before a failure. For a detailed explanation of the output, see the show ip rsvp sender command.

Router# show ip rsvp sender detail

PATH:

Tun Dest: 24.1.1.1 Tun ID: 1 Ext Tun ID: 23.1.1.1

Tun Sender: 23.1.1.1, LSP ID: 126

Path refreshes arriving on POS1/0 from PHOP 11.1.1.1

Path refreshes being sent to NHOP 12.1.1.2 on POS1/1

Session Attr::

Setup Prio: 0, Holding Prio: 0

Flags: Local Prot desired, Label Recording, SE Style

Session Name:tagsw4500-23_t1

ERO:

12.1.1.2 (Strict IPv4 Prefix, 8 bytes, /32)

14.1.1.1 (Strict IPv4 Prefix, 8 bytes, /32)

14.1.1.2 (Strict IPv4 Prefix, 8 bytes, /32)

24.1.1.1 (Strict IPv4 Prefix, 8 bytes, /32)

Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytes

Fast-Reroute Backup info:

Inbound FRR: Not active

Outbound FRR: Ready -- backup tunnel selected

Backup Tunnel: Tu2 (label 0)

Bkup Sender Template:

Tun Sender: 15.1.1.1, LSP ID: 126

Bkup FilerSpec:

Tun Sender: 15.1.1.1, LSP ID 126

show ip rsvp reservation command

Following is sample output from the show ip rsvp reservation command entered at the head-end of a primary LSP. Entering the command at the head-end of the primary LSP shows, among other things, the status of FRR (that is, local protection) at each hop this LSP traverses. The per-hop information is collected in the Record Route Object (RRO) that travels with the Resv message from the tail to the head.

Router# sho ip rsvp res det

Reservation:

Tun Dest: 24.1.1.1 Tun ID: 1 Ext Tun ID: 23.1.1.1

Tun Sender: 23.1.1.1 LSP ID: 104

Next Hop: 11.1.1.2 on POS1/0

Label: 18 (outgoing)

Reservation Style is Shared-Explicit, QoS Service is Controlled-Load

Average Bitrate is 0 bits/sec, Maximum Burst is 1K bytes

Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes

RRO:

12.1.1.1/32, Flags:0x1 (Local Prot Avail/to NHOP)

Label subobject: Flags 0x1, C-Type 1, Label 18

14.1.1.1/32, Flags:0x0 (Local Prot Avail/In Use/Has BW/to NHOP)

Label subobject: Flags 0x1, C-Type 1, Label 16

14.1.1.2/32, Flags:0x0 (No Local Protection)

Label subobject: Flags 0x1, C-Type 1, Label 0

Resv ID handle: CD000404.

Policy: Accepted. Policy source(s): MPLS/TE

Notice the following about the primary LSP:

•It has protection that uses a NHOP backup tunnel at its first hop.

•It has protection and is actively using an NHOP backup tunnel at its second hop.

•It has no local protection at its third hop.

The RRO display shows the following information, for each hop:

•Whether local protection is available (that is, whether the LSP has selected a backup tunnel)

•Whether local protection is in use (that is, whether the LSP is currently using its selected backup tunnel)

•Whether the selected backup tunnel is an NHOP or NNHOP backup tunnel

•Whether the backup tunnel used at this hop provides bandwidth protection

At a Point of Local Repair (PLR), LSPs transition from Ready to Active if one of the following events occurs:

•Primary interface goes down—If the primary interface (LSP's outbound interface) goes down and the LSP is ready to use a backup tunnel, the LSP will transition to the active state causing its data to flow over the backup tunnel. On some platforms and interface types (for example, GSR POS interfaces), fast interface-down logic has been added to detect this event very quickly. On other platforms where this logic does not exist, detection time is slower. On such platforms, it may be desirable to enable RSVP Hello (see the next bulleted item, "Hellos detect next hop is down").

•Hellos detect next hop is down—If Hellos are enabled on the primary interface (LSP's outbound interface), and the LSP's next hop is no longer reachable, the next hop is declared down. This event will cause the LSP to begin actively using its backup tunnel. Notice that a next hop will be declared down even if the primary interface does not go down. For example, if the next hop stops responding due to a reboot or software/hardware problem, Hellos will trigger the LSPs using this next hop to switch to their backup tunnels. Hellos can also help trigger Fast ReRoute on interfaces such as Gigabit Ethernet where the interface remains up but is unusable (due to lack of link-layer liveness detection mechanisms).

Primary Tunnel Does Not Select Backup Tunnel That is Up

If a backup tunnel is up, but it is not selected as a backup tunnel by the primary tunnel (LSP), enter the following commands for the backup tunnel:

•shutdown

•no shutdown

Note If you change the status of a backup tunnel, the backup tunnel selection algorithm is rerun for the backup tunnel. LSPs that have currently selected (that is, are ready to use) that backup tunnel will be disassociated from it, and then reassociated with that backup tunnel or another backup tunnel. This is generally harmless and usually results in mapping the same LSPs to that backup tunnel. However, if any LSPs are actively using that backup tunnel, shutting down the backup tunnel will tear down those LSPs.

Enhanced RSVP Commands

The following RSVP commands have been enhanced to display information that can be helpful when examining Fast ReRoute state or when troubleshooting Fast ReRoute:

These commands show control plane state; they do not show data state. That is, they show information about RSVP messages (Path and Resv) used to signal LSPs. For information about the data packets being forwarded along LSPs, use the show mpls forwarding command.

RSVP Hello

The RSVP Hello feature enables RSVP nodes to detect when a neighboring node is not reachable. Use this feature when notification of link-layer failures is not available and unnumbered links are not used, or when the failure detection mechanisms provided by the link layer are not sufficient for timely node failure detection. Hello must be configured both globally on the router and on the specific interface to be operational.

•Verify that at least one LSP has a backup tunnel by viewing the output of the "show ip rsvp sender" command. A value of "Ready" indicates that a backup tunnel has been selected.

"No entry at index (error may self-correct, RRO may not yet have propagated from downstream node of interest)" Error Message is Printed at the Point of Local Repair

Fast ReRoute relies on a Record Route Object (RRO) in Resv messages arriving from downstream. Routers receiving Path messages with the SESSION_ATTRIBUTE bit indicating that the LSP is fast-reroutable should include an RRO in the corresponding Resv messages.

If an LSP is configured for Fast ReRoute, but the Resv arriving from a downstream router contains an incomplete RRO, the "No entry at index (error may self-correct, RRO may not yet have propagated from downstream node of interest)" message is printed. An incomplete RRO is one in which the NHOP or the NNHOP did not include an entry in the RRO.

This error typically means that backup tunnels to the NHOP or the NNHOP cannot be selected for this LSP because there is insufficient information about the NHOP or NNHOP due to the lack of an RRO entry.

Occasionally there are valid circumstances in which this situation occurs temporarily and the problem is self-corrected. If subsequent Resv messages arrive with a complete RRO, ignore the error message.

To determine whether the error has been corrected, view the RRO in Resv messages by entering the clear ip rsvp hello instance counters command. Use an output filter keyword to view only the LSP of interest.

"Couldn't get rsbs (error may self-correct when Resv arrives)" Error Message is Printed at the Point of Local Repair

The PLR cannot select a backup tunnel for an LSP until a Resv message has arrived from downstream.

When this error occurs, it typically means that something is truly wrong. For example, no reservation exists for this LSP. You can troubleshoot this problem by using the debug ip rsvp reservation command to enable debug.

Occasionally there are valid circumstances in which this error message occurs and there is no need for concern. One such circumstance is when an LSP experiences a change before any Resv message has arrived from downstream. Changes can cause a PLR to try to select a backup tunnel for an LSP, and the selection will fail (causing this error message) if no Resv message has arrived for this LSP.

Enabling Fast ReRoute for all Tunnels

On router R1, enter interface configuration mode for each tunnel to be protected (Tunnel 1000 and Tunnel 2000). Enable these tunnels to use a backup tunnel in case of a link or node failure along their paths. Tunnel 1000 will use 10 units of bandwidth from the sub-pool; Tunnel 2000 will use 5 units of bandwidth from the global-pool.

interface Tunnel1000

tunnel mpls traffic-eng fast-reroute

tunnel mpls traffic-eng bandwidth sub-pool 10

interface Tunnel2000

tunnel mpls traffic-eng fast-reroute

tunnel mpls traffic-eng bandwidth 5

Creating an NHOP Backup Tunnel

On router R2, create an NHOP backup tunnel to R3. This backup tunnel should avoid using the link 12.1.1.2.

Associating Backup-Bandwidth and Pool Type with Backup Tunnels

Backup tunnel 1 is to be used only by LSPs that take their bandwidth from the global pool. It does not provide bandwidth protection. Backup tunnel 2 is to be used only by LSPs that take their bandwidth from the sub-pool. Backup tunnel 2 provides bandwidth protection for up to 1000 units.

Syntax Description

Defaults

Command Modes

Global EXEC

Command History

Release

Modification

12.0(22)S

This command was introduced.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Examples

Following is sample output from the show ip rsvp hello instance detail command and then the clear ip rsvp hello instance counters command. Notice that the "Statistics" fields have been cleared to zero.

ip rsvp signalling hello dscp

To set the Differentiated Services Code Point (DSCP) value that is in the IP header of the Hello message sent out from an interface, use the ip rsvp signalling hello dscp command in interface configuration mode. To disable this feature, use the no form of this command.

ip rsvp signalling hello dscp [num]

no ip rsvp signalling hello dscp

Syntax Description

num

(Optional) DSCP value. Valid values are from 0 to 63.

Defaults

The default value is 0.

Command Modes

Interface configuration

Command History

Release

Modification

12.0(22)S

This command was introduced.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Usage Guidelines

If a link is congested, it is recommended that you set the DSCP to a value higher than zero (0) to reduce the likelihood that Hello messages will be dropped.

You configure the DSCP per interface, not per flow.

The DSCP applies to all RSVP flows installed on a specific interface. You can configure each interface independently for DSCP.

Examples

In the following example, Hello messages sent from this interface have a DSCP value of 48:

ip rsvp signalling hello refresh interval

Syntax Description

Frequency, in milliseconds, at which a node sends Hello messages to a neighbor. Valid values are from 10 to 30,000.

Defaults

200 milliseconds

Command Modes

Interface configuration

Command History

Release

Modification

12.0(22)S

This command was introduced.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Usage Guidelines

You can configure the Hello request interval on a per-neighbor basis. A node periodically generates a Hello message containing a HELLO REQUEST object for each neighbor whose status is being tracked. The frequency of those Hello messages is determined by the Hello interval.

Examples

In the following example, Hello requests are sent to a neighbor every 50 milliseconds:

ip rsvp signalling hello refresh misses

To specify how many Hello acknowledgments a node can miss in a row before the node considers that communication with its neighbor is down, use the ip rsvp signalling hello refresh misses command in interface configuration mode.

ip rsvp signalling hello refresh misses num

Syntax Description

num

The number of sequential Hello acknowledgments that a node can miss. Valid values are from 4 to 10.

Defaults

The default is 4.

Command Modes

Interface configuration

Command History

Release

Modification

12.0(22)S

This command was introduced.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Usage Guidelines

Hello comprises a Hello message, a HELLO REQUEST object, and a HELLO ACK object. Each request is answered by an acknowledgment. If a link is very congested or has a very heavy load, set this number to a value higher than the default value to ensure that Hello does not falsely declare that a neighbor is down.

Examples

In the following example, if the node does not receive five Hello acknowledgments in a row, the node declares that its neighbor is down:

mpls traffic-eng backup-path

To assign one or more backup tunnels to a protected interface, use the mpls traffic-eng backup-path command in interface configuration mode.

mpls traffic-eng backup-path tunneltunnel-id

Syntax Description

tunneltunnel-id

Tunnel ID of the backup tunnel that can be used in case of a failure.

Defaults

No backup tunnels are used if this interface goes down.

Command Modes

Interface configuration

Command History

Release

Modification

12.0(10)ST

This command was introduced.

12.0(16)ST

With Link Protection, this command selected the one-and-only backup tunnel for a given protected interface. If you enter the command twice, the second occurrence overwrites the first occurrence.

12.0(22)S

You can now enter this command multiple times to select multiple backup tunnels for a given protected interface. This can be done for both Link and Node Protection. The command is supported on the Cisco 10000 series ESRs.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Usage Guidelines

Enter this command on the interface to be protected (Link Protection), or on the interface whose downstream node is being protected (Node Protection). You can enter this command multiple times to select multiple backup tunnels for a given protected interface. An unlimited number of backup tunnels can be assigned to protect an interface. The only limitation is memory. By entering this command on a physical interface, LSPs using this interface (sending data out of this interface) can use the indicated backup tunnels if there is a link or node failure.

Examples

The following example assigns backup tunnel 34 to interface POS5/0:

Router(config)# interface pos5/0

Router(config-if)# mpls traffic-eng backup-path tunnel34

Related Commands

Command

Description

tunnel mpls traffic-eng fast-reroute

Enables an MPLS Traffic Engineering tunnel to use a backup tunnel if there is a link or node failure (provided that a backup tunnel exists).

mpls traffic-eng fast-reroute timers

To specify how often the router considers switching an LSP to a new (better) backup tunnel if additional backup-bandwidth becomes available, use the mpls traffic-eng fast-reroute timers command in global configuration mode. To disable this timer, set the frequency to zero or use the no form of this command.

mpls traffic-eng fast-reroute timers [frequency frequency]

no mpls traffic-eng fast-reroute timers

Syntax Description

frequency frequency

(Optional) Interval, in seconds, between scans to determine if an LSP should use a new, better backup tunnel. Valid values are from 0 to 604800. A value of 0 disables promotions to a better LSP.

Defaults

By default, the timer is running and is set to a frequency of every 300 seconds (5 minutes). If you enter no mpls traffic-eng fast-reroute timers, the router returns to this default behavior.

Command Modes

Global configuration

Command History

Release

Modification

12.0(22)S

This command was introduced.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Examples

In the following example, LSPs are scanned every 2 minutes (120 seconds) to see if they should be promoted to a better backup tunnel.

Router(config)# mpls traffic-eng fast-reroute timers frequency 120

show ip rsvp hello

To show if Hello is enabled globally on the router and if Hello statistics are enabled, use the show ip rsvp hello command in global EXEC mode.

Status of communication. Values are UP (node is communicating with its neighbor) and LOST (communication has been lost or never was established).

Type

Values are ACTIVE (node is sending requests) and PASSIVE (node is responding to a request).

I/F

Interface type.

LSPs protecting

Number of LSPs that are being protected.

Refresh Interval Configured

The frequency with which a node generates a Hello message containing a HELLO REQUEST object for each neighbor whose status is being tracked. The frequency of these Hello messages is determined by the Hello interval specified in the ip rsvp signalling hello refresh interval command.

Min

Minimum refresh interval.

Max

Maximum refresh interval.

Average

Average refresh interval.

Waverage

Weighted average refresh interval.

Current

Current refresh interval.

Src_instance

Source instance field value.

Dst_instance

Destination instance field value.

Communication with neighbor lost

Subsequent fields designate the number of times that communication with the neighbor was lost and why.

Num times

Total number of times that communication with neighbor was lost.

Reasons

Subsequent fields designate why communication with the neighbor was lost.

Missed acks

Number of times that communication was lost due to missed ACKs.

Bad Src_Inst received

Number of times that communication was lost due to bad Bad Src_Inst fields.

Bad Dst_Inst received

Number of times that communication was lost due to bad Dst_Inst fields.

Syntax Description

(Optional) Displays information only for tunnels that go to a particular destination (tail) that is specified in the IP address.

sourceipaddress

(Optional) Displays information only for tunnels originating at the headend specified in the IP address.

dst-port pnum

(Optional) Destination port. Displays information only for tunnels that have the tunnel ID specified in the pnum field.

src-portpnum

(Optional) Source port. Displays information only for tunnels that have the LSP ID (also called the tunnel instance) specified in the pnum field.

Defaults

This command has no default behavior or values.

Command Modes

EXEC

Command History

Release

Modification

11.2

This command was introduced.

12.2

The detail keyword was added to display additional request information.

12.0(22)S

This command has been enhanced to show some useful Fast ReRoute information for when an LSP is actively using a backup tunnel that terminates at this node (that is, when a node is the Merge Point.) If desired, information for only a single tunnel or a subset of tunnels can be displayed. The command is supported on the Cisco 10000 series ESRs.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Usage Guidelines

When hundreds or thousands of tunnels exist and you are interested in only a few, it is useful to display output for only a single tunnel or a subset of tunnels. To request a limited display, enter the show ip rsvp request command with the appropriate keyword (which in this case is called an output filter): destination, source, dst-port, and src-port. You can enter any or all of the output filters, and you can enter them whether or not you specify the detail keyword.

Examples

Following is sample output from the show ip rsvp request detail command when the command is entered on the Merge Point (MP) before a failure and after a failure.

Notice that after the failure, there are two entries for the rerouted LSP. Information referenced in the following explanation is highlighted.

The first entry continues to show the pre-failure information (i.e., Resv messages are being sent to 14.1.1.1 on Ethernet1). This state is for the Resv being sent upstream before the failure, in response to Path messages sent before the failure. This state may time out quickly, or it may continue to be refreshed for a few minutes if, for example, an upstream node is unaware of the failure.

The second entry shows the post-failure information (i.e., Resv messages are being sent to 15.1.1.1 on Ethernet2). This state is for the Resv messages being sent upstream after the failure (to the PLR), and will remain and be refreshed as long as the LSP is rerouted.

In this example, the MP is also the tail of the LSP. There is no RRO information because there are no nodes downstream.

show ip rsvp reservation

To display downstream reservation state information (that is, information related to the Resv message arriving from downstream), use the show ip rsvp reservation command in EXEC mode.

Syntax Description

(Optional) Displays information only for tunnels that go to a particular destination (tail) that is specified in the IP address.

sourceipaddress

(Optional) Displays information only for tunnels originating at the headend specified in the IP address.

dst-port pnum

(Optional) Destination port. Displays information only for tunnels that have the tunnel ID specified in the pnum field.

src-portpnum

(Optional) Source port. Displays information only for tunnels that have the LSP ID (also called the tunnel instance) specified in the pnum field.

Defaults

This command has no default behavior or values.

Command Modes

EXEC

Command History

Release

Modification

11.2

This command was introduced.

12.2

The detail keyword was added to display additional reservation information.

12.0(22)S

The command displays useful Fast ReRoute information when an LSP is actively using a backup tunnel at this node (that is, when a node is the PLR). If desired, information for only a single tunnel or a subset of tunnels can be displayed. The command is supported on the Cisco 10000 series ESRs.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Usage Guidelines

When hundreds or thousands of tunnels exist and you are interested in only a few, it is useful to display output for only a single tunnel or a subset of tunnels. To request a limited display, enter the show ip rsvp reservation command with the appropriate keyword (which in this case is called an output filter): destination, source, dst-port, and src-port. You can enter any or all of the output filters, and you can enter them whether or not you specify the detail keyword.

Examples

Following is sample output from the show ip rsvp reservation detail command when the command is entered on the Point of Local Repair (PLR) before a failure and after a failure.

•At the PLR, you see "FRR is in progress (we are PLR)" when an LSP has been rerouted (that is, it is actively using a backup tunnel).

•Resv messages arrive on a different interface and from a different Next Hop after a failure. The pre-failure display shows the original NHOP and arriving interface; the post-failure display shows both the original and the new (Bkup) NHOP and arriving interface. The label is also shown.

•The RRO in arriving Resv messages changes after the failure, given that the Resv messages will avoid the failure (that is, it will traverse different links and/or hops).

Related Commands

Command

Description

ip rsvp reservation

Enables a router to simulate RSVP Resv message reception from the sender.

show ip rsvp sender

To display path state information (that is, information related to the Path messages arriving from upstream), and the state of Fast ReRoute for a given MPLS Traffic Engineering LSP, use the show ip rsvp sender command in EXEC mode.

Syntax Description

(Optional) Displays information only for tunnels that go to a particular destination (tail) that is specified in the IP address.

sourceipaddress

(Optional) Displays information only for tunnels originating at the headend specified in the IP address.

dst-port pnum

(Optional) Destination port. Displays information only for tunnels that have the tunnel ID specified in the pnum field.

src-portpnum

(Optional) Source port. Displays information only for tunnels that have the LSP ID (also called the tunnel instance) specified in the pnum field.

Defaults

This command has no default behavior or values.

Command Modes

EXEC

Command History

Release

Modification

11.2

This command was introduced.

12.0(22)S

The command output includes additional information that can be helpful when examining Fast ReRoute state or when troubleshooting Fast ReRoute. If desired, information for only a single tunnel or a subset of tunnels can be displayed. The command is supported on the Cisco 10000 series ESRs.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Usage Guidelines

This command is very useful for determining the state of RSVP signalling both before and after an LSP has been fast rerouted. The command is most useful when you enter it at the Point of Local Repair (PLR) or at the Merge Point (MP).

When hundreds or thousands of tunnels exist and you are interested in only a few, it is useful to display output for only a single tunnel or a subset of tunnels. To request a limited display, enter the show ip rsvp sender command with the appropriate keyword (which in this case is called an output filter): destination, source, dst-port, and src-port. You can enter any or all of the output filters, and you can enter them whether or not you specify the detail keyword.

Examples

Following is sample output from the show ip rsvp sender detail command under the following circumstances:

•Command is entered at the PLR before a failure (see Example 1)

•Command is entered at the PLR after a failure (see Example 2)

•Command is entered at the MP before a failure (see Example 3)

•Command is entered at the MP after a failure (see Example 4)

•Command output shows all senders (see Example 5)

•Command output only shows senders who have a specific destination (see Example 6)

•Show more detail about a sender who has a specific destination (see Example 7)

The first five fields provide information that uniquely identifies the LSP.

The first three fields identify the LSP's session (that is, the contents of the SESSION object in arriving Path messages).

Tun Dest

IP address of the destination of the tunnel.

Tun ID

Tunnel identification number.

Ext Tun ID

Extended tunnel identification number.

The next two fields identify the LSP's sender (SENDER_TEMPLATE object of arriving Path messages).

Tun Sender

Tunnel sender.

LSP ID

LSP identification number.

The remaining fields indented under PATH provide additional information about this LSP.

Session Attr—Session attributes. Refers to information included in the SESSION_ATTRIBUTE object of arriving Path messages, such as the Setup and Holding Priorities, Flags, and the Session Name.

Setup Prio

Setup priority.

Holding Prio

Holding priority.

Flags

An LSP must have the "Local protection desired" Flag of the SESSION_ATTRIBUTE object set for the LSP to use a backup tunnel (that is, in order to receive local protection). If this flag is not set, you have not enabled Fast ReRoute for this tunnel at its headend (by entering the tunnel mpls traffic-eng fast-reroute command). NNHOP backup tunnels rely on label recording, so LSPs should have the "label recording desired" flag set too. This flag is set if the tunnel was configured for Fast ReRoute.

ERO—Refers to the EXPLICIT_ROUTE object of the Path messages. This field displays the contents of the ERO at this node. As a Path message travels from the sender (headend) to the receiver (tailend), each node removes its own IP address from the ERO. The displayed value reflects the remainder of hops between this node and the tail.

Fast-Reroute Backup info—Information that is relevant to Fast ReRoute for this LSP.

Inbound FRR

If this node is downstream from a rerouted LSP (for example, at a Merge Point for this LSP), the state is Active.

Outbound FRR

If this node is a PLR for an LSP, there are three possible states:

•Active—This LSP is actively using its backup tunnel, presumably because there has been a downstream failure.

•No Backup—This LSP does not have local (Fast ReRoute) protection. No backup tunnel has been selected for it to use in case of a failure.

•Ready—This LSP is ready to use a backup tunnel in case of a downstream link or node failure. A backup tunnel has been selected for it to use.

Backup Tunnel

If the Outbound FRR state is Ready or Active, this field indicates the following:

•Which backup tunnel has been selected for this LSP to use in case of a failure.

•The inbound label that will be prepended to the LSP's data packets for acceptance at the backup tunnel tail (the Merge Point).

Bkup Sender Template

If the Outbound FRR state is Ready or Active, SENDER_TEMPLATE and FILTERSPEC objects are shown. These objects will be used in RSVP messages sent by the backup tunnel if/when the LSP starts actively using the backup tunnel. They differ from the original (pre-failure) objects only in that the node (the PLR) substitutes its own IP address for that of the original sender. For example, Path and PathTear messages will contain the new SENDER_TEMPLATE. Resv and ResvTear messages will contain the new FILTERSPEC object. If this LSP begins actively using the backup tunnel, the display changes as shown below.

Bkup FilerSpec

If the Outbound FRR state is Ready or Active, SENDER_TEMPLATE and FILTERSPEC objects are shown. These objects will be used in RSVP messages sent by the backup tunnel if/when the LSP starts actively using the backup tunnel. They differ from the original (pre-failure) objects only in that the node (the PLR) substitutes its own IP address for that of the original sender. For example, Path and PathTear messages will contain the new SENDER_TEMPLATE. Resv and ResvTear messages will contain the new FILTERSPEC object. If this LSP begins actively using the backup tunnel, the display changes as shown in Example 2.

Example 2: Command is entered at the PLR after a failure

If the LSP begins actively using the backup tunnel and the command is entered at the PLR after a failure, the display changes as shown below.

Note Highlighted fields are referenced in the explanation that follows the sample display.

Router# show ip rsvp sender detail

PATH:

Tun Dest: 24.1.1.1 Tun ID: 1 Ext Tun ID: 23.1.1.1

Tun Sender: 23.1.1.1, LSP ID: 126

Path refreshes arriving on POS1/0 from PHOP 11.1.1.1

Path refreshes being sent to NHOP 24.1.1.1 on Tunnel2

Session Attr::

Setup Prio: 0, Holding Prio: 0

Flags: Local Prot desired, Label Recording, SE Style

Session Name:tagsw4500-23_t1

ERO:

24.1.1.1 (Strict IPv4 Prefix, 8 bytes, /32)

24.1.1.1 (Strict IPv4 Prefix, 8 bytes, /32)

Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytes

Fast-Reroute Backup info:

Inbound FRR: Not active

Outbound FRR: Active -- using backup tunnel

Backup Tunnel: Tu2 (label 0)

Bkup Sender Template:

Tun Sender: 15.1.1.1, LSP ID: 126

Bkup FilerSpec:

Tun Sender: 15.1.1.1, LSP ID 126

Orig Output I/F: Et2

Orig Output ERO:

12.1.1.2 (Strict IPv4 Prefix, 8 bytes, /32)

14.1.1.1 (Strict IPv4 Prefix, 8 bytes, /32)

14.1.1.2 (Strict IPv4 Prefix, 8 bytes, /32)

24.1.1.1 (Strict IPv4 Prefix, 8 bytes, /32)

Once an LSP is actively using a backup tunnel, the following changes occur:

•Path refreshes are no longer sent to the original NHOP out the original interface. They are sent through the backup tunnel to the node that is the tail of the backup tunnel (NHOP or NNHOP).

•The ERO is modified so that it will be acceptable upon arrival at the NHOP or NNHOP.

•The display shows both the original ERO and the new one now being used.

•The display shows the original output interface (that is, the interface from which Path messages were sent for this LSP before the failure).

Example 3: Command is entered at the MP before a failure

If the same show ip rsvp sender command is entered at the Merge Point (the backup tunnel tail), the display changes from before to after the failure. Following is sample output before a failure:

Router# show ip rsvp sender detail

PATH:

Tun Dest: 24.1.1.1 Tun ID: 1 Ext Tun ID: 23.1.1.1

Tun Sender: 23.1.1.1, LSP ID: 126

Path refreshes arriving on POS0/0 from PHOP 14.1.1.1

Session Attr::

Setup Prio: 0, Holding Prio: 0

Flags: Local Prot desired, Label Recording, SE Style

Session Name:tagsw4500-23_t1

Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytes

Fast-Reroute Backup info:

Inbound FRR: Not active

Outbound FRR: No backup tunnel selected

Example 4: Command is entered at the MP after a failure

After a failure, the following changes occur:

•The interface and previous hop (PHOP) from which Path messages are received will change.

•The inbound FRR becomes Active.

•The original PHOP and the original input interface are displayed as shown below.

Following is sample output after a failure:

Router# show ip rsvp sender detail

PATH:

Tun Dest: 24.1.1.1 Tun ID: 1 Ext Tun ID: 23.1.1.1

Tun Sender: 23.1.1.1, LSP ID: 126

Path refreshes arriving on POS0/1 from PHOP 15.1.1.1 on Loopback0

Session Attr::

Setup Prio: 0, Holding Prio: 0

Flags: Local Prot desired, Label Recording, SE Style

Session Name:tagsw4500-23_t1

Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytes

Fast-Reroute Backup info:

Inbound FRR: Active

Orig Input I/F: POS0/0

Orig PHOP: 14.1.1.1

Now using Bkup Filterspec w/ sender: 15.1.1.1 LSP ID: 126

Outbound FRR: No backup tunnel selected

Notice the following changes, which are highlighted in the sample command output:

•After a failure, Path refreshes arrive on a different interface and from a different PHOP.

•The original PHOP and input interface are shown under Fast-Reroute Backup information, along with the FILTERSPEC object that will now be used when sending messages (such as Resv and ResvTear).

Shows entries that match one of four possible states: active, ready, partial, or complete.

active

The FRR rewrite has been put into the forwarding database (where it can be placed onto appropriate incoming packets).

ready

The FRR rewrite has been created, but has not yet been moved into the forwarding database.

partial

State before the FRR rewrite has been fully created; its backup routing information is still incomplete.

complete

State after the FRR rewrite has been assembled: ready or active.

role

Shows entries associated either with the tunnel head or tunnel midpoint.

head

Entry associated with the tunnel head.

middle

Entry associated with the tunnel midpoint.

detail

Shows long-form information (LFIB-FRR total number of clusters, groups, and items) in addition to the short-form information (prefix, label, and state).

Defaults

This command has no default behavior or values.

Command Modes

EXEC

Command History

Release

Modification

12.0(10)ST

This command was introduced.

12.0(22)S

This command is used for Node Protection. The command is supported on the Cisco 10000 series ESRs.

12.0(23)S

Output display reflects reduction in rewrites-per-prefix when LDP is not enabled.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Usage Guidelines

A tunnel head end item is created and added to the FRR database for each TE tunnel that is protected by Fast ReRoute. The existence of the head end item indicates that the label rewrite stored in the LFIB is protected, and that any IP prefix that uses the tunnel as its next hop will be FRR protected. You can confirm this information for each individual prefix by using the show mpls forwarding-table detail command.

A prefix item is created and added to the FRR database for each prefix that has label information associated with it via TDP/LDP and is being routed over a protected TE tunnel.Those items correspond to unique label rewrites, which are FRR protrected and used by LFIB.

LSP midpoint items are created and added to the FRR database for LSPs that use the node as a transit, if their LSP output interface is protected by Fast ReRoute.

Examples

The following is sample output from the show mpls traffic-eng fast-reroute database command at a tunnel head link. (Prefix item and LSP midpoint information categories are empty in this first example because LDP has not been enabled. In the second example, shown after Table 11, LDP has been enabled).

(Optional) Restricts the display to tunnels with the indicated role (all, head, middle, tail, or remote).

all

(Optional) Displays all tunnels.

head

(Optional) Displays tunnels with their head at this router.

middle

(Optional) Displays tunnels with a midpoint at this router.

tail

(Optional) Displays tunnels with a tail at this router.

remote

(Optional) Displays tunnels with their head at some other router; this is a combination of middle and tail.

up

(Optional) Displays tunnels if the tunnel interface is up. Tunnel midpoints and tails are typically up or not present.

down

(Optional) Displays tunnels that are down.

namestring

(Optional) Displays tunnel with the specified name. The tunnel name is derived from the interface description, if specified; otherwise, it is the interface name. The tunnel name is included in the signalling message so it is available at all hops.

(Optional) Displays tunnels whose path metric is greater than the current shortest path, constrained by the tunnel's configured options. Selected tunnels would have a shorter path if they were reoptimized immediately.

suboptimal constraints max

Displays tunnels whose path metric is greater than the current shortest path, constrained by the tunnel's configured options, and considering only the network's capacity. Selected tunnels would have a shorter path if no other tunnels were consuming network resources.

interface inphys_intf

Displays tunnels that use the specified input interface.

interface outphys_intf

Displays tunnels that use the specified output interface.

interfacephys_intf

Displays tunnels that use the specified interface as an input or output interface.

propertybackup

Selects MPLS TE tunnels being used to protect physical interfaces on this router. A tunnel configured to protect a link against failure is a backup tunnel and has the backup tunnel property.

Displays information about the Fast ReRoute protection provided by each tunnel selected by other options specified with this command. The information includes the physical interface protected by the tunnel, the number of TE LSPs (tunnels) protected, and the bandwidth protected.

protection

Displays information about the protection provided to each tunnel selected by other options specified with this command. The information includes whether protection is configured for the tunnel, the protection (if any) provided to the tunnel by this router, and the tunnel bandwidth protected.

Defaults

If you specify this command without any arguments or keywords, the command displays general information about each MPLS TE tunnel known to the router.

Command Modes

EXEC

Command History

Release

Modification

12.0(5)S

This command was introduced.

12.0(10)ST

The new brief format includes input and output interface information. The suboptimal and interface keywords were added to the non-brief format. The non-brief, non-summary formats contain the history of LSP selection.

12.0(22)S

The property, back-up, fast-reroute, and protection keywords were added. The command is supported on the Cisco 10000 series ESRs.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Usage Guidelines

To select the tunnels for which information is displayed, use the tunnel, destination, source-id, role, up, down, name, suboptimal, interface and property keywords and options singly or combined.

To select the type of information displayed about the selected tunnels, use the brief, accounting, backup, or protection keywords.

Examples

The following is sample output from the show mpls traffic-eng tunnel brief command. It displays brief information about every MPLS TE tunnel known to the router.

RSVP has or has not been enabled. (This feature is enabled as a consequence of MPLS Traffic Engineering being enabled.)

Forwarding

Status of forwarding (enabled or disabled).

Periodic Reoptimization

Schedule for periodic reoptimization.

TUNNEL NAME

Name of the interface that is configured at the tunnel head.

DESTINATION

Identifier of the tail-end router.

Head

Summary information about tunnel heads at this device.

UP IF

Upstream interface that the tunnel used.

DOWN IF

Downstream interface that the tunnel used.

STATE/PROT

For tunnel heads, admin-down or up. For non-heads, signalled.

The following is sample output from the show mpls traffic-eng tunnels propertybackup-tunnel brief command. It displays brief information about all MPLS TE tunnels acting as Fast Reroute backup tunnels (property backup) for interfaces on the router.

Router# show mpls traffic-eng tunnels property backup brief

Signalling Summary:

LSP Tunnels Process: running

RSVP Process: running

Forwarding: enabled

Periodic reoptimization: every 3600 seconds, next in 2231 seconds

Periodic FRR Promotion: every 300 seconds, next in 131 seconds

Periodic auto-bw collection: disabled

TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT

Router_t578 88.88.88.88 - PO1/0 up/up

Router_t5710 7.7.7.7 - unknown admin-down

Router_t5711 7.7.7.7 - PO1/1 up/up

Displayed 3 (of 9) heads, 0 (of 1) midpoints, 0 (of 0) tails

The following is sample output from the show mpls traffic-eng tunnels backup command. This command selects every MPLS TE tunnel known to the router and displays information about the Fast ReRoute protection each selected tunnels provides for interfaces on this router; the command does not generate output for tunnels that do not provide Fast ReRoute protection of interfaces on this router.

Router# show mpls traffic-eng tunnels backup

Router_t578

LSP Head, Tunnel578, Admin: up, Oper: up

Src 55.55.55.55, Dest 88.88.88.88, Instance 1

Fast Reroute Backup Provided:

Protected i/fs: PO1/0, PO1/1, PO3/3

Protected lsps: 1

Backup BW: any pool unlimited; inuse: 100 kbps

Router_t5710

LSP Head, Tunnel5710, Admin: admin-down, Oper: down

Src 55.55.55.55, Dest 7.7.7.7, Instance 0

Fast Reroute Backup Provided:

Protected i/fs: PO1/1

Protected lsps: 0

Backup BW: any pool unlimited; inuse: 0 kbps

Router_t5711

LSP Head, Tunnel5711, Admin: up, Oper: up

Src 55.55.55.55, Dest 7.7.7.7, Instance 1

Fast Reroute Backup Provided:

Protected i/fs: PO1/0

Protected lsps: 2

Backup BW: any pool unlimited; inuse: 6010 kbps

The following is sample output from the show mpls traffic-eng tunnels property fast-reroute protection command. This command selects every MPLS TE tunnel known to the router that was signaled as a Fast ReRoute protected LSP (property fast-reroute) and displays information about the protection this router provides each selected tunnel.

Related Commands

Specifies how often the router considers switching an LSP to a new (better) backup tunnel if additional backup-bandwidth becomes available.

tunnel mpls traffic-eng backup-bw

To specify what types of LSPs can use a backup tunnel, whether the backup tunnel should provide bandwidth protection, and if so, how much, use the tunnel mpls traffic-eng backup-bw command in interface configuration mode.

Syntax Description

global-pool

Only LSPs using bandwidth from the global-pool can use the backup tunnel.

sub-pool

Only LSPs using bandwidth from the sub-pool can use the backup tunnel.

bandwidth

The amount of bandwidth this backup tunnel can protect. The router limits the LSPs that can use this backup tunnel so that the sum of the bandwidth of the LSPs does not exceed the specified amount of bandwidth. If there are multiple backup tunnels, the router will use the best-fit algorithm (see "Backup Tunnel Selection Procedure") to determine which backup tunnel to use.

Unlimited

Backup tunnel does not provide bandwidth protection. Any number of LSPs can use the backup tunnel, regardless of their bandwidth.

Defaults

If neither sub-pool nor global-pool is entered, it is assumed that any LSP (those using bandwidth from the sub-pool or global-pool) can use this backup tunnel.

Command Modes

Interface configuration mode, on the backup tunnel interface

Command History

Release

Modification

12.0(22)S

This command was introduced.

12.2(18)SXD1

This command was integrated into Cisco IOS Release 12.2(18)SX.

Usage Guidelines

If both sub-pool and global-pool are specified, sub-pool must be specified first on the command line. For example, tunnel mpls traffic-eng backup-bw sub-pool 100 global-pool Unlimitedis legal, but it is not legal to specify tunnel mpls traffic-eng backup-bw global-pool Unlimited sub-pool 100.

If sub-pool is Unlimited, global-pool cannot also be Unlimited. Entering such a command (tunnel mpls traffic-eng backup-bw sub-pool Unlimited global-pool Unlimited)would be the same as entering nothing at all because it is the default behavior.

Examples

In the following example, backup tunnel 1 is to be used only by LSPs that take their bandwidth from the global pool. The backup tunnel does not provide bandwidth protection. Backup tunnel 2 is to be used only by LSPs that take their bandwidth from the sub-pool. Backup tunnel 2 provides bandwidth protection for up to 1000 units.

Related Commands

Glossary

backup tunnel—An MPLS Traffic Engineering tunnel used to protect other (primary) tunnels' traffic when a link or node failure occurs.

bandwidth—The available traffic capacity of a link.

CEF—Cisco Express Forwarding. A means for accelerating the forwarding of packets within a router, by storing route lookup.

Cisco Express Forwarding—See CEF.

differentiated services code point—See DSCP.

DSCP—Differentiated Services Code Point. Six bits in the IP header, as defined by the IETF. These bits determine the class of service provided to the IP packet.

enterprise network—A large and diverse network connecting most major points in a company or other organization.

Fast ReRoute—Procedures that enable temporary routing around a failed link or node while a new LSP is being established at the head end.

flooding—Traffic passing techniques used by switches and bridges in which traffic received on an interface is sent out all the interfaces of that device except the interface on which the information was received originally.

global pool—The total bandwidth allocated to an MPLS Traffic Engineering link or node.

headend—The router that originates and maintains a given LSP. This is the first router in the LSP's path.

hop—Passage of a data packet between two network nodes (for example, between two routers).

instance—A Hello instance implements the RSVP Hello extensions for a given router interface address and remote IP address. Active Hello instances periodically send Hello Request messages, expecting Hello ACK messages in response. If the expected Ack message is not received, the active Hello instance declares that the neighbor (remote IP address) is unreachable (that is, it is lost). This can cause LSPs crossing this neighbor to be fast rerouted.

interface—A network connection.

intermediate nodes—Intermediate System-to-Intermediate System. Link-state hierarchical routing protocol that calls for intermediate system (IS) routers to exchange routing information based on a single metric to determine network topology.

link—A point-to-point connection between adjacent nodes. There can be more than one link between adjacent nodes. A network communications channel consisting of a circuit or transmission path and all related equipment between a sender and a receiver. Sometimes referred to as a line or a transmission link.

load balancing—A configuration technique that shifts traffic to an alternative link if a certain threshold is exceeded on the primary link. Load balancing is similar to redundancy in that if an event causes traffic to shift directions, alternative equipment must be present in the configuration. In load balancing, the alternative equipment is not necessarily redundant equipment that only operates in the event of a failure.

LSP—Label-switched path. A configured connection between two routers, in which label switching is used to carry the packets. The purpose of an LSP is to carry data packets.

merge point—The backup tunnel's tail.

MPLS—Multiprotocol Label Switching. Packet-forwarding technology, used in the network core, that applies data link layer labels to tell switching nodes how to forward data, resulting in faster and more scalable forwarding than network layer routing normally can do.

MPLS global label allocation—There is one label space for all interfaces in the router. For example, label 100 coming in one interface is treated the same as label 100 coming in a different interface.

next hop—The next downstream node along an LSP's path. Also called NHOP.

next-hop backup tunnel—See NHOP backup tunnel.

next-next hop—The node after the next downstream node along an LSP's path. Also called NNHOP.

next-next-hop backup tunnel—See NNHOP backup tunnel.

NHOP—Next hop. The next downstream node along an LSP's path.

NHOP backup tunnel—Next-hop backup tunnel. Backup tunnel terminating at the LSP's next hop beyond the point of failure, and originating at the hop immediately upstream of the point of failure. It bypasses a failed link, and is used to protect primary LSPs that were using this link before the failure.

NNHOP—Next-next hop. The node after the next downstream node along an LSP's path.

NNHOP backup tunnel—Next-next-hop backup tunnel. Backup tunnel terminating at the LSP's next-next hop beyond the point of failure, and originating at the hop immediately upstream of the point of failure. It bypasses a failed link and/or node, and is used to protect primary LSPs that were using this link or node before the failure.

node—Endpoint of a network connection or a junction common to two or more lines in a network. Nodes can be interconnected by links, and serve as control points in the network. Computers on a network, or any endpoint or a junction common to two or more lines in a network. Nodes can be processors, controllers, or workstations.

primary LSP—The last LSP originally signaled over the protected interface before the failure. The LSP before the failure.

primary tunnel—Tunnel whose LSP may be fast rerouted if there is a failure. Backup tunnels cannot be primary tunnels.

promotion—Conditions, such as a new backup tunnel comes up, cause a reevaluation of a backup tunnel that was chosen for an LSP. If the reevaluation is successful, it is called a promotion.

protected interface—An interface that has one or more backup tunnels associated with it.

redundancy—The duplication of devices, services, or connections so that, in the event of a failure, the redundant devices, services, or connections can perform the work of those that failed.

RSVP—Resource Reservation Protocol. An IETF protocol used for signaling requests (setting up reservations) for Internet services by a customer before that customer is permitted to transmit data over that portion of the network.

scalability—An indicator showing how quickly some measure of resource usage increases as a network gets larger.

state—Information that a router must maintain about each LSP. The information is used for rerouting tunnels.

sub-pool—The more restrictive bandwidth in an MPLS Traffic Engineering link or node. The sub-pool is a portion of the link or node's overall global pool bandwidth.

tailend—The router upon which an LSP is terminated. This is the last router in the LSP's path.

topology—The physical arrangement of network nodes and media within an enterprise networking structure.

tunnel—Secure communications path between two peers, such as two routers.