IOS XR MC-LAG with ICCP: Router-Pair Configuration

MC-LAG on IOS XR is implemented as mLACP with an ICCP control channel between two routers, and the design intent is the same as on any other vendor: make the downstream device believe it is connected to one switch. What differs is the vocabulary and the failure behaviour. IOS XR uses the terms PoA (Point of Attachment, the router pair) and DHD (dual-homed device), each PoA is assigned a node ID, and the system MAC and priority are synchronised over ICCP so both peers look identical to the downstream device. This article walks the configuration and the state checks that matter when a bundle will not come up.

The building blocks

• ICCP — synchronises LACP configuration and operational state between the two PoA routers, and must be reachable over an IP path independent of the bundle under protection.
• mLACP bundle — the multi-chassis bundle that presents an active/standby service to the DHD.
• System MAC and system priority — identical on both PoA routers. Cisco documentation notes these can be configured or automatically synchronised over ICCP.
• Node ID — unique per PoA router, value 0 to 7. The node ID plus 8 forms the most significant nibble of the LACP port number, which is how the DHD keeps the two peers' ports distinct within one bundle.

That last detail explains a whole class of failures: if both routers use the same node ID, the LACP port numbers collide and the downstream device treats two independent links as the same port.

Step 1 — ICCP between the peers

RP/0/RSP0/CPU0:PoA-1# configure
RP/0/RSP0/CPU0:PoA-1(config)# interface Loopback0
RP/0/RSP0/CPU0:PoA-1(config-if)# ipv4 address 10.255.255.1 255.255.255.255
RP/0/RSP0/CPU0:PoA-1(config-if)# exit

RP/0/RSP0/CPU0:PoA-1(config)# lacp system mac 0011.2233.4455
RP/0/RSP0/CPU0:PoA-1(config)# lacp system priority 1

RP/0/RSP0/CPU0:PoA-1(config)# redundancy
RP/0/RSP0/CPU0:PoA-1(config-redundancy)# iccp
RP/0/RSP0/CPU0:PoA-1(config-redundancy-iccp)# local ipv4 address 10.255.255.1
RP/0/RSP0/CPU0:PoA-1(config-redundancy-iccp)# peer ipv4 address 10.255.255.2
RP/0/RSP0/CPU0:PoA-1(config-redundancy-iccp)# commit

Use loopbacks reachable through the routed core, not the links you are protecting. ICCP over the same physical path as the bundle defeats the purpose: when the path fails, control and data go down together with no liveness fallback.

Step 2 — the mLACP bundle

RP/0/RSP0/CPU0:PoA-1(config)# interface Bundle-Ether10
RP/0/RSP0/CPU0:PoA-1(config-if)# description MC-LAG-TO-DHD
RP/0/RSP0/CPU0:PoA-1(config-if)# lacp switchover suppress-flaps 300
RP/0/RSP0/CPU0:PoA-1(config-if)# mlacp iccp-group 1
RP/0/RSP0/CPU0:PoA-1(config-if)# mlacp redundancy-group 1
RP/0/RSP0/CPU0:PoA-1(config-if)# mlacp switchover type revertive
RP/0/RSP0/CPU0:PoA-1(config-if)# mlacp port-priority 100
RP/0/RSP0/CPU0:PoA-1(config-if)# mac-address 0011.2233.4456
RP/0/RSP0/CPU0:PoA-1(config-if)# commit

Configure the same bundle identifier and ICCP group on the peer, with the peer's port priority deciding which side is preferred. Revertive switchover makes recovery deterministic; non-revertive avoids a second traffic shift when the failed member returns, which some designs prefer for large LAGs.

Node ID and redundancy group

RP/0/RSP0/CPU0:PoA-1(config)# redundancy
RP/0/RSP0/CPU0:PoA-1(config-redundancy)# group 1
RP/0/RSP0/CPU0:PoA-1(config-redundancy-group)# mlacp node 0
RP/0/RSP0/CPU0:PoA-1(config-redundancy-group)# mlacp system mac 0011.2233.4455
RP/0/RSP0/CPU0:PoA-1(config-redundancy-group)# mlacp system priority 1
RP/0/RSP0/CPU0:PoA-1(config-redundancy-group)# interface Bundle-Ether10
RP/0/RSP0/CPU0:PoA-1(config-redundancy-group)# commit

