AP上线流程AP上线流程中的报文交互如图1-1所示,通常将AP上线的主要流程分为AP获取IP地址阶段(以DHCP方式为例)、AP发现AC阶段、AP接入AC阶段、AC下发配置阶段、CAPWAP隧道维持阶段和配置更新阶段等几个阶段。
图1-1 AP上线流程中的报文交互

图中同时标明了AP的CAPWAP状态机的部分状态,各个状态的含义如下:
- Discovery:AP发现AC的状态
- DTLS connect:AP和AC之间建立DTLS连接状态
- Join:DTLS连接完成,AP加入AC的状态
- Image data:AP从AC下载软件版本文件进行升级的状态
- Configure:AP从AC获取初始化配置的状态
- Data check:AP和AC进行信息交换,确认配置的状态
- Run:CAPWAP链路正常建立的状态
- Config:AP从AC获取下发的配置
这里从AP的CAPWAP状态机状态的变化,来简单梳理一下AP上线的基本流程,具体的流程可以参考后续章节内容:
- Idle(图中未标识)
AP正常启动,初始化完成后的状态,AP开启CAPWAP状态机。
- Idle -> Discovery
AP获取地址后,由Idle切换到Discovery状态,开始发送Discovery Request报文发现AC。
- Discovery -> DTLS connect
在AP选择AC后,会根据AC的配置选择建立DTLS连接,AP由Discovery切换到DTLS connect状态(实际上在这中间还有DTLS会话建立、DTLS认证等状态,这里做了简化描述)。
- DTLS connect -> Join
DTLS连接建立完成后,AP状态由DTLS connect切换为Join,开始发送Join Request报文请求加入AC。
- Join -> Image data
AC回复Join Response报文,报文中携带了期望的AP软件版本,如果AP当前的软件版本和AC期望的软件版本不一致的话,AP状态由Join切换到Image data,开始在线升级版本。版本升级完成后,AP会重启并重复上述过程。
- Join -> Configure
AC允许AP加入后,AP状态由Join切换为Configure,开始发送Configuration Status Request报文请求AC下发初始化配置。
- Configure -> Data check
AC下发初始化配置后,AP状态由Configure切换为Data check,开始和AC交换信息确认配置。
- Data check -> Run
当初始化配置确认完成,AC给AP发送了Change State Event Response报文后,AP状态由Data check切换为Run,即CAPWAP链路正常建立。在这个阶段,AP和AC之间会周期性的通过发送Keep Alive和Echo报文来检查CAPWAP数据隧道和控制隧道的连通性。
AP获取IP地址阶段AP获取IP地址的方式包括静态方式、DHCP方式和SLAAC(Stateless Address Autoconfiguration)方式。
AP获取IP地址阶段的常见问题如下:
AP静态地址配置错误
- AP配置的静态IP地址不唯一,与网络中其他设备的IP地址存在冲突。
- 二层组网规划下,AP配置的静态IP地址和AC不在一个网段。
- 三层组网规划下,未配置AP路由的出口网关。
- AP未重启,导致配置的静态IP地址未生效。
AP静态地址配置错误
DHCP方式下AP未分配到IP地址
- DHCP服务器和AP之间网络不通,如VLAN未创建或未放通等。
- DHCP配置不正确。
- 未配置DHCP地址池或DHCP地址池中空闲地址不足。
AP和AC之间的网络不通
AP未分配到IP地址
AP发现AC阶段AP发现AC阶段的报文交互如图1-3所示。
图1-3 AP发现AC阶段报文交互

实际报文示例:
Discovery(AP发现AC):
DTLS connect(AP和AC建立DTLS连接):
AP通过AC发现机制来得知当前网络中哪些AC是可用的,然后决定最佳的AC来建立CAPWAP链路。
- AP在获取到IP地址后,需要通过Discovery Request报文来发现当前网络中可用的AC。在AP发送Discovery Request文启动发现AC的流程后,其CAPWAP状态由Idle变更为Discovery。Discovery Request报文中包含了AP的版本和胖瘦形态等信息。
- AC在接收到Discovery Request报文后,会结合根据配置的IP版本、AP的黑白名单、AP认证方式(MAC认证、SN认证和不需要认证)以及License资源限制等信息判断是否允许该AP接入并记录判断结果。如果允许,则向该AP单播回应Discovery Response报文,该报文中包含了AC Name、AC版本、CAPWAP源地址和DTLS状态等信息;如果不允许,则不回应Discovery Response报文。
- 如果AP收到多个AC回应的Discovery Response报文,AP会根据AC的优先级、AC的负载(AC上当前AP的个数)等信息来决策并选择AC。
AP可以通过静态配置和动态方式获取AC的IP地址:
如果AP和AC之间是二层组网,可以不需要指定AC的IP地址,AP可以通过广播方式发现AC;如果AP和AC之间是三层组网,则必须指定AC的IP地址,否则AP无法通过广播方式发现AC。
如果未指定AC的IP地址,则通过发送Discovery Request广播报文来发现AC;如果已经指定了AC的IP地址,则直接给指定的AC发送Discovery Request单播报文。
如果AC上开启了DTLS功能,并通过Discovery Response报文告知AP,AP会启动DTLS协商以建立和AC之间的DTLS连接。AP和AC之间建立DTLS连接之后,后续的报文会加密传输。DTLS可以对CAPWAP中的数据报文和控制报文分别进行加密配置。
AP发现AC阶段的常见问题如下:
AP和AC之间网络不通
- 管理VLAN未创建
- 中间网络未放通管理VLAN
- VLAN tag配置错误
- 中间网络存在环路
AP和AC之间的网络不通
未指定AC的IP地址或指定的AC IP地址错误
- AC与AP之间配置为三层组网,但是AP未指定AC的IP地址
- AC VRRP组网场景下,AP未指定的AC的虚地址
未指定AC的IP地址或指定的AC IP地址错误
AC未配置CAPWAP源接口/源地址或配置错误
AC未配置CAPWAP源接口/源地址或配置错误
AC上未配置CAPWAP源接口或源地址
AP不是FIT形态
AP不是FIT形态
License资源不足或者AP数量超过AC规格
AP连接数超过AC最大能接入的AP数
CAPWAP链路的DTLS协商失败
AC和AP的DTLS PSK密钥不一致
DTLS协商失败
AC上离线添加的AP的MAC和SN与AP实际不一致
在离线添加AP时,添加的AP MAC和SN与实际AP不一致
AC上配置的AP MAC和AP SN与实际AP不一致
AP被加入黑名单
AP被误添加到了黑名单中
AP被加入到黑名单
AP接入AC阶段AP接入AC阶段的报文交互如图1-4所示。
图1-4 AP接入控制阶段报文交互

