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:

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.

1.    enable


2.    configure terminal


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


4.    exit

Router> enable

Router# configure terminal

Router(config)# ip rsvp signalling hello graceful-restart mode full 

Router(config)# exit

1.    enable


2.    configure terminal


3.    interface type slot / subslot / port [. subinterface-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


8.    exit

Router> enable

Router# configure terminal

Router(config)# interface POS 1/0/0

Router(config-if)# ip rsvp signalling hello graceful-restart neighbor 10.0.0.0 

Router(config-if)# exit

Router(config)# exit

1.    enable


2.    configure terminal


3.    ip rsvp signalling hello graceful-restart dscp num


4.    exit

Router> enable

Router# configure terminal

Router(config)# ip rsvp signalling hello graceful-restart dscp 30

Router(config)# exit

1.    enable


2.    configure terminal


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


4.    exit

Router> enable

Router# configure terminal

Router(config)# ip rsvp signalling hello graceful-restart refresh interval  5000

Router(config)# exit

1.    enable


2.    configure terminal


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


4.    exit

Router> enable

Router# configure terminal

Router(config)# ip rsvp signalling hello graceful-restart refresh misses 5

Router(config)# exit

1.    enable


2.    show ip rsvp hello graceful-restart


3.    exit

Router> enable

Router# show ip rsvp hello graceful-restart

Router# exit