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.
Perform the following tasks on devices before configuring the MPLS Traffic
Engineering—RSVP Graceful Restart feature:
Configure the Resource Reservation Protocol (RSVP).
Enable MPLS.
Configure traffic engineering (TE).
Enable graceful restart.
Restrictions for MPLS TE—RSVP Graceful
Restart
Graceful restart supports node failure only.
Cisco recommends that you configure interface hellos only if the neighbor device
does not support node hellos.
Unnumbered interfaces are not supported.
You cannot configure an interface hello for graceful restart and a hello state
timeout (HST) on the same interface.
Information About MPLS TE—RSVP Graceful
Restart
The following section provides information about MPLS TE—RSVP Graceful Restart.
Graceful Restart Operation
The MPLS Traffic Engineering—RSVP Graceful Restart feature allows a neighboring Route
Processor (RP) to recover from disruption in control plane service (specifically, the
Label Distribution Protocol (LDP) component) without losing its Multiprotocol Label
Switching (MPLS) forwarding state. This feature has the following benefits:
Graceful restart allows a node to recover state information from its neighbor
when there is an RP failure or the device has undergone a stateful switchover
(SSO).
Graceful restart allows session information recovery with minimal disruption to
the network.
A node can perform a graceful restart to help a neighbor recover its state by
keeping the label bindings and state information to provide a quick recovery of
the failed node and not affect the traffic that is currently forwarded.
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 Devices 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.
A node hello is transmitted when graceful restart is globally configured and the first
LSP to the neighbor is created.
Interface hello is an optional configuration. If you configure the graceful restart
Hello command on an interface, the interface hello is considered to be an additional
hello instance with the neighbor.
The Device transmits an interface hello for graceful restart when all of the following
conditions are met:
Graceful restart is configured globally.
Graceful restart is configured on the interface.
An LSP to the neighboring Device is created and goes over the interface.
Cisco recommends that you use node hellos if the neighbor supports node hellos, and
configure interface hellos only if the neighbor Device does not support node hellos.
Interface hellos differ from node hellos. as follows:
Interfacehello—The source address in the IP header of the hello message has an IP
address that matches the interface that the Hello message sent out. The
destination address in the IP header is the interface address of the neighbor on
the other side of the link. A TTL of 1 is used for per-interface hellos as it is
destined for the directly-connected neighbor.
Nodehello—The source address in the IP header of the Hello message includes the
TE Device ID of the sending Device. The destination address of the IP header has
the Device ID of the neighbor to which this message is sent. A TTL of more than
1 is used.
The figure below shows the graceful restart extension to these messages that an object
called Restart_Cap, which tells neighbors that a node, may be capable of restarting if a
failure occurs. The time-to-live (TTL) in these messages is set to 255 so that
adjacencies can be maintained through alternate paths even if the link between two
neighbors goes down.
The 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, graceful restart is enabled on Device 1, Device 2, Device 3, and
Device 4. For simplicity, assume that all Devices are restart capable. A TE label
switched path (LSP) is signaled from Device 1 to Device 4.
Device 2 and Device 3 exchange periodic graceful restart hello messages every 10000 ms
(10 seconds), and so do Device 2 and Device 1 and Device 3 and Device 4. Assume that
Device 2 advertises its restart time as 60000 ms (60 seconds) and its recovery time as
60000 ms (60 seconds) as shown in the following example:
The restart and recovery time are shown in bold in the
last entry.
Device 3 records this into its database. Also, both neighbors maintain the neighbor
status as UP. However, Device 3’s control plane fails at some point (for example, a
Primary Route Processor 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 four ACK messages are missed from Device 2 (40 seconds), Device 3 declares
communication with Device 2 lost “indicated by LOST” and starts the restart time to wait
for the duration advertised in Device 2’s restart time previously and recorded (60
seconds). Device 1 and Device 2 suppress all RSVP messages to Device 3 except hellos.
Device 3 keeps sending the RSVP Path and Resv refresh messages to Device 4 and Device 5
so that they do not expire the state for the LSP; however, Device 3 suppresses these
messages for Device 2.
Note
A node restarts if it misses four ACKs or its hello src_instance (last source
instance sent to its neighbor) changes so that its restart time = 0.
Before the restart time expires, Device 2 restarts and loads its configuration and
graceful restart makes the configuration of Device 2 send the hello messages with a new
source instance to all the data links attached. However, because Device 2 has lost the
neighbor states, it does not know what destination instance it should use in those
messages; therefore, all destination instances are set to 0.
When Device 3 sees the hello from Device 2, Device 3 stops the restart time for Device 2
and sends an ACK message back. When Device 3 sees a new source instance value in Device
2’s hello message, Device 3 knows that Device 2 had a control plane failure. Device 2
gets Device 3’s source instance value and uses it as the destination instance going
forward.
Device 3 also checks the recovery time value in the hello message from Device 2. If the
recovery time is 0, Device 3 knows that Device 2 was not able to preserve its forwarding
information and Device 3 deletes all RSVP state that it had with Device 2.
If the recovery time is greater than 0, Device 1 sends Device 2 Path messages for each
LSP that it had previously sent through Device 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 Device 2 before the failure.
When Device 3 receives a Path message from Device 2, Device 3 sends a Resv message
upstream. However, Device 3 suppresses the Resv message until it receives a Path
message.
How to Configure MPLS TE—RSVP Graceful
Restart
This section describes how to configure MPLS TE—RSVP Graceful Restart.
Enabling Graceful Restart
To enable graceful restart, perform this procedure.
Note
It is optional that you configure graceful restart on an interface.
Procedure
Command or Action
Purpose
Step 1
enable
Example:
Device enable
Enables privileged EXEC mode. Enter your password, if prompted.
Device(config)# ip rsvp signalling hello graceful-restart refresh misses 5
Sets a refresh limit on a device with graceful restart enabled.
Step 4
end
Example:
Device(config)# end
Exits to privileged EXEC mode.
Verifying Graceful Restart
Configuration
Procedure
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables privileged EXEC mode. Enter your password, if prompted.
Step 2
showiprsvphellograceful-restart
Example:
Device# showiprsvphellograceful-restart
Displays information about the status of graceful restart and related parameters.
Step 3
end
Example:
Device# end
Exits to user EXEC mode.
Configuration Examples for MPLS TE—RSVP
Graceful Restart
The following section provides configuration examples for MPLS TE—RSVP Graceful
Restart.
Example: MPLS TE—RSVP Graceful Restart
Example
In the following example, graceful restart is enabled, and related parameters, including a
DSCP value, a refresh interval, and a missed refresh limit are set:
Device# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Device(config)# ip rsvp signalling hello graceful-restart mode help-neighbor
Device(config)# ip rsvp signalling hello graceful-restart dscp 30
Device(config)# ip rsvp signalling hello graceful-restart refresh interval 10000
Device(config)# ip rsvp signalling hello graceful-restart refresh misses 4
Device(config)# end
The following example verifies the status of graceful restart and the configured
parameters:
Device# show ip rsvp hello graceful-restart
Graceful Restart:Enabled (help-neighbor only)
Refresh interval:10000 msecs
Refresh misses:4
DSCP:0x30
Advertised restart time:0 secs
Advertised recovery time:0 secs
Maximum wait for recovery:3600000 secs
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 History for MPLS Traffic
Engineering—RSVP Graceful Restart
This table provides release and related information for the features explained in
this module.
These features are available in all the releases subsequent to the one they were
introduced in, unless noted otherwise.
Release
Feature
Feature Information
Cisco IOS XE Cupertino 17.7.1
MPLS Traffic Engineering—RSVP Graceful Restart
The MPLS Traffic Engineering—RSVP Graceful Restart feature allows
a neighboring Route Processor (RP) to recover from disruption in
control plane service (specifically, the Label Distribution
Protocol (LDP) component) without losing its Multiprotocol Label
Switching (MPLS) forwarding state.
Use the Cisco Feature Navigator to find information about platform and software image
support. To access Cisco Feature Navigator, go to https://cfnng.cisco.com/