Juniper JUNOSE, Руководство по настройке

Страница: 286 / 738

When a neighboring router that has been configured as a graceful restart helper
determines that the number of continuous missing hellos has reached the configured
hello miss limit, it declares the router to be down. The helper router then waits for
a period equal to the restart time that it received from the router and stored before
the failure. During this period, the helper router preserves the restarting router's
RSVP-TE state and MPLS forwarding state for the established LSPs and keeps
forwarding MPLS traffic. However, the helper router suspends the refreshing of path
and resv state to the restarting router. The helper router keeps sending hello messages
to the restarting router with an unchanged source instance value and a destination
instance value set to zero. The helper router removes the RSVP-TE state for any LSP
that was in the process of being established when the neighbor was declared to be
down.
If the helper router does not receive a hello message from the restarting router during
the restart period, the helper router immediately exits the recovery procedure and
cleans up the states associated with the restarting router. The helper router determines
that the failed neighbor has restarted when it finds a new source instance in the
neighbor's hello message. When a nonzero recovery time is received in that hello
message, the helper router determines that the restarted neighbor supports state
recovery. The helper router then starts the recovery procedures. However, if the
recovery time specified in the hello message is zero, then the helper router exits the
recovery procedure and cleans up the states associated with the restarting router.
Recovery Behavior
In the recovery period, neighboring helper routers and the restarting router
resynchronize the RSVP-TE state and MPLS forwarding state. During this period,
MPLS traffic continues to be forwarded.
The helper router starts the recovery procedure by marking as stale the RSVP-TE
state associated with the restarting router. The upstream helper router then refreshes
all the path messages shared with the downstream restarting router. The upstream
helper router includes the recovery_label object in the path message to the
downstream restarting router for the label binding information that the restarting
router specified before the restart. The downstream helper router does not refresh
the reservation state control block (RSB) shared with the restarting router until a
corresponding path message is received from the restarting router.
During the recovery period, the restarting router checks for the state associated with
an incoming path message. If the RSVP-TE state already exists, the restarting router
handles the path message as usual. Otherwise, the restarting router examines the
path message for the recovery_label object. If the recovery_label object is not found,
the restarting router treats the path message as a setup request for a new LSP and
handles the path message as usual.
If the recovery_label object is found, the restarting router searches for the outgoing
label based on the incoming interface and incoming label that are specified in the
recovery_label object. If the restarting router does not find a match for the forwarding
entry, the restarting router treats the path message as a setup request for a new LSP.
If the restarting router finds a match, it conveys to the downstream neighbors the
outgoing label associated with the forwarding entry in the suggested_label object in
the path message and it continues normal operations.
250 ■
RSVP-TE Graceful Restart
JUNOSe 11.0.x BGP and MPLS Configuration Guide