Juniper ICCP Backup Liveness: Prevent MC-LAG Split-Brain - 夜莺博客

Juniper ICCP Backup Liveness: Prevent MC-LAG Split-Brain

When the ICCP session between MC-LAG peers fails, both switches can end up active at the same time - a split-brain state where the server receives duplicate traffic. Juniper's answer is backup liveness detection: an out-of-band keepalive channel over the management network that lets each peer determine whether the other is still alive, and drive the LACP system ID change that forces the server to pick one side. This article explains how the feature works and how to configure it.

How Backup Liveness Detection Works

Backup liveness detection determines whether a peer is up or down by exchanging keepalive messages over the management link between the two ICCP peers. When an ICCP connection is operationally down, each peer sends liveness detection requests; if responses are not received within the specified time for a given number of consecutive attempts, the liveness check fails and the configured failure action is implemented. It must be configured on both peers.

Important detail: when backup liveness detection is configured, the peer status is always up if either the ICCP TCP connection is established or BFD is configured and up - the backup liveness check only runs while ICCP is down.

Configuration

! QFX1
user@switch# set protocols iccp peer 10.50.1.2 backup-liveness-detection backup-peer-ip 10.1.1.2

! QFX2
user@switch# set protocols iccp peer 10.50.1.1 backup-liveness-detection backup-peer-ip 10.1.1.1

backup-peer-ip is the management (out-of-band) IP address of the remote peer. Configure BFD for faster ICCP failure detection:

user@switch# set protocols iccp peer 10.50.1.1 liveness-detection minimum-receive-interval 1000
user@switch# set protocols iccp peer 10.50.1.1 liveness-detection minimum-transmit-interval 1000

Split-Brain Prevention and LACP System ID Behavior

During a split-brain, both active and standby peers change their LACP system IDs. The connected server accepts the LACP system ID of the first link that comes up and brings down the other links carrying a different system ID - so only one MC-LAG peer forwards traffic. When the ICCP connection is active again, both peers return to the configured LACP system ID.

Juniper documents the failure matrix: with ICCP down and ICL down or up, an active backup liveness detection changes the LACP system ID to the default value for both active and standby multichassis aggregated Ethernet interfaces; an inactive one leaves the system ID unchanged.

Timer and Topology Recommendations

  • Keep the ICCP liveness-detection interval at 8 seconds or more when ICCP runs over an IRB interface, so GRES works seamlessly; single-hop BFD is fine over a dedicated physical link.
  • Use the peer loopback address for ICCP peering so a direct link failure does not reset the session.
  • Configure the master-only statement on the management interface IP so the connection is not reset during GRES.
  • Use different interfaces and different FPCs for the ICL and ICCP paths.

Related articles: MC-LAG ICCP failure liveness and LACP system ID, ICCP, BFD and LACP system ID deep dive, and MC-LAG ICCP failure packet loop troubleshooting.

原文链接:https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/backup-liveness-detection-edit-protocols-iccp-peer-qfx-series.html