H3C AC/AP常用命令 - 我的学习小站

AC查看客户端RSSI

# 查看某个客户端rssi
dis wlan client mac-addr xx verbose | in RSSI
# 查看所有客户端rssi
dis wlan client verbose | in RSSI

查看ap的地址

display wlan ap all addres

查看ap信息

dis wlan ap all ver
# 查看某个ap的信息
display wlan ap name APNAME verbose

AP LED灯控制（调整）

wlan ap APNAME 
led-mode

AC开启telnet登录AP

提示：The connection was closed by the remote host!
如何开启

[AC] probe
[AC] wlan ap-execute all exec-console enable

# 后续关闭使用disable即可

开启后默认ap登录密码为：h3capadmin

查看AP空口利用率

进入ap后先sys,然后probe.才能运行下面的命令查看

<AP>sys
[AP]probe

查看信道利用率，判断空口繁忙情况
1. 命令：display ar5drv 1/2（单频AP则只有一个射频口，双频AP则1表示5G视频口，2表示2.4G射频口） channelbusy
2. [AP-probe]display ar5drv 1 channelbusy（或者用这个display ar5drv 2channelbusy查看2.4G频率的空口）

例如：通过命令查看，AP的5G射频口空口目前处于正常状态，当CtlBusy高于60时，则表示空口繁忙。如果ap没什么人连接也出现这么高的一般可以从AP信道方面着手修改每个AP让其处于不同的信道以减少信号干扰造成的空口繁忙。

查看AP空口统计情况，判断空口质量。
1. 命令：display ar5drv 1/2（单频AP则只有一个射频口，双频AP则1表示5G视频口，2表示2.4G射频口） statistics

[AP-probe]display ar5drv 1 statistics

说明：

每个Radio有4个普通发送队列和1个紧急发送队列，通常数据报文都走1号队列。通常我们主要关注1号队列。
TxDiscardFrame表示此队列丢弃的报文总数，包括发送失败和队列溢出的报文。
TxDiscardFrame/ TxUcastFrameCnt表示丢包率，如果超过3%的时候就应当警惕了。
RadioResetOnErr意味着Radio芯片复位，会导致丢包，正常情况下不应当出现这个错误。
BeaconBusyCnt和BeaconErrCnt表示AP发送beacon的繁忙度及错误统计，此处可以看出空口的质量，如果出现增长则会出现丢包现象。

空口不合理：

RxBusy>>TxBusy，RxBusy+TxBusy总和达到80以上。
例如RxBusy平均80，TxBusy小于5。此种情况属于典型的WLAN内部干扰，即同频AP之间互相可见，竞争一个信道介质，导致空口利用率RX方向异常偏高。解决的办法包括合理的信道规划、功率规划、关闭RRM低速率、关闭广播Probe应答和调大Beacon帧间隔、二层隔离等。
RxBusy和TxBusy相差不多，RxBusy+TxBusy总和达到80以上。
例如RxBusy平均50，TxBusy平均40左右。此种情况下一般体验尚可，如果仍有终端上网慢，最有可能的原因是无线CPE数量过多，或者部分CPE业务量较大，占用了过多带宽。建议开启终端限速或者扩容增加AP解决。
RxBusy<<TxBusy，RxBusy+TxBusy总和达到80以上。
例如TxBusy平均80，RxBusy小于5。此种情况说明AP下行方向发包受阻。在室外CPE应用中较为常见。发生这类故障时，一般伴随着client verbose信息中TX协商速率低，即AP发送给CPE的帧经常丢失，进而降速重传，最后导致AP发送的帧都是低速帧。低速帧会大量消耗空口资源，进而导致CPE体验集体变差。遇到这种情况，可以先观察该AP下的CPE信号强度，如果RSSI都在30以上，则可以尝试在AP侧通过强制TX高速率解决，11n情况下建议尝试MCS 13。
还有一种导致空口体验差的情况是存在非WLAN干扰，但非WLAN干扰存在的证据不明显。从空口利用率上看，当CtlBusy大大超出RxBusy和TxBusy总和时，可以认为是非WLAN干扰存在的一个证据。常见的非WLAN干扰源有如无线摄像头、靠的太近的3G/4G基站等（室外AP要求与3/4G基站天线距离保持在5米以上）。当怀疑存在非WLAN干扰时，可以用排除法来证明。即先排除周边的WLAN干扰源，比如关闭周边AP，并使用omnipeek抓包发现无法抓取WiFi报文。如果此种情况下仍然存在CtlBusy异常高，可以作为外部干扰存在的证据。