I've observed a weird behavior in a FabricPath topology, running on a mix of N7K's and N55K's. The topology is pretty straightfoward, following the generel best-practice recommendations when implementing a FabricPath network. The network consists of 4 spinenodes (SUP2, M2 and F2E), providing all the Layer3-services, and 4 leafnodes, running pure Layer2.
Following an upgrade on the N7K's from 6.2(2) to 6.2(6), the FabricPath network became highly unstable, resulting on massive packetloss, loss of connectivity to both the FabricPath nodes and various servers connected to the FabricPath network. Before being restored to a stable state, we observed that the L2FM process increased significantly in CPU-usage and the logmsg L2FM-4-L2FM_MAC_MOVE appeared continuously, but each time reporting that the same MAC-address had been re-learned by a new FP-SID. This particular mac belonged to a virtual machine, but at the rate at which the msg were logged, it seemed somewhat impossible that the machine were able to migrate across DC-sites and that theese msg were accurate.
We've subsequently submitted a TAC case, but alongside that, I'd just like to delve into any reasons why the FabricPath topology would re-learn the same MAC again and again across every FP-SID in the topology. So I'm just reaching out to see if anyone has encountered this and if so, what caused this issue. So far, the 6.2(6) is not a suspect, but since we have 200+ of theese particular virtual machines in the network, it seems unlikely that one device could bring the network to a standstill.
This has been documented as a cisco bug now. It's crucial to carefully consider the right code for your environment (probably a version of 7). Good luck!
CSCue14426 : High CPU on L2FM and MAC Move Logs
Symptom: Nexus 7000 runs high CPU on L2FM (the process manages MAC address in Nexus 7000). If 'logging level l2fm 5' is configured, the following message will be logged: %L2FM-4-L2FM_MAC_MOVE: Mac in vlan has moved from to
Conditions: The trigger of the problem is that a physical member of a port channel goes from individual mode to bundled mode. It requires "no lacp suspend individual" configured. This causes a hardware mis-configured on the switch.
Workaround: shut and no shut the related physical port of the port channel
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...