Description

When ICCP and ICP-PL are running in separate links, a loop can be created if the multi-chassis-protection statement is misconfigured.

This article explains what should be done to prevent the loop from being created.

 

Symptoms

multi-chassis-protection is used to determine if the MC-LAG peer is up when ICCP goes down. If ICCP goes down, the peer with prefer-status-control-active will remain up, and the peer will change the lacp-system-id to the default to bring the interfaces down. This is to prevent split brain scenarios.

Most customers use a single ae bundle for ICCP and ICL-PL connections. In this scenario, customers configure the bundle as a multi-chassis-protection interface with no issues.

 
+---------------------+                 +-----------------------+
|                     | ae0 ICCP/ICL-PL |                       |
|  MC-LAG-PEER-A      +-----------------+  MC-LAG-PEER-B        |
|                     |                 |                       |
+---------------------+                 +-----------------------+
 

As per recommendation, some customers decide to have ICCP and ICL-PL running in separate links to prevent a single point of failure. The problem here is that when the ICCP interface (in this case ae0) is configured as a multi-chassis-protection interface, a loop is created since the MC-LAG peers will not know that ae1 is part of the MC-LAG and it will act as a regular trunk. 

 
+---------------------+      ae0 ICCP        +-----------------------+
|                     +----------------------+                       |
|  MC-LAG-PEER-A      |                      |  MC-LAG-PEER-B        |
|                     |      ae1 ICL-PL      |                       |
|                     +----------------------+                       |
|                     |                      |                       |
+---------------------+                      +-----------------------+
 

Due to this, during a fault scenario, you will see the MAC addresses learn in the ICL-PL with the flag DL (Dynamically local), when it should be DR (Dynamically remote).

 

Solution

To avoid this problem, configure ICL-PL (ae1) as the multi-chassis-protection interface.

#set multi-chassis multi-chassis-protection <peer-ip-address> interface ae1 

 

Modification History

10/30/2023: Minor edit
4/22/2019: Minor non-technical changes made
9/11/2019: Changed configuration command for ICL-Pl as the multi-chassis-protection interface to set multi-chassis multi-chassis-protection

Related Information