当前位置:首页>弱电技术>网络通信>华为无线AP终端网络慢什么原因怎么处理?

华为无线AP终端网络慢什么原因怎么处理?

现象描述

无线终端存在网络延迟、卡顿等网络慢的现象。

可能原因

确认问题发生在有线侧还是无线侧:

无线侧:

  • VLAN配置不合理。
  • AP信道利用率不正常。
  • AP报文缓存资源以及发包队列不正常。
  • AP信号强度不正常。
  • AP内部存在丢包。
  • 有低速率用户做大流量业务。

有线侧:

  • 中间网络存在ARP丢包。
  • 有线网络中存在环路。
  • 设备CPU利用率不正常。
  • AP的IP地址冲突。
  • 网线有问题。

原因检查操作步骤

华为无线AP终端网络慢什么原因怎么处理?

1、通过ping包确定故障范围是否在网关以下网络

在处理故障之前,通过ping包的方式来确认故障的范围,从而明确故障排查的范围。

# 从STA分别ping网关和外网地址,观察ping包的情况,从而确定故障范围。

  • 如果从STA ping网关出现不稳定的情况,如频繁丢包、延迟波动等,说明故障出现在网关以下的网络中。
  • 如果从STA ping网关正常,但是ping外网地址出现不稳定的情况,说明故障出现在网关以上的网络中。

如果Ping包过程中出现丢包的情况,可以参考如下内容进行排查:

  • 有线侧丢包:终端用户Ping不通网关(有线侧丢包)
  • 无线侧丢包:STA丢包(无线侧丢包)

2、检查AP与网关之间有线网络是否正常

# 从网关ping连接AP的交换机,观察ping包情况。

  • 如果网关与交换机之间ping包稳定,说明网关与交换机之间有线网络正常。请从3开始排查无线侧网络问题。
  • 如果网关与交换机之间ping包不稳定,说明需要排查网关与交换机之间有线网络的故障。请从13开始排查有线侧网络问题。

如果无法从网关ping交换机(如交换机作为纯二层设备),可以从AC ping AP,也能一定程度反映有线网络是否有问题。

3、检查业务VLAN和管理VLAN配置是否合理

管理VLAN和业务VLAN在不同转发方式下的配置推荐如下表所示。

表1 管理VLAN和业务VLAN在不同转发方式下的配置推荐

转发方式

业务VLAN

管理VLAN

配置影响

配置推荐

直接转发

1

100

用户业务报文打上管理VLAN,导致业务混乱。

不推荐

100

1

可能会受VLAN1广播域过大、广播泛洪的影响,导致网络阻塞,影响用户体验。

不推荐

1

1

可能会受VLAN1广播域过大、广播泛洪的影响,导致网络阻塞,影响用户体验。

不推荐

100

100

数据转发异常。

不推荐

100

50

标准推荐配置。

推荐

隧道转发

1

100

可能会受VLAN1广播域过大、广播泛洪的影响,导致网络阻塞,影响用户体验。

不推荐

100

1

可能会受VLAN1广播域过大、广播泛洪的影响,导致网络阻塞,影响用户体验。

不推荐

1

1

MAC漂移,导致数据转发异常。

不推荐

100

100

MAC漂移,导致数据转发异常。

不推荐

100

50

标准推荐配置。

推荐

a、执行命令display vlan brief查看VLAN ID与端口的对应关系。

 display vlan brief
U:Up;D:Down;TG:Tagged;UT:Untagged;

VID Name Status Ports
--------------------------------------------------------------------------------
1 enable UT: Eth-Trunk60(D) Eth-Trunk62(D) Eth-Trunk63(D)
GE0/0/1(U) GE0/0/2(D) GE0/0/3(D) GE0/0/4(D)
GE0/0/5(D) GE0/0/6(D) GE0/0/7(D) GE0/0/8(D)
GE0/0/9(D) GE0/0/10(D) GE0/0/11(D)
GE0/0/12(D) GE0/0/13(D) GE0/0/14(D)
GE0/0/15(D) GE0/0/16(D) GE0/0/17(D)
GE0/0/18(D) GE0/0/19(D) GE0/0/20(D)
GE0/0/21(D) GE0/0/22(D) GE0/0/23(D)
GE0/0/24(U) XGE0/0/1(D) XGE0/0/2(D)
10 enable
11 enable

b、执行命令interface GigabitEthernet 0/0/x进入端口,检查各接口下管理VLAN和业务VLAN的配置是否合理。

如果管理VLAN和业务VLAN的配置不合理,如同时使用VLAN1作为业务VLAN和管理VLAN,请参考表1进行配置。

 system-view
[AC] interface GigabitEthernet 0/0/5
[AC-GigabitEthernet0/0/5] display this
#
interface GigabitEthernet0/0/5
port link-type trunk
port trunk pvid vlan 100
port trunk allow-pass vlan 100
#
return

4、检查AP的CPU利用率是否正常

如果设备的CPU利用率一直很高(超过80%),会导致各种业务异常,出现丢包、网络延迟大等现象。

# 在AP上查看AP的CPU利用率,确认AP的CPU利用率是否正常。

 system-view
[AP] diagnose
[AP-diagnose] display cpu-usage
CPU Usage Stat. Cycle: 10 (Second)
usr: 1.8% sys: 0.9% irq: 0.0% softIrq: 0.9%
CPU Usage: 3.6% Max: 80.1%
CPU Usage Stat. Time : 2005-07-27 19:12:04
CPU Usage Max. Time : 2005-07-27 19:02:40

造成设备CPU利用率高的原因有很多,请参考CPU占用率高处理。

5、检查AP的信道利用率是否正常

WLAN网络中所有终端共享带宽,相互竞争带宽资源,如果周围环境中无线终端很多,或网络中有很多广播、组播报文(组播、广播报文都是低速率发送,消耗空口资源多),相互抢占信道的情况就会很严重,最终导致信道利用率高,无线网络不稳定,出现ping包延迟大、丢包等情况。

  • AC+FIT AP场景

# 在AC上执行命令display radio all,查看AP所在信道的信道利用率,确认AP的信道利用率是否正常。

对于AC+中心AP+RU的场景,在AC上查询RU的信道利用率时,需要在WLAN视图下执行命令ap data-collection enable开启RU数据缓存功能。

 display radio all
