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. It also collects the ICCP liveness parameters in one reference table and provides two complete deployment configuration examples you can adapt directly.

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. Because the shared identity is a control-plane artifact, it is only as stable as the control-plane channel carrying it — which is why every ICCP failure mode turns into an LACP problem within seconds.

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 minimum-interval 2000
set protocols iccp peer 10.0.0.2 liveness-detection multiplier 3

liveness-detection minimum-interval sets how often keepalives are sent (2000 ms in this example) and multiplier sets how many missed keepalives trigger a session failure (3). The effective detection time is interval × multiplier, so here the peer is declared dead after about 6 seconds. Note the difference between the two timers that people most often confuse: session-establishment-hold-time protects the session from tearing down while it is being established or after a transient reset, while liveness-detection controls how fast an established session is declared dead. Raising the hold time does not slow down failure detection, and lowering the liveness interval does not speed up session establishment.

ICCP Liveness Parameters Reference

• protocols iccp local-ip-addr — source address for the ICCP TCP session. Use a loopback or IRB address that survives link failures, not a physical interface address.
• protocols iccp peer <ip> — the peer address. The session is a single TCP connection per peer pair.
• session-establishment-hold-time — seconds the session is kept from failing during establishment or after a reset. Typical values are in the 240–360 second range on production EX/QFX deployments.
• liveness-detection minimum-interval — keepalive interval in milliseconds. On ICCP over IRB, Juniper recommends 8000 ms or higher so GRES is not mistaken for a failure.
• liveness-detection multiplier — number of consecutive missed keepalives before the peer is declared down. Three is the common starting point.
• liveness-detection backup-liveness-detection — enables the out-of-band heartbeat over the management network used when ICCP TCP is down.
• mc-ae init-delay-time — delays LACP on a recovering node so the surviving node keeps the shared system ID long enough for the customer LAG to stay stable.
• mc-ae-id — the MC-LAG identifier. Must be identical on both peers.
• chassis-id — must differ (0 on one peer, 1 on the other).
• status-control — active means the node participates in MC-LAG role election; standby is for designs where one side is deliberately passive.

These parameters interact more than they look. A 2-second liveness interval with a multiplier of 3 gives 6-second failure detection, but on a shared management network with jitter that is optimistic; a 200 ms interval is fast enough to declare failure during a normal control-plane hiccup. The practical approach is to size the timer to the platform's reboot and switchover behavior first, then to the detection target. For a wider design discussion, see Juniper MC-LAG design: ICCP liveness, ICL and hold timers.

Deployment Example 1: ICCP over a Dedicated ICL

The most common data-center design carries ICCP over a dedicated inter-chassis link aggregated across multiple line cards. Peer A here is 10.0.0.1 and peer B is 10.0.0.2; the ICL is ae99 and the customer-facing bundle is ae0.

set interfaces ae99 aggregated-ether-options lacp active
set interfaces ae99 aggregated-ether-options lacp periodic fast
set interfaces ae99 unit 0 family inet address 10.0.0.1/30

set protocols iccp local-ip-addr 10.0.0.1
set protocols iccp peer 10.0.0.2 session-establishment-hold-time 360
set protocols iccp peer 10.0.0.2 liveness-detection minimum-interval 2000
set protocols iccp peer 10.0.0.2 liveness-detection multiplier 3

On the peer, mirror the configuration with the address roles reversed. The ICL must be aggregated and its member links must be spread across FPCs; a single-link ICL turns one fiber fault into an MC-LAG split.

Deployment Example 2: ICCP over IRB with Backup Liveness

When ICCP is carried in-band over an IRB — for example when the two peers are in different racks and no dedicated ICL exists — the design must add the backup liveness channel, because the ICCP path now shares fate with the data path.

set interfaces irb unit 100 family inet address 10.10.10.1/24
set protocols iccp local-ip-addr 10.10.10.1
set protocols iccp peer 10.10.10.2 session-establishment-hold-time 360
set protocols iccp peer 10.10.10.2 liveness-detection backup-liveness-detection
set protocols iccp peer 10.10.10.2 liveness-detection minimum-interval 8000
set protocols iccp peer 10.10.10.2 liveness-detection multiplier 3

Two things are deliberate here. The interval is 8000 ms, not 2000 ms, because sub-8-second ICCP liveness intervals can break GRES on IRB-based ICCP. And the backup liveness channel means that if the IRB path itself fails, the peers still know whether the remote chassis is alive — which is the difference between a clean single-node takeover and a split-brain that keeps the shared system ID alive on both sides. The configuration pattern and failure consequences are covered in more detail in Junos MC-LAG split-brain: backup liveness detection configuration.

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. If the system IDs on the two peers still match but the bundle is flapping, look for a physical or LACP-rate issue instead, and work through the Juniper Ethernet interface troubleshooting checklist before changing any MC-LAG parameter.

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. Watch for the second-order effect too: each flap re-triggers MAC and ARP resynchronization, and a churning table looks like a MAC flapping problem to anything downstream.

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. Size it against the platform's realistic control-plane recovery time — the goal is that LACP on the recovering node comes up only after ICCP has re-established and the peers agree on the shared system ID again.

Failure Scenario 4: A Peer Reboots and Rejoins

A clean reboot is the case where good timers pay off. The rebooting node stops sending LACPDUs; the surviving node detects the peer down through liveness detection, and depending on the backup liveness result either keeps the shared system ID (peer confirmed dead) or reverts to its default. When the rebooted node comes back, ICCP re-establishes, the shared system ID is re-advertised, and the downstream bundle re-forms. The failure mode to avoid is the half-recovered state: node back up, ICCP not yet established, LACP already running on the customer bundle. That is exactly what init-delay-time and a conservative session-establishment-hold-time exist to prevent.

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.
5. Confirm the ICL is aggregated across multiple FPCs before blaming timers.
6. After any change, re-run the failure test in a maintenance window and confirm the intended failure action fires.

For more MC-LAG background see our guide to Juniper MC-LAG best practices and the scenario-by-scenario discussion in our MC-LAG ICCP failure scenarios article on liveness detection and LACP system ID behavior.

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