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

CAPWAP建立过程

CAPWAP协议中对CAPWAP状态机进行完整地描述，整个过程包括：Discovery—>Join—>Image Data—>Configuration—>Data check—>Run

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

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

2)AP发现AC

3)AP请求加入AC

4)AP自动升级

5)AP配置下发

6)AP配置确认

7)通过CAPWAP隧道转发数据

1、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隧道。

2、AP发现AC

AP获取到AC的IP地址后，AP发送Discovery报文后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的型号：AP220-E，以及该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的过程包括以下四个步骤：

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

b、AC收到Discovery Request后，响应Discovery Response，状态机状态不发生变化。

c、AP发出Discovery Request一段时间以后，没有收到Discovery Response，AP上CAPWAP状态机更新到Sulking。

d、AP上的Sulking状态持续30秒钟后，转Idle状态，又开始发送discovery request报文。

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

3、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的六个步骤：

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秒钟后，状态机删除。

4、AP自动升级

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

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

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

6) AC收到Image Data Request报文后进入<Image Data>状态，并回应Image Data Response报文。

7) AC将新的主程序通过若干个Image Data Request发送到AP。

8) AP收到Image Data Response后，30秒后还没有收到AC发来的Image Data Request，则状态转DTLS Teardown。

9) AP对每一个收到的主程序分片消息响应Image Data Response。

10) AP升级成功或者失败后，设备重启。

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

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

5、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按要求进行配置。如果AC在发出Join Response后，60秒内没有收到Config Status Request，则状态转DTLS Teardown。

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

6、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数据通道，开始数据转发。

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

7、通过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配置。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/article/detail/49024