AP 批量掉线?别查 AP 了!罪魁祸首是 AC 转发
2026/7/7 7:17:29 网站建设 项目流程

一、故障核心信息速览

项目详情
故障现象业务高峰期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:故障现象确认与初步判断

  1. 登录AC执行命令,采集基础数据:
    • display ap offline-record:统计AP离线数量、时间分布(确认是否集中于业务高峰期)
    • display ap all:核查AP设备本身是否重启(uptime无重置则排除AP硬件/系统问题)
  2. 链路连通性测试:
    • 对AP与AC进行PING测试,确认丢包率(本案例<1%,排除链路故障)
  3. 初步结论:排除AP硬件、链路问题,聚焦AC侧异常

步骤2:CAPWAP隧道问题定位

  1. 执行命令查看隧道状态:display capwap tunnel statistics
  2. 关键判断:若echo-fail(心跳未响应)计数暴涨,且发生时间与业务高峰期、AP离线时间吻合,排除链路丢包后,锁定AC负载问题

步骤3:AC负

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询