CH/BW:Channel/Bandwidth
CE:Current EIRP (dBm)
ME:Max EIRP (dBm)
CU:Channel utilization
ST:Status
WM:Working Mode (normal/monitor/monitor dual-band-scan/monitor proxy dual-band-scan)
------------------------------------------------------------------------------------
AP ID Name RfID Band Type ST CH/BW CE/ME STA CU WM
------------------------------------------------------------------------------------
0 60de-4474-9640 0 2.4G bgn on 6/20M 24/24 0 55% normal
0 60de-4474-9640 1 5G an on 56/20M 25/25 0 3% normal
------------------------------------------------------------------------------------
Total:2
  • FAT AP场景

# 执行命令display ap traffic statistics wireless radio radio-id,查看AP所在信道的信道利用率,确认AP的信道利用率是否正常。

对于FAT中心AP+RU的场景,在FAT中心AP上查询RU的信道利用率时,需要在WLAN视图下执行命令ap data-collection enable开启RU数据缓存功能。

<Huawei> display ap traffic statistics wireless radio 0
-----------------------------------------------------------------------
...
Wireless channel utilization(%)                       :70
...
-----------------------------------------------------------------------

一般情况下,如果信道利用率超过60%,则可能会对用户造成网络波动。导致信道利用率高的原因和解决方法如下:

  • 无线网络环境干扰严重,此时,需要对AP的信道进行合理的规划,降低干扰。可以手动将信道切换至信道利用率低的信道,或者在无业务影响时进行调优操作。
  • 网络中组播、广播报文很多,此时,需要查看网络中的组播、广播报文的情况,具体请参见8。

6、检查AP系统报文缓存资源的剩余可用buffer资源是否正常

AP的转发模块和Wi-Fi收发包模块共用一个buffer资源池,如果buffer资源不足,会出现丢包的情况。

# 在AP上执行命令display memory-pool info查看AP系统报文缓存资源,确认剩余可用buffer资源是否正常。

<AP> system-view 
[AP] diagnose 
[AP-diagnose] display memory-pool info 
... 
Show PBuf Buffer Pool info : 
============== BufMan Info =================== 
BufMan Shm Addr[0x42600000], Shm Size[0x1e00000], L1 Num[64], L1 in use[6] 
Buffer Num[13358], each buffer has [0x900] bytes 
L1 stack info: 
        Offset = 0x130, L2Offset = 0xd728, num = 128, SP = 38 
L1 stack info: 
        Offset = 0x344, L2Offset = 0xd728, num = 0, SP = 0 
L1 stack info: 
        Offset = 0x358, L2Offset = 0xd728, num = 4, SP = 0 
L1 stack info: 
        Offset = 0x37c, L2Offset = 0xd728, num = 16, SP = 0 
L1 stack info: 
        Offset = 0x3d0, L2Offset = 0xd728, num = 16, SP = 0 
L1 stack info: 
        Offset = 0x424, L2Offset = 0xd728, num = 0, SP = 0 
L2 stack info: 
        Offset = 0xd728, len = 0x4000 
        front = 13014, rear = 2630, available = 6000

如果AP剩余可用的buffer资源在100以下,则认为AP的buffer资源不足,会出现丢包的情况。此时,请联系技术支持人员寻求技术支持。

7、检查发包队列是否存在拥塞或者被占满的情况

报文到达AP Wi-Fi驱动模块后,会先缓存在队列中等待调度发送,如果Wi-Fi驱动模块缓存队列被占满或者拥塞严重,则会出现丢包、延迟大的情况。

AP Wi-Fi驱动模块的缓存队列出现拥塞,肯定是被某些终端占用了,常见的如终端信号弱、离开Wi-Fi覆盖区域等场景,都会导致发给此终端的报文无法顺利发出,而堵塞在AP的缓存队列中。

a、在AP上查看AP的Wi-Fi驱动模块发包队列情况,确认发包队列是否存在拥塞或者被占满的情况。

  • 对于仅支持11n类型的AP,如AP6x10xN,查看AP的Wi-Fi驱动模块发包队列情况。

V200R006C10及之前版本命令行:display interface radio radio-id txq-buf

V200R006C20及之后版本命令行:display wifi txq-buf radio radio-id 。以此为例。

<AP> system-view 
[AP] diagnose 
[AP-diagnose] display wifi txq-buf radio 0

[txqbuf]
  ath_softc free buf:1024
  tx queue depth    :1024
  txq 0:buf_used = 0           minfree = 48          aggr_depth = 0           axq_depth = 0
  txq 1:buf_used = 0           minfree = 32          aggr_depth = 0           axq_depth = 0
  txq 2:buf_used = 0           minfree = 16          aggr_depth = 0           axq_depth = 0
  txq 3:buf_used = 0           minfree = 0           aggr_depth = 0           axq_depth = 0
  txq 4:buf_used = 0           minfree = 0           aggr_depth = 0           axq_depth = 0
  txq 5:buf_used = 0           minfree = 0           aggr_depth = 0           axq_depth = 0
  txq 6:buf_used = 0           minfree = 0           aggr_depth = 0           axq_depth = 0
  txq 7:buf_used = 0           minfree = 0           aggr_depth = 0           axq_depth = 0
  txq 8:buf_used = 0           minfree = 48          aggr_depth = 0           axq_depth = 0
  txq 9:buf_used = 0           minfree = 0           aggr_depth = 0
  • 对于仅支持11ac类型的AP,如AP5x30xN,查看AP的Wi-Fi驱动模块发包队列情况。

V200R006C10版本命令行:debugging wlandrv setplv printlevel_num

V200R006C20版本命令行:debugging wifi trace-print level printlevel_num

V200R007及之后版本命令行:display wifi txq-buf radio radio-id。以此为例。

<AP> system-view 
[AP] diagnose
[AP-diagnose] display wifi txq-buf radio 1
[Txqbuf]
  Host tx queue depth:2500
[Frames queued to hwq]
  --------------------------------------
  Q0  Q1  Q2  Q3  Q4  Q5  Q6  Q7  Q8  Q9
  1   0   0   0   0   0   0   0   0   0
  --------------------------------------
