TechLibrary

Navigation

Supported Platforms

EX4600

Troubleshooting Multichassis Link Aggregation

Use the following information to troubleshoot multichassis link aggregation configuration issues:

MAC Addresses Learned on Multichassis Aggregated Ethernet Interfaces Are Not Removed from the MAC Address Table

Problem

Description: When both of the mulitchassis aggregated Ethernet interfaces on both connected multichassis link aggregation group (MC-LAG) peers are down, the MAC addresses learned on the multichassis aggregated Ethernet interfaces are not removed from the MAC address table.

For example, if you disable the multichassis aggregated Ethernet interface (ae0) on both MC-LAG peers by issuing the set interfaces ae0 disable command and commit the configuration, the MAC table still shows the MAC addresses as being learned on the multichassis aggregated Ethernet interfaces of both MC-LAG peers.

user@switchA> show ethernet-switching table

Ethernet-switching table: 6 entries, 2 learned, 0 persistent entries
  VLAN	            MAC address       Type         Age Interfaces
  v10               *                 Flood          - All-members
  v10               00:10:94:00:00:01 Learn(L)     3:55 ae0.0 (MCAE)
  v10               00:10:94:00:00:02 Learn(R)        0 xe-0/0/9.0
  v20               *                 Flood          - All-members
  v30               *                 Flood          - All-members
  v30               84:18:88:de:b1:2e Static         - Router

user@switchB> show ethernet-switching table

Ethernet-switching table: 6 entries, 2 learned, 0 persistent entries
  VLAN	            MAC address       Type         Age Interfaces
  v10               *                 Flood          - All-members
  v10               00:10:94:00:00:01 Learn(R)        0 ae0.0 (MCAE)
  v10               00:10:94:00:00:02 Learn         40 xe-0/0/10.0
  v20               *                 Flood          - All-members
  v30               *                 Flood          - All-members
  v30               84:18:88:df:83:0a Static         - Router

Solution

This is expected behavior.

MC-LAG Peer Does Not Go into Standby Mode

Problem

Description: A multichassis link aggregation group (MC-LAG) peer does not go into standby mode if the MC-LAG peer IP address specified in the Inter-Chassis Control Protocol (ICCP) configuration and the IP address specified in the multichassis protection configuration are different.

Solution

To prevent failure to enter standby mode, make sure that the peer IP address in the ICCP configurations and the IP address in multichassis protection configurations are the same.

Secondary MC-LAG Peer with Status Control Set to Standby Becomes Inactive

Problem

Description: When the interchassis control link-protection link (ICL-PL) and multichassis aggregated Ethernet interfaces go down on the primary multichassis link aggregation group (MC-LAG) peer, the secondary MC-LAG peer’s multichassis aggregated Ethernet interfaces with status control set to standby become inactive instead of active.

Solution

This is expected behavior.

Redirect Filters Take Priority over User-Defined Filters

Problem

Description: Multichassis link aggregation group (MC-LAG) implicit failover redirection filters take precedence over user-configured explicit filters.

Solution

This is expected behavior.

Operational Command Output Is Wrong

Problem

Description: After you deactivate Inter-Chassis Control Protocol (ICCP), the show iccp operational command output still shows registered client daemons, such as mcsnoopd, lacpd, and eswd.

For example:

user@switch> show iccp

Client Application: MCSNOOPD
  Redundancy Group IDs Joined: None

Client Application: lacpd
  Redundancy Group IDs Joined: 1 

Client Application: eswd
  Redundancy Group IDs Joined: 1

The show iccp command output always shows registered modules regardless of whether or not ICCP peers are configured.

Solution

This is expected behavior.

ICCP Connection Might Take Up to 60 Seconds to Become Active

Problem

Description: When the Inter-Chassis Control Protocol (ICCP) configuration and the routed VLAN interface (RVI) configuration are committed together, the ICCP connection might take up to 60 seconds to become active.

Solution

This is expected behavior.

MAC Address Age Learned on a Multichassis Aggregated Ethernet Interface Is Reset to Zero

Problem

