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
