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 the Graceful Restart Hello command is configured on an interface, the interface hello is considered to be an additional hello instance with the neighbor.

An interface hello for Graceful Restart is transmitted when all of the following conditions are met:

• Graceful Restart is configured globally.
• Graceful restart is configured on the interface.
• An LSP to the neighbor 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:

• Interface hello --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.
• Node hello --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.

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:

23:33:36: Outgoing Hello:
23:33:36:   version:1 flags:0000 cksum:883C ttl:255 reserved:0 length:32
23:33:36:  HELLO                type HELLO REQUEST length 12:
23:33:36:   Src_Instance: 0x6EDA8BD7, Dst_Instance: 0x00000000
23:33:36:  RESTART_CAP          type 1 length 12:
23:33:36:   Restart_Time: 0x0000EA60, Recovery_Time: 0x0000EA60

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.

In Cisco IOS 12.2(33)SRE and later releases, MPLS TE primary tunnels, backup tunnels, and automesh tunnels can coexist with SSO; that is, they can be configured together. However, there are the following functional differences:

• Headend autotunnels created on the active RP are not checkpointed and created on the standby RP.
• After the SSO switchover, the new active RP recreates all the headend autotunnels and signals their LSPs. The LSP ID is different from the LSP ID used before the SSO switchover. Tunnel traffic may be dropped during the signaling of new autotunnel LSPs.
• SSO coexistence does not affect TE autotunnels in the midpoint or tailend routers along the LSPs from being checkpointed and recovered.

1.    enable

2.    configure terminal

3.    ip rsvp signalling hello graceful-restart mode (help-neighbor| full)

4.    exit

Note

If you have many tunnels/LSPs (100 or more) or if you have a large-scale network, the following configuration is recommended:

ip rsvp signalling refresh reduction
ip rsvp signalling rate-limit period 50 burst 16 maxsize 3000 limit 37
ip rsvp signalling patherr state-removal
ip rsvp signalling initial-retransmit-delay 15000

Note	You must repeat this procedure for each of the neighbor router's interfaces.

1.    enable

2.    configure terminal

3.    interface type number

4.    Repeat Step 3 as needed to configure additional interfaces.

5.    ip rsvp signalling hello graceful-restart neighbor ip-address

6.    Repeat Step 5 as needed to configure additional IP addresses on a neighbor router's interfaces.

7.    exit

1.    enable

2.    configure terminal

3.    ip rsvp signalling hello graceful-restart dscp num

4.    exit

1.    enable

2.    configure terminal

3.    ip rsvp signalling hello graceful-restart refresh interval interval-value

4.    exit

1.    enable

2.    configure terminal

3.    ip rsvp signalling hello graceful-restart refresh misses msg-count

4.    exit

1.    enable

2.    show ip rsvp hello graceful-restart

3.    exit

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

The following example verifies the status of RSVP graceful restart and the configured parameters:

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