backup-liveness-detection
Syntax
backup-liveness-detection {
backup-peer-ip ipv4-address;
}
Description
Determine whether a peer is up or down by exchanging keepalive messages over the management link between the two Inter-Chassis Control Protocol (ICCP) peers.
When an ICCP connection is operationally down, the status of the peers hosting a multichassis link aggregation group (MC-LAG) is detected by sending liveness detection requests to each other. Peers must respond to liveness detection requests within a specified amount of time. If the responses are not received within that time for a given number of consecutive attempts, the liveness detection check fails, and a failure action is implemented. Backup liveness detection must be configured on both peers hosting the MC-LAG.
For more information on the ICCP failure scenarios and handling the failures, refer to ICCP Failure Scenarios for EX9200 Switches.
The remaining statement is explained separately. See CLI Explorer.
If backup liveness detection is configured, the peer status is always up when either the ICCP TCP Connection is established, or Bidirectional Forwarding Protocol (BFD) is configured and the peer is up. The backup liveness check is only performed when the ICCP connection is down.
When an MC-LAG node (n0) is rebooted with ICCP disabled on it, the backup liveness of the other node (n1) remains active even though the remote link goes down. This is because the status of the last action performed on the Backup Liveness process is shown in the CLI, the Backup Liveness process is not active on the other node (n1), and therefore, the node (n1) is unable to read the current status of the first node (n0). However, there is no traffic loss. The Backup Liveness process is not active all the time; it runs only when initiated.
Required Privilege Level
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
Release Information
Statement introduced in Junos OS Release 12.2.