VRRP fail-back takes ca. 30 seconds when connecting ports belong to MLT


Article ID: 167905


Updated On:




Describes possible source of long fail-back time when connecting back ports belong to MLTIn DBHA or multibox HA VRRP, a fail-over to the VRRP backup chassis caused by disconnecting one or more MLT (LACP) ports takes a moment and full traffic is restored within relatively short time as expected, typically 3-5 seconds.

When re-connecting all MLT (LACP) links to the original MasterĀ chassisĀ (currently Backup) with preemption enabled fail-over happens immediately, as configured, but it takes an unexpectedly long time (approximately 30 seconds), to restore full traffic.


The problem might be caused by the configuration of external devices connected to the Crossbeam X-Series platform, as all ports on the NPM are brought up immediately. Often it's a problem of configuration in the context of Spanning Tree Protocol (STP) or a similar configuration issue, which blocks normal traffic from being forwarded for a couple of seconds while STP checks for loops in the network.


Please review the configuration of the connected devices and verify whether those devices are configured to bring up all ports and forward traffic immediately. Usually the function that needs to be enabled is called PortFast or fast-start or a similar name.

With this feature, the STP for the port in question assumes that the port is not part of a loop and immediately moves to the forwarding state and does not go through the blocking, listening, or learning states. This command does not turn STP off. This command makes STP skip a few initial steps (unnecessary steps, in this circumstance) on the selected port.

On Cisco devices this function is called PortFast and should be enabled.

This feature can be safely turned on in environments where the Crossbeam X-Series platform works as a Layer 3+ firewall separating L2 broadcast domains in fact terminating any L2 loops.