[Tid queue stats]
  SW queue stats <---> HW queue stats
  ------------------------------
  TID 0     0               0
  TID 1     0               0
  TID 2     0               0
  TID 3     0               0
  TID 4     0               0
  TID 5     0               0
  TID 6     0               0
  TID 7     0               0
  TID 8     0               0
  TID 9     0               0
  TID 10    0               0
  TID 11    0               0
  TID 12    0               0
  TID 13    0               0
  TID 14    0               0
  TID 15    0               0
  TID 16    0               0
  TID 17    0               0
  TID 18    0               1
  TID 19    0               0
  ------------------------------
[Prefetch Tx queue stats]
  ------------------------------
  TID 0     0
  TID 1     0
  TID 2     0
  TID 3     0
  TID 4     0
  TID 5     0
  TID 6     0
  TID 7     0
  ------------------------------
  • 对于支持11ax类型的AP,如AirEngine8760-X1-PRO,查看AP的Wi-Fi驱动模块发包队列情况。

V200R019C10版本命令行:display lmac txq-buf radio radio-id

[AP-diagnose] display lmac txq-buf radio 1
Hardware tx queue statistic:
------------------------------------------------------------------
        Txq0  Txq1  Txq2   Txq3   Txq4   Txq5   Txq6   Txq7
Total   0     0     0      0      0      0      0      0
------------------------------------------------------------------
        Txq8  Txq9  Txq10  Txq11  Txq12  Txq13  Txq14  Txq15
Total   0     0     0      0      0      0      0      0
------------------------------------------------------------------

Software tid queue statistic:
------------------------------------------------------------------
        Tid0   Tid1   Tid2   Tid3   Tid4
Total   0      0      0      0      0
------------------------------------------------------------------
        Tid5   Tid6   Tid7   Tid8   Tid9
Total   0      0      0      0      0
------------------------------------------------------------------

Qos queue statistic:
------------------------------------------------------------------
       BE     BK     VI     VO
Total  0      0      0      0
------------------------------------------------------------------

一般情况下,Wi-Fi驱动模块的缓存队列基本处于0占用的状态,不会持续处于被占用的情况,所以如果上述显示信息中的字段数字维持在100以上,则说明队列出现了拥塞的情况。此时,请联系技术支持人员寻求技术支持。

b、如果AP Wi-Fi驱动模块的缓存队列出现拥塞,查看每个终端占用队列的具体情况。

V200R006C10及之前版本命令行:display sta-statistics radio radio-id list。

V200R006C20~V200R019C00版本命令行:display wifi sta-statistics radio radio-id。以此为例。

<AP> system-view 
[AP] diagnose 
[AP-diagnose] display wifi sta-statistics radio 1 
ADDR           AID CHAN TXRATE RXRATE RSSI IDLE TXSEQ RXSEQ SKIP   NORML  CAPS ACAPS ERP STATE    HTCAPS 
9cfc-013a-a9d3 1   149  78M    78M    56   0    0     65535 0      0      E          0   1400001b AWQ 
--------------------------STA:8038-bc1b-8850 Statistics------------------------- 
[NorMalPS] 
  sendPktAsNiPsUmac  : 0 
 
[RateFind Lastest Info] 
  GoodPut(kbps)      : 0                  Per          : 0% 
  RateCode           : 0x0 
 
--------------------------STA:9cfc-013a-a9d3 Statistics------------------------- 
[NorMalPS] 
  sendPktAsNiPsUmac  : 0 
  
[ap-yuan-diagnose] 
[RateFind Lastest Info] 
  GoodPut(kbps)      : 70492              Per          : 0% 
  RateCode           : 0xc8 
 
---------------------------STA:8038-bc1b-8850 TidInfo--------------------------- 
[tidno: 17] 
  wal_txq_id          : 4          is_registered_for_hwq_empty : 0 
  sw_retry_failure    : 0          tx_header_size              : 0 
  tid_flags           : 0x3da0     pause_module_id_map         : 0 
  block_module_id_map : 0          tid_winsn                   : 0x0 
  tid_startsn         : 800        tid_winunack                : 0x0 
  tid_frameqhead      : 0          tid_frameqaddr              : 0 
  num_mpdu_in_frameq  : 0          num_mpdu_in_hwq             : 0 
  tid_frameqlastnum   : 0          tid_frameqlastpad           : 0 
  total_mpdus_allowed : 0          allow_n_flags               : 0 
  win_credit          : 1          win_size_o                  : 1 
  fail_cnt_succ       : 0          pn_low                      : 0xffffffffffffffff 
 
[tidno: 18] 
  wal_txq_id          : 6          is_registered_for_hwq_empty : 0 
  sw_retry_failure    : 0          tx_header_size              : 0 
  tid_flags           : 0x2da0     pause_module_id_map         : 0 
  block_module_id_map : 0          tid_winsn                   : 0xffffffffffffffff 
  tid_startsn         : 3880       tid_winunack                : 0x0 
  tid_frameqhead      : 4445124    tid_frameqaddr              : 4445124 
  num_mpdu_in_frameq  : 0          num_mpdu_in_hwq             : 0 
  tid_frameqlastnum   : 1          tid_frameqlastpad           : 3 
  total_mpdus_allowed : 0          allow_n_flags               : 0 
  win_credit          : 1          win_size_o                  : 1 
  fail_cnt_succ       : 0          pn_low                      : 0xffffffffffffffff 
 
[tidno: 16] 
  wal_txq_id          : 1          is_registered_for_hwq_empty : 1 
  sw_retry_failure    : 0          tx_header_size              : 10 
  tid_flags           : 0x3dc2     pause_module_id_map         : 2048 
  block_module_id_map : 0          tid_winsn                   : 0x0 
  tid_startsn         : 116        tid_winunack                : 0x0 
  tid_frameqhead      : 0          tid_frameqaddr              : 0 
  num_mpdu_in_frameq  : 0          num_mpdu_in_hwq             : 0 
  tid_frameqlastnum   : 0          tid_frameqlastpad           : 0 
  total_mpdus_allowed : 0          allow_n_flags               : 0 
  win_credit          : 1          win_size_o                  : 1 
  fail_cnt_succ       : 0          pn_low                      : 0xffffffffffffffff 
 
