MAC Address Table Update Packet for Switches from Standalone APs

[justsalvino]

We are supporting a client that have a standalone 3rd party APs connected to Cisco access switches.

Our issue is that some of the roaming devices are producing MAC flapping logs in the Cisco Switches.

The client is using Layer 2 roaming for its access points.

We tried to replicate the scenario in a lab with the following topology: 

AP1---[VLAN 10]---Switch1---[TRUNK]---Switch2---[VLAN 10]---AP2

We weren't able to simulate the MAC address flapping using cellphones and tablet as clients.

The clients can roam seamlessly, the MAC address of the clients in the MAC address table are flushed successfully and no MAC flap logs are seen in the switches.

My questions are:

1. Isn't it that the default behavior of switches is to issue a MAC flap logs when an existing entry in the MAC address table is seen from another interface?
2. Is there a protocol that can be used (by APs) to update the MAC address table on the switches without causing MAC flap logs?

Thanks and Regards,

Justin

[Mark Malone]

Hey

Yes when you have wireless devices moving around your going to see mac flaps its the switches notification just saying that's it sees mac being learnt in another interface , its not an issue unless your not using wireless then it could be some concern as you may have a loop but with wireless the devices roam between aps so the switch will see the same source mac coming from different ints 

You can turn off the notification , have not heard personally of any specific protocol on an ap that prevents this as really its the switch that sees it as an issue an is just making you aware that it happened , expected behaviour  

[justsalvino]

Hi Mark,

Thanks for the response. That's what we also thought but when we simulated the scenario we weren't able to simulate the MAC flapping log.

What puzzled me is that the client's entry in the MAC address table was flushed successfully in the MAC address table of the switches which should trigger a "MAC address flap" log.

I've tested if the switches we used can detect a MAC flap (by configuring a duplicate MAC address in my laptop) and it did but it did not when we simulated clients roaming from the APs.

Regards,

Justin

[Mark Malone]

strange the test didn't work but if you think about it logically you can see why there generated , macs broadcast ap picks it up learns it and passes to direct switch , user then gets up and moves to another room connects to different ap connected to different switch and repeats the steps again but this time mac is still in the table and switch sees it as already being learnt from another interface so flushes the table

We had this issue in a very large network before and it wasn't the mac flap causing the issue it was when the table was flushed each time more broadcasts/cpu resources etc start which we know can cause network issues and the more wireless users moving the more broadcasts etc generated after every flush  ,I the end we broke the network by segmenting it to layer 3 to prevent the issue but that was an extreme case where there were thousands of wireless users on huge layer 2 network

Ciscos Official Take on it when wireless in use

Q. I see the error message : %C4K_EBM-4-HOSTFLAPPING:Host [mac-addr] in vlan [num] is flapping between port [num] and port [num] connected to the Access Points. How do we resolve this?

A. This error message occurs when switch learns the same MAC address through multiple ports. This can be due to one of these reasons

1. When a client roams from one AP to another AP, the new AP informs the client of the MAC address to the switch. If both the APs are connected to the same switch, the MAC address of the client is associated to both the switch ports connected to the APs. This creates a duplicate entry for the client and generates this error message until the time that the switch synchronizes its CAM table. This error message is quite normal in a wireless environment, but, if too much roaming occurs, this can overload the CPU of the switch. Check the client driver and firmware. In addition, ensure that coverage is good so that the client does not roam often.

2. When there is a loop, the switch can learn the same MAC address through multiple ports connected to other switches. Ensure that the TP is enabled on the switch.

[justsalvino]

We'll suggest that to the client. Actually CPU utilization of the switches are okay but some APs are going intermittent based on SolarWinds, might be APs fault but we need to prove that the issue is not on the Cisco switches.

We'll be running another series of tests and I'll post an update when we are done.

Thanks and Regards,

Justin