无线AP 每天都会掉线4次左右

无线AP每天固定掉线4次左右，原因可能出在多个环节。不过别担心，我们可以按照从简到繁的顺序来排查。

🔍 第一步：快速定位，查看AP掉线原因

与其猜测，不如直接让设备“告诉”你原因。登录你的无线控制器（AC），执行以下命令，这是定位问题最直接的一步：

• 查看AP掉线记录：

  bash

  display wlan ap statistics tunnel-down-record

  这个命令会列出AP最近掉线的时间及具体原因。重点关注 Tunnel Down Reason 字段，常见的错误原因有：

  • Neighbor dead timer expired：表示心跳超时，AP与AC失联，通常指向网络链路问题。

  • Failed to retransmit message：表示报文重传失败，通常也是链路不稳定或AC过于繁忙。

  • Processed join request in Run state：表示AP在已运行状态又重新发起连接，通常是链路不稳定导致的重连。

• 查看AP详细状态：

  bash

  display wlan ap name <AP名称> verbose

  重点关注 Lost echo responses（丢失的心跳响应数），数值越大说明链路越不稳定。

⚙️ 第二步：由简入繁，逐一排查

1. 物理与环境检查（最常见）

• PoE供电与网线：检查AP的网线和水晶头是否接触良好。尝试更换网线或交换机上的PoE供电端口。如果AP支持，也可以用独立电源适配器测试，以排除PoE供电不稳定的问题。

• 信号干扰：检查AP安装环境，确保没有强干扰源。相邻AP应使用不重叠的信道（如2.4GHz使用1、6、11）。可以调整AP的发射功率，原则是“功率宜小不宜大”。

• 有线网络质量：登录AP上联的交换机，检查端口是否有CRC错误计数增长。CRC错误增多说明物理线路或光模块可能存在问题。

2. AC（无线控制器）性能与配置检查

• 检查AC负载：在AC上执行 display cpu-usage 和 display memory 查看CPU和内存使用率。如果业务高峰期CPU持续高于80%，AC就可能因处理能力不足而无法及时回应AP的心跳，导致AP误认为掉线。

• 优化转发模式（关键）：检查AP的转发模式。如果是 集中转发（Tunnel forwarding） ，所有无线业务流量都需经过AC转发，这会极大消耗AC性能。建议改为本地转发（Direct forwarding），让业务流量直接从AP本地转发，AC只负责管理。

• 检查DHCP与VLAN：确认AP能稳定获取IP地址，且DHCP地址池未满。建议为无线业务分配独立的业务VLAN。

3. 软件与配置调优

• 升级固件：检查AC和AP的软件版本，过旧的版本可能存在已知的稳定性问题。如有新版本，建议在维护窗口期进行升级。

• 调整CAPWAP心跳：如果网络环境存在轻微延迟，可以适当调整CAPWAP隧道的心跳间隔等参数，但这属于高级操作，建议在技术支持指导下进行。