[tidno: 19] 
  wal_txq_id          : 1          is_registered_for_hwq_empty : 0 
  sw_retry_failure    : 0          tx_header_size              : 0 
  tid_flags           : 0x3da0     pause_module_id_map         : 0 
  block_module_id_map : 0          tid_winsn                   : 0x0 
  tid_startsn         : 0          tid_winunack                : 0x0 
  tid_frameqhead      : 0          tid_frameqaddr              : 0 
  num_mpdu_in_frameq  : 0          num_mpdu_in_hwq             : 0 
  tid_frameqlastnum   : 0          tid_frameqlastpad           : 0 
  total_mpdus_allowed : 0          allow_n_flags               : 0 
  win_credit          : 1          win_size_o                  : 1 
  fail_cnt_succ       : 0          pn_low                      : 0xffffffffffffffff

V200R019C10版本命令行:display lmac sta-statistics queue-status radio radio-id

[AP-diagnose] display lmac sta-statistics queue-status radio 1

-------------------------------STA:aab8-3cdb-f2fc-------------------------------
Tx tid queue info:
Base info:
Tid num                   : 0        1        2        3        4        5        6        7        8
Hardware txq ID           : 1        0        0        1        2        2        3        3        11
Tid flag                  : 0x65     0x1      0x1      0x1      0x1      0x1      0x65     0x1      0x1007
Tid start sn              : 1        0        0        0        0        0        1233     0        0
Negotiate window size     : 64       1        1        1        1        1        64       1        1
Software retry failure    : 0        0        0        0        0        0        0        0        0
Failure count             : 0        0        0        0        0        0        0        0        0
MPDU count                : 0        0        0        0        0        0        0        0        0
Retrans MPDU count        : 0        0        0        0        0        0        0        0        0
MPDU byte                 : 0        0        0        0        0        0        0        0        0
Retrans MPDU byte         : 0        0        0        0        0        0        0        0        0
MSDU num                  : 0        0        0        0        0        0        0        0        0
MSDU byte                 : 0        0        0        0        0        0        0        0        0
MPDU total num            : 0        0        0        0        0        0        0        0        0
Window credit             : 64       1        1        1        1        1        64       1        1
Queue ctrl info:
MSDU limit due rate       : 25273    0        0        0        0        0        25273    0        0
MSDU limit due dequeue    : 26325    0        0        0        0        0        26325    0        0
Max allowed MSDU          : 26325    0        0        0        0        0        25273    0        0
MSDU drop due limit       : 0        0        0        0        0        0        0        0        0
MSDU timeout threshold(ms): 10000    10000    10000    10000    10000    10000    10000    10000    10000
Fisrt MSDU dwell time     : 0        0        0        0        0        0        0        0        0
MSDU drops due expire     : 0        0        0        0        0        0        0        0        0
Current time              : 72014451  72014451  72014451  72014451  72014451  72014451  72014451  72014451  72014451
Last success send time    : 90589    0        0        0        0        0        71988157  0        0
Dequeue MSDU count        : 0        0        0        0        0        0        0        0        0
MSDU limit due powersave  : 25273    25273    25273    25273    25273    25273    25273    25273    0
Protocal info:
Max MSDU num              : 1        1        1        1        1        1        1        1        0
Max MSDU byte             : 1500     1500     1500     1500     1500     1500     1500     1500     0
Packet type               : 0        0        0        0        0        0        0        0        0
Packet encryption type    : 0        0        0        0        0        0        0        0        0
Has qos flag              : 0        0        0        0        0        0        0        0        0
Has ctrl flag             : 0        0        0        0        0        0        0        0        0
Prot info tid flag        : 0x0      0x0      0x0      0x0      0x0      0x0      0x0      0x0      0x0
Power save info:
Service period start time : 0        0        0        0        0        0        0        0        0
Pause cmd flag            : 0        0        0        0        0        0        0        0        0
Su only on flag           : 0        0        0        0        0        0        0        0        0
Pending frame  sleep      : 0        0        0        0        0        0        0        0        0
Power saving info         : 0x0      0x0      0x0      0x0      0x0      0x0      0x0      0x0      0x0
Schedule info:
Schedule list type        : 2        0        0        0        0        0        2        0        0
Tid in schedule           : 1        0        0        0        0        0        1        0        0
Tokens num                : 1        0        0        0        0        0        0        0        0
Priority                  : 0        0        0        0        0        0        0        0        0
Schedule abnormal num     : 0        0        0        0        0        0        0        0        0
Tid pending status        : 0        0        0        0        0        0        0        0        0
Rx pkt seqnumber info:
Tid num                   : 0        1        2        3        4        5        6        7        8
Mask                      : 0        0        0        0        0        0        0        0        0
Seq num start             : 99       0        0        0        0        0        0        0        0
Seq num end               : 163      0        0        0        0        0        0        0        0
Seq num                   : 0x620    0x0      0x0      0x0      0x0      0x0      0x0      0x0      0x0

发给终端的报文有多个优先级,每个优先级对应一个队列。如上所示的显示信息中,列出了当前AP对应射频上关联的所有终端在每一个队列中占用的buffer数量(num_mpdu_in_frameq),如果该参数的数值维持在20以上,则说明该终端占用了发包队列。此时,请联系技术支持人员寻求技术支持。

8、检查AP接口上接收到的组播和广播报文的统计信息是否正常

WLAN网络中发送组播、广播报文时,因为报文不会重传,所以为了确保接收端的收包成功率,都是以较低速率发送。如果网络中有大量的组播、广播报文往空口发送,会导致空口资源浪费严重,出现信道利用率持续升高,影响无线终端正常的上网体验,出现延迟大、丢包的情况。

# 在AP上查看AP对应接口上接收到的组播和广播报文的统计信息,观察组播、广播报文增长速率。可以多执行几次,观察报文统计计数增长的情况。

<AP> display interface GigabitEthernet 0/0/0
GigabitEthernet0/0/0 current state : UP
Line protocol current state : UP
Description:HUAWEI, AP Series, GigabitEthernet0/0/0 Interface
Switch Port, PVID : 1, TPID : 8100(Hex), The Maximum Frame Length is 1800
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 8038-bc1b-86c0
Last physical up time : 2005-07-27 19:02:43 UTC+08:00
Last physical down time : 2005-07-27 19:02:27 UTC+08:00
Current system time: 2005-07-27 22:50:31+08:00
Port Mode: COMMON COPPER
Speed : 1000, Loopback: NONE
Duplex: FULL, Negotiation: ENABLE
Mdi : AUTO
Last 300 seconds input rate 64 bits/sec, 0 packets/sec
Last 300 seconds output rate 120 bits/sec, 0 packets/sec
Input peak rate 3320 bits/sec,Record time: 2005-07-27 19:02:47
Output peak rate 7104 bits/sec,Record time: 2005-07-27 19:02:46