Set node 0 on one router and node 1 on the peer. Verify both routers report the same system MAC afterwards — if they do not, ICCP has not synchronised and the DHD will see two different LACP partners.

Verification

RP/0/RSP0/CPU0:PoA-1# show redundancy iccp status
RP/0/RSP0/CPU0:PoA-1# show lacp system-id
RP/0/RSP0/CPU0:PoA-1# show bundle Bundle-Ether10
RP/0/RSP0/CPU0:PoA-1# show bundle Bundle-Ether10 mlacp
RP/0/RSP0/CPU0:PoA-1# show interfaces Bundle-Ether10
RP/0/RSP0/CPU0:PoA-1# show mlacp bundle-information
RP/0/RSP0/CPU0:PoA-1# show mlacp interface Bundle-Ether10

Check four things: ICCP session up in both directions, identical LACP system IDs, one router reporting the bundle at active/standby state, and matching member port states on both sides after a forced failover.

Failure behaviours to expect

Operational notes

• Keep ICCP traffic on a routed path with a BFD or routing-level liveness check so peer death is detected in under a second.
• Log and alert on show redundancy iccp status rather than on the bundle state alone; the bundle stays up during an ICCP outage, so bundle-only monitoring is blind to it.
• Document node IDs in the design; the same node ID on a rebuilt router is a common post-maintenance incident.
• After any MC-LAG change, test with a real failover during a maintenance window rather than trusting the configuration.

MC-LAG troubleshooting decision table

When an mLACP bundle will not come up, the fault is almost always in one of five places. Work down the table rather than changing configuration at random.

Suppression timers deserve a note. A lacp switchover suppress-flaps value of a few hundred seconds prevents a marginal member from causing repeated switchovers, and a revertive switchover model returns traffic to the preferred member when it recovers. Non-revertive models avoid a second traffic shift but leave capacity unbalanced after recovery. Decide which behaviour your service expects before you need to debug it under pressure.

Scale and design considerations

• ICCP path independence — the ICCP path must not transit either router's own protected links. If a single fibre cut can break both ICCP and the bundle, the MC-LAG provides no protection at all.
• Port priority planning — all links in one bundle on the same PoA should share the same port priority; mixing them produces unpredictable active/standby selection.
• Maximum active links — if the downstream device has a limit on active member links, the PoA selection must respect it, otherwise links flap between active and standby.
• Coupled versus decoupled service — decide whether the Layer 3 interface or pseudowire follows the bundle state. Coupled designs simplify failover reasoning; decoupled designs keep routing up when the bundle is in standby, which suits some service topologies.
• Node IDs are durable state — record node ID per chassis in the design document. A replacement router installed with the wrong node ID produces LACP port number collisions that look like a downstream bug.

Verification before handing over to operations

RP/0/RSP0/CPU0:PoA-1# show redundancy iccp status
RP/0/RSP0/CPU0:PoA-1# show lacp system-id
RP/0/RSP0/CPU0:PoA-1# show bundle Bundle-Ether10 mlacp detail
RP/0/RSP0/CPU0:PoA-1# show mlacp bundle-information
RP/0/RSP0/CPU0:PoA-1# show interfaces Bundle-Ether10 accounting

Run a documented failover test before handover: shut one PoA's member links, confirm the downstream device keeps forwarding, confirm the surviving router carries the load, then restore and confirm the intended member becomes active again. A design that has never been failed over is an assumption, not a redundancy plan.

Related material

For platform-level troubleshooting of IOS XR hardware and fabric issues see ASR 9000 IOS XR fabric troubleshooting and the ASR 9000 troubleshooting commands guide. The equivalent behaviour on Junos, including the LACP system ID change matrix, is documented in Juniper MC-LAG ICCP failure scenarios.

原文链接：https://community.cisco.com/t5/service-providers-documents/asr9000-xr-multichassis-lag-or-mc-lag-mclag-guide/tac-p/3133916