一、概述

在瘦 AP + 无线控制器(AC) 的方案中，所有的 AP 都由 AC 统一控制。随着瘦 AP 方案迅速得到普及，各个厂商之间的兼容性变得越来越重要，这是制定 CAPWAP 协议的主要原因，目的是 AC 可以控制不同厂商的 AP，但是现在还未能实现

AC 通过 CAPWAP 来控制 AP，在集中转发模式下，STA 的所有报文都由 AP 封装成 CAPWAP 报文后再由 AC 解封装后进行转发。在本地转发模式，用户数据虽然不会通过 CAPWAP 隧道发送到 AC，但 AP 依然由 AC 通过 CAPWAP 报文进行控制。因此 CAPWAP 可以说是瘦 AP 方案中最为重要的技术之一

目前 CAPWAP 功能的实现主要是基于三层网络传输模式下，即所有的 CAPWAP 报文都被封装成 UDP 报文格式在 IP 网路中传输，而 CAPWAP 隧道也是由 AC 的接口 IP 地址和 WTP 的 IP 地址来维护的（对应我们无线控制器的 Loopback 0 地址以及 AP 的 IP 地址）。因此保证 CAPWAP 隧道运行正常的前提是无线控制器的 Loopback 0 地址与 AP 的 IP 地址之间路由可达

二、CAPWAP 建立过程     

CAPWAP 协议中对 CAPWAP 状态机进行完整地描述，整个过程包括：

Discovery → Join → Image Data → Configuration → Data check → Run     

CAPWAP 建立需要经历以下 7 个过程：

1. AP 通过DNS，DHCP，静态配置IP地址，广播等方式获取到 AC 的 IP 地址

2. AP 发现 AC

3. AP 请求加入 AC

4. AP 自动升级

5. AP 配置下发

6. AP 配置确认

7. 通过 CAPWAP 隧道转发数据 

① AP 获取 AC 的 IP 地址

AP 首先要获取到 IP 地址。AP 获取 AC 的 IP 地址有多种方式，例如：DNS 解析、DHCP 的 option 选项、配置静态 IP 地址、广播、组播等。在锐捷无线产品的实际部署过程中，通过 DHCP + Option138 方式分配 AP 与 AC 的 IP 地址，其中 Option138 配置为 IP 数组类型，可以配置多个 AC 的 IP 地址

如下图所示，AP 第一次启动后需要先获取自身以及 AC 的 IP 地址

   

★ 当 AP 第一次获取到 AC 的 IP 地址后，那么该地址会被保存在 flash 中，不是在 config.text 配置文件中。因此以后 AP 再启动时，只要能获取到自己的 IP 地址，即使没有获取 AC 的 IP 地址，也能与之前配置的 AC 建立 CAPWAP 隧道  

★ AP 11.x 的版本开始支持 Ooption 43 上线

② AP 发现 AC

AP 获取到 AC 的 IP 地址后，AP 发送 CAPWAP  [Discovery Request 报文] 后 CAPWAP 状态机进入 <Discovery> 状态

1）报文分析

CAPWAP 控制报文的 Discovery 帧结构，由于它完成的是查找现有 AC 的过程，此时控制隧道还未建立，所以它是所有控制报文中唯一非加密数据报文。下图为控制报文 [Discovery Request 报文]  与 [Discovery Response 报文] 的报文格式

在无线的瘦 AP 方案中，AP 获取到 AC 的 IP 地址后，马上发出多个  [Discovery Request 报文] 报文，报文包括：

• 广播 [Discovery Request 报文]

• 组播 [Discovery Request 报文]（目的地址为 224.0.1.140）

• 单播 [Discovery Request 报文]（目的地址为 AC 的 IP 地址），AC 的 IP 地址可以多个，所以这类型的报文可能有多个

因为  [Discovery Request 报文] 内数据是非加密的，因此我们在报文中直观地看到  [Discovery Request 报文] 报文的信息，如下图所示，报文信息中包括 AP 的型号：AP330-I，以及该 AP 的软硬件信息等。   

  

AC 回应的[Discovery Response 报文] 内的数据也是非加密的。如下图所示，AP 发出的 [Discovery Request 报文] 后，IP 地址 1.1.1.1 的 AC 给予回应。回应的报文中包括 AC 的软硬件版本，AC 的名称等

 

注：这里 AC 的名称不是 AC 的 hostname，而是在用于集群冗余配置的名称。配置如下：

Ruijie(config)# ac-controller     

Ruijie(config-ac)# ac-name ruijie-ac

2）处理流程

在 CAPWAP 状态机流程图中，AP 发现 AC 的过程包括以下 4 个步骤：

• AP 启动后 AP 处于 <Idle> 状态，当 AP 发出  [Discovery Request 报文]，那么 AP 上 CAPWAP 状态机更新到 <Discovery> 状态

