Single MAC Address on multiple VLANs

[balla-zoltan]

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

[nkarpysh]

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

[balla-zoltan]

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.

[nkarpysh]

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

[balla-zoltan]

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.

[nkarpysh]

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