The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The NSF/SSO--MPLS TE and RSVP Graceful Restart feature allows a Route Processor (RP) to recover from disruption in control
plane service without losing its Multiprotocol Label Switching (MPLS) forwarding state.
Cisco nonstop forwarding (NSF) with stateful switchover (SSO) provides continuous packet forwarding, even during a network
processor hardware or software failure. In a redundant system, the secondary processor recovers control plane service during
a critical failure in the primary processor. SSO synchronizes the network state information between the primary and the secondary
processor.
Prerequisites for NSF SSO--MPLS TE and RSVP Graceful Restart
Configure Resource Reservation Protocol (RSVP) graceful restart in full mode.
Configure RSVP graceful restart on all interfaces of the neighbor that you want to be restart-capable.
Configure the redundancy mode as SSO. See the Stateful Switchover feature module for more information.
Enable NSF on the routing protocols running among the provider routers (P), provider edge (PE) routers, and customer edge
(CE) routers. The routing protocols are as follows:
Border Gateway Protocol (BGP)
Open Shortest Path First (OSPF)
Intermediate System-to-Intermediate System (IS-IS)
See the Cisco Nonstop Forwarding feature module for more information.
Enable MPLS.
Configure traffic engineering (TE).
Restrictions for NSF SSO--MPLS TE and RSVP Graceful Restart
RSVP graceful restart supports node failure only.
Unnumbered interfaces are not supported.
You cannot enable RSVP fast reroute (FRR) hello messages and RSVP graceful restart on the same router.
You cannot enable primary one-hop autotunnels, backup autotunnels, or autotunnel mesh groups on a router that is also configured
with SSO and Route Processor Redundancy Plus (RPR+). This restriction does not prevent an MPLS TE tunnel that is automatically
configured by TE autotunnel from being successfully recovered if any midpoint router along the label-switched path (LSP) of
the router experiences an SSO.
MPLS TE LSPs that are fast reroutable cannot be successfully recovered if the LSPs are FRR active and the Point of Local Repair
(PLR) router experiences an SSO.
When you configure RSVP graceful restart, you must use the neighbor’s interface IP address.
Information About NSF SSO--MPLS TE and RSVP Graceful Restart
Overview of MPLS TE and RSVP Graceful Restart
RSVP graceful restart allows RSVP TE-enabled nodes to recover gracefully following a node failure in the network such that
the RSVP state after the failure is restored as quickly as possible. The node failure may be completely transparent to other
nodes in the network.
RSVP graceful restart preserves the label values and forwarding information and works with third-party or Cisco routers seamlessly.
RSVP graceful restart depends on RSVP hello messages to detect that a neighbor went down. Hello messages include Hello Request
or Hello Acknowledgment (ACK) objects between two neighbors.
As shown in the figure below, the RSVP graceful restart extension to these messages adds an object called Hello Restart_Cap,
which tells neighbors that a node may be capable of recovering if a failure occurs.
The Hello Restart_Cap object has two values: the restart time, which is the sender’s time to restart the RSVP_TE component
and exchange hello messages after a failure; and the recovery time, which is the desired time that the sender wants the receiver
to synchronize the RSVP and MPLS databases.
In the figure above, RSVP graceful restart help neighbor support is enabled on Routers 1 and 3 so that they can help a neighbor
recover after a failure, but they cannot perform self recovery. Router 2 has full SSO help support enabled, meaning it can
perform self recovery after a failure or help its neighbor to recover. Router 2 has two RPs, one that is active and one that
is standby (backup). A TE LSP is signaled from Router 1 to Router 4.
Router 2 performs checkpointing; that is, it copies state information from the active RP to the standby RP, thereby ensuring
that the standby RP has the latest information. If an active RP fails, the standby RP can take over.
Routers 2 and 3 exchange periodic graceful restart hello messages every 10,000 milliseconds (ms) (10 seconds), and so do
Routers 2 and 1 and Routers 3 and 4. Assume that Router 2 advertises its restart time = 60,000 ms (60 seconds) and its recovery
time = 60,000 ms (60 seconds) as shown in the following example:
Router 3 records this into its database. Also, both neighbors maintain the neighbor status as UP. However, Router 3’s control
plane fails at some point (for example, a primary RP failure). As a result, RSVP and TE lose their signaling information and
states although data packets continue to be forwarded by the line cards.
When Router 3 declares communication with Router 2 lost, Router 3 starts the restart time to wait for the duration advertised
in Router 2’s restart time previously recorded (60 seconds). Routers 1 and 2 suppress all RSVP messages to Router 3 except
hellos. Router 3 keeps sending the RSVP PATH and RESV refresh messages to Routers 4 and 5 so that they do not expire the state
for the LSP; however, Routers 1 and 3 suppress these messages for Router 2.
When Routers 1 and 3 receive the hello message from Router 2, Routers 1 and 3 check the recovery time value in the message.
If the recovery time is 0, Router 3 knows that Router 2 was not able to preserve its forwarding information, and Routers 1
and 3 delete all RSVP state that they had with Router 2.
If the recovery time is greater than 0, Router 1 sends Router 2 PATH messages for each LSP that it had previously sent through
Router 2. If these messages were previously refreshed in summary messages, they are sent individually during the recovery
time. Each of these PATH messages includes a Recovery_Label object containing the label value received from Router 2 before
the failure.
When Router 3 receives a PATH message from Router 2, Router 3 sends a RESV message upstream. However, Router 3 suppresses
the RESV message until it receives a PATH message. When Router 2 receives the RESV message, it installs the RSVP state and
reprograms the forwarding entry for the LSP.
Benefits of MPLS TE and RSVP Graceful Restart
State Information Recovery
RSVP graceful restart allows a node to perform self recovery or to help its neighbor recover state information when there
is an RP failure or the device has undergone an SSO.
Session Information Recovery
RSVP graceful restart allows session information recovery with minimal disruption to the network.
Increased Availability of Network Services
A node can perform a graceful restart to help itself or a neighbor recover its state by keeping the label bindings and state
information, thereby providing a faster recovery of the failed node and not affecting currently forwarded traffic.
How to Configure NSF SSO--MPLS TE and RSVP Graceful Restart
Sets the value to control the request interval in graceful restart hello messages. This interval represents the frequency
at which RSVP hello messages are sent to a neighbor; for example, one hello message is sent per each interval.
Note
If you change the default value for this command and you also changed the RSVP refresh interval using the iprsvpsignallingrefreshinterval command, ensure that the value for the iprsvpsignallinghellograceful-restartrefreshintervalcommandislessthanthevaluefortheiprsvpsignallinghellorefreshinterval command. Otherwise, some or all of the label-switched paths (LSPs) may not be recovered after an SSO has occurred.
Step 4
exit
Example:
Router(config)# exit
(Optional) Returns to privileged EXEC mode.
Setting a Value to Control the Missed Refresh Limit for RSVP Graceful Restart Hello Acknowledgements
Router(config)# ip rsvp signalling hello graceful-restart refresh misses 5
Specifies how many sequential RSVP TE graceful restart hello acknowledgments (ACKs) a node can miss before the node considers
communication with its neighbor lost.
Note
If you change the default value for this command and you are also using the iprsvpsignallinghellorefreshmissescommand, ensure that the value for the iprsvpsignallinghellograceful-restartrefreshmissescommandislessthanthevaluefortheiprsvpsignallinghellorefreshmisses command. Otherwise, some or all of the LSPs may not be recovered after an SSO has occurred.
Step 4
exit
Example:
Router(config)# exit
(Optional) Returns to privileged EXEC mode.
Verifying the RSVP Graceful Restart Configuration
SUMMARY STEPS
enable
showiprsvphellograceful-restart
exit
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
(Optional) Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
showiprsvphellograceful-restart
Example:
Router# showiprsvphellograceful-restart
Displays information about the status of RSVP graceful restart and related parameters.
Step 3
exit
Example:
Router# exit
(Optional) Returns to user EXEC mode.
Configuration Examples for NSF SSO--MPLS TE and RSVP Graceful Restart
Example Configuring NSF SSO--MPLS TE and RSVP Graceful Restart
In the following example, RSVP graceful restart is enabled globally and on a neighbor router’s interfaces as shown in the
figure below. Related parameters, including a DSCP value, a refresh interval, and a missed refresh limit are set.
enable
configure terminal
ip rsvp signalling hello graceful-restart mode full
interface POS 1/0/0
ip rsvp signalling hello graceful-restart neighbor 10.0.0.1
ip rsvp signalling hello graceful-restart neighbor 10.0.0.2
exit
ip rsvp signalling hello graceful-restart dscp 30
ip rsvp signalling hello graceful-restart refresh interval 50000
ip rsvp signalling hello graceful-restart refresh misses 5
exit
Example Verifying the NSF SSO--MPLS TE and RSVP Graceful Restart Configuration
Router# show ip rsvp hello graceful-restart
Graceful Restart: Enabled (full mode)
Refresh interval: 10000 msecs
Refresh misses: 4
DSCP:0x30
Advertised restart time: 30000 msecs
Advertised recovery time: 120000 msecs
Maximum wait for recovery: 3600000 msecs
Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement
Technical Assistance
Description
Link
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use
these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products
and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.
Feature Information for NSF SSO--MPLS TE and RSVP Graceful Restart
The following table provides release information about the feature or features described in this module. This table lists
only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise,
subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco
Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Table 1. Feature Information for NSF/SSO--MPLS TE and RSVP Graceful Restart
Feature Name
Releases
Feature Information
NSF/SSO--MPLS TE and RSVP Graceful Restart
Cisco IOS XE Release 3.1S
Cisco IOS XE Release 3.5S
The NSF/SSO--MPLS TE and RSVP Graceful Restart feature allows a Route Processor (RP) to recover from disruption in control
plane service without losing its Multiprotocol Label Switching (MPLS) forwarding state.
Cisco nonstop forwarding (NSF) with stateful switchover (SSO) provides continuous packet forwarding, even during a network
processor hardware or software failure. In a redundant system, the secondary processor recovers control plane service during
a critical failure in the primary processor. SSO synchronizes the network state information between the primary and the secondary
processor.
In Cisco IOS XE Release 3.1S, this feature was implemented on the Cisco ASR 1000 Series Aggregation Services Routers.
The following commands were introduced or modified:
cleariprsvphigh-availabilitycounters,
debugiprsvphigh-availability,
debugiprsvpsso,
debugmplstraffic-enghasso,
iprsvpsignallinghellograceful-restartdscp,
iprsvpsignallinghellograceful-restartmode,
iprsvpsignallinghellograceful-restartmodehelp-neighbor,
iprsvpsignallinghellograceful-restartneighbor,
iprsvpsignallinghellograceful-restartrefreshinterval,
iprsvpsignallinghellograceful-restartrefreshmisses,
showiprsvpcounters,
showiprsvpcountersstateteardown,
showiprsvphello,
showiprsvphelloclientlspdetail,
showiprsvphelloclientlspsummary,
showiprsvphelloclientneighbordetail,
showiprsvphelloclientneighborsummary,
showiprsvphellograceful-restart,
showiprsvphelloinstancedetail,
showiprsvphelloinstancesummary,
showiprsvphigh-availabilitycounters,
showiprsvphigh-availabilitydatabase,
showiprsvphigh-availabilitysummary.
In Cisco IOS XE Release 3.5S, this feature was implemented on the Cisco ASR 1000 Series Aggregation Services Routers.
MPLS TE— Autotunnel/Automesh SSO Coexistence
Cisco IOS XE Release 3.5S
In Cisco IOS XE Release 3.5S, this feature was implemented on the Cisco ASR 1000 Series Aggregation Services Routers.
Glossary
DSCP--differentiated services code point. Six bits in the IP header, as defined by the Internet Engineering Task Force (IETF).
These bits determine the class of service provided to the IP packet.
FastReroute--A mechanism for protecting Multiprotocol Label Switching (MPLS) traffic engineering (TE) label switched paths (LSPs) from
link and node failure 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 end-to-end LSPs to replace them. Fast reroute (FRR) locally repairs the protected
LSPs by rerouting them over backup tunnels that bypass failed links or nodes.
gracefulrestart--A process for helping a Route Processor (RP) restart after a node failure has occurred.
headend--The router that originates and maintains a given label switched path (LSP). This is the first router in the LSP’s path.
helloinstance--A mechanism that implements the Resource Reservation Protocol (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.
IGP--Interior Gateway Protocol. Internet protocol used to exchange routing information within an autonomous system. Examples
of common Internet IGPs include Interior Gateway Routing Protocol (IGRP), Open Shortest Path First (OSPF), and Routing Information
Protocol (RIP).
ISSU--In Service Software Upgrade. Software upgrade without service interruption.
label--A short, fixed-length data identifier that tells switching nodes how to forward data (packets or cells).
LSP--label switched path. A configured connection between two routers, in which Multiprotocol Label Switching (MPLS) is used
to carry packets.
MPLS--Multiprotocol Label Switching. A method for forwarding packets (frames) through a network. MPLS enables routers at the edge
of a network to apply labels to packets (frames). ATM switches or existing routers in the network core can switch packets
according to the labels.
RSVP--Resource Reservation Protocol. A protocol that supports the reservation of resources across an IP network. Applications
running on IP end systems can use RSVP to indicate to other nodes the nature (bandwidth, jitter, maximum burst, and so on)
of the packet streams they want to receive.
state--Information that a router must maintain about each label switched path (LSP). The information is used for rerouting tunnels.
tailend--The router upon which a label switched path (LSP) is terminated. This is the last router in the LSP’s path.
TE--traffic engineering. The techniques and processes used to cause routed traffic to travel through the network on a path other
than the one that would have been chosen if standard routing methods had been used.
Feedback