如果您的 AP 只是将客户端从无线直接桥接到您的有线网络，那么您会不时看到这种情况。当客户端重新关联到 ESSID 中的其他 AP/小区时，它们将从不同的端口出现。

我假设您在这里谈论的是 Cisco IOS，基于术语“MACFLAP”，当发生这种情况时，它会出现在他们的日志消息中。例如：“%SW_MATM-4-MACFLAP_NOTIF：VLAN 123 中的主机 0011.2233.4455 在端口 Gi1/1 和端口 Gi1/2 之间摆动”

这意味着交换机必须从与缓存在硬件转发表中的端口不同的端口“重新学习”以太网 MAC 地址。对于每个事件，这需要一点 CPU 时间，并且连续发生多次会导致 MACFLAP 消息随着越来越多的 CPU 时间被消耗而被记录。

但是，这不应导致整个表被刷新或清除。只有抖动源 MAC 地址的条目会受到影响。

现在，在您的情况下，如果这是一条不常见的消息，并且只是无线客户端从一个地方移动到另一个地方，我不会太担心这一点。为了防止这种情况，需要一些集中的无线客户端终端。这样，帧就会在一致的位置弹出到有线 VLAN。

但是，如果许多 MAC 地址经常发生这种情况，则可能表明存在第 2 层环路，这肯定需要进行一些调查。:p

摆动事件不需要在端口之间交替的入口流量——从端口 A 上的 MAC 地址入口到交换机上的端口 B 的入口变化足够快就会导致摆动事件被记录；例如，将虚拟机从一台主机实时迁移到另一台主机通常会导致 MAC 波动通知。

至于其他的答案已经覆盖，直到事件是没什么可担心的任何多比你看到的更频繁。您对生成树重新收敛和刷新 MAC 表的担忧是没有根据的；这不是生成树的拓扑更改，并且该表只是针对摆动的 MAC 地址进行了更新 - 同一交换机、同一 vlan 或同一端口上的其他条目不受影响。

除非您收到大量 macflap 通知，否则我不会担心。听起来漫游客户端正在与两个 AP（连接到同一交换机）临时通信，因为它正在从一个 AP 切换到另一个 AP。发生 macflaps 是因为交换机同时在两个接口上看到来自同一 MAC 的流量。我希望 macflaps 在切换完成时停止。通常对 macflaps 的担忧是当它们不停止时 - 每秒多次不断更新 MAC 表的颠簸会严重损坏交换机的硬件（$WORK 曾经以这种方式真正融化了 6500 管理卡）。

我不明白为什么 MAC 表会刷新 L2 域 - 它的上下文是交换机本地的。如果您将其中一个 AP 连接到不同的交换机，您应该不会看到 macflap 通知。