交换机提示 MAC 地址漂移，先别急着认定是环路

日志里出现 MACFLAP、MAC move 或“同一 MAC 在两个端口之间移动”，值班的人很容易直接想到二层环路。这个方向没错，但不够用。交换机看到的是一个现象：它刚从端口 A 学到某个源 MAC，紧接着又从端口 B 收到同一源 MAC 的帧，于是把转发表项改到 B。至于帧为什么会从两边来，得先看移动的节奏和两端口通向哪里。

把告警原文完整记下来，至少保留 MAC、VLAN、两个端口和时间。Cisco 的示例会把这些信息写在同一条日志里；它列出的常见原因除了二层环路，还有无线客户端漫游、冗余设备的虚拟 MAC，以及 EtherChannel 配置不一致。这份排障说明很值得作为判断清单，而不是把每一条告警都当成同一种事故。

先看移动得有多快

同一个手机在两个 AP 之间漫游，可能让上游交换网络在几十秒甚至几分钟内看到 MAC 换了接入位置。若业务正常、移动只发生一两次，而且两个端口确实通向相邻 AP，这更像是正常现象。无线采用本地转发时尤其常见；集中转发的 SSID 则未必会在 AP 接入口看到客户端 MAC，具体差别见AP 显示客户端在线，交换机却查不到它的 MAC？。

另一个极端是同一地址每秒在两个端口间来回跳，伴随广播暴涨、延迟变大或整段网络间歇断流。这时要把二层环路和聚合链路问题放到最前面，处理速度也该更快。

中间还有一类不那么显眼的情况：移动只在主备切换、网关故障转移或虚拟机迁移时发生一次。两台设备合法共享一个虚拟 MAC 时，活动角色切换后表项换端口是预期动作；如果两边同时转发，才会变成异常。不要为了消掉一条告警，把正常的冗余机制先拆掉。

用这条路径把“漂移”变成可验证的线索

下面的命令以 Cisco IOS 风格举例，其他厂商名称不同，思路相同：

show logging | include MACFLAP
show mac address-table address aaaa.bbbb.cccc vlan 20
show interfaces status
show cdp neighbors detail
show lldp neighbors detail
show spanning-tree vlan 20
show etherchannel summary

我会按这个顺序走：

1. 固定现场。 从日志抄下 VLAN 和两个端口，别只复制 MAC。MAC 地址在不同 VLAN 中可以分别学习，漏掉 VLAN 很容易查到一条无关记录。
2. 给两个端口贴上“它通向哪里”。 查接口描述、CDP/LLDP 邻居和布线记录。两个端口若都在同一台下级小交换机后面，问题范围一下就小了；若一个是 Port-channel、一个是成员口，优先怀疑聚合状态。
3. 沿两个方向继续追表项。 在相邻交换机上带着同一 MAC 和 VLAN 查询，记录它最后稳定出现的位置。不要从核心随便挑一个端口一路断开；先找到两条路径真正汇合的地方。
4. 同时看 STP 与接口状态。 确认该 VLAN 的根桥、端口角色、阻塞状态和最近拓扑变化。接口频繁 up/down 也会让 MAC 表看起来不停变化，光看 MAC 告警容易把物理层问题漏掉。

这个过程的目的不是马上找到“坏端口”，而是把两个抽象端口还原成一段实际路径。路径一旦画清楚，下一步才有依据。

几种常见现场，各自先查什么

两个普通接入口之间高速来回跳。 先确认有没有小交换机、临时网线、双网口设备或桌面 AP 把两个墙口接在一起。不要假设每个接入口后面只有一台电脑。若影响正在扩大，按变更流程隔离可疑支路，同时保留日志和接口计数；贸然关掉核心上联，往往会把排障窗口变成全网中断。

两个本应聚合的物理口之间跳。 两端都核对聚合模式、成员口、trunk/access 状态、允许 VLAN、native VLAN 和速率协商。常见的坑是一端已经把两根线当作一个 LACP Port-channel，另一端却把它们当两条独立转发链路。交换机不是“没识别出两根线是一组”，而是在各自正确执行本端配置，于是同一帧走出了两个入口。

接入口与无线 AP 口之间偶发跳。 看 MAC 是否属于刚漫游的终端，而不是先改 STP。对照控制器的关联时间、AP 名称和 SSID 转发方式；如果终端离线后又在线，短时间内的位置变化也可能是重新接入。需要确认无线帧里各个地址字段时，可看Wi-Fi 抓包里这几个 MAC 地址分别是谁。

两台网关、负载均衡器或防火墙接口之间跳。 查 HA 状态和最近的切换事件。虚拟 IP/虚拟 MAC 的设计本来就要求活动节点接管流量；真正要查的是是否发生了双活、心跳异常，或者有一台旧设备仍连在业务 VLAN 里。

MAC 厂商看起来不像现场设备。 厂商前缀只能帮助缩小范围，不能证明设备身份。虚拟网卡、USB 扩展坞和本地管理地址都会让前缀失去直觉上的意义。可以先在MAC 厂商查询页查一下，再回到接口、邻居与资产记录做确认。

什么时候该立即升级处理

出现下面任一组合时，不要把它留成一条“稍后再看”的普通日志：同一 MAC 高速反复漂移；多个不相关 MAC 在同一对端口之间跳；CPU、广播/未知单播或丢包同时上升；STP 频繁拓扑变化；用户已经报出大面积卡顿。它们不单独证明环路，但足够说明转发面正在不稳定。

相反，孤立的一次移动也不应被掩盖。把它和 AP 漫游、链路变更、主备切换的时间线对照后再关闭告警，下一次真的出问题时才有可比较的基线。

MAC 地址漂移的关键不是“表项变了”，而是变动有没有符合网络设计。先确认 VLAN、端口和频率，再沿路径验证，既不会放过环路，也不会把一次正常漫游误操作成事故。

参考资料

• Cisco《Troubleshoot MAC Address Flap Notification Error》：MAC 漂移定义、无线漫游、冗余 MAC 与 EtherChannel 场景：https://www.cisco.com/c/en/us/support/docs/ip/syslog/221140-troubleshoot-mac-address-flap-notificati.html
• Cisco《Troubleshoot MAC Flaps/Loop on Cisco Catalyst Switches》：MAC 漂移与 STP、物理回路的排查路径：https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol-stp-8021d/221722-troubleshoot-mac-flaps-loop-on-cisco-cat.html