MAC address flapping issue

[You Z]

Hi,

I have a server connected to port 3 of switch 192.168.0.22, but I see its MAC address on port 7. I have to manually bind its MAC to port 3 to make it communicate with the gateway (192.168.0.1). The MAC also flaps on the trunk ports (19,20,21,22,23) of switch 192.168.0.17. When I tracked the MAC down to the next level of switches, say 192.168.0.11, I just saw the MAC was on port 24 of the switch. The MAC always seems on the trunk ports. It could be a loop, but why other servers on switch 192.168.0.22 are all good? If a loop persists, where is the redundant connection? MAC conflict is rare, but could it happen in my network?

Please refer to the attachment for the topology. Any thoughts are appreciated!

[icecream-guy]

MAC address on a trunk ifs fine.

think of broadcast domain and how it works.

client to switchb:  "who has MAC a.a.a.a (gateway)"
switchb to client: "I do not, but I have access to upstream switch on a trunk port, let me go ask there"
switchb to upstream switcha: "who has MAC a.a.a.a (gateway)"
upstream switcha replys "I have it, the IP is 1.1.1.1n its on port xxx" and sends response to switchb
CAM & Arp tables are updated, on trunk port
switchb sends info to client, so client knows how to get to gateway.


over simplified, but the idea is there.

[Dieselboy]

For the mac to be seen on port 7, there must be a way for the packet to be sourced from the server and arrive on port 7 (else there is a duplicate mac).

I've seen mac flaps before in a few scenarios:

- using QinQ tunnelling = the packet is not really tunnelled but instead has a 2nd VLAN ID added after the first VLAN ID. So the packet looks like it's tunnelled in a different VLAN however the source and destination MACs dont change and arent hidden. So the effect can be multiple macs eg HSRP gateway IPs that are actually in different VLANs (eg vlan 10, 20, 30,...) but when tunnelled under a single transit QinQ VLAN then they're now all inside one transit vlan eg 500

- when using Windows server load balancing = I've touched on this once or twice . From memory, I think all of the servers in a pool use the same Layer 2 MAC address for the purpose of forcing traffic towards them via ARP response. Memory is hazy on this for me as I've only touched on it a couple of times but I tried to remember some key takeaways from that time: a) put the pool servers in their own VLAN b) dont use Windows Server load balancing c) use sticky macs towards the servers from the switch ports. I think essentially (someone could correct me here) this is Microsofts hack at making something work how they want while disregarding other areas of the network. It happens.

- when using (misconfigured) port-channel (NIC teaming) between server and network = If the Windows server has more than 1 network connection and is set up for nic teaming then it can try to load balance packets out towards the network via each connection. Usually, both connections will go into the same switch chassis (or virtual chassis) and the traffic will be understood and accepted. However if the network is not prepared for that then it could log mac flaps because it will see the same mac arriving on different areas of the network.

Regarding your other points:
- I have to manually bind its MAC to port 3 to make it communicate with the gateway = perhaps there's no real connection via the other direction, hence why you have to bind the mac to the real/working direction (perhaps misconfigured native vlan ID ? )
- The MAC always seems on the trunk ports. - native vlan ID mismatch?

Regarding native vlan mismatch, maybe you have something like:

   [Switch 1]  native vlan 10)-------------><------------(native vlan 20[ switch 2]

This would put vlan 10 and vlan 20 in the same broadcast domain. You could also get mac flaps this way

[You Z]

Thank you for the APR explanation and good examples, but I'm still confused. My scenario was quite simple. No VLAN was configured, and everything was in VLAN 1. No NIC teaming, no VM, etc. The single physical server was connected to port 3, but I didn't see its MAC on port 3; it's on trunk port 7. It wouldn't have communicated in the network if I didn't manually bind its MAC to port 3.

[Dieselboy]

Thanks for the info.

Then, seems like you have a physical cabling problem. Imagine VLAN 1 like how water flows through pipes. You're saying that, the physical pipe was connected to port 3 but the network saw the incoming flow on port 7.

You can also trace the mac to the port and check the physically connected device to see if the mac relates to the BIA (burned-in address) to see if it's the same or spoofed/changed.