Description: When you activate and then deactivate an interchassis control link-protection link (ICL-PL), the MAC address age learned on the multichassis aggregated Ethernet interface is reset to zero. The next-hop interface changes trigger MAC address updates in the hardware, which then triggers aging updates in the Packet Forwarding Engine. The result is that the MAC address age is updated to zero.

For example, the ICL-PL has been deactivated, and the show ethernet-switching table command output shows that the MAC addresses have an age of 0.

user@switch> show ethernet-switching table

Ethernet-switching table: 3 entries, 2 learned, 0 persistent entries
  VLAN              MAC address       Type         Age Interfaces
  v100              *                 Flood          - All-members
  v100              00:10:00:00:00:01 Learn(L)     0 ae0.0 (MCAE)
  v100              00:10:00:00:00:02 Learn(L)     0 ae0.0 (MCAE)

Solution

This is expected behavior.

MAC Address Is Not Learned Remotely in a Default VLAN

Problem

Description: If a multichassis link aggregation group (MC-LAG) peer learns a MAC address in the default VLAN, the Inter-Chassis Control Protocol (ICCP) does not synchronize the MAC address with the MAC address of the other MC-LAG peer.

Solution

This is expected behavior.

Snooping Entries Learned on Multichassis Aggregated Ethernet Interfaces Are Not Removed

Problem

Description: When multichassis aggregated Ethernet interfaces are configured on a VLAN that is enabled for multicast snooping, the membership entries learned on the multichassis aggregated Ethernet interfaces on the VLAN are not cleared when the multichassis aggregated Ethernet interfaces go down. This is done to speed up convergence time when the interfaces come up, or come up and go down.

Solution

This is expected behavior.

ICCP Does Not Come Up After You Add or Delete an Authentication Key

Problem

Description: The Inter-Chassis Control Protocol (ICCP) connection is not established when you add an authentication key and then delete it only at the global ICCP level. However, authentication works correctly at the ICCP peer level.

Solution

Delete the ICCP configuration, and then add the ICCP configuration.

Local Status Is Standby When It Should Be Active

Problem

Description: If the multichassis aggregated Ethernet interface is down when the state machine is in a synchronized state, the multichassis link aggregation group (MC-LAG) peer local status is standby. If the multichassis aggregated Ethernet interface goes down after the state machine is in an active state, then the local status remains active, and the local state indicates that the interface is down.

Solution

This is expected behavior.

Packets Loop on the Server When ICCP Fails

Problem

Description: When you enable backup liveness detection for a multichassis link aggregation group (MC-LAG), and the backup liveness detection packets are lost because of a temporary failure on the MC-LAG, then both of the peers in the MC-LAG remain active. If this happens, both of the MC-LAG peers send packets to the connected server.

Solution

This is expected behavior.

Both MC-LAG Peers Use the Default System ID After a Reboot or an ICCP Configuration Change

Problem

Description: After a reboot or after a new Inter-Chassis Control Protocol (ICCP) configuration has been committed, and the ICCP connection does not become active, the Link Aggregation Control Protocol (LACP) messages transmitted over the multichassis aggregated Ethernet interfaces use the default system ID. The configured system ID is used instead of the default system ID only after the MC-LAG peers synchronize with each other.

Solution

This is expected behavior.

No Commit Checks Are Done for ICL-PL Interfaces

Problem

Description: There are no commit checks on the interface being configured as an inter-chassis link-protection link (ICL-PL), so you must provide a valid interface name for the ICL-PL.

Solution

This is expected behavior.

Double Failover Scenario

Problem

Description: If the following events happen in this exact order—Inter-Chassis Control Protocol (ICCP) goes down, and the multichassis aggregated Ethernet interface on the multichassis link aggregation group (MC-LAG) peer in active mode goes down—a double failover occurs. In this scenario, the MC-LAG peer in standby mode does not detect what happens on the active MC-LAG peer. The MC-LAG peer in standby mode operates as if the multichassis aggregated Ethernet interface on the MC-LAG in active mode were up and blocks the inter-chassis link-protection link (ICL-PL) traffic. The ICL-PL traffic is not forwarded.

Solution

This is expected behavior.