• AC 收到  [Discovery Request 报文] 后，响应 [Discovery Response 报文]，状态机状态不发生变化 

• AP 发出  [Discovery Request 报文]  一段时间以后，没有收到 [Discovery Response 报文]，AP 上 CAPWAP 状态机更新到 <Sulking>

• AP 上的 <Sulking> 状态持续 30 秒钟后，转 <Idle> 状态，又开始发送  [Discovery Request 报文]

注：[Discovery Request 报文] 和 [Discovery Response 报文]  采用 UDP 明文发送。因此在第三步骤中，如果网络状况很差的情况下，或者 AP 的数量较多，AC 即使回应也可能会导致 AP 一直在 <Sulking> 状态与 <Discovery> 状态来回切换

③ AP 请求加入 AC 

AP 发出 [Discovery Request 报文] 并得到回应，则开始准备加入到该 AC。如果 AP 发出 [Discovery Request 报文] 得到多个 AC 回应，并且多个 AC 在该 AC 上定义的优先级不同，那么 AP 会优先申请加入到优先级最高的 AC

以下为配置举例：在 AC1 与 AC2 上均定义了 AP0001 的优先级，如果同时收到 AC1 与 AC2 的回应，那么 AP0001 向 AC1 请求加入

Ruijie(config)# ap-config AP0001

Ruijie(config-ap)# primary-base AC1

Ruijie(config-ap)# secondary-base AC2

AP 加入 AC 前，先进行 DTLS 验证，当 AP 与 AC 之间的 DTLS 握手成功后，AP 发出 Join 请求开始请求加入。

这个过程里面的所有报文均为加密报文。以下为报文格式（摘自 RFC5418） 

在 AP 请求加入 AC 的整个过程中，所有的报文都是经过加密的。下面是 AP 请求加入 AC 的 6 个步骤：

1）AP 将自己的状态更新到 <DTLS Setup>，AC 新建状态机，初始值为 <DTLS Setup> 状态

2）AP 和 AC 之间开始进行 DTLS 握手，如果 60 秒内 DTLS 握手还是不成功，将自己状态更新成 <DTLS Teardown>

3）AP 和 AC 之间 DTLS 握手成功后，将自己状态更新为 <Join> 状态，并发出 Join Request 报文

4）AC 收到 [Join Request 报文]，并回应 [Join Response 报文]，如果 AC 从 DTLS 握手开始的时间算起，60 秒内还没有收到 [Join Request 报文]，状态更新成 <DTLS Teardown>  

5）AP 收到 [Join Response 报文]，如果 Result Code 为 Success，则 AP 加入 AC 成功。如果 Result Code 不为 Success，状态机状态更新到 <DTLS Teardown>。如果 AP 没有收到 [Join Response 报文]，并且AP在重传 Join Request 报文 4 次以后，还没有收到 [Join Response 报文] 状态更新成 <DTLS Teardown>   

6）AP 在 <DTLS Teardown> 状态持续 5 秒钟后，进入 <Sulking> 状态，再等 30 秒后恢复到 <Idle> 状态，AC 在 5 秒钟后，状态机删除

④ AP 自动升级

<Image Data> 状态是 AC 对 AP 升级的过程，目的是为了 AP 的版本可正常关联 AC。下面是 AP 自动升级的 7 个步骤：

1）AP 收到 [Join Response 报文] 后，先比较当前运行的软件版本和 AC 要求运行的软件版本是否一致，如果不一致则发送[Image Data Request 报文] 请求进行自动升级

2）AP 发出 [Image Data Request 报文] 后，将状态机更新成 <Image Data>。如果 AP 的 [Image Data Request 报文] 在传输过程中丢失，重传多次都没有到达 AC 的情况下，AP 和 AC 的状态机要更新到 <DTLS Teardown>     

3）AC 收到 [Image Data Request 报文] 报文后进入 <Image Data> 状态，并回应 [Image Data Response 报文]  

4）AC 将新的主程序通过若干个  [Image Data Request 报文]  发送到 AP   

5）AP 收到 [Image Data Response 报文]  后，30 秒后还没有收到 AC 发来的  [Image Data Request 报文]，则状态转<DTLS Teardown>   

6）AP 对每一个收到的主程序分片消息响应 [Image Data Response 报文] 

7）AP 升级成功或者失败后，设备重启

注：AC 通过 CAPWAP 控制报文下发升级版本给 AP，而不是通过 CAPWAP 数据报文 

如下图所示，AP 的升级过程中会有大量的控制报文。通过报文过滤可以看出控制报文的占用文件大小略大于 AP 版本

   

⑤ AP 配置下发

当 AP 比较版本后判定 AP 不需要升级，或者当 AP 已经升级完毕时， AC 开始下发配置给 AP 

以下为配置下发的主要过程：

