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负载问题

步骤3：AC负载与转发模式核查

核查AC资源占用：
display cpu-usage：查看CPU使用率（峰值≥80%需警惕）display ap traffic-rate：查看AC上行口流量（接近或超过1Gbps为高危）
核查AP转发模式：display ap run-info，确认是否为Tunnel forwarding（隧道转发）根因确认：隧道转发导致AC承担过量业务流量，引发CPU、带宽瓶颈，进而导致CAPWAP心跳延迟

步骤4：解决方案实施与验证

单AP测试调整：wlan ap [AP编号] forward-mode direct-forward全量AP迁移：陆续将所有AP转发模式改为本地转发效果验证：
监控AC CPU使用率、上行口流量是否下降至正常范围核查CAPWAP echo-fail计数是否清零持续24小时观察AP离线记录收集用户反馈，确认业务恢复情况

三、核心知识点解析

1. 两种转发模式的核心区别

转发模式	数据流向	优势	劣势	适用场景
隧道转发（Tunnel forwarding）	无线业务流量→AP→AC→交换网络	统一策略管控，配置便捷	占用AC大量资源，易引发瓶颈	需极强业务管控的小规模网络
本地转发（direct-forward）	无线业务流量→AP→交换网络	降低AC负载，提升转发效率	策略需配合交换网络部署	大规模网络、高流量业务场景（默认推荐）

2. AC被压垮的关键原因

隧道转发强制所有无线流量汇聚AC，即使10台AP满载业务，流量都要走ACAC的数据面处理能力远低于专业转发设备（如交换机），即使配备万兆口，内部并发处理能力有限CAPWAP心跳为毫秒级响应，AC高负载时心跳延迟，触发AP误判离线

四、实操补充：关键配置与批量操作

1. 主流品牌AP转发模式配置命令

品牌	查看转发模式命令	配置本地转发命令	备注
华为（Huawei）	`display ap run-info ap-id [AP-ID]`	`wlan ap [AP名称/ID] forward-mode direct-forward`	需先进入WLAN视图：`system-view → wlan`
华三（H3C）	`display wlan ap [AP名称] running-config`	`wlan ap [AP名称] service-template 1 forward-mode local`	华三称“本地转发”为local-forward
Cisco	`show ap config general [AP名称]`	`ap name [AP名称] dot11 {24ghz	5ghz} enterprise-mode local`
锐捷（Ruijie）	`show ap running-config [AP名称]`	`ap-config [AP名称] forward-mode direct`	支持全局或单AP配置

2. AC负载预警阈值配置（以华为为例）

（1）CPU负载预警配置


system-view
snmp-agent trap enable feature-name wlanac trap-name "cpuusagehigh"  # 启用CPU高负载告警
wlan
cpu-usage threshold 70  # 配置预警阈值（建议70%，超阈值触发告警）
cpu-usage trap-interval 5  # 告警间隔5分钟，避免频繁告警

（2）上行口流量预警配置


system-view
interface GigabitEthernet0/0/1  # 进入AC上行口
traffic-limit inbound 1000000 kbps alert 80  # 入方向超800Mbps告警（1Gbps链路）
traffic-limit outbound 1000000 kbps alert 80  # 出方向超800Mbps告警
snmp-agent trap enable feature-name ifnet trap-name "iftrafficlimitexceed"  # 启用流量超限告警

（3）CAPWAP echo-fail告警配置


system-view
wlan
capwap echo-fail threshold 5  # 单AP连续5次心跳失败触发告警
capwap trap enable echo-fail  # 启用心跳失败告警

3. 大规模AP转发模式批量迁移方法

（1）华为AC批量配置（适合≥50台AP）


system-view
wlan
ap-group name [AP组名称]  # 按区域分组，便于批量管理
forward-mode direct-forward  # 整组AP配置为本地转发
commit  # 提交配置，AP自动生效（无业务中断）

（2）Cisco批量配置（通过模板）


configure terminal
ap template [模板名称]
dot11 24ghz enterprise-mode local
dot11 5ghz enterprise-mode local
exit
ap name [AP名称1] template [模板名称]
ap name [AP名称2] template [模板名称]
# 批量应用：使用SSH工具（如SecureCRT）发送命令到所有AP会话

（3）迁移注意事项

先选择1-2台非核心业务AP测试，验证转发正常后再全量推进避开业务高峰期（如深夜、周末），单组迁移间隔5分钟，避免网络波动迁移后核查VLAN、ACL、QoS策略适配性（参考下方方案）

4. 隧道转发→本地转发的策略适配方案

（1）VLAN配置适配

隧道转发：VLAN由AC统一分配，AP无需配置本地转发：需在AP上联交换机端口配置Trunk，透传业务VLAN


# 华为交换机配置示例
system-view
interface GigabitEthernet0/0/24  # AP上联端口
port link-type trunk
port trunk allow-pass vlan 10 20  # 放行无线业务VLAN

（2）ACL策略适配

隧道转发：ACL在AC上统一配置本地转发：ACL迁移至核心交换机/防火墙，保障策略一致性


# 核心交换机ACL配置示例
acl number 3000
rule permit ip source vlan 10 destination any  # 允许VLAN10业务流量
rule deny ip source vlan 10 destination 192.168.1.0 0.0.0.255  # 禁止访问特定网段

（3）QoS策略适配

隧道转发：QoS在AC上配置，优先保障语音/视频流量本地转发：QoS在AP或上联交换机配置


# 华为AP本地QoS配置示例
system-view
wlan
ap [AP名称]
qos-profile name voice-high
dot11e cos 5  # 语音流量标记COS值5（高优先级）

五、运维避坑指南（核心经验）

大规模无线网络优先采用本地转发（direct-forward），非特殊管控需求不推荐全网隧道转发AP批量掉线可能是“假象”，核心病源多为AC负载过高，AP仅为症状表现CAPWAP echo-fail计数是关键判断指标，一旦暴涨，优先排查AC CPU、带宽负载无线规划需兼顾“信道、带宽”与“转发架构”，避免忽略转发模式导致AC资源不足限制AC业务流量承载≤1Gbps，AC核心定位是管理设备，而非高并发数据转发设备批量迁移转发模式前，务必验证策略适配性，避开业务高峰期，降低风险配置AC负载预警（CPU、流量、心跳失败），提前规避瓶颈问题