13

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?

  • What kind of problems are you seeing from this, aside from the flapping warning in the log? – Shane Madden May 8 '13 at 6:23
  • 1
    You could look at tunnelling if it's actually causing you issues. Although Aerohive don't have a controller I think they support GRE tunnelling back to a specified AP which then can drop the traffic on to the local switching. Is it causing an operational issue? – Jody Botham May 8 '13 at 7:10
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 9 '17 at 15:36
16

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

| improve this answer | |
  • 1
    I am under the impression that is not a normal re-learning thing. If i plug my workstation from one to an other ehternet port i wouldnt get a macflap. I believe it happens when it changes a couple of times back and forth between ports... – user209 May 8 '13 at 10:47
9

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.

| improve this answer | |
  • I agree. Occasional macflaps are no worry. Totally different than an STP topology change. – Dennis Olvany May 9 '13 at 1:33
5

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.

| improve this answer | |
  • Its not happening very often... But my thought about the flushing of mac tables: mac table can be flushed by spanning tree because it might interp the macflap as a topology change. The macflap occures on trunk links cause the ap's are connected on trunk ports... If thats the case the mac table gets flushed troughout the l2 domain for that vlan... – user209 May 8 '13 at 20:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.