先梳理关键日志信息
目标 AP 隧道断开原因：Neighbor dead timer expired（邻居保活超时）
CAPWAP 默认参数：
Echo interval 10s，Echo count 3
机制：连续 3 次（30 秒）收不到 AP 回送的 Echo Response，AC 判定 AP 失联，拆除隧道。
同时现场特征：每日固定掉线 4 次左右，大量 AP 均存在周期性上下线，不是单台故障。
一、先区分 3 大类根因，按排查优先级
类型 1：CAPWAP Echo 报文被中间网络丢包（最高概率）
CAPWAP 控制报文 UDP 5246，很多场景容易被拦截 / 队列丢弃：
AP 与 AC 之间存在防火墙、三层交换机，ACL / 风暴抑制、QoS 拥塞丢弃 Echo 报文；
上行链路瞬时拥塞，小报文优先被丢弃（Echo 小包极易被尾部丢弃）；
中间设备开启 LACP 短超时、STP 震荡、端口 flapping，短暂断流导致保活超时。
现象特征：掉线原因Neighbor dead timer expired，和你截图完全吻合。
类型 2：PoE 供电不稳定（WA4320 高频故障点）
WA4320-ACN-SI 标准 802.3af 供电刚好卡功率阈值：
网线老化、接触不良，负载波动时 PoE 临时降功率；
交换机 PoE 电源功率余量不足；
端口过流保护间歇性触发，AP 短暂重启。
校验手段：
plaintext
display poe interface GigabitEthernet x/x/x
display poe fault-log
如果 AP 重启，Last reboot reason会显示电源相关；单纯保活超时不会显示重启记录。
类型 3：无线侧干扰 / AP 自身软件 BUG
射频干扰导致 AP 上行报文丢失（如果 AP 是本地转发，CAPWAP 控制流量依旧走上联，无线干扰不会导致 CAPWAP 断连）；
✅重点区分：
本地转发：终端流量不走隧道，仅 CAPWAP 控制报文；无线干扰不会造成隧道断开；
集中转发：业务流量 + 控制报文都走隧道。
AP Boot / 系统版本老旧，CAPWAP 协议栈 bug，Echo 应答异常。
二、针对性排查步骤（现场执行顺序）
1、抓包验证：判断 Echo 报文双向是否可达
在 AC 侧或者上联交换机镜像端口抓 UDP 5246：
AC 发 Echo Request，长期收不到 AP 回应 → 上行网络单向丢包；
报文收发正常仍然报 dead timer → AP 固件问题。
2、优化 CAPWAP 保活参数（临时缓解，定位故障）
不建议直接长期调大，优先找到根因；维护窗口测试
plaintext
wlan ap apname
echo-interval 20
echo-count 5
超时时间由 30s 放宽至 100s。
👉 如果调整后掉线大幅减少，确认是中间网络存在短时报文丢失。
3、网络侧核查清单
三层设备放行 UDP 5246（CAPWAP 控制）、5247（数据），不要开启 ACL 限速；
上联交换机关闭单播风暴抑制！风暴抑制极易随机丢弃 CAPWAP 小包；
plaintext
interface GigabitEthernet 1/0/X
undo storm-constrain unicast
存储、大流量业务上联交换机开启burst-mode enable，避免突发拥塞丢弃控制报文；
检查链路 CRC 错包：display interface GigabitEthernet x/x/x，确认无 input/output error。
4、PoE 交叉验证
把故障 AP 更换到另外一台 PoE 交换机端口，持续观察是否依旧定时掉线。
换端口后故障消失：原交换机 PoE 电源 / 端口硬件问题；
故障依旧：排除 PoE，聚焦 CAPWAP 网络与固件。
5、固件版本核查
WA4320-ACN-SI 老旧版本存在 CAPWAP Echo 处理缺陷：
建议升级 AP BootWare & AP 镜像版本，同步 AC 平台版本至稳定基线。
三、补充日志里其他隧道 down 原因说明
你截图里还有大量：
Failed to retransmit message
Processed join request in Run state
含义：
隧道保活超时拆除后，AP 立刻重新发起 CAPWAP Join 请求，重建隧道，就是你看到的反复上下线现象。
四、两套方案取舍
短期临时规避
上调 AP 视图 echo-interval/echo-count；
交换机接口关闭单播风暴抑制，保障 CAPWAP 控制报文优先转发。
根治方案顺序
交叉测试排除 PoE 供电问题；
核查中间网络是否丢弃 UDP5246 报文；
升级 AC 与 AP 稳定版本；
必要时部署 CAPWAP 隧道 QoS，将 5246 端口映射至高优先级队列。
快速自测判断小技巧
如果所有 AP 统一时间段批量掉线 → 上联汇聚 / 核心交换机拥塞、风暴抑制、链路震荡；
如果零散 AP 随机掉线 → 单链路、PoE、个别 AP 硬件问题。

先排查下链路问题，连通性问题 

细化无线的管理VLAN。就能解决。可以不掉线。