4. CAPWAP协议详解：隧道建立、控制与数据通道、状态机、保活机制

CAPWAP，全称是Control And Provisioning of Wireless Access Points。说白了，它就是AC（无线控制器）和AP（瘦AP）之间沟通的“官方语言”。没有它，AP就是一堆散兵游勇，没法被统一管理。

我刚开始接触无线网络时，总觉得CAPWAP很神秘。后来在项目里排过几次隧道建不起来的故障，才真正摸透了它的脾气。今天咱们就把这个协议掰开揉碎了讲清楚。

4.1 CAPWAP隧道是怎么建立的？

AP上电后，第一件事就是找AC。这个过程我习惯叫它“寻亲记”。大致分三步：

1. AP发现AC：AP通过DHCP、DNS、广播等方式，找到AC的IP地址。
2. DTLS握手：建立安全的控制通道。这一步是加密的，防止有人冒充AC。
3. 状态机迁移：AP和AC互相确认身份，交换能力信息，最终进入运行态。

嗯，这里要注意。有些厂商的AP默认开启了DTLS加密，如果你的AC不支持，隧道就建不起来。我曾经在某个园区网项目里，因为AC的证书过期，导致200多台AP全部离线。排查了一下午才发现是证书问题。

4.2 控制通道 vs 数据通道

这两条通道的分工很明确。我整理了一张对比表，方便你理解：

对比项	控制通道	数据通道
端口	UDP 5246	UDP 5247
用途	配置下发、状态上报、保活	用户数据转发
加密	必须DTLS加密	可选加密（通常不加密）
可靠性	可靠传输（有重传机制）	尽力而为（UDP直传）
典型报文	Configuration Update Request/Response	802.11数据帧封装

你想想看，控制通道要是丢了包，AP可能就收不到配置，用户连不上网。所以它必须可靠。数据通道嘛，用户上网的流量，丢几个包顶多卡一下，用UDP直传效率更高。

4.3 CAPWAP状态机详解

AP和AC之间的状态迁移，就像两个人从陌生到熟悉的过程。CAPWAP定义了5个主要状态：

• Idle（空闲）：AP刚启动，还没开始找AC。
• Discovery（发现）：AP发送Discovery Request，等待AC回复。
• Join（加入）：AP选择了一个AC，发送Join Request。AC回复Join Response，并分配一个Session ID。
• Configure（配置）：AC把配置（SSID、信道、功率等）下发给AP。AP应用配置后回复确认。
• Run（运行）：AP正常工作，用户可以通过它上网了。

我画了一张状态机迁移图，帮你直观理解：

为什么会从Run状态回退到Idle？说白了就是保活机制失效了。AP和AC之间需要定期互报平安，如果连续几次没收到对方的保活报文，就认为对方挂了，隧道断开，AP重新回到Idle状态，从头开始找AC。

4.4 保活机制（Keepalive）

保活机制是CAPWAP隧道稳定的基石。AP和AC各自维护一个定时器，周期性地发送Keepalive报文。默认情况下，AP每30秒发一次，AC每30秒发一次。如果连续3次没收到对方的回复，就判定隧道中断。

我习惯把保活机制比作“心跳监测”。你想想看，如果一个人心跳停了，那肯定出大事了。CAPWAP也一样，保活断了，隧道就断了，用户就掉线了。

保活报文的格式很简单，就是一个空的控制报文，里面带一个序列号。收到后回复一个确认。嗯，这里有个细节：保活报文走的是控制通道（UDP 5246），所以它也是DTLS加密的。

4.5 常见故障与排查思路

CAPWAP隧道相关的故障，我总结了几种典型场景：

• 隧道建不起来：检查AC的IP地址是否可达，UDP 5246/5247端口是否被防火墙拦截，DTLS证书是否有效。
• 隧道频繁中断：检查网络丢包率，查看AC的CPU/内存使用率，确认保活报文是否正常收发。
• AP卡在Join状态：可能是AC的License不足，或者AP的版本与AC不兼容。
• 数据通道不通：检查数据转发模式（本地转发还是集中转发），确认VLAN配置是否正确。

我曾经在某个连锁酒店项目里，遇到AP全部卡在Discovery状态。排查后发现是DHCP Option 43配置错了，AC的IP地址写成了网关地址。你想想看，AP拿着网关地址去建隧道，怎么可能成功？改过来就好了。