AP 显示客户端在线，交换机却查不到它的 MAC？

值班时经常会遇到这种对不上号的情况：控制器里手机显示已关联、认证也成功，网关上能看到它的 IP；登录接入交换机查这个 MAC，却什么也没有。先别重启 AP，也别急着把它当成地址随机化问题。客户端流量从 AP 怎么出去，决定了哪台交换机会学到这个 MAC。

先确认查的是手机当前的地址

手机可能对这个 SSID 使用私有 Wi-Fi 地址。资产标签、蓝牙地址或另一条无线网络里的地址，都不能替代当前关联记录中的地址。先从控制器、AP 客户端列表或手机网络详情里复制当前值，再去交换机查。

查看时也要带上 VLAN 和端口范围。同一个地址可能出现在另一个 VLAN 的历史记录里；交换机表项又会老化，客户端刚上线但还没发普通数据流量时，动态表里暂时没有条目并不奇怪。可以先产生一次访问，再查询：

show mac address-table address aabb.ccdd.eeff

命令格式按设备厂商调整。交换机 MAC 表如何学习和老化，见交换机 MAC 地址表的工作方式。

核心问题：SSID 在哪里桥接

无线网络常见的转发方式大致有两类，具体名称因厂商而异：

AP 本地转发。 客户端数据在 AP 所在位置桥接到有线 VLAN。只要对应 VLAN 到了 AP 交换机端口，并且客户端发出了数据帧，接入交换机通常会从帧的源地址学到客户端 MAC。此时查不到，才值得继续查 AP 上联 VLAN、端口模式、认证后的 VLAN 分配以及交换机 MAC 学习事件。

隧道集中转发。 AP 把客户端数据封装后送到控制器，再由控制器所在位置接入有线网络。AP 上联看到的主要是 AP 与控制器之间的隧道外层流量；客户端原始帧在隧道内。于是 AP 接入交换机上没有客户端 MAC，可能正是设计如此。客户端 MAC 更可能出现在控制器本地转发或解封装之后连接的交换机端口上。

混合部署也很常见：员工 SSID 集中转发，访客或语音 SSID 本地转发。不要凭 SSID 名称推断模式，去看实际策略，以及该客户端所在 AP、控制器和 VLAN 的转发配置。厂商对隧道与桥接模式的解释可以互相印证，例如 Aruba 校园网设计指南讨论了不同 SSID 转发模式下 AP 交换机端口的要求。

顺着数据路径找，不要从一台交换机猜

我会按这条顺序走一遍：

1. 在无线控制器确认客户端当前 MAC、关联 AP、SSID 和业务 VLAN；如果客户端刚漫游，先确认页面里的 AP 信息已经更新。
2. 查这个 SSID 是本地桥接还是隧道转发，并找到数据真正进入有线网络的位置。
3. 本地转发就查 AP 上联交换机端口和目标 VLAN；集中转发就继续查控制器的数据出口、解封装后的 VLAN 和对应交换机端口。
4. 在正确的交换机上查询动态 MAC 表，并核对 VLAN、端口和最近学习时间。

如果你能在 AP 上联抓包，看到连续的 CAPWAP 数据报文，只能说明隧道流量经过这里；它不能证明客户端以太网帧已在 AP 上联解封装。常见的 IPv4 CAPWAP 部署中，数据使用 UDP 5247，控制流量使用 UDP 5246。IPv6 数据通道也可能使用 UDP-Lite，所以抓不到这两个 UDP 端口，不能单独证明没有隧道。可以先用下面的过滤条件确认常见的 UDP 隧道流量：

sudo tcpdump -ni eth0 'udp port 5246 or udp port 5247'

接口名和抓包位置要按现场替换；若隧道启用了加密，抓包可能只能确认外层端点，不能直接读出客户端帧。CAPWAP 的传输端口和 IPv6 数据通道行为见 RFC 5415。无线侧怎么看地址字段，另见Wi-Fi 抓包里的 MAC 地址。

只有当转发模式、VLAN 和交换机端口都确认无误，MAC 仍然没有出现，才继续排查端口安全、MAC 学习限制、环路保护或客户端是否实际发出流量。这样能避免为了一个“查不到”的表项，先把整个 AP 或交换端口折腾一遍。