Juniper MC-LAG ICCP Failure: LACP System ID Behavior on QFX

Juniper's Multichassis Link Aggregation (MC-LAG) relies on the Inter-Chassis Control Protocol (ICCP) to keep two QFX switches behaving like one logical device. When that ICCP session drops, the way each peer treats its LACP system ID decides whether the attached server keeps a stable bundle or suffers a painful re-convergence. This article walks through the official ICCP failure scenarios documented for QFX switches, explains what each one does to the LACP system ID, and shows the Junos statements engineers use to avoid split-brain states in the first place.

ICCP Failure Scenarios and LACP System ID Behavior

Juniper's failure-handling table for QFX series summarises what happens to a multichassis aggregated Ethernet (MC-AE) interface whose status is set to standby. The three inputs are the ICCP connection state, the ICL (inter-chassis link) state and the backup liveness peer status:

• ICCP down, backup liveness not configured — the LACP system ID is changed to the default value, so the downstream device keeps only the links of the first peer that comes up.
• ICCP down, backup liveness Active — the LACP system ID is changed to the default value for both the active and the standby MC-AE interfaces. Both peers still believe the other side is alive, so neither can safely take over.
• ICCP down, backup liveness Inactive — no change is made to the LACP system ID. Liveness has confirmed the remote peer is really gone, so the surviving switch can keep the configured system ID and the server bundle stays up.
• ICCP up but ICL down — the LACP state is set to standby and the MUX state moves to waiting, preventing loops over a broken inter-chassis link.

The default system ID change is the switch's safety mechanism: when a true split-brain exists, forcing both sides back to the default LACP system ID makes the server select a single peer's links instead of forwarding through both. See our related breakdown of MC-LAG ICCP, BFD and LACP system ID behavior for the protocol fundamentals.

Why Backup Liveness Detection Matters

ICCP runs over TCP, so a plain link failure between the peers can take the session down while both switches are still powered and forwarding. Without extra state, both MC-LAG peers may stay active and send duplicate traffic to the connected server — the "packets loop on the server" failure mode documented in Juniper's MC-LAG troubleshooting guide. Backup liveness detection gives each peer an out-of-band heartbeat over the management network so a peer can distinguish "ICCP lost" from "peer is dead".

set protocols iccp backup-liveness-detection backup-peer-ip 10.10.10.2
set protocols iccp peer 10.10.10.2 liveness-detection minimum-interval 8000
set protocols iccp peer 10.10.10.2 session-establishment-hold-time 340

Best practice notes from Juniper: configure the liveness interval to at least 8 seconds when ICCP runs over an IRB interface so graceful Routing Engine switchover (GRES) works seamlessly, and add the master-only statement to the management IP used for liveness on both routing engines so the heartbeat survives a GRES. Our article on ICCP backup liveness configuration covers the full setup.

Verifying ICCP and MC-AE State

When a failure is suspected, start with the operational commands that expose each layer of the MC-LAG control plane:

user@qfx> show iccp
user@qfx> show iccp detail
user@qfx> show mc-ae
user@qfx> show lacp interfaces ae0 detail
user@qfx> show interfaces ae0 extensive | match "LACP|MC-AE"

show iccp reports the TCP connection state between the peers, the BFD liveness state and the client applications (MCSNOOPD, LACPD, ESWD). show mc-ae shows which role each MC-AE is currently playing. For deeper failure hunting, see our standby and split-brain scenario guide.

Design Rules That Prevent the Failure Modes

• Run ICCP over the peer loopback addresses instead of a direct link, so a single cable failure does not drop the session.
• Use prefer-status-control-active on the active peer so the LACP system ID does not revert to default during an ICCP failure.
• Prefer the icl-down-delay timer over hold-time when the status-control-active peer reboots, to avoid momentary traffic loss on the standby peer.
• Keep the session-establishment hold time (default 300 s) at least 100 s above the init delay time — Juniper suggests 340 s hold with 240 s init delay on QFX.
• Enable backup liveness detection on both peers; configure it on a dedicated out-of-band management path whenever possible.

Understanding exactly which LACP system ID behavior follows each ICCP failure state is what separates a clean MC-LAG failover from a server-side LACP storm. Verify the state with the commands above before touching any configuration.

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