组网及说明
ADCampus组网，AC旁挂核心，本地转发
告警信息
无
问题描述
【故障现象】有反馈称部分AP下终端无法接入5 GHz射频，会接到更远端的AP上，且接入后无法访问互联网。
接入2.4 GHz射频可以正常使用，同一AP的5 GHz和2.4 GHz都绑定同一个服务模板，业务vlan相同，授权ACL下发也完全相同。
过程分析
【现场排查】根据故障现象描述，首先有如下几种可能：
1. 部分AP的5 GHz射频没有发送Beacon帧，导致终端搜到是就是远端AP的5 GHz射频放出的信号，
这个有几种方法可以查看：
① 查看AP的5 GHz射频是否有发Beacon帧，这个在AP的Probe视图下看Beacon帧是否随着时间有增长：
[AP-probe]视图
display ar5drv 1 statistics
Beacon statistics
BeaconIntCnt: 1562 // 看这个参数是否有增长
BeaconBusyCnt : 0
BeaconErrCnt: 0
WA6600系列AP的芯片不同，硬件驱动不同，查看BeaconIntCnt需要使用如下命令：
===============display ar5drv 1 bss all===============
[BssTable Info]:
BasicMacAddr(4873-97cb-ab00) BssTblAddr(0xd6100000) Used(1)/Total(16)
-----------------------------------------------
Bss BssIdx(0) MacAddr(4873-97cb-ab00) IsSREnable:0 Status(Used)
[Beacon Info]:
TxBcnCnt(1168) IsDtim(Y)## 看这个
② 更简单的方法，使用PC端的Inssider软件或者手机端的Cloudnet APP扫描信号，看是否有这个AP对应放出的5 GHz的BSSID。
根据上述排查发现，这些故障AP是可以正常放出信号的，排除这种可能。
2. 终端接入AP的5 GHz射频异常：工程师为故障AP的5 GHz射频绑定了一个单独的测试服务模板，配置与故障服务模板完全一致，发现终端同样无法接入，且终端尝试接入的时候关联不上，即在AC侧通过：display wlan client mac-address H-H-H查看没有终端的表项建立，这说明是终端关联失败，而非后面获取IP地址有问题。
对此，在AP和AC上分别开启debug以确认终端的关联报文处理的异常位点 。
AP上开启，目的在于判断AP是否收到了终端侧发来的auth request或者association request请求，并且是否上送了AC以及是否收到AC侧的应答。
[AP-Probe] debugging ar5drv 1 packet all mac HHHH-HHHH-HHHH verbose// 注意：这里的 “HHHH-HHHH-HHHH” 是测试终端的MAC地址
[AP-Probe] debugging system internal wlan forward packet content HH:HH:HH:HH:HH:HH
<AP> debugging wlan forward error
分析方法参考案例：
https://zhiliao.h3c.com/theme/details/216257
https://zhiliao.h3c.com/theme/details/202463
解析软件参考：
https://zhiliao.h3c.com/Tool/details/5249
通过debug分析发现，AP接收到了终端发送的auth request请求，并且上送给AC，但是没有收到来自AC侧的回复。
随即，在AC上开启：
<AC> debugging wlan forward packet
<AC> debugging wlan forward error
<AC> debugging wlan client mac-address HHHH-HHHH-HHHH
通过debug分析发现，AC收到了AP通过CAPWAP数据隧道（5247端口）上送的对应终端的auth request报文，但却似乎没有建立表项，这说明AC在处理该auth request报文时产生了异常。
通过多方排查，发现由于该局点AC版本较老，是已知软件问题引起的ACL下发进程挂住，进而导致处理终端接入的stamgrd进程也挂住，目前问题还不算非常严重，而随着时间的持续，最终可能发展为所有AP的所有射频下的无线服务模板，终端都无法正常关联。
于是当晚安排了窗口期完成AC的整体升级。
升级后终端可以正常接入所有AP的5 GHz和2.4 GHz射频了，但是却发现一个奇怪的问题：
· 终端接入AP的5 GHz射频，不会自动弹出portal页面；
· 终端接入同一AP的2.4 GHz射频，可以自动弹出portal页面，认证后可以正常上网。
难道之前的问题没有解决？毕竟终端接入5 GHz和2.4 GHz时是同一个服务模板，且业务vlan和授权ACL下发都是一样的
事实并非如此，
顺着正常的思路，我们首先排查终端接入后不会自动弹出portal页面的问题，
一般而言，终端接入后自动弹出portal页面，需要终端访问DNS是通的，且该DNS一般必须是可以解析终端自动探测域名的公网DNS地址。
查看AC上的free-rule配置都是正确的，而且5 GHz和2.4 GHz射频绑定的服务模板采用的是同一套portal认证规则，认证服务器也完全相同，因此也排除了这些故障。
进一步地，让终端分别接入5 GHz（此时由于终端可以正常关联且获取IP地址，因此在AC上是有表项的）和2.4 GHz射频，然后查看：
<AC> display mac-authentication connection user-mac H-H-H
<AC> display wlan client mac-address H-H-H verbose
这两个命令查看终端获取的授权vlan和授权acl，连接5 GHz射频和2.4 GHz射频上绑定的同一个服务模板时也是完全相同的，这说明也可以排除授权vlan或者授权acl下发异常的问题。
下一步，让终端连接5 GHz和2.4 GHz射频时分别ping内网的free-rule地址和公网的free-rule地址，
发现这样一个现象：终端连接5 GHz射频同一服务模板时，ping内网free-rule都可以通，即使是新增的，而ping公网DNS完全不通，
但是终端连接2.4 GHz射频时，ping内网和公网free-rule地址都可以通。
难道还是AP自身的问题？事实并非如此，
由于是集中转发，工程师在AC---核心的端口进行了流统，发现终端连接5 GHz射频ping外网不通的根本原因是：
AC将终端的icmp报文上送给核心，核心也上送了上层的ACG设备，但是ACG设备并未给核心回包。
这说明问题出在了上层的ACG及以上设备上，最终排查结果是ACG的负载分担配置存在问题。
解决方法
【解决方案】调整ACG的负载分担配置，完成配置调整后终端使用完全正常。
【问题反思】
1. 在工程师第二天与客户的沟通中得知，其实该局点反馈的无线问题现象实质是：
① 终端连接5 GHz射频无法访问公网；
② 终端在部分AP下5 GHz和2.4 GHz射频接入都有异常。
但由于客户IT没有正确的记录和汇总这些信息，导致工程师一开始在排查方向上走了些许弯路。
因此，在故障发生时，准确而全面地记录和汇总故障信息对于故障的排查是至关重要的。
2. 本次的故障是一环套一环，虽然通过AC的版本升级解决了终端无法关联的故障，但是后面终端连接5 GHz无法上网，但连接2.4 GHz却能上网的异常现象极易让人将后面的第二个故障与第一个产生联系，进而影响判断。
因此遇到故障问题时，需要有理性的头脑和冷静的判断，同时也有善于运用多种排查方法和思路来找出真正的故障原因。