H3C无线 | 故障排查篇 – AP掉线怎么查

H3C WLAN

我们先观察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处理。

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.

如下为AP掉线的原因，比较常见原因有：Failed to retransmit message、Processed join request in Run state、Neighbor dead timer expired，这些通常都是链路不稳定、丢包造成的。

（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字节的包：

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

如何判断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保护。