【无线】capwap隧道技术原理是什么?

发布时间: 2013-11-16 点击量:4762 打印 字体:

概述

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

      AC通过CAPWAP来控制AP,在集中转发模式下,STA的所有报文都由AP封装成CAPWAP报文后再由AC解封装后进行转发。即使是本地转发模式,AP依然由AC通过CAPWAP报文进行控制。因此CAPWAP可以说是瘦AP方案中最为重要的技术之一。

      目前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 Request报文,并且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的性能要求更高。

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

00 分享 纠错
相关条目