Juniper MC-LAG ICCP Failure: Packet Loop and Troubleshooting Guide

2026年8月31日 LOG admin

MC-LAG (Multichassis Link Aggregation) on Junos makes two switches behave like one active-active bundle, but the moment the Inter-Chassis Control Protocol (ICCP) session between the peers breaks, a cascade of subtle failures can appear — from packet loops on the attached server to stale MAC entries and wrongly suppressed failover. Based on Juniper's official MC-LAG troubleshooting documentation for QFX and EX series, this article collects the most common ICCP failure scenarios, explains why each one happens, and gives the exact solution or expected-behavior note for every case.

Why ICCP Failure Causes Packet Loops

When you enable backup liveness detection for an MC-LAG and the liveness packets are lost due to a temporary failure, both peers can remain active at the same time. With two peers forwarding traffic for the same Multichassis Aggregated Ethernet (MC-AE) interface, the server sees frames arriving from two sources and packets can loop. The recommended fix is to configure interfaces aeX aggregated-ether-options mc-ae events iccp-peer-down force-icl-down, which forces the inter-chassis link (ICL) down when ICCP is lost so that the secondary peer stops forwarding.

Common Junos MC-LAG Failure Scenarios

1. MAC Address Age Resets to Zero on MC-AE

Activating and then deactivating an interchassis link-protection link (ICL-PL) resets the MAC address age learned on the multichassis aggregated Ethernet interface to zero. This is expected behavior — the next-hop interface change triggers MAC updates in hardware, which in turn trigger aging updates in the Packet Forwarding Engine. The show ethernet-switching table output showing age 0 is normal.

2. MAC Not Learned Remotely in Default VLAN

On a QFX3500 running Junos 12.3 or earlier, ICCP does not synchronize a MAC address learned in the default VLAN with the other MC-LAG peer. Upgrade to a newer release to resolve this known limitation.

3. Local Status Stays Standby

If the MC-AE interface is down when the state machine is in a synchronized state, the local status becomes standby. If the interface goes down after the state machine is active, the local status remains active. Check the interface state before concluding the peer has failed.

4. Double Failover Scenario

If ICCP goes down and then the active MC-AE interface also goes down, a double failover occurs: the standby peer has no ICCP information and cannot coordinate failover correctly. This is one of the most disruptive MC-LAG failure modes and is why backup liveness detection plus force-icl-down is strongly recommended.

5. Layer 3 Traffic Not Redirected to Standby

When ICCP is down, the status of the remote MC-LAG peer is unknown — even if it is configured as standby, Layer 3 traffic is not redirected to it because the switch assumes the peer is down.

ARP and MAC Out-of-Sync Fix: arp-l2-validate

To prevent ARP and MAC table entries drifting out of sync in an MC-LAG configuration, configure the arp-l2-validate option on the switch's IRB interface. This option turns on validation of ARP and MAC entries and automatically applies updates when they become out of sync. It is available on QFX Series, EX4300 (from Junos 15.1R4) and EX9200 (from 13.2R4) switches. Enable it as a workaround during incidents, but disable it during normal operation because it can impact performance in large-scale configurations.