Log of MAC address

[goapps.us]

We have been fighting an issues and TAC is recommending to get MS involved. During our troubleshooting, we have used the following command  "show platform fwm info mac 0051.5600.030d 9", as an example. This is great, but you need the MAC address to get a usable output. 

Is there a way to dump the MAC learning history of an FI to a TXT file?  This way we could review the MAC history. 

Thanks 

[kashima yoshihito]

Hi goapps.us.

using macro of teraterm , you can get the results repeatedly.

1st. open the teraterm .

2nd . set the teraterm ( file -> log )

3rd.# connect nxos

4th.# terminal length 0

5th.using macro as follows

(sample.ttl)

while 1
sendln 'show platform fwm info mac xxxx.xxxx.xxxx 1<=a number of vlan'
wait '#'
pause 10
endwhile

you can get the results repeatedly , and you can stop the macro whenever you like while you can see pasue  count of macro  on a display.

[Kirk J]

Greetings.

I think I remember you asking about a powershell option for looking at learned macs.

Are you trying to see if you are getting macs learned on ports that are unexpected?

What is your case/SR #?

Thanks,

Kirk...

[goapps.us]

Hello Kirk 

The SE I'm working with is fairly confident that this issue is caused by Hyper-v. My case is 638250377 and I have opened a case with MS. 

To recap, the issues we were facing is that all VM MAC addresses were moving from FI to FI. This would cause VM lock up, and lost connectivity, especially @ boot. We changed the vSwitch LB method from Dynamic to "Hyper-V Port" and things have greatly improved. 

Now that the LB method is changed, I would expect MAC addresses to change only after a VM reboot or a live migration. But that is not the case. 

MAC learning history would useful to isolate patterns. 

Thanks 

[Kirk J]

Greetings.

Took a quick look at your SR/case.

I think you are running 2.24 or 2.25b on the UCSM.

There is a 'teaming' bug that gets fixed in 2.25c that can trigger similar symptoms (CSCuv00089)

However, it looks like you have a veth that is actually dynamically learning the same mac on two different vlans (appears to becoming from the OS/Hypervisor  if I'm reading that right), so that may just be an issue with the OS that you are currently pursuing.

Looks like you have a join call with MS on Monday, and will be interested to see what the results are.

You may need to do a UCSM span/monitoring session in order to confirm the exact frames that are being send up from the vnics/OS that are hitting the veth.

Hope Monday's call brings you closer to resolution!

Kirk...

[goapps.us]

Hello Kirk 

Thank you so much for your efforts. I really appreciate you looking into this issue. I will keep you informed on our progress. 

As far as the MAC issue, that has been addressed. this was caused by a misconfiguration in UCSM. The assigned SE would have more details on the exact steps taken to address that specific issue. 

Thanks 

[goapps.us]

Hello Kirk, 

I'm sorry to say, updating to 2.26e (eNic 3.4.0.140) has not addressed my issues. I updated my original post. Could I ask you to quickly review? 

Thanks 

[goapps.us]

Hello Kirk 

I'm happy to report that this MS update finally resolved our issue!  https://support.microsoft.com/en-us/kb/3137691. 

Thanks