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