Juniper MC-LAG ICCP 故障：Liveness 与 LACP System ID

MC-LAG（Multi-Chassis Link Aggregation）让两台 Juniper 交换机对下游设备表现为一台逻辑设备，而维系这种“一体化”假象的正是 ICCP（Inter-Chassis Control Protocol）。ICCP 一旦中断，最直观的现象几乎总是 LACP System ID 的变化：两台设备不再通告相同的 System ID，下游服务器看到的是一台新设备，链路开始震荡。本文按 Juniper 官方故障处理矩阵，逐条说明 ICCP Down、ICL Down、backup liveness 三种状态下的实际行为，并给出可直接落地的配置与验证命令。

ICCP 与 ICL 各自的职责

• ICCP（控制面）：运行在 TCP/IP 之上，用于在两台 MC-LAG 对等体之间同步控制信息——配置参数、LACP System ID、转发状态。通常锚定在 loopback 地址上，并用 BFD 做快速故障检测。
• ICL（数据面）：两台对等体之间的跨机箱链路，用于转发跨设备的流量。ICL 断开但 ICCP 正常时，控制面仍可协商，数据面需要靠 standby 状态兜底。
• MC-AE：多机箱聚合以太网接口，两台设备上的配置必须一致（相同的 mc-ae-id、相同的 LACP 管理 key），chassis-id 必须不同（一边 0、一边 1）。

官方故障矩阵（关键行为表）

针对 status 设置为 standby 的 MC-AE 接口，行为取决于 ICCP 状态、ICL 状态与 backup liveness 对端状态三者：

• ICCP Down，未配置 backup liveness：LACP System ID 变为默认值（两台都变）。原因很简单——每台设备都无法确认对端是否还活着，只能各自恢复成“独立设备”，让下游只建立一条链路，避免不一致的捆绑。
• ICCP Down，backup liveness 为 Active：active 与 standby 两个 MC-AE 接口的 LACP System ID 都变为默认值。
• ICCP Down，backup liveness 为 Inactive：LACP System ID 保持不变。此时已确认对端真的死亡，存活的设备可以继续使用配置的 System ID，服务器侧链路不会因切换而重新收敛。
• ICCP Up 但 ICL Down：LACP 状态置为 standby，MUX 状态机进入 waiting——避免在跨机箱链路已断的情况下继续转发造成环路。

这套逻辑的核心是区分“ICCP 丢失”与“对端已死”：只有后者才能安全地继续扮演同一台设备。

配置：让行为可预测

set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast
set interfaces ae0 aggregated-ether-options lacp system-id 00:11:22:33:44:55
set interfaces ae0 aggregated-ether-options lacp admin-key 1
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

set protocols iccp local-ip-address 10.255.0.1
set protocols iccp peer 10.255.0.2 session-establishment-hold-time 340
set protocols iccp peer 10.255.0.2 liveness-detection minimum-interval 1000
set protocols iccp peer 10.255.0.2 liveness-detection multiplier 3
set protocols iccp peer 10.255.0.2 liveness-detection backup-liveness-detection
set protocols iccp peer 10.255.0.2 backup-liveness-detection backup-peer-ip 10.255.9.2

配置要点：两台设备必须使用相同的 mc-ae-id 与管理 key；chassis-id 必须不同；status-control active 表示该节点参与主备选举。backup liveness 走管理网，为的是用一条完全独立的通道回答“对端到底还在不在”。

验证命令

show iccp
show iccp peer 10.255.0.2
show lacp interfaces ae0
show interfaces ae0 extensive | match "MC-AE|LACP|Status|Chassis"
show mc-ae status
show configuration protocols iccp

重点看：ICCP 会话是 Up 还是 Down、BFD 是否按时收到心跳、show lacp interfaces 中两端的 System ID 是否一致、MC-AE 是 active 还是 standby。切换前务必确认设备上的 MC-AE 角色与你预期一致。

设计与运维建议

• ICCP 走聚合接口，子链路分布在不同 FPC/线卡上；同时配置 backup liveness 通道，避免单链路或单卡故障造成“静默脑裂”。
• 若 ICCP 通过 IRB 接口承载，liveness-detection interval 至少 8 秒，以便 GRES（平滑路由引擎切换）正常工作。
• ICL 与 ICCP 尽量使用不同端口/不同 FPC，并保证 ICL 容量足以承载单侧整机故障时的全部流量。
• 把对端故障演练写进变更流程：断开 ICCP 链路，观察 System ID 与服务器侧链路状态，再恢复——这类演练在维护窗口内完成，比在故障时第一次见更安全。

相关阅读：Juniper MC-LAG 设计：ICCP Liveness、ICL 与 Hold Timer、MC-LAG ICCP 故障场景与 LACP System ID 行为。

原文链接：https://juniper.net/documentation/us/en/software/junos/mc-lag/topics/concept/best-practices-usage-notes.html