锐捷无线CAPWAP隧道技术原理

CAPWAP简介

CAPWAP（Control And Provisioning of Wireless Access Points 无线接入点的控制和配置协议）：是由IETF（互联网工程任务组）标准化组织于2009年3月定义。capwap协议是一个通用的协议，定义了AC和WTP通过capwap协议传输机制进行控制和数据平面的通信。使用UDP协议的5246和5247端口用于传输控制消息和数据消息，AP上线的过程就是CAPWAP隧道建立的过程，

CAPWAP协议报头格式

CAPWAP协议报头字段

CAPWAP Preamble：8 位预判码，2 种 CAPWAP 首部的前 8 位为预判码，用于快速判断此报文是否经过 DTLS 加密。前 4 位指明 CAPWAP 版本，目前的版本号为 0；后 4 位值为 1 时是 CAPWAP DTLS 首部，值为 0 时是 CAPWAP 首部。
Version：version of capwap
Type：0-capwap header
1-capwap dtls header
HLEN：5 位首部长度，指明 CAPWAP 首部的长度。
RID：5 位射频标识符，指明此报文的来源射频。
WBID： 5 位无线帧标识符， 指明无线帧类型， 有 IEEE 802.11, IEEE802.16 和 EPC Global 3 种。
T：1 位数据帧标识符，值为 1 时数据帧是由 WBID指明的类型，值为 0 时是 IEEE802.3 数据帧。
F：1 位分组标志，值为 1 时此报文是一个 CAPWAP报文分组(IPV6)，需要和其他分组重组成完成的报文。
L：1 位分组结束标志，值为 1 时此报文是最后一个分组。
W：1 位选项标志，值为 1 时存在 Wireless Specific Information 选项。
M：1 位选项标志，值为 1 时存在 Radio MAC Address选项。
K：1 位存活标志，指明此报文用于保持连接存活，不能携带用户数据。
Flags：3 位预留标志。
Fragment ID：16 位分组标识符，识别不同的报文分组，ID 相同的分组属于同一个 CAPWAP 报文
Fragment Offset：13 位分组位移，各分组在该CAPWAP 报文中的位置。
Reserved：3 位预留码。
Radio MAC Address：32 位射频 MAC 地址，不足32 位以全 0 填充。指明报文来源射频的 MAC 地址。
Wireless Specific Information：32 位特殊无线信息，不足 32 位以全 0 填充。包含特殊信息，如与 IEEE 802.11, IEEE802.16 和 EPCGlobal 的关联等。
Payload：数据报文是用户数据，控制报文则是控制消息。

CAPWAP报文分类

1. 控制消息报文(UDP5246)：控制消息作为管理消息在AP与AC间进行交互
2. 数据消息报文(UDP5247)：数据消息被封装成无线帧

CAPWAP控制消息

CAPWAP隧道建立过程的状态机

1. Discovery阶段
2. DTLS协商阶段（可选）
3. Join阶段
4. Image data
5. configure
6. Data check阶段
7. Run（Data）阶段
8. Run（Control）阶段

CAPWAP隧道建立过程

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

   CAPWAP隧道建立——AP获取地址（四步交互）

   在没有预配置AC IP列表时，则启动AP动态AC发现机制。通过DHCP获取IP地址，并通过DHCP协议中的option返回AC地址列表。

   首先是AP发送discover广播报文，请求DHCP server响应，在DHCP服务器侦听到discover报文后，它会从没有租约的地址范围中，选择最前面的空置IP，连同其他TCP/IP设定，响应AP一个DHCP offer报文，该报文中会包含一个租约期限的信息。

   由于DHCP offer报文既可以是单播报文，也可以是广播报文，当AP端收到多台DHCP Server的响应时，只会挑选其中一个offer(通常是最先抵达的那个)，然后向网络中发送一个DHCP request广播报文，告诉所有的offer，并重新发送DHCP，DHCP server它将指定接收哪一台服务器提供的IP地址

   同时，AP也会向网络发送一个ARP封包，查询网络上面有没有其他机器使用该IP地址，如果发现该IP已被占用，AP会发送出一个DHCP Decline封包给DHCP服务器，拒绝接收其DHCP discover 报文。

   当DHCP Server接收到AP的request报文之后，会向AP发送一个DHCP Ack响应，该报文中携带的信息包括了AP的IP地址，租约期限，网关信息，以及DNS server IP等，以此确定租约的正式生效，就此完成DHCP的四步交互工作。
   

2. AP发现AC

   CAPWAP隧道建立-AP发现AC（Discovery）：

   AP启动CAPWAP协议的发现机制，AP以单播或广播的形式发送Discovery报文请求报文试图关联AC，随后CAPWAP状态机进入Discovery状态，AC收到AP的discovery request以后，会发送一个单播discover response 给AP，AP可以通过discover response中所带的AC优先级或者AC上当前AP的个数等，确定与哪个AC建立会话。