Input: 610 packets, 90015 bytes
Unicast: 13, Multicast: 244
Broadcast: 352, Jumbo: 0
Discard: 0, Total Error: 0

CRC: 0, Giants: 0
Jabbers: 0, Throttles: 0
Runts: 0, Alignments: 0
Symbols: 0, Ignoreds: 0
Frames: 0

Output: 457 packets, 207021 bytes
Unicast: 0, Multicast: 457
Broadcast: 0, Jumbo: 0
Discard: 0, Total Error: 0

Collisions: 0, ExcessiveCollisions: 0
Late Collisions: 0, Deferreds: 0
Buffers Purged: 0

Input bandwidth utilization threshold : 100.00%
Output bandwidth utilization threshold: 100.00%
Input bandwidth utilization : 0%
Output bandwidth utilization : 0%

如果广播或组播报文的增长速率超过100pps,说明该接口接收到的广播、组播报文较多。

解决方法如下:

a、开启二层网络的隔离功能。

# 在交换机或AC的接口下配置接口二层隔离功能。以AC为例。

<AC> system-view
[AC] interface GigabitEthernet 0/0/1
[AC-GigabitEthernet0/0/1] port-isolate enable
[AC-GigabitEthernet0/0/1] quit

# 在AC的流量模板下配置用户二层隔离功能。

[AC] wlan
[AC-wlan-view] traffic-profile name default
[AC-wlan-traffic-prof-default] user-isolate l2
[AC-wlan-traffic-prof-default] quit
[AC-wlan-view] quit

在交换机或AC上开启接口的广播和组播报文限速功能。以AC为例。

[AC] interface GigabitEthernet 0/0/1
[AC-GigabitEthernet0/0/1] broadcast-suppression packets 1000
[AC-GigabitEthernet0/0/1] multicast-suppression packets 1000

9、通过rf-ping命令检查问题终端的信号强度和速率是否正常

无线终端信号强度弱,会导致收、发包出现重传的情况。无线通信系统的速率是动态变化的,重传会导致发送端降速来确保通信成功率。

导致无线信号强度弱的常见原因包括:

  • 终端与AP之间存在障碍物,如墙体、建筑物等。
  • 终端所处区域内没有规划AP进行覆盖。
  • 终端与AP之间的物理距离较远。

排查步骤如下:

a、在AC上执行命令rf-ping -c number sta-mac,查看问题终端的信号强度和速率,确认无线侧通信是否顺畅。

<AC> system-view
[AC] wlan
[AC-wlan-view] rf-ping -c 10 183d-a27a-0570
Info: RfPing start, press CTRL+C to break.
Tx rate=130.0 Mbps, Reply from 183d-a27a-0570: RSSI=-43 dBm time < 1 ms
Tx rate=130.0 Mbps, Reply from 183d-a27a-0570: RSSI=-43 dBm time < 1 ms
Tx rate=130.0 Mbps, Reply from 183d-a27a-0570: RSSI=-46 dBm time < 1 ms
Tx rate=130.0 Mbps, Reply from 183d-a27a-0570: RSSI=-46 dBm time < 1 ms
Tx rate=130.0 Mbps, Reply from 183d-a27a-0570: RSSI=-42 dBm time < 1 ms
Tx rate=130.0 Mbps, Reply from 183d-a27a-0570: RSSI=-44 dBm time=1 ms
Tx rate=130.0 Mbps, Reply from 183d-a27a-0570: RSSI=-44 dBm time=1 ms
Tx rate=130.0 Mbps, Reply from 183d-a27a-0570: RSSI=-43 dBm time < 1 ms
Tx rate=130.0 Mbps, Reply from 183d-a27a-0570: RSSI=-42 dBm time < 1 ms
Tx rate=130.0 Mbps, Reply from 183d-a27a-0570: RSSI=-43 dBm time < 1 ms
10 packets transmitted, 10 received, 0% packet loss, time < 1 ms, RSSI -43 dBm

如上所示的显示信息中,需要关注发包速率(Tx rate)和信号强度(RSSI):

  • 在信号强度正常的情况下,如果速率反复变化,说明网络中存在无线干扰,需要对AP进行信道规划和功率调整。
  • 如果终端信号强度低于-70dBm,说明终端信号强度弱,需要查看Wi-Fi网络覆盖是否存在盲区,如果存在,需要补盲解决。同时还需要查看AP是否分布密集,如果是,建议调整功率或者调整AP位置,保证漫游体验。

b、在AC上执行命令display station sta-mac sta-mac,查看终端是否关联到远端AP。

<AC> display station sta-mac b878-2eb4-2689
------------------------------------------------------------------------------
...
The upstream SNR(dB) : 80.0
...
Neighbor list:
------------------------------------------
AP name RfID SNR RCPI
------------------------------------------

------------------------------------------
total: 0
...
------------------------------------------------------------------------------

如果邻居列表中存在SNR比STA当前关联的AP的SNR高,则说明终端可能关联到了远端AP,建议开启智能漫游功能。配置如下:

<AC> system-view
[AC] wlan
[AC-wlan-view] rrm-profile name wlan-rrm
[AC-wlan-rrm-prof-wlan-rrm] smart-roam enable //从V200R008版本开始,智能漫游功能默认是开启的,如被关闭,可以执行命令undo smart-roam disable开启

10、通过报文跟踪手段检查AP设备内部是否存在丢包

a、从AC ping终端,通过报文跟踪功能来跟踪icmp报文从网络侧到终端侧的发送情况。

V200R006C20及之后版本执行命令行:

<AP> system-view
[AP] diagnose
[AP-diagnose] debugging wifi pkt-print clear //清空当前过滤条件,便于重新设置过滤条件
[AP-diagnose] debugging wifi pkt-print counter clear //清空当前计数,方便查看新的计数
[AP-diagnose] debugging wifi pkt-print condition icmp //设置过滤条件
[AP-diagnose] debugging wifi pkt-print condition dst-mac 482c-a042-6e54 //设置过滤条件,目的MAC地址是终端的MAC地址
[AP-diagnose] debugging wifi pkt-print on print-num 1000 //设置最多统计多少个满足条件的报文
[AP-diagnose] debugging wifi pkt-print counter query //查看统计计数
ID CNT SEQ TIME
WIFI_PKT_PROC_KAP_TX_HOOK 5 0 2018-9-28 10:38:49
WIFI_PKT_PROC_TX_DATA_COMPLETE_OK 5 0 2018-9-28 10:38:49

