ON THIS PAGE
Secondary MC-LAG Peer with Status Control Set to Standby Becomes Inactive
ICCP Connection Might Take Up to 60 Seconds to Become Active
MAC Address Age Learned on a Multichassis Aggregated Ethernet Interface Is Reset to Zero
Snooping Entries Learned on Multichassis Aggregated Ethernet Interfaces Are Not Removed
ICCP Does Not Come Up After You Add or Delete an Authentication Key
Both MC-LAG Peers Use the Default System ID After a Reboot or an ICCP Configuration Change
Multicast Traffic Floods the VLAN When the ICL-PL Interface Goes Down and Up
Layer 3 Traffic Sent to the Standby MC-LAG Peer Is Not Redirected to Active MC-LAG Peer
ARP and MAC Table Entries Become Out of Sync in an MC-LAG Configuration
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:00:5E:00:53:00 Learn(L) 3:55 ae0.0 (MCAE) v10 00:00:5E:00:53:01 Learn(R) 0 xe-0/0/9.0 v20 * Flood - All-members v30 * Flood - All-members v30 00:00:5E:00:53:03 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:00:5E:00:53:04 Learn(R) 0 ae0.0 (MCAE) v10 00:00:5E:00:53:05 Learn 40 xe-0/0/10.0 v20 * Flood - All-members v30 * Flood - All-members v30 00:00:5E:00:53:06 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
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
MAC Address Age Learned on a Multichassis Aggregated Ethernet Interface Is Reset to Zero
Problem
Description
When you activate and then deactivate an interchassis 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
On a QFX3500 switch running Junos OS Release 12.3 or earlier, if a multichassis link aggregation group (MC-LAG) peer learns a MAC address in the default VLAN, 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
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 interchassis 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 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 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 interface. When this happens, the aggregated Ethernet interface goes down.
Solution
Restart Link Aggregation Control Protocol (LACP) on the multichassis link aggregation group (MC-LAG) peer hosting the aggregated Ethernet interface to bring up the aggregated Ethernet interface. Restarting LACP removes the multichassis aggregated Ethernet properties of the aggregated Ethernet 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.
ARP and MAC Table Entries Become Out of Sync in an MC-LAG Configuration
Problem
Description
The ARP and MAC address tables in an MC-LAG configuration normally stay synchronized, but updates might be lost in extreme situations when table updates are happening very frequently, such as when link flapping occurs in an MC-LAG group.
Solution
To avoid ARP and MAC entries becoming out of sync in an MC-LAG configuration, you can configure the arp-l2-validate option on the switch’s IRB interface, as follows:
user@switch> set interfaces irb arp-l2-validate
The arp-l2-validate option is available only on QFX
Series switches and EX4300 switches starting with Junos OS Release
15.1R4, and EX9200 switches starting with Junos OS Release 13.2R4.
This option turns on validation of ARP and MAC table entries, automatically applying updates if they become out of sync. You might want to enable this option as a workaround when the network is experiencing other issues that also cause loss of ARP and MAC synchronization, but disable it during normal operation because this option might impact performance in scale configurations.