1）AP 收到 AC 发来的 [Join Response 报文]，其 Result Code 为 Success，且 AP 当前运行的版本和要求运行的版本一致，AP发出 [Config Status Request 报文]，进入 <Config> 状态  

2）AC 收到 [Config Status Request 报文] 后，进入 <Config> 状态。并回应 [Config Status Response 报文]，通知 AP 按要求进行配置。如果 A C在发出  [Join Response 报文] 后，60 秒内没有收到 [Config Status Request 报文] ，则状态转 <DTLS Teardown>   

3）AP 收到 [Config Status Response 报文]，配置同步完成。如果 AP 发出 [Config Status Request 报文] 后，51 秒内没有收到 [Config Status Response 报文]，则状态转 <DTLS Teardown>

⑥ AP 配置确认

AC 下发配置后还需要确认配置是否在 AP 上执行成功。以下为配置确认的主要过程： 

1）AP 收到 [Config Status Response 报文] 后，状态进入 <Data Check>, 并发送 [Change State Event Request 报文] 报告配置执行情况

2）AC 收到 [Change State Event Request 报文]，如果当前是 <Config> 状态，则状态转 <Data Check>，并回应 [Change State Event Response 报文]。如果 AC 在发出 [Config Status Response 报文] 后，25 秒内没有收到 [Change State Event Request 报文]，则状态转 <DTLS Teardown>   

3）AP 收到 [Change State Event Response 报文] 后，如果当前是 <Data Check> 状态，则状态转 <Run>，并创建CAPWAP 数据通道，开始数据转发

4）当 AP 进入 <Run> 状态，说明 AP 与 AC 的控制和数据通道建立已成功，用户可根据需要，对指定的 AP 做配置设置，如创建 WLAN、设置信道、调整发射功率等等，并可实时监控 AP 的运行状态。     

⑦ 通过CAPWAP隧道转发数据

AP 进入 <Run> 状态后，AP 与 AC 开始转发用户数据，同时也需要定期检查 CAPWAP 通道是否正常工作

以下为检查 CAPWAP 通道的主要过程：  

1）AP 进入<Run> 状态后，开始创建数据通道，并每隔 30 秒发送 1 个数据通道保活报文

2）AC 收到第 1 个保活报文, 如果当前是 <Data Check> 状态，则进入 <Run> 状态，并回应 <Data Channel> 保活报文。如果 AC 在发出 [Change State Event Response 报文] 后，30 秒内没有收到第 1 个 <Data Channel> 保活报文，则状态转<DTLS Teardown> 

3）AP 和 AC 收到保活报文后，如果 60 秒内没有收到第 1 个数据通道保活报文，则认为数据通道断掉，状态转 <DTLS Teardown>

4）当 AP 或者 AC 检测到数据通道断掉后，CAPWAP 状态机更新到 <DTLS Teardown>  

注：现在数据通道断不会导致隧道断，而是控制通道断开才会导致 CAPWAP 隧道断开，因此，步骤 3，步骤 4 不会导致状态机变化。事实上，Keepalive 在数据通道传输，是数据通道的保活报文，而控制通道是依靠 Echo 进行保活

以下是 STA 无线终端用户的数据转发，用户数据通过 CAPWAP 数据通道传输。CAPWAP 数据报文分为以下两种格式：

非加密格式，其中 Wireless Payload 为用户的数据报文，由于它是非加密的，所以这种数据报文只能应用在 Wireless Payload 内的无线数据已做过安全加密的基础之上。

例如无线信号已经采用了 WEP、WPA 或者 WPA2 进行了加密 

注：这里的无线数据加密指的是无线信号的加密，目的是为了别人即使在空气中获取到该报文也很难破解出 Wireless Payload 的用户数据。而当 AP 将无线报文（802.11的数据报文）转为 802.3 有线以太网的数据报文后，Wireless Payload 内的数据是不加密的

因此通过抓包分析，我们可以看到用户的交互数据。从下图可以直观看到用户的 PING 报文如何被封装成 CAPWAP 数据报文。红色小方框中与黄底色标注的内容分别为源目的 MAC 地址与 IP 地址。    

注：加密格式，Wireless Payload 用户数据被加密后无法直接看出来，这种封装格式使用户的数据报文在有线上传输更加安全，同时也对 AC 的性能要求更高

锐捷产品目前只支持非加密格式数据报文

一般情况下，AP 上线通过 AP 名称与 AP 配置名称的匹配来决定 AP 使用哪个配置。而 MAC 地址绑定是比名称匹配更强的绑定关系，其优先级高于名称匹配。因此，只要 AP 配置所绑定的 MAC 地址与 AP 的 MAC 地址一致，则 AP 上线时使用该配置

用户可以通过 no ap-config ap-name 命令删除指定离线 AP 配置

用户可以通过命令 no ap-config all 命令删除本 AC 上所有离线 AP 配置