V200R006C10及之前版本执行如下命令行:

<AP> system-view
[AP] diagnose
[AP-diagnose] debugging wifi print condition clear //清空当前过滤条件,便于重新设置过滤条件
[AP-diagnose] debugging wifi print condition counter clear //清空当前计数,方便查看新的计数
[AP-diagnose] debugging wifi print 3 //配置为3表示只统计报文,不打印报文内容
[AP-diagnose] debugging wifi print condition icmp //设置过滤条件
[AP-diagnose] debugging wifi print condition dst-mac 2469-a593-6d9a //设置过滤条件,目的MAC地址是终端的MAC地址
[AP-diagnose] debugging wifi print on print-num 1000 //设置最多统计多少个满足条件的报文
[AP-diagnose] debugging wifi print condition counter query //查看统计计数
ID CNT SEQ TIME
WIFI_PKT_PROC_KAP_TX_HOOK 10 0 2015-5-29 1:26:41
WIFI_PKT_PROC_OSIF_START 10 0 2015-5-29 1:26:41
WIFI_PKT_PROC_VAP_SEND 10 0 2015-5-29 1:26:41
WIFI_PKT_PROC_SEND_WBUF_INTER 10 0 2015-5-29 1:26:41
WIFI_PKT_PROC_TX_SEND 10 0 2015-5-29 1:26:41
WIFI_PKT_PROC_TX_START 10 0 2015-5-29 1:26:41
WIFI_PKT_PROC_ATH_TX_START_DMA 10 0 2015-5-29 1:26:41
WIFI_PKT_PROC_TX_START_DMA_AMPDU 10 0 2015-5-29 1:26:41
WIFI_PKT_PROC_WIFI_IEEE80211_UPDATE_STATUS_OK 10 0 2015-5-29 1:26:41

如上面显示信息所示,最上面的一项是报文进入Wi-Fi驱动模块时的计数统计,后面的依次是报文经过Wi-Fi驱动模块的各个发送流程,直至发送成功。正常情况下,各个流程的计数统计应该是一样的,如果不一样或全为0,说明Wi-Fi驱动模块存在丢包或没有收到报文。

b、从AC ping终端,通过报文跟踪功能来跟踪终端的icmp响应报文从终端侧到网络侧的发送情况。

V200R019C10版本执行命令行:

[AP-diagnose] debugging lmac pkt-print on print-num 1000
[AP-diagnose] debugging lmac pkt-print condition icmp
[AP-diagnose] debugging lmac pkt-print counter clear
[AP-diagnose] debugging lmac pkt-print counter query
ID CNT SEQ TIME
Tx all receive data pkt from cap 22 0 3359060104
Tx all receive mgmt pkt from umac 725 0 3359060498
Tx receive specific data pkt from cap 21 0 3359060104
Tx specific data pkt enqueue 21 0 3359060105
Tx send specific msdu to smac 28 0 3359059603
Tx specific msdu done 28 0 3359059604
Rx all receive mgmt pkt from smac 52 0 3359056177
Rx all receive data pkt from smac 31 0 3359059606
Rx send specific data pkt to cap 20 0 3359059606

V200R006C20~V200R019C00版本执行命令行:

<AP> system-view
[AP] diagnose
[AP-diagnose] debugging wifi pkt-print clear //清空当前过滤条件,便于重新设置过滤条件
[AP-diagnose] debugging wifi pkt-print counter clear //清空当前计数,方便查看新的计数
[AP-diagnose] debugging wifi pkt-print condition icmp //设置过滤条件
[AP-diagnose] debugging wifi pkt-print condition source-mac 482c-a042-6e54 //设置过滤条件,源MAC地址是终端的MAC地址
[AP-diagnose] debugging wifi pkt-print on print-num 1000 //设置最多统计多少个满足条件的报文
[AP-diagnose] debugging wifi pkt-print counter query //查看统计计数
ID CNT SEQ TIME
WIFI_PKT_PROC_WIFI_RECV_PROCESS 5 0 2018-9-28 10:48:56
WIFI_RX_AMSDU_POP_LL 5 0 2018-9-28 10:48:56
WIFI_RX_AMSDU_RX_PN_OK 5 0 2018-9-28 10:48:56
WIFI_RX_AMSDU_RX_DELIVERS 5 0 2018-9-28 10:48:56
WIFI_RX_AMSDU_RECEIVE_HOOK 10 0 2018-9-28 10:48:56
WIFI_RXFILTER_DROPUNENC_ACCEPT 5 0 2018-9-28 10:48:56

V200R006C10及之前版本执行如下命令行:

 system-view
[AP] diagnose
[AP-diagnose] debugging wifi print condition clear //清空当前过滤条件,便于重新设置过滤条件
[AP-diagnose] debugging wifi print condition counter clear //清空当前计数,方便查看新的计数
[AP-diagnose] debugging wifi print 3 //配置为3表示只统计报文,不打印报文内容
[AP-diagnose] debugging wifi print condition icmp //设置过滤条件
[AP-diagnose] debugging wifi print condition src-mac 2469-a593-6d9a //设置过滤条件,源MAC地址是终端的MAC地址
[AP-diagnose] debugging wifi print on print-num 1000 //设置最多统计多少个满足条件的报文
[AP-diagnose] debugging wifi print condition counter query //查看统计计数
ID CNT SEQ TIME
WIFI_PKT_PROC_WIFI_RECV_PROCESS 10 0 2015-5-29 1:37:11
WIFI_PKT_PROC_MESH_DATA_RECV 10 0 2015-5-29 1:37:11
WIFI_PKT_PROC_DELIVER_DATA 10 0 2015-5-29 1:37:11
WIFI_PKT_PROC_ATH_AMPDU_INPUT 10 0 2015-5-29 1:37:11
WIFI_PKT_PROC_ATH_AMPDU_INPUT_RX_IN_ORDER 10 0 2015-5-29 1:37:11
WIFI_PKT_PROC_RX_NET80211_RX 10 0 2015-5-29 1:37:11
WIFI_PKT_PROC_RX_PROCESS 10 0 2015-5-29 1:37:11
WIFI_PKT_PROC_RECV_KEYHAS_OK 10 0 2015-5-29 1:37:11
WIFI_PKT_DROP_RX_NET80211_RX_KEYMISS 10 0 2015-5-29 1:37:11
WIFI_PKT_DROP_INPUT_DATA_MCASTECHO 10 0 2015-5-29 1:37:11

