设为首页   锐捷官网
用其他帐号登录:
查看: 1019|回复: 0

【无线】 capwap隧道技术原理

[复制链接]

13

主题

97

帖子

229

积分

版主

Rank: 7Rank: 7Rank: 7

积分
229
发表于 2016-1-5 14:55:29 | 显示全部楼层 |阅读模式
概述
      在瘦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地址。
1.jpg
注:当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的报文格式。
   1.jpg
在无线的瘦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 的软硬件信息等。
  
1.jpg
AC回应的Discovery Response报文内的数据也是非加密的。如下图所示,AP发出的Discovery Request后,IP地址1.1.1.1的AC给予回应。回应的报文中包括AC的软硬件版本,AC的名称等。
   1.jpg
注:这里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):
   1.jpg
在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版本。
   1.jpg
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。
       1.jpg
注:现在数据通道断不会导致隧道断,而是控制通道断开才会导致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地址。
   1.jpg
注:加密格式,Wireless Payload用户数据被加密后无法直接看出来,这种封装格式使用户的数据报文在有线上传输更加安全,同时也对AC的性能要求更高。
锐捷产品目前只支持非加密格式数据报文。

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则