MC-LAG ICCP Failure: LACP System ID Behavior on Junos

MC-LAG (Multi-Chassis Link Aggregation) on Junos OS keeps two QFX or EX switches acting as one logical switch, but the whole design depends on the ICCP control channel staying healthy. When ICCP goes down, the peers must change behavior deterministically or the downstream server will see two different LACP partners and start flapping links. This article explains the ICCP failure scenarios documented by Juniper, what happens to the LACP system ID in each case, and how backup liveness detection, BFD timers and GRES change the recovery story.

ICCP Failure Scenarios and the LACP System ID Matrix

Juniper documents a clear action matrix for QFX Series switches. The outcome depends on three inputs: ICCP connection status, ICL (inter-chassis link) status, and whether backup liveness detection reports the peer as Active or Inactive.

• ICCP Down, backup liveness not configured: the LACP system ID is changed to the default value, so each MC-LAG peer stops pretending to be one switch.
• 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.
• ICCP Down, backup liveness Inactive: no change to the LACP system ID.
• ICCP Up but ICL Down: LACP state is set to standby and the MUX state machine moves to the waiting state.

The logic behind the matrix is simple: when the peer is confirmed dead (backup liveness Inactive), keeping a shared LACP system ID is safe because only one switch remains. When the peer may still be alive but ICCP is lost, each switch reverts to a unique default LACP system ID so the downstream device brings up only one link instead of forming an inconsistent bundle. For a deeper look at adjacent failure modes such as standby state and split-brain, see our earlier breakdown of MC-LAG ICCP failure scenarios: standby and split-brain.

Backup Liveness Detection Configuration

Backup liveness detection gives the peers an out-of-band channel through the management network that is used only when the ICCP TCP connection is operationally down. The peers exchange liveness requests, and if no response arrives within the configured timeout for a set number of consecutive attempts, the peer is declared down and the failure action above is applied. If backup liveness detection is configured, peer status is always Up when either the ICCP TCP connection is established or BFD is up; the backup liveness check only runs while ICCP is down.

set protocols iccp peer 1 session-establishment-hold-timer 340
set protocols iccp peer 1 liveness-detection backup-liveness-detection
set protocols iccp peer 1 liveness-detection minimum-interval 1000
set protocols iccp peer 1 liveness-detection multiplier 3

Juniper recommends configuring ICCP connectivity over an aggregated interface whose child links are spread across multiple FPCs, and adding the backup liveness channel so a single link or FPC failure cannot silently split the pair. See the dedicated reference on ICCP backup liveness detection for MC-LAG for more detail.

ICCP over IRB and BFD Timer Guidance

When ICCP is carried over an IRB interface, configure the ICCP liveness-detection interval (the BFD timer) to at least 8 seconds. An interval below 8 seconds can break graceful Routing Engine switchover (GRES): during GRES there is a control-plane gap that a fast BFD timer mistakes for a peer failure, forcing an unnecessary LACP system ID change and traffic disruption. An 8-second or longer interval lets GRES complete seamlessly.

GRES, ARP and MAC Synchronization Notes

• During GRES, ARP entries learned remotely on the MC-LAG peer are purged and then re-learned; plan for the brief re-population window.
• ARP and MAC tables normally stay synchronized, but link flapping can desynchronize them; Juniper recommends the arp-l2-validate statement on IRB interfaces as a workaround, disabling it again in normal operation because it can cost performance at scale.
• Dynamic ARP resolution over the ICL interface is not supported; ARP replies received on ICL are discarded.
• DHCP relay combined with MAC address synchronization is not supported; use VRRP over IRB/RVI when Layer 3 DHCP relay is required, and prefer the bootp forwarding helper over the extended jdhcp process.

Split-Brain Prevention Summary

Split-brain occurs when ICCP adjacency is lost while both peers are still forwarding. The combination of aggregated ICCP links, backup liveness detection over the management network, a master-only management address, and a conservative BFD liveness interval is what keeps the LACP system ID behavior deterministic. Apply the same system ID and administration key on both peers, verify with show iccp and show lacp interfaces, and always test peer failure in a maintenance window. For general design guidance, review our Juniper MC-LAG best practices article as well.

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