Multicast Traffic Floods the VLAN When the ICL-PL Interface Goes Down and Up

Problem

Description: When interchassis control link-protection link (ICL-PL) goes down and comes up, multicast traffic is flooded to all of the interfaces in the VLAN. The Packet Forwarding Engine flag Ip4McastFloodMode for the VLAN is changed to MCAST_FLOOD_ALL. This problem only occurs when a multichassis link aggregation group (MC-LAG) is configured for Layer 2.

Solution

This is expected behavior.

Layer 3 Traffic Sent to the Standby MC-LAG Peer Is Not Redirected to Active MC-LAG Peer

Problem

Description: When Inter-chassis Control Protocol (ICCP) is down, the status of a remote MC-LAG peer is unknown. Even if the MC-LAG peer is configured as standby, the traffic is not redirected to this peer because it is assumed that this peer is down.

Solution

This is expected behavior.

Aggregated Ethernet Interfaces Go Down

Problem

Description: When a multichassis aggregated Ethernet interface is converted to an aggregated Ethernet (AE) interface, it retains some multichassis aggregated Ethernet interface properties. For example, the aggregated Ethernet interface might retain the administrative key of the multichassis aggregated Ethernet. When this happens, the aggregated Ethernet interface goes down.

Solution

Restart the Link Aggregation Control Protocol (LACP) on the multichassis link aggregation group (MC-LAG) peer hosting the AE interface to bring up the AE interface. Restarting LACP removes the multichassis aggregated Ethernet properties of the AE interface.

Flooding of Upstream Traffic

Problem

Description: When MAC synchronization is enabled, the multichassis link aggregation group (MC-LAG) peer can resolve Address Resolution Protocol (ARP) entries for the MC-LAG routed VLAN interface (RVI) with either of the MC-LAG peer MAC addresses. If the downstream traffic is sent with one MAC address (MAC1) but the peer has resolved the MAC address with a different MAC address (MAC2), the MAC2 address might not be learned by any of the access layer switches. Flooding of the upstream traffic for the MAC2 address might then occur.

Solution

Make sure that downstream traffic is sent from the MC-LAG peers periodically to prevent the MAC addresses from aging out.

Supported Platforms

EX4600

TechLibrary

Supported Platforms

Related Documentation

Troubleshooting Multichassis Link Aggregation

MAC Addresses Learned on Multichassis Aggregated Ethernet Interfaces Are Not Removed from the MAC Address Table

Problem

Solution

MC-LAG Peer Does Not Go into Standby Mode

Problem

Solution

Secondary MC-LAG Peer with Status Control Set to Standby Becomes Inactive

Problem

Solution

Redirect Filters Take Priority over User-Defined Filters

Problem

Solution

Operational Command Output Is Wrong

Problem

Solution

ICCP Connection Might Take Up to 60 Seconds to Become Active

Problem

Solution

MAC Address Age Learned on a Multichassis Aggregated Ethernet Interface Is Reset to Zero

Problem

Solution

MAC Address Is Not Learned Remotely in a Default VLAN

Problem

Solution

Snooping Entries Learned on Multichassis Aggregated Ethernet Interfaces Are Not Removed

Problem

Solution

ICCP Does Not Come Up After You Add or Delete an Authentication Key

Problem

Solution

Local Status Is Standby When It Should Be Active

Problem

Solution

Packets Loop on the Server When ICCP Fails

Problem

Solution

Both MC-LAG Peers Use the Default System ID After a Reboot or an ICCP Configuration Change

Problem

Solution

No Commit Checks Are Done for ICL-PL Interfaces

Problem

Solution

Double Failover Scenario

Problem

Solution

Multicast Traffic Floods the VLAN When the ICL-PL Interface Goes Down and Up

Problem

Solution

Layer 3 Traffic Sent to the Standby MC-LAG Peer Is Not Redirected to Active MC-LAG Peer

Problem

Solution

Aggregated Ethernet Interfaces Go Down

Problem

Solution

Flooding of Upstream Traffic

Problem

Solution

Related Documentation

Modified: 2015-02-18

Supported Platforms

Related Documentation

Modified: 2015-02-18