WlanNAT场景部署分析.docxVIP

Wlan NAT场景部署分析可能存在如下的NAT 应用场景：单AP 部署在NAT 之后，接入公网的AC场景。多AP 部署在NAT之后，接入公网AC的场景。AC 部署在NAT之后，AP部署公网场景。AC，AP均部署在NAT之后场景。AP 1AP 2AP 3NATAC10.0.0.210.0.0.310.0.0.410.0.0.120.0.0.120.0.0.2AP 5黄色代表控制通道，绿色代表数据通道场景2）为通用部署，1）看作2）的特例。AC 控制通道（端口号-5246），数据通道（端口号-5247）下面的分析均基于AC 需要支持的能力对于2）部署场景，属于NAT常见的应用。其他各场景均可适用2）中的方法。当前AC版本对于接入的AP的控制通道和数据通道报文的处理仅根据收到报文的源IP来作为关键字，这对于NAT后单AP的场景部署还是适用的，但对于NAT后存在多AP的部署来说，AC 收到来自各AP的报文的源IP完全相同，因此对于目前AC 3.2版本是无法满足此部署能力。解决办法：AC 提供探测接入AP 与AC 之间是否存在NAT 的能力，AC发现AP位于NAT之后，则需要告知AP开启数据链路的保活开关，以防止NAT上的capwap数据链路的会话信息老化掉。处理逻辑流程：Step 1：在控制通道，wtp join AC，利用“Capwap local IPv4 address”判定wtp 和AC 之间是否存在NATStep 2: 若存在NAT，AC 通过控制通道下发 “开启数据链路保活开关”给wtpStep3: wtp 在收到AC的change status response后开始发送数据通道保活报文给ACStep4:AC 收到数据通道保活报文后，刷新AC的保活时间，然后原报文返回AP对AC现有版本的影响： 1、AC AP管理模块：AC上AP管理模块创建ap 数据结构时，从join中提取Session ID，并记录经过NAT后的控制通道源IP+源Port。需要解决下面几个问题：当AC从数据通道收到AP的数据通道保活报文时，如何快速找到已经创建好的AP的数据实例？根据保活报文中的Sessin ID 做hash key当AC 从数据通道收到非保活(无Session ID)的数据报文时，如何快速找到已经创建好的AP的数据实例？用户态设计方案存在如下问题待讨论：调度模块 ----- 原有系统调度以AP 的IP为调度key，使得同AP的报文(数据通道和控制通道)调度到同一worker 线程。对于NAT存在的情况下，若依然以AP的IP为key进行调度的话则会使得同一NAT后的所有不同的Aps的报文处理也都调度到了同一worker线程了，这需要评估对性能的影响？若不以AP的IP为调度key，而是以AP’s IP + Port 为key进行调度的话，没法保证同一AP 的控制隧道报文与数据隧道的报文调度到同一worker线程 （同一AP的控制报文与数据报文调度到不同worker线程的影响是什么？会增大锁等待的资源开销，目前锁的力度大）同时若非NAT环境下采取AP的IP作为调度key，而NAT环境下采取AP的IP+ Port作为调度key，那么若AC部署的环境中存在某些AP在NAT之后，而某些AP则直接2层接入AC的话，那么调度模块在进行调度时还根本没法知道所收到的报文是否经过了NAT，从而调度模块也无法决定是采取哪种调度key-----结论：调度模块继续以AP’s IP 为key进行调度，使得同IP的报文始终在同一worker线程处理。优化系统原有每接口创建2个socket，修改为AC 进程仅创建2个通道的socket：数据通道socket和控制通道的socket。AC向AP发包的目的地由业务逻辑控制并传入（需要发包的业务根据自已的AP上记录的IP+Ctl_Port/Data_Port 信息传入Send_Packet接口）。AP 管理模块 ----- AC所管理的AP的实例的创建与查询。原有系统采取 AP’s IP作为key来进行处理的，这在无NAT的场景下可以很好的工作，但是对于存在NAT的情况下，还采取AP’s IP来做为key的话，就会导致AP管理张冠李戴的问题。那么对于存在NAT部署的情况下，AP管理的key 需要采取AP’s IP + Port,问题就来了，如何保证数据通道报文和控制通道报文处理时，根据AP’s IP + data_port或AP’s IP + ctrl_port 能够定位到同一个AP实例呢？(考虑对AP的实例建立3个hash冲突链：基于session_id/AP’s IP+data_port/ AP’s IP+ctrl_port 实现方式，从3个不同维度来进行AP实例的查找，见下图：)，这需要修改原有的一系列与AP管理的接