Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

FabricPath: L2FM-4-L2FM_MAC_MOVE

Hi all,

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.

Thanks

/Ulrich

2 REPLIES
New Member

I am experiencing the same

I am experiencing the same issue, have you found the solution?

This has been documented as a

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
Description
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
1193
Views
0
Helpful
2
Replies
CreatePlease to create content