When a peer determines that communication has been lost, it can reinitiate the
sending of hello messages. In this case, the peer generates a new source instance
different than the one it previously used for communication with its peer.
RSVP-TE Graceful Restart
RSVP-TE graceful restart enables routers to maintain MPLS forwarding state when a
link or node failure occurs. In a link failure, control communication is lost between
two nodes, but the nodes do not lose their control or forwarding state.
A node failure occurs when the LSR has a failure in the RSVP-TE control plane, but
not in the data plane. The LSR maintains its data forwarding state. Traffic can continue
to be forwarded while RSVP-TE restarts and recovers. The graceful restart feature
supports the restoration and resynchronization of RSVP-TE states and MPLS
forwarding state between the restarting router and its RSVP-TE peers during the
graceful restart recovery period.
The RSVP-TE graceful restart feature enables an LSR to gracefully restart, to act as a
graceful restart helper node for a neighboring router that is restarting, or both.
Announcement of the Graceful Restart Capability
LSRs use the RSVP-TE hello mechanism to announce their graceful restart capabilities
to their peer RSVP-TE routers. Both restarting LSRs and helper LSRs include the
restart_cap object in hello requests and hello acks. The restart_cap object specifies
both the graceful restart time and the graceful restart recovery time:
■restart time—The sum of how long it takes the sender to restart RSVP-TE after
a control plane failure plus how long it takes to reestablish hello communication
with the neighboring RSVP-TE routers.
■recovery time—The period within which you want neighboring routers to
resynchronize with the sending router’s RSVP-TE state and MPLS forwarding
state after the peers have re-established hello communication. The restarting
LSR advertises the configured or default recovery time only while the graceful
restart is in progress. When the LSR is not currently restarting or when it is
incapable of preserving its MPLS forwarding state during the restart, the LSR
advertises a recovery time of zero.
Both the restarting router and neighboring GR helper routers save the restart and
recovery times that they receive from their peers.
Restarting Behavior
When the control plane fails, the LSR stops sending hello messages to its RSVP-TE
neighbors. However, as a restarting router the LSR can continue to forward MPLS
traffic because it preserves its MPLS forwarding state during the restart. When
RSVP-TE comes back up, the restarted router sends the first hello message to its
neighbors with a new source instance value to indicate that it had a control plane
failure. The destination instance value in the hello message is set to zero. The recovery
time included in this hello message is set to zero only if the router was unable to
preserve the MPLS forwarding state or to support control state recovery.
254 â– RSVP-TE Graceful Restart
JUNOSe 11.1.x BGP and MPLS Configuration Guide
To Next Page
Loading...
Need help?
General