如上面显示信息所示,最下面的一项是报文进入Wi-Fi驱动模块时的计数统计,后面的依次是报文经过Wi-Fi驱动模块的各个接收流程,直至发送到转发模块。正常情况下,各个流程的计数统计应该是一样的,如果不一样或全为0,说明Wi-Fi驱动模块存在丢包或没有收到报文。

如果报文在设备内部收发过程中存在丢包,请联系华为技术支持人员寻求技术支持。

c、问题处理结束后关闭报文跟踪功能。

V200R019C10版本执行如下命令行:

[AP-diagnose] debugging lmac pkt-print condition clear //清空当前过滤条件
[AP-diagnose] debugging lmac pkt-print off //关闭统计开关

V200R006C20~V200R019C00版本执行命令行:

[AP-diagnose] debugging wifi pkt-print clear //清空当前过滤条件
[AP-diagnose] debugging wifi pkt-print off //关闭统计开关

V200R006C10及之前版本执行如下命令行:

[AP-diagnose] debugging wifi print condition clear //清空当前过滤条件
[AP-diagnose] debugging wifi print off //关闭统计开关

11、检查是否关闭WMM功能

在AC上查看AP的射频模板,检查是否关闭了WMM功能。如果WMM功能被关闭,当前终端的速率只能为802.11g的速率,此时,需要开启WMM功能。

 display radio-5g-profile name default
------------------------------------------------------------
......
WMM switch : disable
......
------------------------------------------------------------
 system-view
[AC] wlan
[AC-wlan-view] radio-5g-profile name default
[AC-wlan-radio-5g-prof-default] undo wmm disable

12、检查是否存在建链速率低的终端在做大流量业务

AP下关联低速率下做大流量业务的终端,可能会导致该AP下的其他用户无法正常上网,该终端停止业务后,其他用户恢复正常。

a、通过display station ap-id X 查看该AP下是否存在建链速率低的终端。

 display station ap-id 3
Rf/WLAN: Radio ID/WLAN ID
Rx/Tx: link receive rate/link transmit rate(Mbps)
-----------------------------------------------------------------------------------------------------------------
STA MAC AP ID Ap name Rf/WLAN Band Type Rx/Tx RSSI VLAN IPv4 address SSID Status
-----------------------------------------------------------------------------------------------------------------
14cf-9208-9abf 0 1047-8007-6f80 0/2 2.4G 11n 65/58 -70 10 10.10.10.253 tap1 Normal
-----------------------------------------------------------------------------------------------------------------
Total: 1 2.4G: 1 5G: 0

在有业务的情况下,如果终端的建链速率(Tx或Rx)小于30Mbps,说明该终端的建链速率低。

b、执行命令display station statistics sta-mac sta-mac查看该终端下的统计。

 display station statistics sta-mac 14cf-9208-9abf
-----------------------------------------------------------------
Packets sent to the station : 7
Packets received from the station : 40
Bytes sent to the station : 1170
Bytes received from the station : 3911
Wireless data rate sent to the station(kbps) : 0
Wireless data rate received from the station(kbps) : 0
Trigger roam total : 0
Trigger roam failed : 0
STA power save percent : 0%
------------------------------------------------------------------------------

一般认为,如果终端流量超过10M,说明该终端在进行大流量业务。具体还需要结合实际网络情况来判断。

为保证其他终端能够正常上网,可以通过如下方法进行处理:

  • 对单个终端进行限速,具体的限制速率请结合实际网络情况来配置。
 system-view
[AC] wlan
[AC-wlan-view] traffic-profile name p1
[AC-wlan-traffic-prof-p1] rate-limit client up 2000
[AC-wlan-traffic-prof-p1] rate-limit client down 2000
  • 开启智能漫游功能。
 system-view
[AC] wlan
[AC-wlan-view] rrm-profile name wlan-rrm
[AC-wlan-rrm-prof-wlan-rrm] smart-roam enable //从V200R008版本开始,智能漫游功能默认是开启的,如被关闭,可以执行命令undo smart-roam disable开启

13、检查有线网络侧中间设备是否存在ARP丢包

如果中间设备ARP丢包严重,会导致通信双方无法及时学习到对方的ARP表项,出现网络时通时断的异常情况。

# 在中间设备(如交换机)上执行命令display cpu-defend statistics wired,检查中间设备ARP CPCAR丢包情况。

 display cpu-defend statistics wired
-----------------------------------------------------------------------
Packet Type Pass Packets Drop Packets
-----------------------------------------------------------------------
8021X 0 0
arp-miss 0 0
arp-reply 0 0
arp-request 6 0
capwap 0 0
capwap-association 0 0
capwap-discovery 0 0
capwap-echo 0 0
capwap-keepalive 0 0
dhcp-client 0 0

如果ARP Request包的丢包率超过50%,说明该中间设备ARP丢包严重。

解决方法如下:

  • 在设备当前CPU利用率不高的情况下,可以增大ARP Request报文上送CPU的限制速率。
 system-view
[LSW] cpu-defend policy test //创建策略
[LSW-cpu-defend-policy-test] packet-type arp-request rate-limit 256 wired //调整ARP Request报文的限制速率
[LSW-cpu-defend-policy-test] quit
[LSW] cpu-defend-policy test //应用策略
  • 配置攻击溯源功能,避免网络中有终端存在ARP泛洪攻击行为。
[LSW] cpu-defend policy test
[LSW-cpu-defend-policy-test] auto-defend protocol arp
[LSW-cpu-defend-policy-test] auto-defend threshold 50 //设置攻击溯源检查阈值为50pps,如果超过该阈值,则认为被攻击
[LSW-cpu-defend-policy-test] auto-defend action deny timer 60 //检测到攻击后,直接丢弃报文并将终端加入黑名单60s
[LSW-cpu-defend-policy-test] quit
[LSW] cpu-defend-policy test //应用策略

