当AP与AC的CAPWAP隧道三次建立重连都失败后，会重启吗

一、CAPWAP隧道重传机制详解

在H3C的CAPWAP协议实现中，存在一个可靠的“重传与超时”机制：

1. AC发送探测报文：AC会定期向已建立隧道的AP发送CAPWAP保活（Keepalive）报文，用于检测链路状态。

2. 三次超时判定为失败：如果AC连续发送探测报文后，超过3次未收到AP的响应，就会判定隧道已断开。

3. 记录失败原因：此时AC会记录一条隧道断开日志，原因码通常是 Failed to retransmit message（报文重传失败）。

4. 注意：这“三次失败”指的是隧道建立后的保活探测机制，而非隧道建立过程中的三次重试。

 二、三次失败后AP会做什么？

结论：AP不会重启，而是进入“持续重试”模式。

根据CAPWAP协议的恢复机制：

• 隧道故障时：AP和AC都会将自己的状态设置为“运行信息锁定”，并保存故障隧道的会话ID。

• 锁定状态下：AP会停止对终端的探测，但不响应新的连接请求，等待隧道恢复。

• 恢复过程：AP与AC交换隧道恢复报文，各自恢复运行状态，并重建隧道。

整个过程AP并不会主动重启，而是一直尝试与AC重新建立连接，直到成功。

 三、可以通过命令查看隧道断开原因

如果你想确认AP当前的状态，可以在AC上执行以下命令，查看历史隧道断开记录：

与你描述场景相关的原因码：

• Failed to retransmit message：报文重传失败，通常由网络不稳定导致

• Neighbor dead timer expired：邻居报告定时器超时

• Data check timer expired：数据检测定时器超时

 四、如果一直连不上，AP会“死循环”吗？

不会死循环，但有“降级”行为。

当隧道长时间无法建立时，AP通常会：

1. 持续重试：按照一定的退避算法（如指数退避）不断尝试与AC建立连接

2. 本地保持运行：如果AP之前已有配置（如胖AP模式），可能会降级为本地转发，保证基础网络不中断

3. 不主动重启：除非因其他原因（如镜像下载完成、系统错误）触发重启，否则AP不会因隧道建立失败而重启