实际报文示例:
- AP和AC之间的DTLS连接建立完成后,AP会向前一个阶段选择的AC发送Join Request报文申请加入该AC,AP进入Join状态。
- AC判断是否允许AP接入。如果在Discovery阶段已经进行了判断,则直接利用Discovery阶段缓存的判断结果,无需重复判断;如果没有缓存结果,则按照图1-5所示流程重新进行判断。完成判断后,AC会回复Join Response报文给AP,告知是否允许AP接入的判断结果,同时报文中还包含了期望AP使用的版本信息。图1-5 AC判断是否允许AP接入流程

- AP在接收到Join Response报文后,会比较当前运行的系统软件版本和AC期望的软件版本是否一致。如果不一致,则AP进入Image data状态,开始下载升级文件并启动软件版本升级,升级方式包括AC模式、FTP模式和SFTP模式。AP在软件版本更新完成后重新启动,重启后会重复进行前面几个阶段。需要说明的是,如果升级失败了,AP一样会重启,然后一样会重复进行前面几个阶段,所以,如果AP在线升级配置错误了,可能会导致AP在上述几个阶段不停循环,直到AP正确升级软件版本。
AP接入AC阶段的常见问题如下:
AC和AP之间版本不匹配
AC和AP之间版本不匹配
AP在线升级失败
- AC上配置了AP在线升级,但是未正确上传AP的软件包或上传的软件包错误
- AP和FTP/SFTP服务器之间网络不通
AP在线升级失败
AC下发配置阶段当AP比较版本后判断AP无需升级或AP已经升级成功后,AC开始给AP下发配置。
AC下发配置阶段的报文交互如图1-6所示。
图1-6 Configure阶段报文交互流程

实际报文示例:
Configure:
Data check:
- AP接收到AC的Join Response报文后,判断AC允许其接入且当前运行的软件版本和AC期望的软件版本一致时,AP向AC发送Configuration Status Request报文来传递AP当前的配置并进入Configure状态,报文中携带了多个Radio Administrative State信息。
- AC收到Configuration Status Request报文后,给AP发送回应报文Configuration Status Response,给AP下发初始化配置。实际上,在这个阶段AC并未进行实际的业务下发,而是在CAPWAP链路正常建立后,才正式下发业务配置。
- AP收到Configuration Status Response报文后,进入data check状态,并根据报文内容执行相应的初始化配置。
- AP在执行完初始化配置后,给AC发送Change State Event Request报文通知配置执行情况,报文中包含了配置执行后Radio的状态以及配置执行的结果。
- AC收到Change State Event Request报文后,发送回应报文Change State Event Response,并根据需要刷新AP的相关信息。
AC下发配置阶段的常见问题如下:
AP初始化配置失败
- AP和AC的中间网络的MTU配置不合理。
- 有线侧存在丢包。
AP初始化配置失败
CAPWAP隧道维持阶段CAPWAP隧道维持阶段的报文交互如图1-6所示。
图1-7 CAPWAP隧道维持阶段报文交互流程

实际报文示例:
在经过了前面几个阶段之后,AP已经在AC上正常上线了,但是还有一个重要的阶段,也就是要维持AC和AP之间的CAPWAP隧道。
AP和AC之间会互相发送Keep Alive报文来检测数据隧道的连通状态;互相发送Echo报文来检测控制隧道的连通状态。
AP会启动定时器来发送Keep Alive和Echo报文,同时启动隧道检测超时定时器,如果在规定的时间内收到Keep Alive和Echo Response报文,则重置超时定时器;否则认为接收报文超时。
配置更新阶段配置更新阶段的报文交互如图1-6所示。
图1-8 配置更新阶段报文交互流程

- AP在AC上正常上线后,AC会给AP发送Configuration Update Request报文下发配置。
- AP在接受到Configuration Update Request报文后,会从Run状态转为Config状态,完成真正的配置下发。
- AP接收AC下发的配置后,会给AC发送Configuration Update Response报文告知AC是否成功接收AC下发的配置。
配置更新阶段的常见问题如下:
AP上线后WLAN业务配置下发失败
AP在AC上正常上线之后,在AC上对AP进行WLAN业务配置,如果AC和AP之间存在链路不通或者对端设备无回应等情况,AC下发WLAN业务配置给AP失败。
AP和AC之间的网络不通