交换机+ac+dhcp

一、为什么核心上的 DHCP 分配 MAC，和 AC 上的 AP MAC 不一样？

• AP 的 CAPWAP 隧道源 MAC（虚拟 MAC）
• 或者 AP 的 BSSID（无线射频 MAC）
• 甚至是 AC 自身或中间设备的 MAC

二、完整解释：AP 的 IP 到底是谁申请的？

1. 瘦 AP 上线的流程

1. AP 上电 → 发送 DHCP 请求（源 MAC 是AP 自身的管理 MAC）
2. 核心交换机 DHCP 服务器给 AP 分配 IP（IP+MAC 绑定的是AP 管理 MAC）
3. AP 拿到 IP 后，和 AC 建立 CAPWAP 隧道（这时候隧道源 MAC 会被封装 / 转换）
4. 之后所有管理流量，都通过 CAPWAP 隧道发送，AC 看到的 MAC 是隧道 MAC，不是原始的管理 MAC

2. 为什么会出现 “MAC 不一致”

三、快速定位：哪个 MAC 才是对的？

1. 先在 AC 上看 AP 的真实 MAC

• AP 的物理 MAC（和设备背面标签一致）
• AP 的管理 IP（核心 DHCP 分配的 IP）

2. 再在核心上查这个 IP 对应的 MAC

• 如果ARP 表里的 MAC 和 AC 上的 AP 物理 MAC 一致：说明 DHCP 分配是对的，只是 AC 管理界面显示的 MAC 是其他字段（比如 BSSID）
• 如果ARP 表里的 MAC 是 AC 或其他设备的 MAC：说明中间有三层转发或隧道封装，MAC 被替换了

四、常见的几种 “假不一致” 情况

1. AC 上显示的是 BSSID，不是 AP 管理 MAC
   • AC 里的 AP 列表，很多时候默认显示的是无线射频的 BSSID，而不是 AP 的管理 MAC
   • 解决：看 display wlan ap verbose 里的 AP MAC Address 字段，那才是管理 MAC
2. DHCP 请求被 AC 或三层设备中继，MAC 被替换
   • 如果 AP 的管理 VLAN 不是直连核心，而是经过 AC 或三层转发，DHCP 报文的源 MAC 会被中间设备替换
   • 解决：把 AP 的管理 VLAN 直接透传到核心，关闭 AC 的 DHCP 中继
3. AP 上线后，核心上的 ARP 表被 CAPWAP 隧道刷新
   • AP 和 AC 建立隧道后，核心上的 ARP 表项可能会被 AC 的 MAC 覆盖
   • 解决：清掉核心的 ARP 表，让 AP 重新触发 ARP 学习

五、解决办法（按优先级）

1. 先确认 AC 上的 AP 管理 MAC 和 IP 对应关系
2. 在核心上用 ARP 命令查 IP 对应的真实 MAC，和 AC 上的对比
3. 关闭 AC 的 DHCP 中继，让 AP 的 DHCP 请求直接发给核心
4. 确保 AP 的管理 VLAN 没有经过三层转发，避免 MAC 被替换