CAPWAP协议介绍

无线局域网络的架构主要分为:
1. 基于控制器的AP架构(瘦AP:Fit AP);
2. 传统的独立AP架构(胖AP:Fat AP);

1、胖AP介绍:
胖AP 除了无线接入功能外,一般具有 WAN,LAN,多支持DHCPserver,DNS,MAC克隆以及VPN接入,防火墙等安全功能。

2、瘦AP介绍:
瘦AP是 指 自身不能单独配置或者 使用的无线AP产品,这种产品仅仅是一个WLAN系统的一部分,负责管理安装和操作:

AC和fit AP之间运行的协议一般为CAPWAP协议。

3、 Fat AP 和Fit AP比较

问题-无线网络是如何实现三层漫游功能的???

10.2 CAPWAP 隧道介绍
背景:
由于传统的WLAN系统结构已无法满足大规模组网需求,因此IETF成立了CAPWAP工作组,研究大规模WLAN的解决方案,以实现各厂商控制器与AP的互通。
CAPWAP:control And Provisioning of wireless access point(无线接入点控制和配置协议)
CAPWAP起源:

LWAPP具有完整的协议框架,定义了详细的报文结构及多方面的控制消息元素,但全新制定的安全机制还需实践验证;
SLAPP使用业界认可的DTLS(数据传输层安全协议)技术是其亮点。
相对前两者而言,CTP和WiCoP实现了集中式WLAN体系结构的基本要求,但考虑不够全面,特别是安全性方面有所欠缺。
CAPWAP工作组对以上四种通信协议进行评测后,最终采用LWAPP协议作为基础进行扩展,使用DTLS安全技术,加入其他三种协议的有用特性,制定了CAPWAP协议。

10.3 CAPWAP介绍
CAPWAP 用于无线终端接入点AP和无线网络控制器AC之间的通信交互,实现AC对其所关联的AP集中管理和控制;
该协议包含主要内容有:
1. AP对AC的自动发现 及 AP& AC的状态机运行,维护
2.AC对AP进行管理,业务配置下发
3. STA数据封装CAPWAP 隧道进行转发

10.4 WLAN转发模型
1、直接转发
2、隧道转发

直接转发模式:
也称数据报文本地转发,AC只对AP进行管理,业务数据都是由本地直接转发;
蓝色虚线:管理流;红色虚线:数据流

隧道转发模式:
也称作数据报文集中转发,业务数据报文由AP同一封装后到达AC实现转发,AC不但对AP进行管理,还作为AP流量的转发中枢。
蓝色虚线:管理流;红色虚线:数据流

两种转发方式比较:

问题-需要验证:直接转发-业务的网关落在汇聚设备上,隧道转发-业务的网关落在AC上;是吗?需要验证。


10.5 CAPWAP报文格式:

CAPWAP是基于UDP端口的应用层协议。
CAPWAP协议传输层运输两种类型的负载:
数据消息,封装转发无线帧 。
控制消息,管理AP和AC之间交换的管理消息 。
CAPWAP数据和控制报文基于不同的UDP端口发送:
控制报文端口为UDP端口5246。
数据报文端口为UDP端口5247。

10.6 瘦AP对AC的自动发现流程

AP上电后,当存在预配置的AC IP列表时,则AP直接启动预配置静态发现流程并与指定的AC连接。
如果未配置AC IP列表,则启动AP动态发现AC机制,执行DHCP/DNS/广播发现流程后与AC连接。

1、瘦AP动态发现AC的过程:

  1.AP启动以后会通过DHCP获取IP地址、DNS server、域名。
  2.AP发出L2广播的发现请求报文试图联系一个AC。如果长时间(30秒)没有响应,AP会启动L3发现。
  3.AP会从DHCP Server通过Option43获得AC的IP,或者通过Option15获得AC的域名,AP向该IP地址(域名)发送发现请求。
  4.接收到发现请求报文的AC会检查该AP是否有接入本机的权限(版本型号不合适也无法接入到AC),如果有则回应发现响应。
  5.AC和AP间建立CAPWAP隧道。

