Table Of Contents
MPLS Traffic Engineering (TE): Link and Node Protection, with RSVP Hellos Support
Bandwidth Protection Considerations
Using Backup Tunnels with Explicitly Signaled Bandwidth
Using Backup Tunnels Signaled with Zero Bandwidth
Related Features and Technologies
Supported Platforms and Interfaces
Supported Standards, MIBs, RFCs, and Drafts
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 an Interface for Fast Link and Node Failure Detection
Verifying That Fast ReRoute Is In Place
Enabling Fast ReRoute for all Tunnels
Creating an NHOP Backup Tunnel
Creating an NNHOP Backup Tunnel
Assigning Backup Tunnels to a Protected Interface
Associating Backup-Bandwidth and Pool Type with Backup Tunnels
Configuring RSVP Hello and POS Signals
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 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
MPLS Traffic Engineering (TE): Link and Node Protection, with RSVP Hellos Support
Feature History
12.0(10)ST
Fast ReRoute Link Protection feature was introduced.
12.0(16)ST
Link Protection for Cisco Series 7200 and 7500 platforms was added.
12.0(22)S
Fast ReRoute enhancements were added.
12.0(23)S
The show mpls traffic-eng fast-reroute database command was revised.
12.0(24)S
Support for the Cisco 10720 Internet Router and the Cisco 12000 series router engine 3 was added.
12.2(18)SXD1
This feature was integrated into Cisco IOS Release 12.2(18)SX.
This document describes the Fast ReRoute (FRR) enhancements, including Node Protection, in Cisco IOS Release 12.0(24)S. Node Protection can be viewed as a superset of (that is, an enhancement to) FRR Link Protection. The document includes the following sections:
•
Supported Platforms and Interfaces
•
Note
Feature Overview
Fast ReRoute (FRR) is a mechanism for protecting MPLS Traffic Engineering (TE) label-switched paths (LSPs) from link and node failures by locally repairing the LSPs at the point of failure, allowing data to continue to flow on them while their headend routers attempt to establish new end-to-end LSPs to replace them. FRR locally repairs the protected LSPs by rerouting them over backup tunnels that bypass failed links or nodes.
Backup tunnels that bypass only a single link of the LSP's path provide Link Protection. They protect LSPs if a link along their path fails by rerouting the LSP's traffic to the next hop (bypassing the failed link). These are referred to as next-hop (NHOP) backup tunnels because they terminate at the LSP's next hop beyond the point of failure. Figure 1 illustrates a next-hop backup tunnel.
Figure 1 Next-Hop Backup Tunnel
FRR provides Node Protection for LSPs. Backup tunnels that bypass next-hop nodes along LSP paths are called next-next-hop (NNH) backup tunnels because they terminate at the node following the next-hop node of the LSP paths, thereby bypassing the next-hop node. They protect LSPs if a node along their path fails by enabling the node upstream of the failure to reroute the LSPs and their traffic around the failed node to the next-next hop. FRR supports the use of RSVP Hellos to accelerate the detection of node failures. NNHOP backup tunnels also provide protection from link failures, because they bypass the failed link as well as the node.
Figure 2 illustrates a next-next hop backup tunnel.
Figure 2 Next-Next Hop 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 include the following:
•
•
•
The Fast ReRoute enhancements include the following:
•
•
•
•
•
•
Benefits
Node Protection
Backup tunnels that terminate at the next-next hop protect both the downstream link and node. This provides protection for link and node failures.
Multiple Backup Tunnels Can Protect the Same Interface
In addition to being required for Node Protection, this enhancement provides the following benefits:
•
•
Bandwidth Protection
Rerouted LSPs not only have their packets delivered during a failure, but the quality of service can also be maintained.
Scalability
A backup tunnel can protect multiple LSPs. Furthermore, a backup tunnel can protect multiple interfaces. This is called many-to-one (N:1) protection. N:1 protection has significant scalability advantages over one-to-one (1:1) protection, where a separate backup tunnel must be used for each LSP needing protection. N:1 protection is not new with Node Protection; it existed with Link Protection.
Example of 1:1 protection: When 5,000 backup tunnels protect 5,000 LSPs, each router along the backup path must maintain state for an additional 5,000 tunnels.
Example of N:1 protection: When one backup tunnel protects 5,000 LSPs, each router along the backup path maintains one additional tunnel.
RSVP Hello
RSVP Hello allows a router to detect when its neighbor has gone down but its interface to that neighbor is still operational. When Layer 2 link protocols are unable to detect that the neighbor is unreachable, Hellos provide the detection mechanism; this allows the router to switch LSPs onto its backup tunnels and avoid packet loss.
Fast ReRoute Operation
This section illustrates and 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 Fast ReRoute. If RSVP Hellos are configured on an interface, messages are periodically sent to the neighboring router. If no response is received, Hellos declare that the neighbor is down. This causes any LSPs going out that interface to be switched to their respective backup tunnels.
Backup Tunnels Terminating at Different Destinations
Figure 3 illustrates an interface that has multiple backup tunnels terminating at different destinations and demonstrates why, in many topologies, support for Node Protection requires supporting multiple backup tunnels per protected interface.
Figure 3 Backup Tunnels that Terminate at Different Destinations
In this illustration, a single interface on R1 requires multiple backup tunnels. LSPs traverse the following routes:
•
•
To provide protection if node R2 fails, two NNHOP backup tunnels are required: one terminating at R3 and one terminating at R4.
Backup Tunnels Terminating at the Same Destination
Figure 4 shows how backup tunnels terminating at the same location can be used for redundancy and load balancing. Redundancy and load balancing work for both NHOP and NNHOP backup tunnels.
Figure 4 Backup Tunnels that Terminate at the Same Destination
In this illustration, there are three routers: R1, R2, and R3. At R1, there are two NNHOP backup tunnels (T1 and T2) that go from R1 to R3 without traversing R2.
Redundancy—If R2 fails or the link from R1 to R2 fails, either backup tunnel can be used. If one backup tunnel is down, the other can be used. LSPs are assigned to backup tunnels when the LSPs are first established. This is done before a failure.
Load balancing—If neither backup tunnel has enough bandwidth to back up all LSPs, both tunnels can be used. Some LSPs will use one backup tunnel, other LSPs will use the other backup tunnel. The router decides the best way to fit the LSPs onto the backup tunnels.
Backup Tunnel Selection Procedure
When an LSP is signaled, each node along the LSP path that provides FRR protection for the LSP selects a backup tunnel for the LSP to use if either of the following events occurs:
•
•
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 LSP's bandwidth. If an LSP is requesting zero bandwidth, the router chooses the backup tunnel that is currently protecting the fewest LSPs.
Pool Type and Backup Tunnels
By default, a backup tunnel provides protection for LSPs that allocate from any pool (that is, global or sub-pool). However, a backup tunnel can be configured to protect only LSPs that use global-pool bandwidth, or only those that use sub-pool bandwidth.
Next-hop Versus Next-next Hop Backup Tunnels
More than one backup tunnel can protect a given LSP, where one backup tunnel terminates at the LSP's NNHOP, and the other terminates at the LSP's NHOP. In this case, the router chooses the backup tunnel that terminates at the NNHOP (that is, Fast ReRoute prefers NNHOP over NHOP backup tunnels).
Table 1 lists the tunnel selection priorities. The first choice is an NNHOP backup tunnel that acquires its bandwidth from a sub-pool or global-pool, and has limited bandwidth. If there is no such backup tunnel, the next choice (2) is a next-next hop backup tunnel that acquires a limited amount of bandwidth from any pool. The preferences go from 1 (best) to 8 (worst), where choice 3 is for an NNHOP backup tunnel with an unlimited amount of sub-pool or global-pool bandwidth.
Figure 7 shows an example of the backup tunnel selection procedure based on the designated amount of global-pool and sub-pool bandwidth currently available.
Figure 7 Choosing from Among Multiple Backup Tunnels
In this example, an LSP requires 20 units (kilobits per second) of sub-pool backup-bandwidth. The best backup tunnel is selected as follows:
1.
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, above, the LSP's backup tunnel is evaluated immediately. Case 3 is addressed by periodically reevaluating LSP-to-backup tunnel mappings. By default, background reevaluation is performed every 5 minutes. This interval is configurable via the mpls traffic-eng fast-reroute timers command.
Bandwidth Protection Considerations
There are numerous ways in which bandwidth protection can be ensured. Table 2 describes the advantages and disadvantages of two methods.
Cisco implementation of FRR does not mandate a particular approach, and it provides the flexibility to use either of the above approaches. However, given a range of configuration choices, be sure that the choices constant with a particular bandwidth protection strategy.
The following sections describe some important issues in choosing an appropriate configuration:
•
•
Using Backup Tunnels with Explicitly Signaled Bandwidth
There are two bandwidth parameters that 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 PLR (the head-end of the backup tunnel) to decide how much primary traffic can be rerouted to this backup tunnel if there is a failure.
Both parameters need to be set to ensure proper operation. The numerical value of the signaled bandwidth and the backup-bandwidth should be the same.
Protected Bandwidth Pools and the Bandwidth Pool from which the Backup Tunnel Reserves its Bandwidth
The tunnel mpls traffic-eng bandwidth command allows you to configure the following:
•
•
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.
Example: In this example, assume the following:
•
•
Bandwidth protection for 10 Kbps of sub-pool traffic on a given link can be achieved by any of the following combinations:
•
tunnel mpls traffic-eng 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 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 max reservable sub-pool value of S, there may be a path from node A to node B such that the difference between max reservable global and max reservable sub-pool is at least S. If it is possible to find such paths for each link in the network, you can establish all the backup tunnels along such paths without any bandwidth reservations. If there is a single link failure, only one backup tunnel will use any link on its path. Since that path has at least S of available bandwidth (in the global pool), assuming that marking and scheduling is configured to classify the sub-pool traffic into a priority queue, the sub-pool bandwidth is guaranteed.
The above approach allows sharing of the global pool bandwidth between backup tunnels protecting independent link failures. The backup tunnels are expected to be used for only a short period of time after a failure (until the head-ends of affected LSPs reroute those LSPs to other paths with available sub-pool bandwidth). The probability of multiple unrelated link failures is very small (in the absence of node or SRLG failures, which result in multiple link failures). Therefore, it is reasonable to assume that link failures are in practice independent with high probability. This "independent failure assumption" in combination with backup tunnels signaled without explicit bandwidth reservation enables efficient bandwidth sharing that yields substantial bandwidth savings.
Backup tunnels protecting the sub-pool traffic do now draw bandwidth from any pool. Primary traffic using the global pool can use the entire global pool, and primary traffic using the sub-pool can use the entire sub-pool. Yet, sub-pool traffic has a complete bandwidth guarantee if there is a single link failure.
A similar approach can be used for node and SRLG protection. However, the decision of where to put the backup tunnels is more complicated because both node and SRLG failures effectively result in the simultaneous failure of several links. Therefore, the backup tunnels protecting traffic traversing all affected links cannot be computed independently of each other. The backup tunnels protecting groups of links corresponding to different failures can still be computed independently of each other, which results in similar bandwidth savings.
Signaled Bandwidth versus Backup-Bandwidth
Backup-bandwidth is used locally (by the router that is the head-end of the backup tunnel) to determine which, and how many, primary LSPs can be rerouted on a particular backup tunnel. The router ensures that the combined bandwidth requirement of these LSPs does not exceed the backup-bandwidth.
Therefore, even when the backup tunnel is signaled with zero bandwidth, the backup-bandwidth must be configured with the value corresponding to the actual bandwidth requirement of the traffic protected by this backup tunnel. Unlike the case when bandwidth requirements of the backup tunnels are explicitly signaled, the value of the signaled bandwidth (which is zero) is not the same value as the backup-bandwidth.
RSVP Hello Operation
RSVP Hello enables RSVP nodes to detect when a neighboring node is not reachable. This provides node-to-node failure detection. When such a failure is detected, it is handled in a similar manner as a link-layer communication failure.
RSVP Hello can be used by FRR when notification of link-layer failures is not available (for example, with Ethernet), or when the failure detection mechanisms provided by the link layer are not sufficient for the timely detection of node failures.
A node running Hello sends a Hello Request to a neighboring node every interval. If the receiving node is running Hello, it responds with Hello Ack. If four intervals pass and the sending node has not received an Ack or it receives a bad message, the sending node declares that the neighbor is down and notifies FRR.
There are two configurable parameters:
•
•
Note
Hello Instance
A Hello instance implements RSVP Hello for a given router interface address and remote IP address. A Hello instance is expensive because of the large number of Hello requests that are sent and the strains they put on the router resources. Therefore, create a Hello instance only when it is necessary and delete it when it is no longer needed.
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.
Hello Commands
RSVP Hello comprises the following commands:
•
•
RSVP Hello Configuration Commands
•
•
•
•
•
•
RSVP Hello Statistics Commands
•
•
•
RSVP Hello Show Commands
•
•
•
•
•
RSVP Hello Debug Commands
•
Restrictions
•
•
•
•
•
Related Features and Technologies
•
•
•
•
•
Related Documents
For IS-IS:
•
•
For Link Protection:
•
•
For MPLS Traffic Engineering:
•
•
•
•
•
•
For OSPF:
•
•
For RSVP:
•
•
Supported Platforms and Interfaces
Supported Platforms
•
–
Enhanced OSM POS modules
Enhanced FlexWAN with POS Port Adapters
WAN ports on the OSM-2+4GE-WAN+ module
WS-X6516
WS-X67xx
Note
•
•
•
•
–
4-port OC-3 POS
1-port OC-12 POS
1-port CHOC-12/DS3
1-port CHOC-12/ STM4 and OC3/ STM1
6-/12-port DS3
6-/12-port E3
6-port CT3
2-port CHOC-3/STM1–
1-port OC-48 POS
4-port OC-12 POS
8-/16-port OC-3 POS–
4-port OC-12c/STM-4c POS ISE
4-port CHOC-12 ISE
1-port OC-48c POS ISE
1-port CHOC-48 ISE
4-, 8-, and 16-port OC3c POS ISESupported Interfaces
•
•
•
Determining Platform Support Through Cisco Feature Navigator
Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.
Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.
To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.
Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:
Availability of Cisco IOS Software Images
Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.
Supported Standards, MIBs, RFCs, and Drafts
Standards
•
•
MIBs
No new or modified MIBs are supported by this feature.
To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs and Drafts
This feature complies with draft-swallow-rsvp-bypass-label-03.txt.
Prerequisites
•
–
–
•
–
–
•
–
–
Configuration Tasks
This section assumes that you want to add Fast ReRoute protection to a network in which MPLS TE LSPs are configured.
Before performing the configuration tasks, it is assumed that you have done the following tasks but you do not have to already have configured MPLS TE tunnels:
•
•
To review how to configure MPLS TE tunnels, see the Cisco IOS Switching Services Configuration Guide, Release 12.2.
The following sections describe how to use FRR to protect LSPs in your network from link or node failures. Each task is identified as either required or optional.
•
•
•
•
•
Note
Note
Enabling Fast ReRoute on LSPs
LSPs can use backup tunnels only if they have been configured as fast reroutable. To do this, enter the following commands, beginning in global configuration mode, at the headend of each LSP:
Creating a Backup Tunnel to the Next Hop or to the Next-Next Hop
To create a backup tunnel to the next hop or to the next-next hop, enter the following commands on the node that will be the headend of the backup tunnel (that is, the node whose downstream link or node may fail). The node on which you enter these commands must be a supported platform. See "Supported Platforms and Interfaces".
Creating a backup tunnel is basically no different from creating any other tunnel. None of the commands below is new.
Note
Assigning Backup Tunnels to a Protected Interface
To assign one or more backup tunnels to a protected interface, enter the following commands on the node that will be the headend of the backup tunnel (that is, the node whose downstream link or node may fail). The node on which you enter these commands must be a supported platform. See "Supported Platforms and Interfaces".
Note
Step 1
Router(config)# interface type slot/port
Moves configuration to the physical interface level, directing subsequent configuration commands to the specific physical interface identified by the type. The slot and port identify the slot and port being configured. The interface must be a supported interface. See "Supported Platforms and Interfaces".
Step 2
Router(config-if)# mpls traffic-eng backup-path tunnel tunnel-id
Allows LSPs going out this interface to use this backup tunnel if there is a link or node failure.
Note
Associating Backup-Bandwidth and Pool Type with a Backup Tunnel
To associate backup-bandwidth with a backup tunnel and designate the type of LSP that can use a backup tunnel, enter the following command:
Configuring an Interface for Fast Link and Node Failure Detection
To configure pos ais-shut, enter the following commands:
interface pos0/0pos ais-shutTo configure pos report lrdi on OS interfaces, enter the following commands:
interface pos0/0pos report lrdiVerifying That Fast ReRoute Is In Place
To ensure that Fast ReRoute can function, do the following:
•
•
•
•
•
•
Fast ReRoute Configuration
To determine if Fast ReRoute has been configured correctly, do the following:
•
•
Conditions that Must Exist for Backup Tunnels to be Operational
If you created LSPs and performed the required configuration tasks but do not have operational backup tunnels (that is, the backup tunnels are not up or the LSPs are not associated with those backup tunnels), verify that all the following conditions exist:
•
On the router where the backup tunnels originate, enter the show mpls traffic-eng tunnels backup command. The command output will allow you to verify the following:
•
•
•
•
Note
•
If none of the above actions works, enable debug by entering the debug ip rsvp fast-reroute command and the debug mpls traffic-eng fast-reroute command on the router that is the headend of the backup tunnel. Then do the following:
1.
2.
3.
show mpls traffic-eng fast-reroute database command
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 32 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)
show mpls traffic tunnel backup command
The following show ip rsvp sender command output verifies that protection has been enabled.
Router# show mpls traffic-eng tunnel backupTunnel1000 Dest: 12.0.0.10 State: Upglb-pool cfg 100 inuse 0 num_lsps 0protects: POS0/0protects: POS0/1The command shows the following information for a given backup tunnel:
•
•
•
•
•
•
•
show ip rsvp sender command
Following is sample output from the show ip rsvp sender detail command when the command is entered at the Point of Local Repair (PLR) before a failure. For a detailed explanation of the output, see the show ip rsvp sender command.
Router# show ip rsvp sender detailPATH:Tun Dest: 24.1.1.1 Tun ID: 1 Ext Tun ID: 23.1.1.1Tun Sender: 23.1.1.1, LSP ID: 126Path refreshes arriving on POS1/0 from PHOP 11.1.1.1Path refreshes being sent to NHOP 12.1.1.2 on POS1/1Session Attr::Setup Prio: 0, Holding Prio: 0Flags: Local Prot desired, Label Recording, SE StyleSession Name:tagsw4500-23_t1ERO:12.1.1.2 (Strict IPv4 Prefix, 8 bytes, /32)14.1.1.1 (Strict IPv4 Prefix, 8 bytes, /32)14.1.1.2 (Strict IPv4 Prefix, 8 bytes, /32)24.1.1.1 (Strict IPv4 Prefix, 8 bytes, /32)Traffic params - Rate: 0G b
Guest
