03-31-2016 02:11 PM - edited 03-01-2019 12:40 PM
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
03-31-2016 06:50 PM
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.
04-01-2016 05:04 AM
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...
04-01-2016 08:37 AM
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
04-02-2016 06:55 PM
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...
04-04-2016 08:49 AM
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
05-03-2016 04:19 AM
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
07-01-2016 04:05 AM
Hello Kirk
I'm happy to report that this MS update finally resolved our issue! https://support.microsoft.com/en-us/kb/3137691.
Thanks
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide