Product guide

Router Redundancy Using XRRP
Overview of XRRP Operation
Router Operation in the Infinite Fail-Back Mode
An XRRP router with permanent (primary and secondary) address control and
infinite fail-back enabled will not surrender permanent control (fail-back) to
a recovered fail-over router except as described below.
■ XRRP traffic is moving between the two routers and a system operator
initiates fail-back by using the xrrp ctrl-transfer CLI command in either of
the following cases:
• on the fail-back router to force a fail-back to the fail-over router
• on the fail-over router, provided that traffic can move between the
fail-back router and the fail-over router
(This command allows the fail-over router to resume primary control of
its XRRP VLANs, which causes the fail-back router to stop advertising
XRRP packets for the fail-over router IP addresses.)
Note If a system operator uses xrrp ctrl-transfer to force a fail-back from a fail-back
router to a fail-over router that has not recovered access to all of its XRRP
VLANs, the fail-back is blocked and the fail-back router continues to advertise
XRRP packets for the failed router’s backed-up IP addresses.
■ Fail-Back is triggered by an event in which all of the fail-back router’s
XRRP VLANs go down due to network problems or by the fail-back router
rebooting. (Contrary to operation without infinite fail-back enabled, the
fail-back router retains permanent control as long as at least one of its
XRRP VLANs is up.)
■ A system operator initiates fail-back by disabling and re-enabling XRRP
on the peer router.
■ Fail-Back is triggered by replacing the failed router in a protection domain
with an XRRP router that is not configured with infinite fail-back.
Note In a protection domain where XRRP router “A” has permanent control and
peer router “B” has all of its XRRP VLANs up, replacing router “A” causes a
fail-back that restores router “B” to primary control of its XRRP VLANs.
12-14