MC-LAG ICCP Failure: Liveness and LACP System ID Runbook

This runbook is for engineers who have MC-LAG running and need to decide, in under five minutes, whether a flapping bundle is an ICCP problem, an ICL problem or a plain LACP problem. It uses only read-only commands, and it is organised around the three inputs Juniper documents in the MC-LAG failure matrix: ICCP session state, ICL state and backup liveness.

The Behaviour You Are Trying to Recognise

While ICCP is healthy, both peers advertise the same LACP system ID, so the downstream device builds one aggregator across two chassis. When ICCP goes down, each peer's LACP system ID behaviour depends on what it believes about its partner:

The reason this matters operationally: a system ID change is a deliberate action, not a symptom. It is how the pair removes ambiguity at the server when the two chassis can no longer agree.

Step 1 - Read ICCP Before Anything Else

show iccp
show iccp session
show iccp log | last 40
show bfd session
show log messages | match iccp

If the session is down, stop. Do not touch LACP, aggregate keys or member links until ICCP is being investigated. Record the exact failure time from show iccp log; it is what you will correlate against the server's own LACP logs and against any change ticket.

Step 2 - Compare the LACP System ID on Both Peers

show lacp interfaces ae0
show lacp interfaces ae0 extensive | match "System"
show interfaces ae0 mc-ae
show interfaces ae0 extensive | match "State|ICCP"

Run the same two commands on the peer. Three outcomes:

• Identical configured IDs on both peers, bundle flapping - not an MC-LAG problem. Work through physical/LACP-rate checks first.
• Both peers showing the default ID - ICCP is down and the failure action has fired. This is the split-brain-prevention branch.
• One configured, one default - the transition is in progress, or the two peers have a config mismatch in mc-ae-id or chassis ID that ICCP could never reconcile.

Step 3 - Check the Configuration Consistency ICCP Enforces

ICCP refuses to complete a session while these do not match. Two minutes spent here explains a surprising number of 'flapping' tickets.

• mc-ae-id - identical on both peers (mandatory).
• chassis-id - must differ (0 on one peer, 1 on the other).
• LACP mode and administration key - identical.
• redundancy-group-id-list - identical and present on both sides.
• local-ip-addr - reachable from the peer through an IGP route, not a directly connected physical address.

show configuration protocols iccp | display set
show configuration interfaces ae0 | display set
show route 

Step 4 - Decide Deliberately Between Two Fixes

There are two legitimate postures and they are not interchangeable. Fail closed is the conservative posture: when the peer's state is unknown, stop forwarding toward it.

set interfaces ae0 aggregated-ether-options mc-ae events iccp-peer-down force-icl-down

Fail open with preference keeps the locally configured active member active during an ICCP outage, and is what you want when the ICL is healthy and the control path is the only thing broken.

set interfaces ae2 aggregated-ether-options mc-ae events iccp-peer-down prefer-status-control-active

Step 5 - Timers to Verify While You Are In There

set protocols iccp local-ip-addr 10.0.0.1
set protocols iccp peer 10.0.0.2 session-establishment-hold-time 340
set protocols iccp peer 10.0.0.2 liveness-detection minimum-interval 8000
set protocols iccp peer 10.0.0.2 liveness-detection multiplier 3
set protocols iccp peer 10.0.0.2 backup-liveness-detection backup-peer-ip 172.16.255.201
set interfaces ae0 aggregated-ether-options mc-ae init-delay-time 120

On QFX with ICCP over an IRB, an 8000 ms liveness interval is the documented starting point so that a graceful Routing Engine switchover is not misread as a dead peer. Keep the establishment hold time at least 100 s above init delay. If you need background on how the two timers differ, the ICCP session flap guide covers the interaction.

Step 6 - The Controlled Failure Test

Never validate MC-LAG failure behaviour for the first time during an incident. In a window:

1. Capture show lacp interfaces and show iccp session on both peers.
2. Disable ICCP on one peer (deactivate protocols iccp) - not a cable pull, so the ICL keeps forwarding.
3. Observe whether the system ID reverted and whether the server kept a working bundle.
4. Repeat with the ICL disabled and ICCP up, and confirm only standby links dropped.
5. Reactivate, confirm the shared ID returns, and re-arm monitoring.

Monitoring That Catches This Before Users Do

Poll three independent values and alert on each separately: ICCP session state, MC-AE state per bundle, and LACP system ID per peer. A system ID mismatch between peers is the leading indicator of split-brain, and it is visible long before the servers start reporting duplicate-IP warnings or duplicated frames.

For the wider failure taxonomy, compare this runbook with the ICL versus ICCP failure behaviour comparison, and use the interface troubleshooting checklist whenever the LACP evidence points at the physical layer instead.

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