UCS powertools

[goapps.us]

Hello Community 

We are fighting an issue and I'm hoping that the powershell cmdlets can help me track it down. 

In brief, we have MAC addresses that are moving from one FI to the other and this is causing unnecessary L2 convergence. When a VM has issues, I can track down it's MAC and then run the following command on each FI to see the MAC learning history "show platform fwm info mac 0051.5600.0309 252". 

Is there a way to leverage the poweshell tools to connect to nxos and compare the FWM info and identify VM's with issues? 

Thanks 

[Kirk J · Accepted solution]

Greetings.

I took a peak at the powertool guide at http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/sw/msft_tools/powertools/ucs_powertool_book/ucs_pwrtool_bkl1.pdf 

While I don't claim to be an expert in programming, I don't think there are objects and classes published for that API that dig down into that level.  If  there is an XML object for it you can usually access it.  Since the VMware MACs are going to be dynamically learned from a VMware guest, there is nothing defined in the UCSM config to reference for that.

What code level is your UCSM at?  There are a couple of bugs including a teaming bug that can cause the appearance of flapping macs (CSCuv00089), and some earlier bugs in 2.21 level that impacted mac learning.

Assuming you don't actually have a couple of VMs battling over the same MAC, are you seeing any of the guestVM macs being dynamically learned on any of the veths that map to a VNIC, and specific hosts/blades?

What is above your FI's?  I recently ran into a case that had N9K's with arp suppression turned on, that had a bug that also caused the appearance of mac flapping (N9Ks were 'reflecting' arp requests, causing it to appear that frames from guestVM were coming from Northbound direction.

Thanks,

Kirk..

[goapps.us]

Hello Kirk 

Thank you very much for your reply. To answer your questions, we are on code 2.2(5b). The interesting thing is that the bud report does not specify if I'm affected! Blades are 200M4 and our FI's are 6248. The northbound switch is a stack of Dell 8024f switches. I hope to change these this summer. 

As far as programming.... I'm no expert either! Based on some reading, what I'm attempting to accomplish is probably not possible with my skills. I would settle for a text output that I can parse for any patterns. 

Finally, the details in the bug report are interesting. I was on 2.2(4b) this past summer as I was setting up this environment. I was also affected by CSCuv04436! Since we have upgraded to 2.2(5b) but we were still facing some odd performance issues. After opening another case, we were able to identify that the vSwitch LB algorithm was set to Dynamic VS Hyper-V port. After our vSwitch, our L2 fabric is much more stable. 

Thanks 

[Kirk J]

Greetings.

For the teaming bug, you are potentially impacted at 2.2(5b).  2.2(5c) is where the fix is introduced.

For the blades/hosts that own the guestVM with the mac in question, you might want to test the bug workaround to see if it stops the mac flapping.  I would just disable one of the uplinks in a team at the hypervisor OS level, to test.

Thanks,

Kirk...