MC-LAG Explained: ICCP, BFD and LACP System ID Deep Dive

MC-LAG (Multi-Chassis Link Aggregation) is the Juniper answer to the single-active-routing-engine problem: instead of one primary RE with all PFEs connected to it, two devices run two active routing engines and present a single LAG to the downstream server. The magic happens in three mechanisms — ICCP for control-plane coordination, BFD for fast failure detection, and a shared LACP system ID so the server sees one logical bundle. This article explains each pillar in depth, based on the Packet-Expert MC-LAG design write-up.

The Problem MC-LAG Solves

High availability features like GRES, NSR and NSB still leave one RE active at a time; when the primary RE fails, all PFEs must reconnect to the backup, causing momentary disruption. MC-LAG offers two active REs in two different chassis, eliminating the switchover disruption entirely.

Pillar 1: ICCP (Inter-Chassis Control Protocol)

ICCP is the TCP-based protocol MC-LAG peers use to exchange control information and coordinate forwarding state. It replicates control traffic and forwarding states across peers and communicates the operational state of MC-LAG members. Key parameters:

• ICCP peer IP — the address used to establish the ICCP session (loopback lo0 recommended).
• session-establishment-hold-time — 50 seconds recommended for faster ICCP establishment.
• redundancy-group-id-list — must be identical on both peers and referenced in the MC-AE configuration.
• liveness-detection minimum-interval / multiplier — BFD timers that detect peer failure; e.g. 60 ms × 3 = 180 ms detection.

Pillar 2: BFD Liveness

Because ICCP rides over TCP, it needs fast failure detection: BFD liveness detection with a 60 ms minimum interval and multiplier 3 gives 180 ms convergence — fast enough to fail over before the server's own LACP timers expire.

Pillar 3: LACP System ID and MC-AE

The Multichassis Aggregated Ethernet interface (MC-AE) takes one interface from each peer and bundles them; the connected device treats them as a normal LAG. The critical requirement is a matching LACP system ID on both peers — unique per MC-AE but identical across the two peers — so the downstream device considers both links members of the same bundle and load-balances across them.

Failure Handling

When ICCP fails, the peers cannot coordinate — see our MC-LAG ICCP failure troubleshooting guide for the packet-loop scenario and fixes. Compare vendor implementations in Arista EOS MLAG and MLNX-OS LAG/LACP configuration.

原文链接：https://packet-expert.org/2016/09/15/multi-chassis-lag/