14、检查有线网络中是否存在环路

如果网络中存在环路,会导致MAC漂移、网络拥塞严重等问题,引起通信不畅,出现丢包、网络延迟大等现象。

a、在交换机上执行命令display interface brief,查看设备接口报文统计信息,观察入方向和出方向的流量。

[LSW] display interface brief
PHY: Physical
*down: administratively down
(l): loopback
(s): spoofing
(b): BFD down
(e): ETHOAM down
InUti/OutUti: input utility/output utility
Interface PHY Protocol InUti OutUti inErrors outErrors
GigabitEthernet0/0/1 down down 0% 0% 0 0
GigabitEthernet0/0/2 up up 0.08% 0.01% 0 0
GigabitEthernet0/0/3 down down 0% 0% 0 0
GigabitEthernet0/0/4 down down 0% 0% 0 0
GigabitEthernet0/0/5 down down 0% 0% 0 0
GigabitEthernet0/0/6 down down 0% 0% 0 0
GigabitEthernet0/0/7 down down 0% 0% 0 0
GigabitEthernet0/0/8 down down 0% 0% 0 0

如果某接口的出方向和入方向流量相差不大,网络中存在环路的可能性很高。此时,需要检查对应接口的详细统计信息。

b、在交换机上执行命令display interface interface-type interface-num,进一步查看对应接口的详细统计信息,观察组播、广播报文增长速率。可以多执行几次,观察报文统计计数增长的情况。

[LSW] display interface GigabitEthernet 0/0/2
GigabitEthernet0/0/2 current state : UP
Line protocol current state : UP
Description:HUAWEI, AC Series, GigabitEthernet0/0/2 Interface
Switch Port, PVID : 1, TPID : 8100(Hex), The Maximum Frame Length is 9216
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 1051-7212-eac5
Last physical up time : 2016-04-18 23:57:03 UTC+08:00
Last physical down time : 2016-04-18 23:56:52 UTC+08:00
Current system time: 2016-04-19 00:11:04+08:00
Port Mode: COMMON COPPER
Speed : 1000, Loopback: NONE
Duplex: FULL, Negotiation: ENABLE
Mdi : AUTO
Last 300 seconds input rate 360 bits/sec, 0 packets/sec
Last 300 seconds output rate 496 bits/sec, 0 packets/sec
Input peak rate 470664 bits/sec,Record time: 2016-04-18 23:57:58
Output peak rate 174664 bits/sec,Record time: 2016-04-18 23:57:58

Input: 547 packets, 39311 bytes
Unicast: 491, Multicast: 19
Broadcast: 37, Jumbo: 0
Discard: 0, Total Error: 0

CRC: 0, Giants: 0
Jabbers: 0, Throttles: 0
Runts: 0

Output: 600 packets, 49436 bytes
Unicast: 599, Multicast: 0
Broadcast: 1, Jumbo: 0
Discard: 0, Total Error: 0

Collisions: 0, ExcessiveCollisions: 0
Deferreds: 0

Input bandwidth utilization threshold : 100.00%
Output bandwidth utilization threshold: 100.00%
Input bandwidth utilization : 0.01%
Output bandwidth utilization : 0.01%

如果组播或广播报文的增长速率超过500pps,说明网络中可能存在环路。此时,需要检查网线连接和对应接口的配置,排除环路。

15、检查AP的IP地址是否冲突

一个AP与其他AP产生IP地址冲突,会导致SSID不稳定,用户频繁掉线。

# 通过display ap all查看所有AP的IP地址,检查其是否有IP冲突情况。

 display ap all
Total AP information:
nor : normal [2]
-----------------------------------------------------------------------------------------
ID MAC Name Group IP Type State STA Uptime
-----------------------------------------------------------------------------------------
0 dcd2-fcf6-76a0 area_1 ap-group1 192.168.120.254 AP6010DN-AGN nor 0 4H:49M:11S
1 60de-4474-9640 area_2 ap-group1 192.168.120.253 AP5010DN-AGN nor 0 6H:3M:40S
-----------------------------------------------------------------------------------------
Total: 2

16、检查有线网络中中间设备的CPU利用率是否正常

如果设备的CPU利用率一直很高(超过80%),会导致各种业务异常,出现丢包、网络延迟大等现象。

# 在交换机上执行命令display cpu-usage,检查中间设备的CPU利用率是否正常。

 display cpu-usage
CPU Usage Stat. Cycle: 10 (Second)
CPU Usage: 1.7% Max: 56.2%
CPU Usage Stat. Time : 2016-04-19 00:16:59
CPU Usage Max. Time : 2016-04-18 23:57:14

造成设备CPU利用率高的原因有很多,当设备的CPU利用率一直很高时,请参考交换机维护宝典中CPU高的相关处理步骤。

17、检查网线是否有问题

如果中间有线网络中的网线有问题,会导致出现大量丢包、网络延迟大等现象。

# 进入接口视图,执行命令virtual-cable-test,最后四个状态均为OK表示网线好的,否则建议更换网线。

[2028-3e97-4240-GigabitEthernet0/0/0]virtual-cable-test
Warning: The command will stop service for a while. Continue? [Y/N]y
Info: This operation may take a few seconds. Please wait for a moment..done.
Pair A length: 1 meter(s)
Pair B length: 1 meter(s)
Pair C length: 1 meter(s)
Pair D length: 1 meter(s)
Pair A state: OK
Pair B state: OK
Pair C state: OK
Pair D state: OK
-

18、收集故障信息

  • 分别在AC和AP上执行命令display version,查看AC和AP的软件版本。
  • 收集各检查步骤的显示信息。

本文由 @释然 发布于弱电智能网 。

题图来自Unsplash,基于CC0协议

内容观点仅代表作者本人,弱电智能网平台仅提供信息存储空间服务。

如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

文章名称:《华为无线AP终端网络慢什么原因怎么处理?》

文章链接:https://www.ruodian360.com/tech/networking/33577.html

添加微信ydian188免费入群,记得备注“弱电智能网”。

给TA打赏
共{{data.count}}人
人已打赏
网络通信

华为网络交换机集群/堆叠通用部署教程

2022-9-14 11:07:56

网络通信

5G专网架构及建设策略思考

2022-9-15 18:19:26

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
搜索