某局点V5 AC插卡无法注册新增AP问题处理

某局点使用无线控制器AC 插卡LSQ1WCMD0配合新增上线AP4330-ACN FIT产品，设备简单网络拓扑直连。正常开局，无特殊配置。

该局点客户因为业务需要需要扩容一批新采购WA4330-ACN FIT设备，AC插卡版本为V5最新R2509P61。但是发现所有的WA4330设备全部无法上线，部分WA4330在注册过程中通过命令Display wlan ap all显示处于JA状态，更多是Idle状态。但是而现场使用的WA2620-AGN则一直在线稳定运行1000多台，检查License和AP模版序列号等基本问题均为正常无低级配置失误。

该问题先进入AP端分析，尝试通过静态指定AC地址，能ping通但是AP上一直提示：

%Sep  1 13:16:21:763 2017 WA4330-ACN LWPC/4/LWPC_UDISC_NO_AC_RESPOND: 

 No AC has responded to the Unicast Discovery request.

通过Debug也显示AP一直在发送Lwapp的Discovery request报文，并且AC也回应了Response，同时Join流程也是完整的，如：

*Sep  1 13:49:24:636 2017 WA4330-ACN LWPC/7/Pkt_Send: 

 Sent Discovery Request to 1.1.1.1 port 12223 (Length: 179)

*Sep  1 13:49:25:936 2017 WA4330-ACN LWPC/7/Pkt_Rcvd: 

 Received Discovery Response from 1.1.1.1 port 12223 (Length: 74)

 *Sep  1 13:49:27:936 2017 WA4330-ACN LWPC/7/Pkt_Send: 

 Sent Join Request to 1.1.1.1 port 12223 (Length: 172)

 *Sep  1 13:49:29:199 2017 WA4330-ACN LWPC/7/Pkt_Rcvd: 

 Received Join Response from 1.1.1.1 port 12223 (Length: 71)

*Sep  1 13:49:30:271 2017 WA4330-ACN LWPC/7/Pkt_Rcvd: 

 Received Join Confirm from 1.1.1.1 port 12223 (Length: 45)

正常的Lwapp流程来说在这之后是AP发起的Configuration Request，同时需要AC回应，但是在AP的Debug显示并没有AC回应的报文，如：

*Sep  1 13:49:32:591 2017 WA4330-ACN LWPC/7/Pkt_Send: 

 Sent Configuration Request to 1.1.1.1 port 12223 (Length: 1837)

在这之后没有了报文交互，直到AP开始发送Capwap流程（这是V5 AP的处理机制，当同时会发起Lwapp和Capwap流程的报文），和Lwapp失效后重新发起新的Lwapp。

此时分析思路在于为何Configuration Request报文后会中断流程，是中间链路丢包了？是AC处理出错了？还是AC返回的信息被AP弄丢了？

当我们再次检查AC的配置时发现AC的内联口存在QOS策略，如：

acl number 3500 name lan-in

 rule 0 permit tcp destination-port eq echo

 rule 5 permit tcp destination-port eq 135

 rule 10 permit tcp destination-port eq 136

 rule 15 permit tcp destination-port eq 137

 rule 20 permit tcp destination-port eq 138

 rule 25 permit tcp destination-port eq 139

 rule 30 permit tcp destination-port eq 389

 rule 35 permit tcp destination-port eq 445

 rule 40 permit tcp destination-port eq 4444

 rule 45 permit udp destination-port eq tftp

 rule 50 permit udp destination-port eq 135

 rule 55 permit udp destination-port eq netbios-ns

 rule 60 permit udp destination-port eq netbios-dgm

 rule 65 permit udp destination-port eq netbios-ssn

 rule 70 permit udp destination-port eq 389

 rule 75 permit udp destination-port eq 445

 rule 80 permit udp destination-port eq 1433

 rule 85 permit udp destination-port eq 1434

traffic classifier 3500 operator and

 if-match acl 3500

#

traffic behavior 3500

 filter deny

#

qos policy 3500

 classifier 3500 behavior 3500

随后尝试将AC内联口取消QOS策略，发现以前不能上线的AP都开始上线注册了。为了验证确实是QOS配置引起的，又将QOS配置增加，然后逐一进行删减Rule条目，发现当QOS策略中仅存一条Udp端口的配置，比如：

acl number 3001

rule 72 permit udp destination-port eq 333

且替换其他Udp端口都能复现故障。随后返查之前的AP与AC的链路抓包发现Configuration Request报文为一个1837大于1500字节的大包，在网络中会被分片处理，因此网络中会将报文分成一个带ag的1518字节报文和一个小报文，如图：

在图中第二个403字节的报文中Ip字段之后有大量的空白留0的字节，这部分内容，因为AC内联口的QOS处理机制存在问题导致Acl规则给匹配上了，因为大量留0空白导致被匹配成了拒绝的端口号。后来Debug ip报文也发现AC没有收到第二个小的报文。这样AP发送的Configuration Reques报文就因为分片导致被QOS误判小报文给拒绝导致AC无法后续的Configuration Response处理。

在该网络中将QOS配置删除迁移到与AC互联的交换机内敛口上去生效，因为在AC内联口配置QOS同样会将AC插卡开启的Fpga硬件快转功能给强制生效成软件转发模式。综合来讲QOS该功能迁移网络中的其他位置进行处理。