The same MAC in different VLANs

[NetworkingGeek1]

Hello community,

Recently I ran into interesting situation in production environment. Core Switch were sending packets with incorrect destination MAC address towards Access switch - it was due to some bug. But my question is not about that bug. The thing is, that destination MAC really belongs to existed host connected to another access switch and it was in another VLAN than host where traffic originally traffic is intended for. So, the first Access Switch knew about this MAC from Core switch, so it was in its MAC address table and it was pointing towards Core Switch itself. So, the situation was like this: Core Switch is sending frames with incorrect MAC destination towards Access Switch, this  Access switch knew about this MAC from Core switch, but it was in another VLAN and it seems that Access switch dropped that frames. But I was expecting that since Access switch knew about that MAC from another VLAN not from the VLAN traffic was destined to, it would just do unknown unicast flooding. But instead it just dropped the traffic as you would expect if it was the same VLAN. As far as I know, switch should not have any issues with the same MAC address being in the different VLAN, because from Switch point of view VLANs are basically separate virtual switches. What is the special about this case? Why switch didn't do unknown unicast flooding?

And also, is there any debug command which I can use to check mac address table or why frames are being dropped?

[Georg Pauwen]

Hello,

are there any log entries indicating duplicate MAC addresses ? That is what you should usually see. Also, it is a bit difficult to follow what you are after. Can you post a diagram showing the expected and the actually happening traffic flow ? In the diagram, also indicate where the 'real' host is located.

[NetworkingGeek1]

Hello @Georg Pauwen  There are no duplicate MAC addresses log and it's ok, because this MAC is different VLAN. I'll make a diagram and post it here.

[MHM Cisco World]

I will clear something here 
in SW L2 domain the ALL mac appear must be for ALL host in Same subnet (VLAN) + the MAC of GW the host use to get out from this subnet. 
Mac address different VLAN from my view is meaning that 
Host have multihome connect to two or Access SW 
each one have it VLAN 
the Core learn the MAC address with specific VLAN and for ward traffic to other Access SW with wong VLAN.

are the host we talk about is VM and you config teaming port ??

[sidshas03]

However, in your situation, it seems that the Access switch did not perform unknown unicast flooding, even though the destination MAC address was not in its MAC address table for the VLAN in question. This could be due to a number of factors, including:

Configuration: It's possible that the switch is configured to drop unknown unicast frames for security reasons, or that the VLAN in question is configured to prevent unknown unicast flooding.

Hardware limitations: Some switches have hardware limitations that prevent them from performing unknown unicast flooding in certain situations. For example, some switches may not be able to handle large amounts of flooded traffic, or may not support flooding between VLANs.

Software bugs: It's also possible that the switch has a software bug that is preventing it from performing unknown unicast flooding correctly.

To debug the issue, you can use the following commands to check the MAC address table and why frames are being dropped:

show mac address-table: This command displays the MAC address table on the switch, including the VLAN and port associated with each MAC address.

show interface [interface]: This command displays information about a specific interface on the switch, including the number of input and output errors and the reason for any drops.

debug [command]: This command enables debugging for a specific command on the switch, allowing you to see detailed information about how the switch is processing frames. However, be careful when using debug commands in a production environment, as they can generate a large amount of output and impact performance.

[NetworkingGeek1]

@sidshas03  Hello. First of all, thank you for your reply and thank you that you understood my question.

I simulated the same situation on another switch, different model and and it also has IOS, instead of IOS-XE which has switch in production and the results were absolutely the same. So, configuration is not an issue here for sure, because I did test with the switch with almost default config. I also don't think that it's hardware limitation, because as I mentioned, I checked it on two different Cisco switches. And the most important, in my test I also checked if unknown unicast flooding generally is working and it's working. Seems that, there is something special for my situation. Maybe it's because traffic for this MAC is coming from the same interface, where this MAC is linked to, but from different VLAN. Please check diagram below:

[NetworkingGeek1]

@Georg Pauwen  Here is the diagram. Core switch by mistake sends packets with dest MAC: AAA to Access Switch-1 over trunk link, it sends it in VLAN 65. Access Switch knows about this MAC from Core Switch, but from VLAN 25. And packets with that dest MAC arrives to the Access Switch-1 and it drops them, but I was expecting this switch to do unknown unicast flooding inside VLAN 65, because this switch knows this MAC from VLAN 25. Maybe it's because this packets are coming from the same interface which has this MAC attached? But still I don't understand this, because they're in different VLANs.

[MHM Cisco World]

only match the native vlan in all three SW and issue will solve

[NetworkingGeek1]

@MHM Cisco World  seems that you're not following   I don't have any issue with native vlan or anything I asked about. I just asked why switch doesn't do unknown unicast flooding.

[MHM Cisco World]

native vlan is miss match, I 90% sure this is case here 
SW2 have same native vlan with Core and SW1 ???

[NetworkingGeek1]

@MHM Cisco World  As I mentioned, there is some known bug and that's why Core switch sends frames with incorrect destination MAC from different VLAN. But this has nothing to do with what I asked, why access switch doesn't do unknown unicast flooding for that MAC if it knows about it only from different VLAN?

[MHM Cisco World]

Client connect to SW2 send G-ARP 
SW2 receive this frame untag so it put it in VLAN assign to port which is VLAN 25 
the SW2-Core is connect to by access vlan 
Core use native vlan 65 but you not assign VLAN for access port connect to SW2 
the Core Assume the packet is from VLAN 65 
then it forward to SW1 
SW1 save the MAC with VLAN 65 

[NetworkingGeek1]

@MHM Cisco World    Even if there is Native VLAN mismatch, why would Core switch send UNICAST traffic to the switch-1, if this MAC is not associated with interface connected to switch-1 ? Again, it has nothing to do with native vlan mismatch. Wrong dest MAC is due to bug in Core switch, I'm asking about access switch, why it behaves like this and discards frames.

[MHM Cisco World]

if you take 5 min.  and check the VLAN 
native vlan in SW1 and Core 
vlan you assign to port interconnect Core-SW1 
vlan you assign to port connect User-SW1 and User-SW2

do this and see if I am right or not. 

[NetworkingGeek1]

@MHM Cisco World  Sorry, but honestly, I don't understand what are you trying to say. I've mentioned many times, my question is not why Core Switch put incorrect destination MAC address from different VLAN. IT'S A KNOWN BUG. And it has nothing to do with Native Vlan mismatch. I have a totally different question.