3. CAPWAP隧道建立-DTLS（可选）

   AP根据此IP地址与AC协商，AP接收到响应消息后开始与AC建立CAPWAP隧道，这个阶段可以选择CAPWAP隧道是否采用DTLS加密传输UDP报文。

   DTLS: Datagram Transport Layer Security（数据报传输层安全协议）
   
   
   
   

4. AP请求加入AC

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

   AP加入AC前，先进行DTLS验证，当AP与AC之间的DTLS握手成功后，AP发出Join请求开始请求加入。这个过程里面的所有报文均为加密报文。

   AP请求加入AC的六个步骤：

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

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

   3、AP和AC之间 DTLS握手成功后，将自己状态更新为状态，并发出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秒钟后，进入状态，再等30秒后恢复到Idle状态，AC在5秒钟后，状态机删除。

   在完成DTLS握手后，AC与AP开始建立控制通道，在建立控制的交互过程中，AC回应的Join response报文中会携带用户配置的升级版本号，握手报文间隔/超时时间，控制报文优先级等信息。AC会检查AP的当前版本，如果AP的版本无法与AC要求的相匹配时，AP和AC会进入Image Data状态做固件升级，以此来更新AP的版本，如果AP的版本符合要求，则进入configuration状态。

   

5. CAPWAP隧道建立-AP升级（image date（可选））

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

   AP根据协商参数判断当前版本是否是最新版本，如果不是最新版本，则AP将在CAPWAP隧道上开始更新软件版本。AP在软件版本更新完成后重新启动，重复进行AC发现、建立CAPWAP隧道、加入过程。

   AP自动升级的七个步骤：

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

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

   3、AC收到Image Data Request报文后进入状态，并回应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升级成功或者失败后，设备重启。

   

6. CAPWAP隧道建立-AP配置下发 （configure）

   进入Configuration状态后是为了做AP的现有配置和AC设定配置的匹配检查，AP发送configuration request到AC，该信息中包含了现有AP的配置，当AP的当前配置与AC要求不符合时，AC会通过configuration response通知AP

   过程：

   1、AP收到AC发来的Join Response，其Result Code为Success,且AP当前运行的版本和要求运行的版本一致，AP发出Config Status Request，进入状态。

   2、AC收到Config Status Request后，进入状态。并回应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。

7. CAPWAP隧道建立-AP配置确认 （date check）

   当完成configuration后，AP发送change state event request信息，其中包含了radio，result，code等信息，当AC接收到change state event request后，开始回应change state event response 。
   至此完成data check 后，已经完成管理隧道建立的过程，开始进入run状态。

   主要过程：

   1、AP收到Config Status Response后，状态进入Data Check, 并发送Change State Event Request报告配置执行情况。

   2、AC收到Change State Event Request，如果当前是状态，则状态转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的运行状态。

8. CAPWAP隧道维护-run（date）

   AP发送keepalive到AC，AC收到keepalive后表示数据隧道建立，AC回应keepalive，AP进入“normal”状态，开始正常工作。

   AP进入run状态后，同时发送echo request报文给AC，宣布建立好CAPWAP管理隧道并启动echo发送定时器和隧道检测超时定时以检测管理隧道时候异常。当AC收到echo request报文后，同样进入run状态，并回应echo response报文给AP，启动隧道超时定时器。到AP收到echo response报文后，会重设检验隧道超时的定时器。

   
   

9. CAPWAP隧道转发数据

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

   主要过程：
   1、AP进入状态后，开始创建数据通道，并每隔30秒发送1个数据通道保活报文。

   2、AC收到第1个保活报文, 如果当前是Data Check状态，则进入状态，并回应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进行保活。   

CAPWAP数据报文

用户数据通过CAPWAP数据通道传输。CAPWAP数据报文分为以下两种格式：

1、非加密格式

非加密格式，其中Wireless Payload为用户的数据报文，由于它是非加密的，所以这种数据报文只能应用在Wireless Payload内的无线数据已做过安全加密的基础之上。例如无线信号已经采用了WEP、WPA或者WPA2进行了加密。（这里的无线数据加密指的是无线信号的加密，目的是为了别人即使在空气中获取到该报文也很难破解出Wireless Payload的用户数据。而当AP将无线报文（802.11的数据报文）转为802.3有线以太网的数据报文后，Wireless Payload内的数据是不加密的） 因此通过抓包分析，我们可以看到用户的交互数据。抓包可以直观看到用户的PING报文如何被封装成CAPWAP数据报文。