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

Juniper MC-LAG (Multi-Chassis Link Aggregation) lets two switches or routers terminate a single LAG from a downstream device, giving link-level redundancy without spanning-tree blocking. The glue that keeps the two chassis acting as one is ICCP (Inter-Chassis Control Protocol), and when ICCP breaks, the visible symptom is almost always the LACP system ID: the two nodes stop advertising a shared system ID and the aggregated link starts flapping. This article walks through the most common ICCP failure scenarios, explains how liveness detection works, and shows exactly what happens to LACP system ID behavior in each case, with the CLI commands you need to verify and fix them.

How MC-LAG and ICCP Work Together

In an MC-LAG deployment, both participating nodes (MC-LAG peers) run the same LAG identifier (mc-ae-id) and present themselves to the downstream switch as a single LAG. ICCP runs over TCP between the peers and carries the state that keeps LACP consistent: the ICCP session tells each peer which system ID the other side is using, so both nodes advertise the same LACP system ID to the customer device. ICCP also synchronizes MAC address tables and monitors link liveness.

ICCP Liveness Detection

ICCP uses a keepalive mechanism to detect whether the peer is alive. On Junos you tune it under protocols iccp:

set protocols iccp local-ip-addr 10.0.0.1
set protocols iccp peer 10.0.0.2
set protocols iccp peer 10.0.0.2 session-establishment-hold-time 360
set protocols iccp peer 10.0.0.2 liveness-detection interval 2
set protocols iccp peer 10.0.0.2 liveness-detection failure-threshold 3

liveness-detection interval sets how often keepalives are sent (2 seconds in this example) and failure-threshold sets how many missed keepalives trigger a session failure (3). The effective detection time is interval × threshold, so here the peer is declared dead after about 6 seconds.

Failure Scenario 1: ICCP Session Goes Down

When the ICCP TCP session fails (control-link outage, keepalive expiry, or a node reboot), the MC-LAG immediately enters a degraded state. Each node stops learning the peer's LACP state and reverts to advertising its own LACP system ID.

• Before failure: both peers advertise the shared system ID (derived from the mc-ae-id and chassis IDs), so the downstream device sees one LAG.
• After failure: each peer advertises a unique system ID. The downstream switch now sees two different LACP partners on its member ports and starts flapping the bundle (typically one member goes to standby/individual).

Verification Commands

show iccp session
show iccp peer-state
show lacp interfaces ae0
show interfaces ae0 extensive

On show lacp interfaces ae0 you will see the system ID change from a shared value to the local value after the ICCP session drops. This is the single most useful symptom to confirm an ICCP problem rather than a physical LAG problem.

Failure Scenario 2: Single ICCP Link Fails but Session Stays Up

If ICCP runs over a single link and that link fails, the session flaps. Junos keeps the session up for a short window using the session-establishment-hold-time, but repeated flaps cause MAC synchronization to churn and the MC-LAG can toggle between active/standby roles. Best practice is to run ICCP over a dedicated inter-chassis link (ICL) or a routed link with redundancy, and to raise session-establishment-hold-time so transient failures do not tear down the session.

Failure Scenario 3: One Control Plane Fails

When one node's control plane crashes but the data plane keeps forwarding, liveness detection expires (no keepalives are processed) and the surviving node declares the peer dead. The surviving node takes over as the active MC-LAG node, but if the failed node still forwards traffic with its own LACP system ID, the downstream bundle flaps until the failed node fully reboots. The init-delay-time parameter helps here:

set interfaces ae0 aggregated-ether-options mc-ae init-delay-time 120

This delays LACP on the recovering node so the surviving node keeps the shared system ID long enough for the customer LAG to stay stable.

MC-LAG Configuration Reference (EX/QFX)

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 chassis-id 0
set interfaces ae0 aggregated-ether-options mc-ae mode active
set interfaces ae0 aggregated-ether-options mc-ae status-control active
set interfaces ae0 aggregated-ether-options mc-ae init-delay-time 120

Both peers must share the same mc-ae-id; chassis-id must differ (0 on one, 1 on the other). status-control active means the node actively participates in role election.

Troubleshooting Checklist

1. Check show iccp session first - if the session is down, fix ICCP before touching LACP.
2. Verify both peers have identical mc-ae-id and lacp settings.
3. Confirm the shared LACP system ID appears on both peers (show lacp interfaces).
4. If flapping persists, look at show log messages | match iccp for session establishment errors.

For more MC-LAG background see our guide to Juniper MC-LAG best practices and the general Juniper Ethernet interface troubleshooting checklist.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/multichassis/topics/topic-map/mc-lag.html