 Feedback
|
Table Of Contents
MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
Prerequisites for MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
Restrictions for MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
Information About MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
Features of MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
Backup Tunnels Terminating at Different Destinations
Backup Tunnels Terminating at the Same Destination
Backup Tunnel Selection Procedure
Load Balancing on Limited-Bandwidth Backup Tunnels
Load Balancing on Unlimited-Bandwidth Backup Tunnels
Bandwidth Protection Considerations
How to Configure MPLS Traffic Engineering—Fast Reroute (FRR) Link and Node Protection
Creating a Backup Tunnel to the Next Hop or to the Next-Next Hop
Assigning Backup Tunnels to a Protected Interface
Associating Backup Bandwidth and Pool Type with a Backup Tunnel
Configuring Backup Bandwidth Protection
Configuring an Interface for Fast Link and Node Failure Detection
Verifying That Fast Reroute Is Configured
Configuration Examples for MPLS Traffic Engineering—Fast Reroute (FRR) Link and Node Protection
Enabling Fast Reroute for all Tunnels: Example
Creating an NHOP Backup Tunnel: Example
Creating an NNHOP Backup Tunnel: Example
Assigning Backup Tunnels to a Protected Interface: Example
Associating Backup Bandwidth and Pool Type with Backup Tunnels: Example
Configuring Backup Bandwidth Protection: Example
Configuring an Interface for Fast Link and Node Failure Detection: Example
Configuring RSVP Hello and POS Signals: Example
clear ip rsvp hello instance counters
clear ip rsvp hello instance statistics
clear ip rsvp hello statistics
ip rsvp signalling hello (configuration)
ip rsvp signalling hello (interface)
ip rsvp signalling hello refresh interval
ip rsvp signalling hello refresh misses
ip rsvp signalling hello statistics
mpls traffic-eng backup-path tunnel
mpls traffic-eng fast-reroute backup-prot-preemption
mpls traffic-eng fast-reroute timers
show ip rsvp hello instance detail
show ip rsvp hello instance summary
show mpls traffic tunnel backup
show mpls traffic-eng fast-reroute database
show mpls traffic-eng tunnels summary
tunnel mpls traffic-eng backup-bw
tunnel mpls traffic-eng fast-reroute
Feature Information for MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
First Published: January 16, 2003Last Updated: December 19, 2006The MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection feature provides link protection (backup tunnels that bypass only a single link of the label-switched path (LSP)), node protection (backup tunnels that bypass next-hop nodes along LSPs), and the following FRR features:
•
Backup tunnel support
•
•
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection" section.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
•
•
•
•
•
Prerequisites for MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
Your network must support the following Cisco IOS features:
•
•
Your network must support at least one of the following protocols:
•
•
Before configuring FRR link and node protection, it is assumed that you have done the following tasks but you do not have to already have configured MPLS TE tunnels:
•
•
Restrictions for MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
•
•
•
•
•
•
•
Information About MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
To configure MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection, you need to understand the following concepts:
•
Fast Reroute
Fast Reroute (FRR) is a mechanism for protecting MPLS traffic engineering (TE) 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 node.
Link Protection
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 an NHOP backup tunnel.
Figure 1 NHOP Backup Tunnel
Node Protection
FRR provides node protection for LSPs. Backup tunnels that bypass next-hop nodes along LSP paths are called next-next-hop (NNHOP) 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 and the node.
Figure 2 illustrates an NNHOP backup tunnel.
Figure 2 NNHOP Backup Tunnel
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 are the following:
•
•
•
Bandwidth Protection
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 the "Backup Tunnel Selection Procedure" section.
LSPs that have the "bandwidth protection desired" bit set have a higher right to select backup tunnels that provide bandwidth protection; that is, those LSPs can preempt other LSPs that do not have that bit set. For more information, see the "Prioritizing Which LSPs Obtain Backup Tunnels with Bandwidth Protection" section.
RSVP Hello
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.
There are two configurable parameters:
•
•
Hello Instance
A Hello instance implements RSVP Hello for a given router interface address and remote IP address. A large number of Hello requests are sent; this puts a strain on the router resources. Therefore, create a Hello instance only when it is necessary and delete it when it is no longer needed.
There are two types of Hello instances:
Active Hello Instances
If a neighbor is unreachable when an LSP is ready to be fast rerouted, an active Hello instance is needed. Create an active Hello instance for each neighbor with at least one LSP in this state.
Active Hello instances periodically send Hello Request messages, and expect 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 (lost). LSPs traversing that neighbor may be fast rerouted.
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.
Features of MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection has the following features:
Backup Tunnel Support
Backup tunnel support has the following capabilities:
•
•
•
Backup Tunnels Can Terminate at the Next-Next Hop to Support FRR
Backup tunnels that terminate at the next-next hop protect both the downstream link and node. This provides protection for link and node failures. For more detailed information, see the "Node Protection" section.
Multiple Backup Tunnels Can Protect the Same Interface
There is no 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.
In addition to being required for node protection, the protection of an interface by multiple backup tunnels provides the following benefits:
•
•
Examples are shown in the "Backup Tunnels Terminating at Different Destinations" section and the "Backup Tunnels Terminating at the Same Destination" section.
Backup Tunnels Provide 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. Example of N:1 protection: When one backup tunnel protects 5000 LSPs, each router along the backup path maintains one additional tunnel.
One-to-one protection is when a separate backup tunnel must be used for each LSP needing protection. N:1 protection has significant scalability advantages over one-to-one (1:1) protection. Example of 1:1 protection: When 5000 backup tunnels protect 5000 LSPs, each router along the backup path must maintain state for an additional 5000 tunnels.
Backup Bandwidth Protection
Backup bandwidth protection allows you to give LSPs carrying certain kinds of data (such as voice) priority for using backup tunnels. Backup bandwidth protection has the following capabilities:
•
•
•
•
Bandwidth Protection on Backup Tunnels
Rerouted LSPs not only have their packets delivered during a failure, but the quality of service can also be maintained.
Bandwidth Pool Specifications 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 subpool 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 not provide bandwidth protection.
Semidynamic 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. If you use this feature, semidynamic NHOP backup tunnel paths can be specified simply by excluding the protected link; semidynamic NNHOP backup tunnel paths can be configured simply by excluding the protected node.
Prioritizing Which LSPs Obtain Backup Tunnels with Bandwidth Protection
In case there are not enough NHOP or NNHOP backup tunnels or they do not have enough backup bandwidth to protect all LSPs, you can give an LSP priority in obtaining backup tunnels with bandwidth protection. This is especially useful if you want to give LSPs carrying voice a higher priority than those carrying data.
To activate this feature, enter the tunnel mpls traffic-eng fast-reroute bw-protect command to set the "bandwidth protection desired" bit. See the "Enabling Fast Reroute on LSPs" section.
The LSPs do not necessarily receive bandwidth protection. They have a higher chance of receiving bandwidth protection if they need it.
LSPs that do not have the bandwidth protection bit set can be demoted. Demotion is when one or more LSPs are removed from their assigned backup tunnel to provide backup to an LSP that has its bandwidth protection bit set. Demotion occurs only when there is a scarcity of backup bandwidth.
When an LSP is demoted, it becomes unprotected (that is, it no longer has a backup tunnel). During the next periodic promotion cycle, an attempt is made to find the best possible backup tunnels for all LSPs that do not currently have protection, including the LSP that was demoted. The LSP may get protection at the same level or a lower level, or it may get no protection.
For information about how routers determine which LSPs to demote, see the "Backup Protection Preemption Algorithms" section.
RSVP Hello
RSVP Hello enables a router to detect when a neighboring node has gone down but its interface to that neighbor is still operational. 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). This allows the router to switch LSPs onto its backup tunnels and avoid packet loss.
For a more detailed description of RSVP Hello, see the "RSVP Hello" section.
Fast Reroute Operation
This section describes the following:
•
•
•
•
•
•
Fast Reroute Activation
Two mechanisms cause routers to switch LSPs onto their backup tunnels:
•
•
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 FRR. 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:
•
•
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 two NNHOP backup tunnels (T1 and T2) 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:
•
•
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:
•
•
•
•
•
•
•
Bandwidth Protection
A backup tunnel can be configured to protect two types of 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 an LSP's bandwidth. If an LSP is requesting zero bandwidth, the router chooses the backup tunnel that is 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 subpool). However, a backup tunnel can be configured to protect only LSPs that use global-pool bandwidth, or only those that use subpool bandwidth.
Tunnel Selection Priorities
This section describes the following:
•
•
NHOP Versus NNHOP 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, FRR 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 subpool 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 subpool or global-pool bandwidth.
Figure 7 shows an example of the backup tunnel selection procedure based on the designated amount of global pool and subpool bandwidth currently available.
Note
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.
2.
3.
4.
5.
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.
2.
3.
For cases 1 and 2, 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.
Backup Protection Preemption Algorithms
When you set the "bandwidth protection desired" bit for an LSP, the LSP has a higher right to select backup tunnels that provide bandwidth protection and it can preempt other LSPs that do not have that bit set.
If there is insufficient backup bandwidth on NNHOP backup tunnels but not on NHOP backup tunnels, the bandwidth-protected LSP does not preempt NNHOP LSPs; it uses NHOP protection.
If there are multiple LSPs using a given backup tunnel and one or more must be demoted to provide bandwidth, there are two user-configurable methods (algorithms) that the router can use to determine which LSPs are demoted:
•
•
For example, If you need ten units of backup bandwidth on a backup tunnel, you can demote one of the following:
•
•
The default algorithm is to minimize the number of LSPs that are demoted. To change the algorithm to minimize the amount of bandwidth that is wasted, enter the mpls traffic-eng fast-reroute backup-prot-preemption optimize-bw command.
Bandwidth Protection Considerations
There are numerous ways in which bandwidth protection can be ensured. Table 2 describes the advantages and disadvantages of three methods.
Cisco implementation of FRR does not mandate a particular approach, and it provides the flexibility to use any of the above approaches. However, given a range of configuration choices, be sure that the choices are constant with a particular bandwidth protection strategy.
The following sections describe some important issues in choosing an appropriate configuration:
•
•
Using Backup Tunnels with Explicitly Signaled Bandwidth
Two bandwidth parameters must be set for a backup tunnel:
•
•
To signal bandwidth requirements of a backup tunnel, configure the bandwidth of the backup tunnel by using the tunnel mpls traffic-eng bandwidth command.
To configure the backup bandwidth of the backup tunnel, use the tunnel mpls traffic-eng backup-bw command.
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 point of local repair (PLR) (that is, the headend 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:
•
•
Note
The tunnel mpls traffic-eng backup-bw command 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.
Bandwidth protection for 10 Kbps of subpool traffic on a given link can be achieved by configuring any of the following command combinations:
•
tunnel mpls traffic-eng backup-bw sub-pool 10
•
tunnel mpls traffic-eng backup-bw sub-pool 10 global-pool unlimited
•
tunnel mpls traffic-eng backup-bw sub-pool 10 global-pool 30
Using Backup Tunnels Signaled with Zero Bandwidth
Frequently it 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:
•
•
For each protected link AB with a maximum reservable subpool value of n, there may be a path from node A to node B such that the difference between the maximum reservable global and the maximum reservable subpool is at least the value of n. 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. Because that path has at least n available bandwidth (in the global pool), assuming that marking and scheduling is configured to classify the subpool traffic into a priority queue, the subpool bandwidth is guaranteed.
This 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 headends of affected LSPs reroute those LSPs to other paths with available subpool bandwidth). The probability of multiple unrelated link failures is very small (in the absence of node or shared risk link group (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 subpool 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 subpool can use the entire subpool. Yet, subpool 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 headend 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.
How to Configure MPLS Traffic Engineering—Fast Reroute (FRR) Link and Node Protection
This section assumes that you want to add FRR protection to a network in which MPLS TE LSPs are configured.
This section contains the following procedures:
•
•
•
•
•
•
•
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 at the headend of each LSP.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Creating a Backup Tunnel to the Next Hop or to the Next-Next Hop
Creating a backup tunnel is basically no different from creating any other tunnel. 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 the "Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPS
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 the "Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images" section.
Note
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
interface type slot/port
Example:Router(config)# interface POS 5/0
Moves configuration to the physical interface level, directing subsequent configuration commands to the specific physical interface identified by the type value. The slot and port identify the slot and port being configured. The interface must be a supported interface. See the "Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images" section. Enters interface configuration mode.
Step 4
mpls traffic-eng backup-path tunnel interface
Example:Router(config-if)# mpls traffic-eng backup-path tunnel 2
Allows LSPs going out this interface to use this backup tunnel if there is a link or node failure.
Note
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 commands.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring Backup Bandwidth Protection
To configure backup bandwidth protection, enter the following commands.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring an Interface for Fast Link and Node Failure Detection
To configure an interface for fast link and node failure detection, enter the following commands.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Verifying That Fast Reroute Is Configured
To verify that FRR can function, perform the following steps.
SUMMARY STEPS
Note
Note
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Step 1
Use this command to verify that backup tunnels are up:
Router# show mpls traffic-eng tunnels briefFollowing is sample output from the show mpls traffic-eng tunnels brief command:
Signalling Summary:LSP Tunnels Process: runningRSVP Process: runningForwarding: enabledPeriodic reoptimization: every 3600 seconds, next in 1706 secondsTUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROTRouter_t1 10.112.0.12 - PO4/0/1 up/upRouter_t2 10.112.0.12 - unknown up/downRouter_t3 10.112.0.12 - unknown admin-downRouter_t1000 10.110.0.10 - unknown up/downRouter_t2000 10.110.0.10 - PO4/0/1 up/upDisplayed 5 (of 5) heads, 0 (of 0) midpoints, 0 (of 0) tailsStep 2
Use this command to verify that LSPs are protected by the appropriate backup tunnels.
Following is sample output from the show ip rsvp sender detail command when the command is entered at the PLR before a failure.
Router# show ip rsvp sender detailPATH:Tun Dest: 10.10.0.6 Tun ID: 100 Ext Tun ID: 10.10.0.1Tun Sender: 10.10.0.1 LSP ID: 31Path refreshes:arriving: from PHOP 10.10.7.1 on Et0/0 every 30000 msecsSession Attr:Setup Prio: 7, Holding Prio: 7Flags: (0x7) Local Prot desired, Label Recording, SE Stylesession Name: R1_t100ERO: (incoming)10.10.7.2 (Strict IPv4 Prefix, 8 bytes, /32)10.10.0.6 (Strict IPv4 Prefix, 8 bytes, /32)RRO:10.10.7.1/32, Flags:0x0 (No Local Protection)10.10.4.1/32, Flags:0x9 (Local Prot Avail/to NNHOP) !Available to NNHOP10.10.1.1/32, Flags:0x0 (No Local Protection)Traffic params - Rate: 10K bits/sec, Max. burst: 1K bytesMin Policed Unit: 0 bytes, Max Pkt Size 4294967295 bytesFast-Reroute Backup info:Inbound FRR: Not activeOutbound FRR: No backup tunnel selectedPath ID handle: 50000416.Incoming policy: Accepted. Policy source(s): MPLS/TEStatus: Proxy-terminatedStep 3
Enter the clear ip rsvp hello instance counters command to verify the following:
•
•
The following command output displays the LSPs that are protected:
Router# show mpls traffic-eng fast-reroute databaseTunnel head end item frr information:Protected Tunnel In-label intf/label FRR intf/label StatusTunne1l0 Tun pos5/0:Untagged Tu0:12304 readyPrefix item frr information:Prefix Tunnel In-label Out intf/label FRR intf/label Status10.0.0.11/32 Tu110 Tun hd pos5/0:Untagged Tu0:12304 readyLSP midpoint frr information:LSP identifier In-label Out intf/label FRR intf/label Status10.0.0.12 1 [459] 16 pos0/1:17 Tu2000:19 readyIf 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:
Router# show mpls forwarding-table 10.0.0.11 detailLocal Outgoing Prefix Bytes tag Outgoing Next Hoptag tag or VC or Tunnel Id switched interfaceTun hd Untagged 10.0.0.11/32 48 pos5/0 point2pointMAC/Encaps=4/8, MTU=1520, Tag Stack{22}48D18847 00016000No output feature configuredFast Reroute Protection via (Tu0, outgoing label 12304)Step 4
For backup tunnels to be operational, the LSP must be 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. Following is sample command output:
Router# show mpls traffic-eng tunnels backupRouter_t578LSP Head, Tunnel578, Admin: up, Oper: upSrc 10.55.55.55, Dest 10.88.88.88, Instance 1Fast Reroute Backup Provided:Protected i/fs: PO1/0, PO1/1, PO3/3Protected lsps: 1Backup BW: any pool unlimited; inuse: 100 kbpsRouter_t5710LSP Head, Tunnel5710, Admin: admin-down, Oper: downSrc 10.55.55.55, Dest 10.7.7.7, Instance 0Fast Reroute Backup Provided:Protected i/fs: PO1/1Protected lsps: 0Backup BW: any pool unlimited; inuse: 0 kbpsRouter_t5711LSP Head, Tunnel5711, Admin up, Oper: up Src 10.55.55.55,, Dest 10.7.7.7, Instance 1Fast Reroute Backup Provided:Protected i/fs: PO1/0Protected lsps: 2Backup BW: any pool unlimited; inuse: 6010 kbpsThe command output will allow you to verify the following:
•
•
•
•
Note
•
You also can 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:
1.
2.
3.
Step 5
Enter the clear ip rsvp hello instance counters command to verify the following:
•
•
The following command output displays the LSPs that are protected:
Router# show mpls traffic-eng fast-reroute databaseTunnel head end item frr information:Protected Tunnel In-label intf/label FRR intf/label StatusTunne1l0 Tun pos5/0:Untagged Tu0:12304 readyPrefix item frr information:Prefix Tunnel In-label Out intf/label FRR intf/label Status10.0.0.11/32 Tu110 Tun hd pos5/0:Untagged Tu0:12304 readyLSP midpoint frr information:LSP identifier In-label Out intf/label FRR intf/label Status10.0.0.12 1 [459] 16 pos0/1:17 Tu2000:19 ready
Note
Router# show mpls forwarding-table 10.0.0.11 detailLocal Outgoing Prefix Bytes tag Outgoing Next Hoptag tag or VC or Tunnel Id switched interfaceTun hd Untagged 10.0.0.11/32 48 pos5/0 point2pointMAC/Encaps=4/8, MTU=1520, Tag Stack{22}48D18847 00016000No output feature configuredFast Reroute Protection via (Tu0, outgoing label 12304)Step 6
Following is sample output from the show ip rsvp reservation command entered at the headend of a primary LSP. Entering the command at the headend 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# show ip rsvp reservation detailReservation:Tun Dest: 10.1.1.1 Tun ID: 1 Ext Tun ID: 172.16.1.1Tun Sender: 172.16.1.1 LSP ID: 104Next Hop: 172.17.1.2 on POS1/0Label: 18 (outgoing)Reservation Style is Shared-Explicit, QoS Service is Controlled-LoadAverage Bitrate is 0 bits/sec, Maximum Burst is 1K bytesMin Policed Unit: 0 bytes, Max Pkt Size: 0 bytesRRO:172.18.1.1/32, Flags:0x1 (Local Prot Avail/to NHOP)Label subobject: Flags 0x1, C-Type 1, Label 18172.19.1.1/32, Flags:0x0 (Local Prot Avail/In Use/Has BW/to NHOP)Label subobject: Flags 0x1, C-Type 1, Label 16172.19.1.2/32, Flags:0x0 (No Local Protection)Label subobject: Flags 0x1, C-Type 1, Label 0Resv ID handle: CD000404.Policy: Accepted. Policy source(s): MPLS/TENotice the following about the primary LSP:
•
•
•
The RRO display shows the following information for each hop:
•
•
•
•
Troubleshooting Tips
This section describes the following:
•
•
•
•
•
LSPs Do Not Become Active; They Remain Ready
At a PLR, LSPs transition from Ready to Active if one of the following events occurs:
•
•
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:
•
•
Note
Enhanced RSVP Commands Display Useful Information
The following RSVP commands have been enhanced to display information that can be helpful when you are examining the FRR state or troubleshooting FRR:
•
•
•
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 Detects When a Neighboring Node Is Not Reachable
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.
Hello Instances Have Not Been Created
If Hello instances have not been created, do the following:
•
•
•
"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
FRR relies on a 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 FRR, 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, display the RRO in Resv messages by entering the clear ip rsvp hello instance counters command. Use an output filter keyword to display 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 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.
Configuration Examples for MPLS Traffic Engineering—Fast Reroute (FRR) Link and Node Protection
This section provides the following configuration examples:
•
•
•
•
•
•
•
•
The examples relate to the illustration shown in Figure 8.
Figure 8 Backup Tunnels
Enabling Fast Reroute for all Tunnels: Example
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 subpool.
Tunnel 2000 will use five units of bandwidth from the global pool. The "bandwidth protection desired" bit has been set by specifying bw-prot in the tunnel mpls traffic-eng fast-reroute command.
Router(config)# interface Tunnel 1000Router(config-if)# tunnel mpls traffic-eng fast-rerouteRouter(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 10Router(config)# interface Tunnel2000Router(config-if)# tunnel mpls traffic-eng fast-reroute bw-protRouter(config-if)# tunnel mpls traffic-eng bandwidth 5Creating an NHOP Backup Tunnel: Example
On router R2, create an NHOP backup tunnel to R3. This backup tunnel should avoid using the link 172.1.1.2.
Router(config)# ip explicit-path name avoid-protected-linkRouter(cfg-ip-expl-path)# exclude-address 172.1.1.2Explicit Path name avoid-protected-link:____1: exclude-address 172.1.1.2Router(cfg-ip_expl-path)# endRouter(config)# interface Tunnel 1Router(config-if)# ip unnumbered loopback0Router(config-if)# tunnel destination 10.3.3.3Router(config-if)# tunnel mode mpls traffic-engRouter(config-if)# tunnel mpls traffic-eng path-option 10 explicit avoid-protected-linkCreating an NNHOP Backup Tunnel: Example
On router R2, create an NNHOP backup tunnel to R4. This backup tunnel should avoid R3.
Router(config)# ip explicit-path name avoid-protected-nodeRouter(cfg-ip-expl-path)# exclude-address 10.3.3.3Explicit Path name avoid-protected-node:____1: exclude-address 10.3.3.3Router(cfg-ip_expl-path)# endRouter(config)# interface Tunnel 2Router(config-if)# ip unnumbered loopback0Router(config-if)# tunnel destination 10.4.4.4Router(config-if)# tunnel mode mpls traffic-engRouter(config-if)# tunnel mpls traffic-eng path-option 10 explicit avoid-protected-nodeAssigning Backup Tunnels to a Protected Interface: Example
On router R2, associate both backup tunnels with interface POS 5/0:
Router(config)# interface POS 5/0Router(config-if)# mpls traffic-eng backup-path tunnel 1Router(config-if)# mpls traffic-eng backup-path tunnel 2Associating Backup Bandwidth and Pool Type with Backup Tunnels: Example
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 subpool. Backup tunnel 2 provides bandwidth protection for up to 1000 units.
Router(config)# interface Tunnel 1Router(config-if)# tunnel mpls traffic-eng backup-bw global-pool UnlimitedRouter(config)# interface Tunnel 2Router(config-if)# tunnel mpls traffic-eng backup-bw sub-pool 1000Configuring Backup Bandwidth Protection: Example
In the following example, backup bandwidth protection is configured:
Note
Router(config-if)# tunnel mpls traffic-eng fast-reroute bw-protectRouter(config)# mpls traffic-eng fast-reroute backup-prot-preemption optimize-bwConfiguring an Interface for Fast Link and Node Failure Detection: Example
In the following example, pos ais-shut is configured:
Router(config)# interface pos 0/0Router(config-if)# pos ais-shutIn the following example, report lrdi is configured on OS interfaces:
Router(config)# interface pos 0/0Router(config-if)# pos report lrdiConfiguring RSVP Hello and POS Signals: Example
Hello must be configured both globally on the router and on the specific interface on which you need FRR protection. To configure Hello, use the following configuration commands:
•
•
The following configuration commands are optional:
•
•
•
•
For configuration examples, see the Hello command descriptions in the "Command Reference" section of MPLS Traffic Engineering (TE): Link and Node Protection, with RSVP Hellos Support, Release 12.0(24)S.
To configure POS signaling for detecting FRR failures, enter the pos report all command or enter the following commands to request individual reports:
pos ais-shutpos report rdoolpos report laispos report lrdipos report paispos report prdipos report sd-berAdditional References
The following sections provide references related to the MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection feature.
Related Documents
Standards
draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt
Fast ReRoute Extensions to RSVP-TE for LSP Tunnels
MIBs
RFCs
draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt.
Fast Reroute Extensions for RSVP-TE for LSP Tunnels
Technical Assistance
Command Reference
This section documents modified commands.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
clear ip rsvp hello instance counters
To clear (refresh) the values for Hello instance counters, use the clear ip rsvp hello instance counters command in privileged EXEC mode.
clear ip rsvp hello instance counters
Syntax Description
This command has no arguments or keywords.
Command Default
None
Command Modes
Privileged EXEC
Command History
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.
Router# show ip rsvp hello instance detailNeighbor 10.0.0.2 Source 10.0.0.1State: UP (for 2d18h)Type: PASSIVE (responding to requests)I/F: Et1/1LSPs protecting: 0Refresh Interval (msec) (used when ACTIVE)Configured: 100Statistics: (from 2398195 samples)Min: 100Max: 132Average: 100Waverage: 100 (Weight = 0.8)Current: 100Src_instance 0xA9F07C13, Dst_instance 0x9BBAA407Counters:Communication with neighbor lost:Num times: 0Reasons:Missed acks: 0Bad Src_Inst received: 0Bad Dst_Inst received: 0I/F went down: 0Neighbor disabled Hello: 0Msgs Received: 2398194Sent: 2398195Suppressed: 0Router# clear ip rsvp hello instance countersNeighbor 10.0.0.2 Source 10.0.0.1State: UP (for 2d18h)Type: PASSIVE (responding to requests)I/F: Et1/1LSPs protecting: 0Refresh Interval (msec) (used when ACTIVE)Configured: 100Statistics:Min: 0Max: 0Average: 0Waverage: 0Current: 0Src_instance 0xA9F07C13, Dst_instance 0x9BBAA407Counters:Communication with neighbor lost:Num times: 0Reasons:Missed acks: 0Bad Src_Inst received: 0Bad Dst_Inst received: 0I/F went down: 0Neighbor disabled Hello: 0Msgs Received: 2398194Sent: 2398195Suppressed: 0Related Commands
clear ip rsvp hello instance statistics
To clear Hello statistics for an instance, use the clear ip rsvp hello instance statistics command in privileged EXEC mode.
clear ip rsvp hello instance statistics
Syntax Description
This command has no arguments or keywords.
Command Default
Hello statistics are not cleared for an instance.
Command Modes
Privileged EXEC
Command History
Examples
This example shows sample output from the show ip rsvp hello statistics command and the values in those fields after you enter the clear ip rsvp hello instance statistics command.
Router# show ip rsvp hello statisticsStatus: EnabledPacket arrival queue:Wait times (msec)Current:0Average:0Weighted Average:0 (weight = 0.8)Max:4Current length: 0 (max:500)Number of samples taken: 2398525Router# clear ip rsvp hello instance statisticsStatus: EnabledPacket arrival queue:Wait times (msec)Current:0Average:0Weighted Average:0 (weight = 0.8)Max:0Current length: 0 (max:500)Number of samples taken: 0Related Commands
clear ip rsvp hello statistics
To globally clear Hello statistics, use the clear ip rsvp hello statistics command in privileged EXEC mode.
clear ip rsvp hello statistics
Syntax Description
This command has no arguments or keywords.
Command Default
Hello statistics are not globally cleared.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to remove all information about how long Hello packets have been in the Hello input queue.
Examples
Following is sample output from the show ip rsvp hello statistics command and the clear ip rsvp hello statistics command. Notice that the values in the "Packet arrival queue" fields have been cleared.
Router# show ip rsvp hello statisticsStatus: EnabledPacket arrival queue:Wait times (msec)Current:0Average:0Weighted Average:0 (weight = 0.8)Max:4Current length: 0 (max:500)Number of samples taken: 2398525Router# clear ip rsvp hello statisticsStatus: EnabledPacket arrival queue:Wait times (msec)Current:0Average:0Weighted Average:0 (weight = 0.8)Max:0Current length: 0 (max:500)Number of samples taken: 16Related Commands
ip rsvp signalling hello statistics
Enables Hello statistics on the router.
show ip rsvp hello statistics
Displays how long Hello packets have been in the Hello input queue.
debug ip rsvp hello
To verify that a Hello instance has been created, a Hello instance has been deleted, or that communication with a neighbor has been lost, use the debug ip rsvp hello command in privileged EXEC mode.
debug ip rsvp hello [stats]
Syntax Description
Command Default
None
Command Modes
Privileged EXEC
Command History
Usage Guidelines
When you enter the debug ip rsvp hello command, Resource Reservation Protocol (RSVP) signaling messages are shown, but RSVP hello messages are excluded because of the large number of hello messages that are sent.
Examples
Following is sample output from the debug ip rsvp hello command. The first portion of the output is for interface Se2/0 when Hello is created:
Router# debug ip rsvp hello00:22:03: RSVP-HELLO: rsvp_hello_inst_init: Initializing ACTIVE hello inst 12.0.0.2->12.0.0.300:22:03: RSVP-HELLO: rsvp_hello_create_instance_from_psb: Next hop Se2/0 is adjacent00:22:03: RSVP-HELLO: rsvp_hello_create_instance_from_psb: Create hello instance for 12.0.0.2->12.0.0.3 on Se2/0 (psb=61BC5F60)00:22:03: RSVP-HELLO: rsvp_hello_find_instance: psb_cnt=2 for hello inst 12.0.0.2->12.0.0.300:22:03: RSVP-HELLO: rsvp_hello_incoming_message: Neighbor 10.0.0.3 state changed to UP00:22:05: %LINK-3-UPDOWN: Interface Tunnel1, changed state to up00:22:06: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to uprsvp-3640-2(config-if)#rsvp-3640-2(config-if)# shutrsvp-3640-2(config-if)#The following output shows that Hello has been deleted:
00:25:19: RSVP-HELLO: rsvp_hello_path_delete: psb for hello inst 10.0.0.2->10.0.0.3 exited READY state (psb_cnt=1)00:25:19: RSVP-HELLO: rsvp_hello_path_delete: psb for hello inst 10.0.0.2->10.0.0.3 exited READY state (psb_cnt=0)00:25:19: RSVP-HELLO: rsvp_hello_path_delete: Last psb deleted, hello inst for 12.0.0.2->12.0.0.3 ACTIVE->PASSIVE00:25:19: RSVP-HELLO: rsvp_hello_path_delete: psb for hello inst 10.0.0.2->10.0.0.3 exited READY state (psb_cnt=0)00:25:19: RSVP-HELLO: rsvp_hello_path_delete: Last psb deleted, hello inst for 13.0.0.2->13.0.0.3 ACTIVE->PASSIVE00:25:21: %LINK-5-CHANGED: Interface Tunnel1, changed state to administratively down00:25:22: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1,changed state to down00:05:51: RSVP-HELLO: Communication lost with 10.0.0.200:05:51: RSVP-HELLO: rsvp_hello_communication_lost: Neighbor 10.0.0.2 was reset (src_inst)Following is sample output from the debug ip rsvp hello stats command:
Router(config)# ip rsvp signalling hello statRouter(config)# endRouter#00:32:28: RSVP-HELLO: rsvp_hello_stats_init: Hello stats is being configuredRelated Commands
ip rsvp signalling hello (configuration)
To enable Hello globally on the router, use the ip rsvp signalling hello command in global configuration mode.
ip rsvp signalling hello
Syntax Description
This command has no arguments or keywords.
Command Default
None
Command Modes
Global configuration
Command History
Usage Guidelines
To enable Hello globally on the router, you must enter this command. You also must enable Hello on the interface.
Examples
In the following example, Hello is enabled globally on the router:
Router# ip rsvp signalling helloRelated Commands
ip rsvp signalling hello (interface)
To enable Hello on an interface where you need Fast Reroute protection, use the ip rsvp signalling hello command in interface configuration mode.
ip rsvp signalling hello
Syntax Description
This command has no arguments or keywords.
Command Default
None
Command Modes
Interface configuration
Command History
Usage Guidelines
You must configure Hello globally on the router and on the specific interface.
Examples
In the following example, Hello is enabled on an interface:
Router(config-if)# ip rsvp signalling helloRelated Commands
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 capability, use the no form of this command.
ip rsvp signalling hello dscp [num]
no ip rsvp signalling hello dscp
Syntax Description
Command Default
None
Command Modes
Interface configuration
Command History
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 Resource Reservation Protocol (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:
Router(config-if)# ip rsvp signalling hello dscp 48Related Commands
ip rsvp signalling hello (interface)
Enables Hello on an interface where you need Fast Reroute protection.
ip rsvp signalling hello refresh interval
To configure the Hello request interval, use the ip rsvp signalling hello refresh interval command in interface configuration mode.
ip rsvp signalling hello refresh interval milliseconds
Syntax Description
milliseconds
Frequency, in milliseconds, at which a node sends hello messages to a neighbor. Range: 10 to 30,000. Default: 200.
Command Default
None
Command Modes
Interface configuration
Command History
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:
Router(config-if)# ip rsvp signalling hello refresh interval 50Related Commands
ip rsvp signalling hello refresh misses
To specify how many consecutive Hello acknowledgments a node can miss before the node considers its neighbor to be 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. Range: 4 to 10. Default: 4.
Command Default
None
Command Modes
Interface configuration
Command History
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 the num argument 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 consecutive Hello acknowledgments, the node declares that its neighbor is down:
Router(config-if)# ip rsvp signalling hello refresh misses 5Related Commands
ip rsvp signalling hello (interface)
Enables Help on an interface.
ip rsvp signalling hello dscp
Sets the DSCP value that is in hello messages sent out from an interface.
ip rsvp signalling hello statistics
To enable Hello statistics on the router, use the ip rsvp signalling hello statistics command in privileged EXEC mode.
ip rsvp signalling hello statistics
Syntax Description
This command has no arguments or keywords.
Command Default
None
Command Modes
Privileged EXEC
Command History
Examples
In the following example, Hello statistics are enabled on the router.
Router(config)# ip rsvp signalling hello statisticsRelated Commands
mpls traffic-eng backup-path tunnel
To configure the physical interface to use a backup tunnel in the event of a detected failure on that interface, use the mpls traffic-eng backup-path tunnel command in interface configuration mode.
mpls traffic-eng backup-path tunnel interface
Syntax Description
Command Default
This command is disabled by default.
Command Modes
Interface configuration
Command History
Examples
The following example specifies the traffic engineering backup tunnel with the identifier 1000:
Router(config-if)# mpls traffic-eng backup-path Tunnel1000Related Commands
mpls traffic-eng fast-reroute backup-prot-preemption
To change the backup protection preemption algorithm to minimize the amount of bandwidth that is wasted, use the mpls traffic-eng fast-reroute backup-prot-preemption command in privileged configuration mode. To use the default algorithm of minimizing the number of label-switched paths (LSPs) that are demoted, use the no form of this command.
mpls traffic-eng fast-reroute backup-prot-preemption [optimize-bw]
no mpls traffic-eng fast-reroute backup-prot-preemption
Syntax Description
Command Default
A minimum number of LSPs are preempted.
Command Modes
Privileged configuration
Command History
12.0(29)S
This command was introduced.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Usage Guidelines
The mpls traffic-eng fast-reroute backup-prot-preemption command allows you to determine the criteria the router will use when selecting the LSPs that will be preempted.
If you enter the command with the optimize-bw keyword, the router chooses LSPs that will waste the least amount of bandwidth.
If you do not enter the mpls traffic-eng fast-reroute backup-prot-preemption optimize-bw command, the router preempts as few LSPs as possible.
Each router in the network does not have to use the same algorithm; that is, you can specify optimize-bw for some routers in the network but not for others.
You can enter the mpls traffic-eng fast-re-route backup-prot-preemption command at any time. If you change the algorithm, it does not affect LSPs that already are protected. It only affects the placement of new LSPs signaled after you enter this command. The command can affect LSPs during the next periodic promotion cycle.
Examples
In the following examples, a next-next hop (NNHOP) backup tunnel has the following characteristics:
•
•
•
The backup tunnel currently is protecting LSP1 through LSP5, which have the following bandwidth, and do not have backup bandwidth protection (that is, the "bandwidth protection desired" bit was not set via the tunnel mpls traffic-eng fast-reroute command):
•
•
•
•
•
As shown, LSP1 through LSP5 use 220 units of bandwidth.
LSP6 has backup bandwidth protection and needs 95 units of bandwidth. Twenty units of bandwidth are available, so 75 more units of bandwidth are needed.
In the following example, backup bandwidth protection is enabled and the amount of wasted bandwidth is minimized:
Router(config)# mpls traffic-eng fast-reroute backup-prot-preemption optimize-bwLSP2 and LS4 are preempted so that the least amount of bandwidth is wasted.
In the following example, backup protection preemption is enabled and the number of preempted LSPs is minimized:
Router(config)# no mpls traffic-eng fast-reroute backup-prot-preemptionThe router selects the LSP whose bandwidth is next-greater than the required bandwidth. Therefore, the router picks LSP5 because it has the next larger amount of bandwidth over 75. One LSP is demoted. and 25 units of bandwidth are wasted.
Related Commands
mpls traffic-eng fast-reroute timers
To specify how often the router considers switching a label-switched path (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 seconds value to zero or use the no form of this command.
mpls traffic-eng fast-reroute timers [frequency seconds]
no mpls traffic-eng fast-reroute timers
Syntax Description
Command 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
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 120show ip rsvp fast bw-protect
To display information about whether backup bandwidth protection is enabled and the status of backup tunnels that may be used to provide that protection, use the show ip rsvp fast bw-protect command in user EXEC or privileged EXEC mode.
show ip rsvp fast bw-protect
Syntax Description
This command has no arguments or keywords.
Command Default
The backup bandwidth protection and backup tunnel status information is not displayed.
Command Modes
User EXEC
Privileged EXECCommand History
12.0(29)S
This command was introduced.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Examples
The following is sample output from the show ip rsvp fast bw-protect command:
Router# show ip rsvp fast bw-protectPrimary Protect BW BackupTunnel I/F BPS:Type Tunnel:Label State BW-P Type-------------- ------- -------- ---------- ----- ---- ----PRAB-72-5_t500 PO2/0 500K:S Tu501:19 Ready ON NhopPRAB-72-5_t601 PO2/0 103K:S Tu501:20 Ready OFF NhopPRAB-72-5_t602 PO2/0 70K:S Tu501:21 Ready ON NhopPRAB-72-5_t603 PO2/0 99K:S Tu501:22 Ready ON NhopPRAB-72-5_t604 PO2/0 100K:S Tu501:23 Ready OFF NhopPRAB-72-5_t605 PO2/0 101K:S Tu501:24 Ready OFF NhopTable 3 describes the significant fields shown in the display.
Related Commands
tunnel mpls traffic-eng fast-reroute bw-protect
Enables an MPLS TE tunnel to use an established backup tunnel in the event of a link or node failure.
show ip rsvp fast detail
To display specific information for Resource Reservation Protocol (RSVP) categories, use the show ip rsvp fast detail command in user EXEC or privileged EXEC mode.
show ip rsvp fast detail
Syntax Description
This command has no arguments or keywords.
Command Default
Specific information for RSVP categories is not displayed.
Command Modes
User EXEC
Privileged EXEC'Command History
Examples
The following is sample output from the show ip rsvp fast detail command:
Router# show ip rsvp fast detailPATH:Tun Dest: 10.0.0.7 Tun ID: 500 Ext Tun ID: 10.0.0.5Tun Sender: 10.0.0.5 LSP ID: 8Path refreshes:sent: to NHOP 10.5.6.6 on POS2/0Session Attr:Setup Prio: 7, Holding Prio: 7Flags: Local Prot desired, Label Recording, SE Style, Bandwidth Prot desiredSession Name: PRAB-72-5_t500ERO: (incoming)10.0.0.5 (Strict IPv4 Prefix, 8 bytes, /32)555.5.6.6 (Strict IPv4 Prefix, 8 bytes, /32)555.6.7.7 (Strict IPv4 Prefix, 8 bytes, /32)10.0.0.7 (Strict IPv4 Prefix, 8 bytes, /32)ERO: (outgoing)555.5.6.6 (Strict IPv4 Prefix, 8 bytes, /32)555.6.7.7 (Strict IPv4 Prefix, 8 bytes, /32)10.0.0.7 (Strict IPv4 Prefix, 8 bytes, /32)Traffic params - Rate: 500K bits/sec, Max. burst: 1K bytesMin Policed Unit: 0 bytes, Max Pkt Size 4294967295 bytesFast-Reroute Backup info:Inbound FRR: Not activeOutbound FRR: Ready -- backup tunnel selectedBackup Tunnel: Tu501 (label 19)Bkup Sender Template:Tun Sender: 555.5.6.5 LSP ID: 8Bkup FilerSpec:Tun Sender: 555.5.6.5, LSP ID: 8Path ID handle: 04000405.Incoming policy: Accepted. Policy source(s): MPLS/TEStatus: ProxiedOutput on POS2/0. Policy status: Forwarding. Handle: 02000406Table 4 describes the significant fields shown in the display.
Related Commands
mpls traffic-eng fast-reroute backup-prot-preemption
Changes the backup protection preemption algorithm to minimize the amount of bandwidth that is wasted.
show ip rsvp hello
To display if Hello is enabled globally on the router and if Hello statistics are enabled, use the show ip rsvp hello command in privileged EXEC mode.
show ip rsvp hello
Syntax Description
This command has no arguments or keywords.
Command Default
None
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the show ip rsvp hello command:
Router# show ip rsvp helloState: EnabledStatistics: EnabledDefault State: DisabledDefault Statistics: DisabledTable 5 describes the significant fields shown in the display.
Related Commands
show ip rsvp hello instance detail
To display detailed information about a Hello instance, use the show ip rsvp hello instance detail command in privileged EXEC mode.
show ip rsvp hello instance detail [filter destination ip-address]
Syntax Description
Command Default
Detailed information about a Hello instance is not displayed.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the show ip rsvp hello instance detail command:
Router# show ip rsvp hello instance detailNeighbor 10.0.0.2 Source 10.0.0.1State: UP (for 2d18h)Type: PASSIVE (responding to requests)I/F: Et1/1LSPs protecting: 0Refresh Interval (msec) (used when ACTIVE)Configured: 100Statistics: (from 2398195 samples)Min: 100Max: 132Average: 100Waverage: 100 (Weight = 0.8)Current: 100Src_instance 0xA9F07C13, Dst_instance 0x9BBAA407Counters:Communication with neighbor lost:Num times: 0Reasons:Missed acks: 0Bad Src_Inst received: 0Bad Dst_Inst received: 0I/F went down: 0Neighbor disabled Hello: 0Msgs Received: 2398194Sent: 2398195Suppressed: 0Table 6 describes the significant fields shown in the display.
Related Commands
show ip rsvp hello instance summary
To display summary information about a Hello instance, use the show ip rsvp hello instance summary command in privileged EXEC mode.
show ip rsvp hello instance summary
Syntax Description
This command has no arguments or keywords.
Command Default
Summary information is not displayed.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the show ip rsvp hello instance summary command:
Router# show ip rsvp hello instance summaryI/F Neighbor Type State LostCntEt1/1 10.0.0.1 PASSIVE UP 0Se2/0 10.0.0.3 ACTIVE UP 0Et1/2 10.0.0.3 ACTIVE UP 0Table 7 describes the significant fields shown in the display.
Related Commands
show ip rsvp hello statistics
To display how long hello packets have been in the Hello input queue, use the show ip rsvp hello statistics command in privileged EXEC mode.
show ip rsvp hello statistics
Syntax Description
This command has no arguments or keywords.
Command Default
Information about how long hello packets have been in the Hello input queue is not displayed.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
You can use this command to determine if the Hello refresh interval is too small. If the interval is too small, communication may falsely be declared as lost.
Examples
The following is sample output from the show ip rsvp hello statistics command:
Router# show ip rsvp hello statisticsStatus: EnabledPacket arrival queue:Wait times (msec)Current:0Average:0Weighted Average:0 (weight = 0.8)Max:4Current length: 0 (max:500)Number of samples taken: 2398525Table 8 describes the significant fields shown in the display.
Related Commands
show ip rsvp interface detail
To display the interface configuration for Hello, use the show ip rsvp interface detail command in privileged EXEC mode.
show ip rsvp interface detail [interface]
Syntax Description
Command Default
The interface configuration for Hello is not displayed.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the show ip rsvp interface detail command:
Router# show ip rsvp interface detail Et1/2Et1/2:Bandwidth:Curr allocated: 0G bits/secMax. allowed (total): 7500K bits/secMax. allowed (per flow): 7500K bits/secMax. allowed for LSP tunnels using sub-pools: 0G bits/secNeighbors:Using IP encap: 1. Using UDP encap: 0DSCP value used in RSVP msgs: 0x0Hello:State: EnabledRefresh Interval: 500Missed Acks: 4DSCP value used in HELLO msgs: 0Table 9 describes the significant fields shown in the display.
Related Commands
show ip rsvp request
To display Resource Reservation Protocol (RSVP)-related request information currently in the database, use the show ip rsvp request command in privileged EXEC mode.
show ip rsvp reservation [detail] [filter [destination ip-address | host-name] [dst-port port-number] [source ip-address | host-name] [src-port port-number]]
Syntax Description
Command Modes
EXEC
Command History
Usage Guidelines
Use the show ip rsvp request command to display the RSVP reservations currently being requested upstream for a specified interface or all interfaces. The received reservations may differ from requests because of aggregated or refused reservations. If desired, information for only a single tunnel or a subset of tunnels can be displayed.
Limiting the Display
When hundreds or thousands of tunnels exist and you are interested in only a few, you can display the 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 (called an output filter): destination, dst-port, source, 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
The following is sample output from the show ip rsvp request command:
Router# show ip rsvp requestTo From Pro DPort Sport Next Hop I/F Fi Serv172.240.1.49 172.240.4.53 1 0 0 172.240.3.53 Et1 FF LOADTable 10 describes the significant fields shown in the display.
The following is sample output from the show ip rsvp request detail command when the command is entered on the MP before and after a failure.
Figure 9 illustrates the network topology for the RSVP configuration example.
Figure 9 Network Topology for the RSVP Configuration Example
Example 1: The command is entered on the MP before a failure.
Router# show ip rsvp request detailRSVP Reservation. Tun Dest: 10.2.2.1 Tun Sender: 10.2.2.0,Tun ID: 1 LSP ID: 126Next Hop is 10.1.1.5 on POS0/1Label is 0Reservation Style is Shared-Explicit, QoS Service is Controlled-LoadAverage Bitrate is 0G bits/sec, Maximum Burst is 1K bytesRRO:EmptyExample 2: The command is entered on the MP after a failure.
Router# show ip rsvp request detailRSVP Reservation. Tun Dest: 10.2.2.1 Tun Sender: 10.2.2.0,Tun ID: 1 LSP ID: 126Next Hop is 10.1.1.5 on POS0/1Label is 0Reservation Style is Shared-Explicit, QoS Service is Controlled-LoadAverage Bitrate is 0G bits/sec, Maximum Burst is 1K bytesRRO:EmptyFRR is in progress (we are Merge Point)RSVP Reservation. Tun Dest: 10.2.2.1 Tun Sender: 10.2.2.0,Tun ID: 1 LSP ID: 126Next Hop is 10.0.0.0 on POS0/1Label is 0Reservation Style is Shared-Explicit, QoS Service is Controlled-LoadAverage Bitrate is 0G bits/sec, Maximum Burst is 1K bytesRRO:EmptyFRR is in progress (we are Merge Point)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 prefailure information (that is, resv messages are being sent to 10.1.1.5 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 (that is, resv messages are being sent to 10.0.0.0 on Ethernet2). This state is for the resv messages being sent upstream after the failure (to the Point of Local Repair [PLR]), and will remain and be refreshed as long as the LSP is rerouted.
In example 2, the MP is also the tail of the LSP. There is no Record Route Object (RRO) information because there are no nodes downstream.
Related Commands
show ip rsvp reservation
To display Resource Reservation Protocol (RSVP)-related receiver information currently in the database, use the show ip rsvp reservation command in user EXEC or privileged EXEC mode.
Syntax for T Releases
show ip rsvp reservation [ip-address | host-name] [detail]
Syntax for 12.0 S and 12.2 S Releases
show ip rsvp reservation [detail] [filter [destination ip-address | host-name] [dst-port port-number] [source ip-address | host-name] [src-port port-number]]
Syntax Description
Command Modes
User EXEC
Privileged EXECCommand History
Usage Guidelines
Use the show ip rsvp reservation command to display the current receiver (RESV) information in the database for a specified interface or all interfaces. This information includes reservations aggregated and forwarded from other RSVP routers.
Limiting the Display
When hundreds or thousands of tunnels exist and you are interested in only a few, you can display the 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 (called an output filter): destination, dst-port, source, 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
The following is sample output from the show ip rsvp reservation command:
Router# show ip rsvp reservationTo From Pro DPort Sport Next Hop I/F Fi Serv172.240.1.49 172.240.4.53 1 0 0 172.240.1.49 Se1 FF LOADTable 11 describes the significant fields shown in the display.
The following is sample output from the show ip rsvp reservation detail command:
Router# show ip rsvp reservation detailRSVP Reservation. Destination is 192.168.104.3, Source is 192.168.104.1,Protocol is UDP, Destination port is 4444, Source port is 4444Next Hop is 192.168.106.2, Interface is ATM1/0.1Reservation Style is Fixed-Filter, QoS Service is Guaranteed-RateResv ID handle: 0A00040B.Created: 12:18:32 UTC Sat Dec 4 2004Average Bitrate is 5K bits/sec, Maximum Burst is 1K bytesMin Policed Unit: 0 bytes, Max Pkt Size: 0 bytesStatus:Policy: Forwarding. Policy source(s): DefaultPriorities - preempt: 5, defend: 2Application ID: 'GUID=www.cisco.com, VER=1.1.1.2, APP=voice, SAPP=h323''/usr/local/bin/CallManager'Table 12 describes the significant fields shown in the display.
The following is sample output from the show ip rsvp reservation detail command when the command is entered on the PLR before and after a failure.
Figure 9 illustrates the network topology for the RSVP configuration example.
Figure 10 Network Topology for the RSVP Configuration Example
Example 1: The command is entered on the PLR before a failure
Router# show ip rsvp reservation detailRSVP Reservation. Tun Dest: 10.2.2.1 Tun Sender: 10.2.2.0,Tun ID: 1 LSP ID: 126Next Hop is 10.1.1.4 on POS1/2Label is 18Reservation Style is Shared-Explicit, QoS Service is Controlled-LoadAverage Bitrate is 0G bits/sec, Maximum Burst is 1K bytesRRO:10.1.1.5/32, Flags:0x0 (No Local Protection)Label record: Flags 0x1, ctype 1, incoming label 1810.1.1.6/32, Flags:0x0 (No Local Protection)Label record: Flags 0x1, ctype 1, incoming label 0Example 2: The command is entered on the PLR after a failure
Router# show ip rsvp reservation detailRSVP Reservation. Tun Dest: 10.2.2.1 Tun Sender: 10.2.2.0,Tun ID: 1 LSP ID: 126FRR is in progress: (we are PLR)Bkup Next Hop is 10.0.0.1 on POS1/1Label is 0Orig Next Hop was 10.1.1.4 on POS1/2Label was 18Reservation Style is Shared-Explicit, QoS Service is Controlled-LoadAverage Bitrate is 0G bits/sec, Maximum Burst is 1K bytesRRO:10.2.2.1/32, Flags:0x0 (No Local Protection)Label record: Flags 0x1, ctype 1, incoming label 0Notice the following (see highlighted text) in Examples 1 and 2:
•
•
•
Related Commands
show ip rsvp sender
To display Resource Reservation Protocol (RSVP) PATH-related sender information currently in the database, use the show ip rsvp sender command in user EXEC or privileged EXEC mode.
Syntax for T Releases
show ip rsvp sender [ip-address | host-name] [detail]
Syntax for 12.0 S and 12.2 S Releases
show ip rsvp sender [detail] [filter [destination ip-address | host-name] [dst-port port-number] [source ip-address | host-name] [src-port port-number]]
Syntax Description
Command Modes
User EXEC
Privileged EXECCommand History
Usage Guidelines
Use the show ip rsvp sender command to display the RSVP sender (PATH) information currently in the database for a specified interface or all interfaces.
The show ip rsvp sender is very useful for determining the state of RSVP signaling both before and after a label-switched packet (LSP) has been fast rerouted. The show ip rsvp sender command is especially useful when used at the Point of Local Repair (PLR) or at the Merge Point (MP).
Limiting the Display
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 (called an output filter): destination, dst-port, source, 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
The following is sample output from the show ip rsvp sender command:
Router# show ip rsvp senderTo From Pro DPort Sport Prev Hop I/F172.240.1.49 172.240.4.53 1 0 0 172.240.3.53 Et1172.240.2.51 172.240.5.54 1 0 0 172.240.3.54 Et1Table 13 describes the significant fields shown in the display.
The following is sample output from the show ip rsvp sender detail command:
Router# show ip rsvp sender detailPATH Session address: 192.168.104.3, port: 4444. Protocol: UDPSender address: 192.168.104.1, port: 4444Inbound from: 192.168.104.1 on interface:Traffic params - Rate: 5K bits/sec, Max. burst: 1K bytesMin Policed Unit: 0 bytes, Max Pkt Size 4294967295 bytesPath ID handle: 09000408.Incoming policy: Accepted. Policy source(s): DefaultPriorities - preempt: 5, defend: 2Application ID: 'GUID=www.cisco.com, VER=10.1.1.2, APP=voice, SAPP=h323''/usr/local/bin/CallManager'Status: ProxiedOutput on ATM1/0.1. Policy status: Forwarding. Handle: 04000409Policy source(s): DefaultTable 14 describes the significant fields shown in the display.
The following is sample output from the show ip rsvp sender detail command under the following circumstances:
•
•
•
•
•
•
•
Figure 9 illustrates the network topology for the RSVP configuration example.
Figure 11 Network Topology for the RSVP Configuration Example
Example 1: The command is entered at the PLR before a failure
The following is sample output from the show ip rsvp sender detail command when it is entered at the PLR before a failure:
Router# show ip rsvp sender detailPATH:Tun Dest: 10.2.2.1 Tun ID: 1 Ext Tun ID: 10.2.2.0Tun Sender: 10.2.2.0, LSP ID: 126Path refreshes arriving on POS1/0 from PHOP 10.1.1.1Path refreshes being sent to NHOP 10.1.1.4 on POS1/1Session Attr::Setup Prio: 0, Holding Prio: 0Flags: Local Prot desired, Label Recording, SE StyleSession Name:tagsw4500-23_t1ERO:10.1.1.4 (Strict IPv4 Prefix, 8 bytes, /32)10.1.1.5 (Strict IPv4 Prefix, 8 bytes, /32)10.1.1.6 (Strict IPv4 Prefix, 8 bytes, /32)10.2.2.1 (Strict IPv4 Prefix, 8 bytes, /32)Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytesFast-Reroute Backup info:Inbound FRR: Not activeOutbound FRR: Ready -- backup tunnel selectedBackup Tunnel: Tu2 (label 0)Bkup Sender Template:Tun Sender: 10.0.0.0, LSP ID: 126Bkup FilerSpec:Tun Sender: 10.0.0.0, LSP ID 126Table 15 describes the significant fields shown in the display.
Note
Example 2: The 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
Router# show ip rsvp sender detailPATH:Tun Dest: 10.2.2.1 Tun ID: 1 Ext Tun ID: 10.2.2.0Tun Sender: 10.2.2.0, LSP ID: 126Path refreshes arriving on POS1/0 from PHOP 10.1.1.1Path refreshes being sent to NHOP 10.2.2.1 on Tunnel2Session Attr::Setup Prio: 0, Holding Prio: 0Flags: Local Prot desired, Label Recording, SE StyleSession Name:tagsw4500-23_t1ERO:10.2.2.1 (Strict IPv4 Prefix, 8 bytes, /32)10.2.2.1 (Strict IPv4 Prefix, 8 bytes, /32)Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytesFast-Reroute Backup info:Inbound FRR: Not activeOutbound FRR: Active -- using backup tunnelBackup Tunnel: Tu2 (label 0)Bkup Sender Template:Tun Sender: 10.0.0.0, LSP ID: 126Bkup FilerSpec:Tun Sender: 10.0.0.0, LSP ID 126Orig Output I/F: Et2Orig Output ERO:10.1.1.4 (Strict IPv4 Prefix, 8 bytes, /32)10.1.1.5 (Strict IPv4 Prefix, 8 bytes, /32)10.1.1.6 (Strict IPv4 Prefix, 8 bytes, /32)10.2.2.1 (Strict IPv4 Prefix, 8 bytes, /32)Once an LSP is actively using a backup tunnel, the following changes occur:
•
•
•
•
Example 3: The 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. The following is sample output before a failure:
Router# show ip rsvp sender detailPATH:Tun Dest: 10.2.2.1 Tun ID: 1 Ext Tun ID: 10.2.2.0Tun Sender: 10.2.2.0, LSP ID: 126Path refreshes arriving on POS0/0 from PHOP 10.1.1.5Session Attr::Setup Prio: 0, Holding Prio: 0Flags: Local Prot desired, Label Recording, SE StyleSession Name:tagsw4500-23_t1Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytesFast-Reroute Backup info:Inbound FRR: Not activeOutbound FRR: No backup tunnel selectedExample 4: The command is entered at the MP after a failure
After a failure, the following changes occur:
•
•
•
The following is sample output after a failure:
Router# show ip rsvp sender detailPATH:Tun Dest: 10.2.2.1 Tun ID: 1 Ext Tun ID: 10.2.2.0Tun Sender: 10.2.2.0, LSP ID: 126Path refreshes arriving on POS0/1 from PHOP 10.0.0.0 on Loopback0Session Attr::Setup Prio: 0, Holding Prio: 0Flags: Local Prot desired, Label Recording, SE StyleSession Name:tagsw4500-23_t1Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytesFast-Reroute Backup info:Inbound FRR: ActiveOrig Input I/F: POS0/0Orig PHOP: 10.1.1.5Now using Bkup Filterspec w/ sender: 10.0.0.0 LSP ID: 126Outbound FRR: No backup tunnel selectedNotice the following changes, which are highlighted in the sample command output:
•
•
Example 5: The command output shows all senders
In the following example, information about all senders is displayed.
Router# show ip rsvp senderTo From Pro DPort Sport Prev Hop I/F BPS Bytes10.2.2.1 10.2.2.0 0 1 59 10.1.1.1 Et1 0G 1K10.2.2.1 172.31.255.255 0 2 9 0G 1K10.2.2.1 10.2.2.0 0 3 12 10.1.1.1 Et1 0G 1K10.2.2.1 172.31.255.255 0 3 20 0G 1K172.16.0.0 172.31.255.255 0 0 23 0G 1K172.16.0.0 172.31.255.255 0 1 22 0G 1K172.16.0.0 172.31.255.255 0 1000 22 0G 1KTable 16 describes the significant fields shown in the display.
Example 6: The command output shows only senders who have a specific destination.
To show only information about senders who have a specific destination, specify the destination filter as shown below. In this example, the destination is 155.16.6.6.
Router# show ip rsvp sender destination 155.16.6.6To From Pro DPort Sport Prev Hop I/F BPS Bytes155.16.0.0 155.31.255 0 0 23 0G 1K155.16.0.0 155.31.255 0 1 22 0G 1K155.16.0.0 155.31.255 0 1000 22 0G 1KExample 7: Show more detail about a sender who has a specific destination.
To show more detail about the sender whose destination port is 1000 (as shown in Example 6), specify the command with the destination port filter:
Router# show ip rsvp sender detail dst-port 1000PATH:Tun Dest 155.16.0.0 Tun ID 1000 Ext Tun ID 155.31.255.255Tun Sender: 155.31.255.255, LSP ID: 22Path refreshes being sent to NHOP 10.1.1.4 on Ethernet2Session Attr::Setup Prio: 7, Holding Prio: 7Flags: SE StyleSession Name:tagsw4500-25_t1000ERO:10.1.1.4 (Strict IPv4 Prefix, 8 bytes, /32)155.16.0.0 (Strict IPv4 Prefix, 8 bytes, /32)Traffic params - Rate: 0G bits/sec, Max. burst: 1K bytesFast-Reroute Backup info:Inbound FRR: Not activeOutbound FRR: No backup tunnel selectedRelated Commands
show mpls traffic tunnel backup
To display information about the backup tunnels that are currently configured, use the show mpls traffic tunnel backup command in user EXEC or privileged EXEC mode.
show mpls traffic tunnel backup tunneltunnel-id
Syntax Description
Command Default
Information about currently configured backup tunnels is not displayed.
Command Modes
User EXEC
Privileged EXECCommand History
Examples
The following is sample output from the show mpls traffic tunnel backup command.
Router# show mpls traffic tunnel backup tunnel1000Tunnel1000 Dest: 10.0.0.9 State: Upany-pool cfg 100 inuse 0 num_lsps 0protects: ATM0.1Table 17 describes the significant fields shown in the display.
Related Commands
tunnel mpls traffic-eng backup-bw
Specifies what types of LSPs can use a backup tunnel, whether the backup tunnel should provide bandwidth protection, and if so, how much.
show mpls traffic-eng fast-reroute database
To display the contents of the Fast Reroute (FRR) database, use the show mpls traffic-eng fast-reroute database command in user EXEC or privileged EXEC mode.
show mpls traffic-eng fast-reroute database [network [mask | masklength] | labels low label [-high label] | interface ifname [backup-interface ifname] | backup-interface ifname] [state {active | ready | partial | complete}] [role {head | middle}][detail]
Syntax Description
Command Default
The contents of the FRR database are not displayed.
Command Modes
User EXEC
Privileged EXECCommand History
Examples
The following example shows output from the show mpls traffic-eng fast-reroute database command at a tunnel head link:
Router# show mpls traffic-eng fast-reroute database 10.0.0.0Tunnel head fast reroute information:Prefix Tunnel In-label Out intf/label FRR intf/label Status10.0.0.0/16 Tu111 Tun hd PO0/0:Untagged Tu4000:16 ready10.0.0.0/16 Tu449 Tun hd PO0/0:Untagged Tu4000:736 ready10.0.0.0/16 Tu314 Tun hd PO0/0:Untagged Tu4000:757 ready10.0.0.0/16 Tu313 Tun hd PO0/0:Untagged Tu4000:756 readyTable 18 describes the significant fields shown in the display.
The following example shows output from the show mpls traffic-eng fast-reroute database command with the labels keyword specified at a midpoint link:
Router# show mpls traffic-eng fast-reroute database labels 250 - 255
Tunnel head fast reroute information:Prefix Tunnel In-label Outintf/label FRR intf/label StatusLSP midpoint frr information:LSP identifier In-label Out intf/label FRR intf/label Status10.110.0.10 229 [7334] 255 PO0/0:694 Tu4000:694 active10.110.0.10 228 [7332] 254 PO0/0:693 Tu4000:693 active10.110.0.10 227 [7331] 253 PO0/0:692 Tu4000:692 active10.110.0.10 226 [7334] 252 PO0/0:691 Tu4000:691 active10.110.0.10 225 [7333] 251 PO0/0:690 Tu4000:690 active10.110.0.10 224 [7329] 250 PO0/0:689 Tu4000:689 activeThe following example shows output from the show mpls traffic-eng fast-reroute database command with the detail keyword included at a tunnel head link:
Router# show mpls traffic-eng fast-reroute database 10.0.0.0. detailLFIB FRR Database Summary:Total Clusters: 2Total Groups: 2Total Items: 789Link 10:PO5/0 (Down, 1 group)Group 51:PO5/0->Tu4000 (Up, 779 members)Prefix 10.0.0.0/16, Tu313, activeInput label Tun hd, Output label PO0/0:773, FRR label Tu4000:773Prefix 10.0.0.0/16, Tu392, activeInput label Tun hd, Output label PO0/0:775, FRR label Tu4000:775Prefix 10.0.0.0/16, Tu111, activeInput label Tun hd, Output label PO0/0:16, FRR label Tu4000:16Prefix 10.0.0.0/16, Tu394, activeInput label Tun hd, Output label PO0/0:774, FRR label Tu4000:774Table 19 describes the significant fields when the detail keyword is used.
Related Commands
show mpls traffic-eng fast-reroute log reroutes
Displays contents of Fast Reroute event log.
show mpls traffic-eng tunnels
To display information about tunnels, use the show mpls traffic-eng tunnels command in user EXEC or privileged EXEC mode.
show mpls traffic-eng tunnels
[destination address]
[source-id {num | ipaddress | ipaddress num}]
[role {all | head | middle | tail | remote}]
[up | down]
[name name]
[suboptimal constraints {none | current | max}]
[interface in phys-intf] [interface out phys-intf | [interface phys-intf
[property {backup | fast-reroute}]
[brief | backup | protection]Syntax Description
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
User EXEC
Privileged EXECCommand History
Usage Guidelines
To select the tunnels for which information is displayed, use the 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, backup, or protection keyword.
Examples
The following is sample output from the show mpls traffic-eng tunnels brief command. It displays brief information about every MPLS TE tunnel known to the router.
Router# show mpls traffic-eng tunnels brief 500Signalling Summary:LSP Tunnels Process: runningRSVP Process: runningForwarding: enabledPeriodic reoptimization: every 3600 seconds, next in 1706 secondsTUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROTRouter_t1 10.112.0.12 - PO4/0/1 up/upRouter_t2 10.112.0.12 - unknown up/downRouter_t3 10.112.0.12 - unknown admin-downRouter_t1000 10.110.0.10 - unknown up/downRouter_t2000 10.110.0.10 - PO4/0/1 up/upDisplayed 5 (of 5) heads, 0 (of 0) midpoints, 0 (of 0) tailsTable 20 describes the significant fields shown in the displays.
The following is sample output from the show mpls traffic-eng tunnels property backup 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 briefSignalling Summary:LSP Tunnels Process: runningRSVP Process: runningForwarding: enabledPeriodic reoptimization: every 3600 seconds, next in 2231 secondsPeriodic FRR Promotion: every 300 seconds, next in 131 secondsPeriodic auto-bw collection: disabledTUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROTRouter_t2000 10.110.0.10 - PO4/0/1 up/upRouter_t2 10.112.0.12 - unknown up/downRouter_t3 10.112.0.12 - unknown admin-downDisplayed 3 (of 9) heads, 0 (of 1) midpoints, 0 (of 0) tailsThe 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 backupRouter_t578LSP Head, Tunnel578, Admin: up, Oper: upSrc 10.55.55.55, Dest 10.88.88.88, Instance 1Fast Reroute Backup Provided:Protected i/fs: PO1/0, PO1/1, PO3/3Protected lsps: 1Backup BW: any pool unlimited; inuse: 100 kbpsRouter_t5710LSP Head, Tunnel5710, Admin: admin-down, Oper: downSrc 10.55.55.55, Dest 7.7.7.7, Instance 0Fast Reroute Backup Provided:Protected i/fs: PO1/1Protected lsps: 0Backup BW: any pool unlimited; inuse: 0 kbpsRouter_t5711LSP Head, Tunnel5711, Admin: up, Oper: upSrc 10.55.55.55, Dest 10.7.7.7, Instance 1Fast Reroute Backup Provided:Protected i/fs: PO1/0Protected lsps: 2Backup BW: any pool unlimited; inuse: 6010 kbpsThe 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.
Router# show mpls traffic-eng tunnels property fast-reroute protectionRouter_t1LSP Head, Tunnel1, Admin: up, Oper: upSrc 10.55.55.55, Dest 10.88.88.88, Instance 25Fast Reroute Protection: RequestedOutbound: FRR ReadyBackup Tu5711 to LSP nhopTu5711: out i/f: PO1/1, label: implicit-nullLSP signalling info:Original: out i/f: PO1/0, label: 12304, nhop: 10.1.1.7With FRR: out i/f: Tu5711, label: 12304LSP bw: 6000 kbps, Backup level: any unlimited, type: any poolRouter_t2LSP Head, Tunnel2, Admin: up, Oper: upSrc 10.55.55.55, Dest 10.88.88.88, Instance 2Fast Reroute Protection: RequestedOutbound: FRR ReadyBackup Tu578 to LSP nhopTu578: out i/f: PO1/0, label: 12306LSP signalling info:Original: out i/f: PO3/3, label: implicit-null, nhop: 10.3.3.8With FRR: out i/f: Tu578, label: implicit-nullLSP bw: 100 kbps, Backup level: any unlimited, type: any poolr9_t1LSP Midpoint, signalled, connection upSrc 10.9.9.9, Dest 10.88.88.88, Instance 2347Fast Reroute Protection: RequestedInbound: FRR InactiveLSP signalling info:Original: in i/f: PO1/2, label: 12304, phop: 10.205.0.9Outbound: FRR ReadyBackup Tu5711 to LSP nhopTu5711: out i/f: PO1/1, label: implicit-nullLSP signalling info:Original: out i/f: PO1/0, label: 12305, nhop: 10.1.1.7With FRR: out i/f: Tu5711, label: 12305LSP bw: 10 kbps, Backup level: any unlimited, type: any poolRelated Commands
show mpls traffic-eng tunnels summary
To display summary information about tunnels, use the show mpls traffic-eng tunnels summary command in user EXEC or privileged EXEC mode.
show mpls traffic-eng tunnels summary
Syntax Description
This command has no arguments or keywords.
Command Modes
User EXEC
Privileged EXECCommand History
Examples
The following is sample output from the show mpls traffic-eng tunnels summary command:
Router# show mpls traffic-eng tunnels summarySignalling Summary:LSP Tunnels Process: runningRSVP Process: runningForwarding: enabledHead: 4 interfaces, 3 active signalling attempts, 3 established5 activations, 2 deactivationsMidpoints: 1, Tails: 0Periodic reoptimization: every 3600 seconds, next in 2778 secondsPeriodic fastreroute: every 300 seconds, next in 168 secondsPeriodic auto-bw collection: every 300 seconds, next in 78 secondsTable 21 describes the significant fields shown in the display.
Related Commands
tunnel mpls traffic-eng backup-bw
To specify what types of label-switched paths (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.
tunnel mpls traffic-eng backup-bw {bandwidth | [sub-pool {bandwidth | Unlimited}] [global-pool {bandwidth | Unlimited}]}
Syntax Description
Command Default
If neither sub-pool nor global-pool is entered, it is assumed that any LSP (those using bandwidth from the subpool or global pool) can use this backup tunnel.
Command Modes
Interface configuration
Command History
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 Unlimited is legal, but it is not legal to specify tunnel mpls traffic-eng backup-bw global-pool Unlimited sub-pool 100.
To limit both subpool and global pool LSPs, enter tunnel mpls traffic-eng backup-bw sub-pool bandwidth global-pool bandwidth.
If subpool 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 subpool. Backup tunnel 2 provides bandwidth protection for up to 1000 units.
Router(config)# interface Tunnel1Router(config-if)# tunnel mpls traffic-eng backup-bw global-pool UnlimitedRouter(config-if)# endRouter(config)# interface Tunnel2Router(config-if)# tunnel mpls traffic-eng backup-bw sub-pool 1000Router(config-if)# endRelated Commands
mpls traffic-eng backup path
Assigns one or more backup tunnels to a protected interface.
tunnel mpls traffic-eng fast-reroute
To enable a Multiprotocol Label Switching (MPLS) traffic engineering (TE) tunnel to use an established backup tunnel in the event of a link or node failure, use the tunnel mpls traffic-eng fast-reroute command in interface configuration mode. To disable this capability, use the no form of this command.
tunnel mpls traffic-eng fast-reroute [bw-protect]
no tunnel mpls traffic-eng fast-reroute
Syntax Description
bw-protect
(Optional) Sets the "bandwidth protection desired" bit so that backup bandwidth protection is enabled.
Command Default
There is no backup bandwidth protection.
Command Modes
Interface configuration
Command History
Usage Guidelines
If you specify the bw-protect keyword, all path messages for the tunnel's label-switched path (LSP) are sent with the bandwidth protection bit set.
After you enter the command, with or without the bw-protect keyword, the requested action or change propagates quickly along all hops of the LSP. Midpoint routers that are point of local repairs (PLRs) for the LSP take the appropriate action based on whether the bit was just set or cleared. If the bit was just set or cleared, a new backup tunnel selection happens for the LSP because it now has a higher or lower priority in the backup tunnel selection process.
To unconfigure only backup bandwidth protection, enter the tunnel mpls traffic-eng fast-reroute command.
To disable an MPLS TE tunnel from using an established backup tunnel in the event of a link or node failure, enter the no form of the command.
Examples
In the following example, backup bandwidth protection is enabled:
Router(config-if)# tunnel mpls traffic-eng fast-reroute bw-protectRelated Commands
Feature Information for MPLS Traffic Engineering (TE)—Fast Reroute (FRR) Link and Node Protection
Table 22 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Cisco IOS software images are specific to a Cisco IOS software release, a feature set, and a platform. Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/cfn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Note
Glossary
backup bandwidth—The usage of NHOP and NNHOP backup tunnels to provide bandwidth protection for rerouted LSPs.
backup tunnel—An MPLS TE tunnel used to protect other (primary) tunnels' traffic when a link or node failure occurs.
bandwidth—The available traffic capacity of a link.
Cisco Express Forwarding—A means for accelerating the forwarding of packets within a router, by storing route lookup.
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 headend.
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 System-to-Intermediate System—IS-IS. 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 link is 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.
limited backup bandwidth—Backup tunnels that provide bandwidth protection.
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 operates only in the event of a failure.
LSP—label-switched path. A connection between two routers in which MPLS forwards the 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.
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. Nodes can be processors, controllers, or workstations.
OSPF—Open Shortest Path First. A link-state hierarchical Interior Gateway Protocol routing algorithm, derived from the IS-IS protocol. OSPF features include least-cost routing, multipath routing, and load balancing.
primary LSP—The last LSP originally signaled over the protected interface before the failure. The primary LSP is 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. A 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.
SRLG—shared risk link group. Sets of links that are likely to go down together.
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 subpool 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.
unlimited backup bandwidth—Backup tunnels that provide no bandwidth (best-effort) protection (that is, they provide best-effort protection).
Note
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2003—2007 Cisco Systems, Inc. All rights reserved
