Mac-flap due to roaming clients on wireless

Question

We are running an Aerohove wireless network (controller-less).. I occasionally get mac-flaps within the VLAN tied to a SSID. I know this is coming from a roaming client.. The problem is that the company I work for has end to end vlans (no money to put L3 devices on access-layer) and I believe that these mac-flaps cause the mac-table to get flushed throughout the L2 domain for that VLAN... which in turn causes more broadcasts and so on.

I know terminating the L2 domain at the access layer would be the best solution, but there is no money on the short term... Any thoughts on how to deal with this issue?

Answer 1

If your APs are just bridging clients from the wireless right onto your wired network, then you're going to see this from time to time. Clients will appear from different ports as they re-associate to other APs/cells in the ESSID.

I'm presuming you're talking about Cisco IOS here, based on the term "MACFLAP", which appears in their log messages when this happens. For example: "%SW_MATM-4-MACFLAP_NOTIF: Host 0011.2233.4455 in vlan 123 is flapping between port Gi1/1 and port Gi1/2"

What this means is that the switch is having to "re-learn" an Ethernet MAC address out of a different port than what is cached in the hardware forwarding table. This takes a little CPU time for each event, and having it happen more than couple times in a row will cause that MACFLAP message to get logged as more and more CPU time is consumed.

However, this should not cause the entire table to be flushed or cleared. Just the entries for the flapping source MAC address should be getting affected.

Now, in your case, if this is an infrequent message and it's just wireless clients moving from place to place, I wouldn't worry about this too much. To prevent this, some centralized wireless client termination would be needed. This way, frames would pop out onto the wired VLAN in a consistent place.

However, if this is happening frequently for many MAC addresses, it could be indicative of a Layer 2 loop which will definitely need some investigation. :p

Answer 2

Flapping events don't require ingress traffic alternating between ports -- a simple change from ingress of a MAC address on port A to port B on a switch quickly enough will cause a flapping event to be logged; for instance, a live migration of a virtual machine from one host to another will often cause a MAC flapping notification.

As the other answers have covered, it's nothing to be worried about whatsoever until the events are much more frequent than what you're seeing. Your concerns about spanning tree re-convergence and flushing of MAC tables are unfounded; it's not a topology change for spanning tree and the table is just getting updated for the MAC address that flapped - other entries on the same switch, same vlan, or same port are unaffected.

Answer 3

Unless you're receiving lots of the macflap notifications, I wouldn't be concerned. It sounds like the roaming client is temporarily communicating with two APs (which are connected to the same switch) as it is being handed off from one to the other. The macflaps are occurring because the switch sees traffic from the same MAC on two interfaces at the same time. I would expect the macflaps to stop as the handoff is complete. The usual concern with macflaps is when they don't stop - the thrashing from constantly updating the MAC table multiple times a second can seriously damage a switch's hardware ($WORK once literally melted a 6500 supervisor card that way).

I don't see why the MAC table would flush through the L2 domain - its context is local to the switch. If you attach one of the APs to a different switch, you should stop seeing the macflap notifications.