AP掉线怎么查
1、 发现AP掉线了第一步怎么查？
我们先观察AP是因为重启掉线，还是未重启掉线。那么如何判断呢？
(1) 通过在AC上查看display wlan ap name xxx verbose，观察system up time和online time，如果一致就说明最近AP有频繁重启，需要进一步查看重启原因；若不一致，就需要关注tunnel down reason字段，查看具体的掉线原因。
如果AP是因为重启而掉线，那我们就需要关注具体的原因，可通过如下字段查看：
<AC>dis wlan ap name ap1 verbose
AP name : ap1
Online time : 16 days 11 hours 0 minutes 16 seconds
System uptime: 16 days 9 hours 34 minutes 34 seconds
Tunnel down reason : Processed join request in Run state
Last reboot reason: Power on
(2) 确认AP发生了重启怎么办？
针对AP的重启原因进行进一步分析：
→ power on：关注AP上行POE交换机端口是否有断电情况，如果是个别AP发生的，检查一下网线长度和网线质量以及POE交换机功率，现场有条件的话用本地电源或POE模块供电看是否仍然出现power on重启。
→ Kernel exception soft reboot：如存在异常重启可联系400处理。
2、如何查看AP掉线原因
AC侧：
[AC] display wlan ap statistics tunnel-down-record
AP name AP ID Tunnel down at Tunnel Down Reason
ap1 2 08-30/14:56:00 Processed join request in Run state
AP侧：
[AP] display logbuffer
%Mar 30 15:58:17:774 2021 LONGI-A1-10F-AP13 CWC/4/CWC_AP_DOWN: Master CAPwap tunnel to AC 172.30.230.3 went down. Reason: Deleted AP IP address.
3、常见AP的掉线原因
如下为AP掉线的原因，比较常见原因有：Failed to retransmit message、Processed join request in Run state、Neighbor dead timer expired，这些通常都是链路不稳定、丢包造成的。
4、如何排查AC—AP的链路是否存在问题？
（1）关注AP丢失的echo报文数目
搜集display wlan ap all verbose查看AP明细信息，发现统计信息中掉线AP显示Lost Echo responses数目，结合Capwap隧道的机制来看，AP发送Echo心跳报文后，控制器需回应Ack报文，AP侧接收不到Echo回应报文时，超过三个就会认为链路存在问题。若Lost echo responses数目较多，则需关注AC-AP链路问题。
（2）查看AP链路检测参数
通过wlan ap-link-test命令可以检测AC与AP之间链路是否存在丢包情况：
[AC]probe
[AC-probe]wlan ap-link-test 192.168.238.7
Transmitted packets : 1
Received packets : 1
Packet loss : 0.00%
Transmitted packet length : 128
Received packet Length : 128
Out-of-order packets : 0
Min RTT(ms) : 1
Average RTT(ms) : 1
Max RTT(ms) : 1
AP last reboot reason : Power on
AP up time : 1 weeks, 6 days, 8 hours, 42 minutes
（3）关注AP有线口链路质量
[AP]display interface
Input: 0 input errors, 0 runts, 0 giants, - throttles
0 CRC, - frame, 0 overruns, 0 aborts
- ignored, - parity errors
CRC：链路质量检测，一般接口存在CRC的话表明该接口的链路质量不好，需要关注计数是否在增长。
解决方法：如果持续增长的话需要更换链路（网线）等操作进行观察 ,并且查看上行交换机接口有无错误包
Overruns：如果AP有线口广播和组播的流量远远大于单播数量，该参数持续增长，则需要关注。
解决方法：精简AP有线口vlan，配置二层隔离，端口隔离。
（4）AC和AP是否跨公网
需保证公网/专网链路的稳定，可以通过ping大包测试链路稳定性。例如，长ping 1000个1500字节的包：
<AC>ping -s 1500 -c 1000 192.168.238.7
Ping 192.168.238.7 (192.168.238.7): 1500 data bytes, press CTRL_C to break
1500 bytes from 192.168.238.7: icmp_seq=0 ttl=255 time=1.069 ms
1500 bytes from 192.168.238.7: icmp_seq=1 ttl=255 time=0.975 ms
1500 bytes from 192.168.238.7: icmp_seq=2 ttl=255 time=1.015 ms
5、AP是否存在批量掉线
如何判断AP存在批量掉线？
通过命令查看AP隧道断的时间，是否都在同一时刻掉线：
[AP] display wlan ap statistics tunnel-down-record
AP name AP ID Tunnel down at Tunnel Down Reason
ap1 1 09-01/15:26:28 Processed join request in Run state
ap2 2 09-01/15:26:28 Processed join request in Run state
ap3 3 09-01/15:26:28 Processed join request in Run state
ap4 4 09-01/15:26:28 Processed join request in Run state
ap4 5 09-01/15:26:28 Failed to retransmit message
若存在AP批量掉线的情况，需重点关注整个网络：
（1）AP有线口的广播和组播报文是否过大。（例如：广播和组播是单播的几倍）
解决方法：精简AP放通的vlan；本地转发上行交换机端口做端口隔离；
（2）AP上行接入交换机是否存在接口震荡，若接口产生STP TC报文，核心下联所有开启了STP的设备收到TC报文后刷新ARP表项，发出大量ARP请求报文，如果核心和AC互联的接口放通了所有vlan，AC就会收到大量ARP报文，导致CPU升高，AP掉线。
解决方法：核心和AC之间的链路只放通必要的vlan，AP上行POE交换机配置边缘端口加BPDU保护。
无线小贴士
信道：传输信息的通道，也就是频段，是以无线信号作为传输载体的数据信号传送通道。按照规定，我国使用的2.4G信道有13个，即1-13信道；5G信道有36, 40, 44, 48, 52, 56, 60, 64, 149, 153, 157,161, 165
底噪：顾名思义就是背景噪声的定义值。在无线环境 芯片有缺省的底噪2.4G和5G各不相同。低于底噪的就被AP认为是噪声不会再进行处理分析，高于底噪的就认为是有效信息 会尽可能地加入硬件收取处理。
,