现网特殊情况下解决建议:
如果现网DHCP Server 不支持Option43 也不支持Option 15则采取以下措施:

  1.AC与 AP采用 二层组网,启用CAPWAP广播发现;
  2.AC与AP仍用三层组网:
     推荐使用AC自带的DHCP Server给AP分IP地址
         -----AP管理流与STA业务流分不同的vlan
     增加部署一台支持option43 的DHCP server
         -----单独为AP建立一个新的DHCP Server。


10.7 CAPWAP隧道建立过程
总体流程:

流程细分:
1、 DHCP交互

DHCP交互过程:

  1.在没有预配置AC IP列表时,则启动AP动态AC发现机制。通过DHCP获取IP地址,并通过DHCP协议中的option返回AC地址列表。
  2.首先是AP发送discover广播报文,请求DHCP server响应,在DHCP服务器侦听到discover报文后,它会从没有租约的地址范围中,选择最前面的空置IP,连同其他TCP/IP设定,响应AP一个DHCP offer报文,该报文中会包含一个租约期限的信息。
  3.由于DHCP offer报文既可以是单播报文,也可以是广播报文,当AP端收到多台DHCP Server的响应时,只会挑选其中一个offer(通常是最先抵达的那个),然后向网络中发送一个DHCP request广播报文,告诉所有的DHCP server它将指定接收哪一台服务器提供的IP地址;
   同时,AP也会向网络发送一个ARP封包,查询网络上面有没有其他机器使用该IP地址,如果发现该IP已被占用,AP会发送出一个DHCP Decline封包给DHCP服务器,拒绝接收其DHCP discover报文。
  4.当DHCP Server接收到AP的request报文之后,会向AP发送一个DHCP Ack响应,该报文中携带的信息包括了AP的IP地址,租约期限,网关信息,以及DNS server IP等,以此确定租约的正式生效,就此完成DHCP的四步交互工作。

2、 AC发现机制(Discovery)

AC发现机制:

  1.AP使用AC发现机制来获知哪些AC是可用的,决定与最佳AC来建立CAPWAP的连接。(当然,AP的发现过程是可选的,如果在AP上已经静态配置了AC,那么就不需要完成AC的发现过程)。
  2.AP启动CAPWAP协议的发现机制,以单播或广播的形式发送发现请求报文试图关联AC,AC收到AP的discovery request以后,会发送一个单播discover response 给AP,AP可以通过discover response中所带的AC优先级或者AC上当前AP的个数等,确定与哪个AC建立会话。

3、 DTLS握手(可选)

DTLS握手:
AP根据此IP地址与AC协商,AP接收到响应消息后开始与AC建立CAPWAP隧道,这个阶段可以选择CAPWAP隧道是否采用DTLS加密传输UDP报文。
DTLS: Datagram Transport Layer Security(数据报传输层安全协议)

4、 Join(开始建立控制隧道)

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

5、Image Date(可选)
主要是固件升级阶段,根据Jion 阶段开始建立控制隧道,在Join response报文中会检查AP自身版本和AC携带的版本信息是否一致;不一致则进入Image Data阶段进行版本同步升级。

AP在软件版本更新完成后重新启动,重复进行AC发现、建立CAPWAP隧道、加入过程。(discovery—》join)

6、Configure

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

7、 Data Check (完成管理隧道建立)

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

8、Run(Data)建立数据隧道

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

9、Run(control):管理隧道维护

AP进入run状态后,同时发送echo request报文给AC,宣布建立好CAPWAP管理隧道并启动echo发送定时器和隧道检测超时定时器以检测管理隧道时候异常。
当AC收到echo request报文后,同样进入run状态,并回应echo response报文给AP,启动隧道超时定时器。
到AP收到echo response报文后,会重设检验隧道超时的定时器。
————————————————
版权声明:本文为CSDN博主「shelly0627」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_42353331/article/details/86504215

原文地址:https://www.cnblogs.com/dier-gaohe/p/14828467.html