MC-LAG ICCP Failure Scenarios: Liveness Detection and LACP System ID Behavior

When the Inter-Chassis Control Protocol (ICCP) connection between two Juniper MC-LAG peers drops, the way each peer treats its multichassis aggregated Ethernet (MC-AE) interface decides whether the server loses its bundle or keeps forwarding. This article walks through the official ICCP failure scenarios for QFX and EX series switches: what backup liveness detection does, when the LACP system ID is changed, and which settings engineers should apply to avoid a split-brain state.

Why ICCP Failure Is Dangerous for MC-LAG

ICCP carries the control messages that keep both MC-LAG peers coordinated - configuration parameters, LACP system IDs and forwarding state. Because ICCP runs over TCP/IP between the peers, a link failure, an FPC failure, or a full peer reboot can bring the adjacency down while both switches stay powered on. If nothing else intervenes, both peers may remain active and both may forward frames to the connected server, which is exactly the split-brain condition described in Junos documentation.

Backup Liveness Detection and the LACP System ID

Junos uses an out-of-band channel for backup liveness detection: the peers exchange keepalive messages over the management network so each can tell whether the other is really down. The key behavior table from the Junos MC-LAG documentation shows:

• ICCP down + backup liveness not configured: the LACP system ID changes to the default value on both active and standby MC-AE interfaces.
• ICCP down + backup liveness active: the LACP system ID also changes to the default - the standby peer confirms the other is dead and takes over.
• ICCP down + backup liveness inactive: no change in LACP system ID, because the peer is assumed alive.
• ICCP up but ICL down: the LACP state on standby links is set to standby and the MUX state moves to waiting.

Because only one LACP system ID can win on the downstream server, the system ID change is what breaks the tie after a real peer failure - the server keeps only the links from the surviving peer.

Verifying ICCP and Liveness State

user@qfx> show iccp
Redundancy Group Information for peer 1
  TCP Connection:          Up
  Liveness Detection:      Up
  Client Application:      MCSNOOPD, LACPD, ESWD

Use show iccp detail to inspect the TCP connection, the BFD-based liveness detection state, and each client application (MCSNOOPD, LACPD, ESWD). When troubleshooting, confirm that backup-liveness-detection is configured on both peers, otherwise the check never runs.

Configuration Best Practices from Juniper

set protocols iccp peer 1 session-establishment-hold-time 340
set protocols iccp peer 1 liveness-detection minimum-interval 8000
set protocols iccp peer 1 backup-liveness-detection backup-peer-ip 192.0.2.2
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options mc-ae mc-ae-id 1
set interfaces ae0 aggregated-ether-options mc-ae redundancy-group 1
set interfaces ae0 aggregated-ether-options mc-ae status-control standby
set interfaces ae0 aggregated-ether-options mc-ae prefer-status-control-active

Juniper also recommends configuring ICCP over peer loopback addresses, using separate ports/FPCs for the ICL and ICCP links, and setting the ICCP BFD interval to at least 8 seconds when ICCP runs over an IRB interface so that GRES stays graceful.

Related Reading on This Site

See our earlier deep dives on MC-LAG ICCP failure scenarios: standby and split-brain and Juniper ICCP backup liveness configuration, plus the ICCP, BFD and LACP system ID deep dive.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/mc-lag/topics/concept/best-practices-usage-notes.html