MC-LAG ICCP Failure Scenarios: Standby and Split-Brain

MC-LAG (Multichassis Link Aggregation) depends on a healthy Inter-Chassis Control Protocol (ICCP) session between two peers, and when that session fails the behavior of the LACP system ID, the standby link state and the data plane all change in very specific ways. This article walks through the documented Juniper MC-LAG ICCP failure scenarios, explains why a peer may not enter standby mode, how backup liveness detection prevents split-brain, and which Junos commands to run when the ICCP connection misbehaves.

What Happens When the ICCP Connection Fails

The ICCP session is the brain of the MC-LAG pair: it synchronizes MAC learning, ARP, and LACP state between the two multichassis aggregated Ethernet interfaces. When ICCP goes down, both peers must coordinate a fallback through backup liveness detection and the inter-chassis link (ICL). Juniper documents the exact matrix of ICCP status, ICL status, backup liveness status and the resulting action on the multichassis aggregated Ethernet interfaces with status control set to standby.

MC-LAG Peer Does Not Go into Standby Mode

A classic failure: the MC-LAG peer never enters standby mode because the peer IP address configured under protocols iccp does not match the IP address configured under the multichassis protection configuration. The two addresses must be identical for the state machine to work.

user@switch# set interfaces ae1 unit 0 multi-chassis-protection 172.16.32.6 interface ae1
user@switch# set protocols iccp local-ip-addr 172.16.32.5
user@switch# set protocols iccp peer 172.16.32.6 session-establishment-hold-time 50
user@switch# set protocols iccp peer 172.16.32.6 redundancy-group-id-list 1

Packets Loop on the Server When ICCP Fails

When backup liveness detection is enabled and its packets are lost during a temporary MC-LAG failure, both peers stay active and both send packets to the connected server. This is expected behavior, and it is exactly the split-brain condition that backup liveness detection is designed to recover from: the liveness check fails after the configured consecutive misses, and the failure action is implemented.

Both Peers Use the Default LACP System ID After a Reboot

After a reboot or a new ICCP configuration commit, if the ICCP connection is not active, LACP messages on the multichassis aggregated Ethernet interfaces use the default system ID instead of the configured one. The server then accepts the first link that comes up and brings down the other links carrying a different LACP system ID, so traffic fails over to one peer only.

ICCP Does Not Come Up After Adding and Deleting an Authentication Key

If an authentication key is added and then deleted at the global ICCP level, the ICCP connection may fail to establish even though authentication works correctly at the peer level. Juniper's documented solution is to delete the ICCP configuration and re-add it.

Liveness Detection and Split-Brain Prevention

Backup liveness detection exchanges keepalives over the management link between the ICCP peers. Configure it on both sides, using the peer's management (backup) IP address:

user@switch# set protocols iccp peer 10.50.1.2 backup-liveness-detection backup-peer-ip 10.1.1.2
user@switch# set protocols iccp peer 10.50.1.1 backup-liveness-detection backup-peer-ip 10.1.1.1
user@switch# set protocols iccp peer 10.50.1.1 liveness-detection minimum-receive-interval 1000

Note that when backup liveness detection is configured, peer status is always up if the ICCP TCP connection is established or BFD is up; the liveness check only runs while ICCP is down. As a further safeguard on QFX switches, enable arp-l2-validate on the IRB interface to resynchronize ARP and MAC table entries during flapping:

user@switch# set interfaces irb arp-l2-validate

Key Troubleshooting Commands

• show iccp - ICCP session state and registered client daemons (mcsnoopd, lacpd, eswd)
• show lacp interfaces ae0 - LACP state and system ID in use
• show ethernet-switching table - MAC entries learned on multichassis aggregated Ethernet interfaces
• show log messages | match ICCP - ICCP state transitions

Best Practices to Avoid ICCP Failure Scenarios

• Use the peer loopback address for ICCP peering so a single link failure does not reset the session.
• Configure ICCP and the ICL on different interfaces and different FPCs.
• Keep session-establishment-hold-time at 50 seconds for faster ICCP bring-up.
• Configure alternative routes (or a two-member LAG) between the ICCP end points.

For related reading on the same topic, see our MC-LAG ICCP failure liveness and LACP system ID deep dive, the MC-LAG ICCP failure packet loop troubleshooting guide, and the ICCP, BFD and LACP system ID overview.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/mc-lag/topics/task/troubleshooting-mc-lag-qfx-series-cli.html