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 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.
Prerequisites for MPLS TE—RSVP Graceful Restart
Perform the following tasks on routers 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 router does not support node hellos.
Unnumbered interfaces are not supported.
You cannot configure an interface hello for graceful restart and an interface hello for Fast ReRoute or hello state timeout
(HST) on the same interface.
Information About MPLS TE—RSVP Graceful Restart
Graceful Restart Operation
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.
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 router 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 router 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 router 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 router ID of the sending router. The destination
address of the IP header has the router 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.
Figure 1. How Graceful Restart Works
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 Router 1, Router 2, Router 3, and Router 4. For simplicity, assume that
all routers are restart capable. A TE label switched path (LSP) is signaled from Router 1 to Router 4.
Router 2 and Router 3 exchange periodic graceful restart hello messages every 10000 ms (10 seconds), and so do Router 2 and
Router 1 and Router 3 and Router 4. Assume that Router 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.
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 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 Router 2 (40 seconds), Router 3 declares communication with Router 2 lost “indicated
by LOST” and starts the restart time to wait for the duration advertised in Router 2’s restart time previously and recorded
(60 seconds). Router 1 and Router 2 suppress all RSVP messages to Router 3 except hellos. Router 3 keeps sending the RSVP
Path and Resv refresh messages to Router 4 and Router 5 so that they do not expire the state for the LSP; however, Router
3 suppresses these messages for Router 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, Router 2 restarts and loads its configuration and graceful restart makes the configuration
of Router 2 send the hello messages with a new source instance to all the data links attached. However, because Router 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 Router 3 sees the hello from Router 2, Router 3 stops the restart time for Router 2 and sends an ACK message back. When
Router 3 sees a new source instance value in Router 2’s hello message, Router 3 knows that Router 2 had a control plane failure.
Router 2 gets Router 3’s source instance value and uses it as the destination instance going forward.
Router 3 also checks the recovery time value in the hello message from Router 2. If the recovery time is 0, Router 3 knows
that Router 2 was not able to preserve its forwarding information and Router 3 deletes all RSVP state that it 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.
How to Configure MPLS TE—RSVP Graceful Restart
Enabling Graceful Restart
Note
It is optional that you configure graceful restart on an
interface.
Router(config)# ip rsvp signalling hello graceful-restart refresh misses 5
Sets a refresh limit on a router with graceful restart enabled.
Step 4
end
Example:
Router(config)# end
Exits to privileged EXEC mode.
Verifying Graceful Restart Configuration
SUMMARY STEPS
enable
showiprsvphellograceful-restart
end
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
showiprsvphellograceful-restart
Example:
Router# showiprsvphellograceful-restart
Displays information about the status of graceful restart and related parameters.
Step 3
end
Example:
Router# end
Exits to user EXEC mode.
Configuration Examples for MPLS TE—RSVP Graceful Restart
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:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# ip rsvp signalling hello graceful-restart mode help-neighbor
Router(config)# ip rsvp signalling hello graceful-restart dscp 30
Router(config)# ip rsvp signalling hello graceful-restart refresh interval 10000
Router(config)# ip rsvp signalling hello graceful-restart refresh misses 4
Router(config)# end
The following example verifies the status of graceful restart and the configured parameters:
Router# 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 Information for MPLS Traffic Engineering—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 MPLS Traffic Engineering—RSVP Graceful Restart
Feature Name
Releases
Feature Information
MPLS Traffic Engineering—RSVP Graceful Restart
12.0(29)S
12.2(33)SRE
12.4(20)T
Cisco IOS XE Release 2.3
The MPLS TE—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 MPLS forwarding state.
In Cisco IOS Release 12.0(29)S, this feature was introduced.
In Cisco IOS Release 12.4(20)T, this feature was integrated.
The following commands were introduced or modified:
iprsvpsignallinghellograceful-restartdscp,iprsvpsignallinghellograceful-restartmodehelp-neighbor,
iprsvpsignallinghellograceful-restartrefreshinterval,
iprsvpsignallinghellograceful-restartrefreshmisses,
showiprsvpcounters,
showiprsvpcountersstateteardown,
showiprsvphello,
showiprsvphelloclientlspdetail,
showiprsvphelloclientlspsummary,
showiprsvphelloclientneighbordetail,
showiprsvphelloclientneighborsummary,
showiprsvphellograceful-restart,
showiprsvphelloinstancedetail,
showiprsvphelloinstancesummary.
In Cisco IOS Release 12.2(33)SRE, per node hellos allow interoperability with Cisco IOS Release 12.0S.
Glossary
autonomous system—A collection of networks that share the same routing protocol and that are under the same system administration.
ASBR—Autonomous System Boundary Router. A router that connects and exchanges information between two or more autonomous systems.
backup tunnel—An MPLS traffic engineering tunnel used to protect other (primary) tunnels’ traffic when a link or node failure occurs.
DSCP—differentiated services code point. Six bits in the IP header, as defined by the IETF. These bits determine the class of
service provided to the IP packet.
Fast Reroute—A mechanism for protecting MPLS traffic engineering (TE) 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. FRR locally repairs the protected LSPs by rerouting them over backup tunnels that bypass failed links
or nodes.
graceful restart—A process for helping a neighboring Route Processor restart after a node failure has occurred.
headend—The router that originates and maintains a given LSP. This is the first router in the LSP’s path.
IGP—Interior Gateway Protocol. Internet protocol used to exchange routing information within an autonomous system. Examples of
common Internet IGPs include IGRP, OSPF, and RIP.
instance—A mechanism that 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.
label—A short, fixed-length data identifier that tells switching nodes how to forward data (packets or cells).
LDP—Label Distribution Protocol. The protocol that supports MPLS hop-by-hop forwarding by distributing bindings between labels
and network prefixes. The Cisco proprietary version of this protocol is the Tag Distribution Protocol (TDP).
LSP—label switched path. A configured connection between two routers, in which MPLS is used to carry packets. A path created
by the concatenation of one or more label switched hops, allowing a packet to be forwarded by swapping labels from an MPLS
node to another MPLS node.
merge point—The tail of the backup tunnel.
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.
PLR—point of local repair. The headend of the backup tunnel.
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.
RP—Route processor. Processor module in routers that contains the CPU, system software, and most of the memory components that
are used in the router. Sometimes called a supervisory processor.
state—Information that a router must maintain about each LSP. The information is used for rerouting tunnels.
tailend—The router upon which an 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.
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.
Feedback