MCT Failover Scenarios
The following scenarios describe what happens if specific elements in the MCT configuration fail:
- Hitless failover occurs.
- The MCT CCEPs stay up during hitless switchover, failover, or upgrade. Link protocols such as UDLD and LACP on CCEPs do not flap. Traffic disruption is minimal (sub-second). The MCT CCP connection flaps once, and MAC is re-synced between the peer devices.
- The CCP goes down and comes back up again once the hitless failover is completed.
- ICL interface or CCP goes down (keep-alive VLAN is configured).
- If a keep-alive VLAN is used, the devices in the cluster can communicate even if the ICL goes down. If the peer device is reachable over the keep-alive VLAN, the MCT peers perform the active/standby negotiation per client. After negotiation, the standby shuts down its client ports, and the active client ports continue to forward the traffic.
- The active/standby negotiation is performed per MCT client on the basis of RBridge ID and client local or remote accessibility. If the client is reachable from both MCT devices, the lower RBridge ID becomes the active device. If the client can be accessed only from one of the MCT devices, the cluster device on which it is reachable becomes the active device.
- If the peer device cannot be reached over the keep-alive VLAN, then both cluster devices keep forwarding.
Note:
RUCKUS recommends using keep-alive VLANs with the MCT configurations. This provides alternative
access if the ICL interface goes down. However, a keep-alive VLAN must not be configured
when
bpdu-flood-enable is configured. Refer to
MCT Layer 2 Protocols.
- Double failures occur (for example, the ICL goes down and the client interface goes down on one of the MCT cluster devices).
Note: The keep-alive link is supported on the ICX 7750 in a single STP or MSTP environment,
even though the ICX 7750 has the BPDU flood-enable feature built in. This is because
BPDU flood-enable in the ICX 7750 is hardware-enabled.