AP 批量掉线？别查 AP 了！罪魁祸首是 AC 转发
一、故障核心信息速览
| 项目 | 详情 |
|---|---|
| 故障现象 | 业务高峰期30+台AP频繁离线，uptime显示AP未重启；无线业务卡顿，用户投诉集中；CAPWAP隧道短暂断开，echo-fail计数暴涨 |
| 核心根因 | 全网AP默认启用Tunnel forwarding（隧道转发），所有无线业务流量汇聚AC，导致AC CPU负载峰值达85%-90%、上行口流量接近1.2Gbps（逼近承载上限），CAPWAP心跳响应延迟，AP误判AC离线 |
| 解决方案 | 将所有AP转发模式改为direct-forward（本地转发），AC仅负责管理面，业务流量由AP直接转发至交换网络 |
| 实施效果 | AC CPU降至35%，CAPWAP echo-fail清零，24小时无AP离线记录，用户反馈无线业务恢复顺畅 |
二、标准化排查流程（可复用）
步骤1：故障现象确认与初步判断
- 登录AC执行命令，采集基础数据：
display ap offline-record：统计AP离线数量、时间分布（确认是否集中于业务高峰期）display ap all：核查AP设备本身是否重启（uptime无重置则排除AP硬件/系统问题）
- 链路连通性测试：
- 对AP与AC进行PING测试，确认丢包率（本案例<1%，排除链路故障）
- 初步结论：排除AP硬件、链路问题，聚焦AC侧异常
步骤2：CAPWAP隧道问题定位
- 执行命令查看隧道状态：
display capwap tunnel statistics - 关键判断：若echo-fail（心跳未响应）计数暴涨，且发生时间与业务高峰期、AP离线时间吻合，排除链路丢包后，锁定AC负载问题