11-02-2011 10:10 AM - edited 03-07-2019 03:10 AM
Does any one of you ever saw a single MAC address showing up on multiple VLANs?
Here is an example:
USPA833COREA_C2#sh mac address-table address 001a.64c8.b31a
Legend: * - primary entry
age - seconds since last seen
n/a - not available
vlan mac address type learn age ports
------+----------------+--------+-----+----------+--------------------------
Module 1:
* 120 001a.64c8.b31a dynamic Yes 0 Te1/5
* 160 001a.64c8.b31a dynamic Yes 5 Te1/5
USPA833COREA_C2#
This is from one of our 6509.
And this is from the 4948 switch that connects to Ten 1/5:
USPA833ASWAL16P01#sh mac address-table address 001a.64c8.b31a
Unicast Entries
vlan mac address type protocols port
-------+---------------+--------+---------------------+--------------------
120 001a.64c8.b31a dynamic ip GigabitEthernet1/23
USPA833ASWAL16P01#
We have some very wierd issue on the network from time to time and there is not one single log entry about it.
Thanks
11-05-2011 11:56 PM
Hello,
Did you try to SPAN traffic on that port to see what are those packets with this source MAC coming on VLAN 160?
Nik
11-06-2011 03:45 AM
This is what was going on at the same time:
This from one of our 6509s:
MST0 is executing the mstp compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 0, address 001b.0dc5.2000
Configured hello time 2, max age 20, forward delay 15, tranmsit hold-count 6
We are the root of the spanning tree
Topology change flag not set, detected flag not set
Number of topology changes 8898 last change occurred 00:00:10 ago --
from TenGigabitEthernet2/2
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0
This is from one of our 4948s that was connected to Ten2/2:
VLAN0060 is executing the ieee compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 60, address 001b.2a55.1e80
Configured hello time 2, max age 20, forward delay 15
Current root has priority 32768, address 001b.0dc5.2000
Root port is 49 (TenGigabitEthernet1/49), cost of root path is 2
Topology change flag not set, detected flag not set
Number of topology changes 21666 last change occurred 00:01:00 ago
from GigabitEthernet1/13
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300
This is the interface configuration:
interface GigabitEthernet1/13
description USPHL0ESX09 Vmnic2
switchport trunk encapsulation dot1q
switchport trunk native vlan 666
switchport trunk allowed vlan 60,80,90,95,110,115,117,118,120,125,127,128,130
switchport trunk allowed vlan add 160,161,166,169,300,400,401,410,420,421,430
switchport trunk allowed vlan add 431,440,441,460,499-501,510,511,520,521,530
switchport trunk allowed vlan add 531,540,541,550,560,561,570,571,580,581,590
switchport trunk allowed vlan add 591,650,700,750,990-992,995,999
switchport mode trunk
switchport nonegotiate
shutdown
speed 1000
duplex full
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
The interesting part is that the server that plugged into that interface has no OS on it. I would expect some DHCP request coming because of the default server interface settings, but not to make spanning-tree converge. I don't think that server caused the problem, however, when we disabled the interface the problem seemed to stop. But when we enabled the interface again to get some captures from it the problem did not come back.
11-06-2011 03:59 AM
Ok,
SO that server caused a bunch of TCNs which in turn caused STP instablity. One thing - you said server has no OS - why do you have then have trunk to it and allow multiple VLANs there?
I would consider this configuration having switch on the other side - or server emulating switching software or VMware to use those VLANs.
It definitely smth starting to happen on the server side and 4948 was getting TCN BPDUs from it thus re-sending it further f port was not just flapping). Also this command on Gi1/13 - " spanning-tree portfast" - Ithink that should be "spanning-tree portfast trunk" on trunk port. Thats why I guess that did not help to stop TCNs as portfast actually help to avoid those.
Hope this helps,
Nik
11-06-2011 04:32 AM
The server is a standb alone server. We were thinking that it is a VM box, but the server guys said it is not. The server used to be connected to this port was a VM box, that is why it configured as it is. The intersting part is that when we turned the port back to capture the traffic the issue we had did not come back and all I saw in the capture that the server tried to get an IP address from the DHCP server. After the interface was re-enabled the spanning-tree convergence did not happen, that is why I think something else was causing the issue.
11-06-2011 07:10 PM
Right,
Difficult to say now - can only guess and this is not good approach for troubleshooting. On reoccurrence - I would again check the STP TCN to find where those are growing from - and sniff that port before shutting down. Also CPU usage, show log on the switches in path can be helpfull.
Nik
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