The Network Access Speed Is Slow
Symptom
STAs experience slow network response, such as network delay and frame freezing.
Possible Causes
Depending on whether the fault occurs on the wireless or wired side.
- Wireless side:
- The VLAN configuration is incorrectly configured.
- The AP's channel utilization is incorrect.
- The AP's packet cache resources and packet sending queue are abnormal.
- The signal strength of the AP is incorrect.
- Packet loss occurs inside the AP.
- There is heavy traffic of services from low-rate STAs.
- Wired side:
- ARP packets are lost on the intermediate network.
- A loop occurs on the wired network.
- The AP's CPU usage is high.
- The AP's IP address conflicts.
- Network cables are faulty.
Troubleshooting Procedure
- Run the ping command to check whether the fault occurs on the lower-layer network of the gateway.
Before rectifying the fault, you can determine the fault scope by sending ping packets.
# Ping the gateway address and external network address from the STA and observe the ping packets to determine the fault scope.
- If the ping operation from the STA to the gateway is unstable, for example, frequent packet loss and delay fluctuation, the fault occurs on the lower-layer network of the gateway.
- If the STA can ping the gateway but cannot ping the external network address, the fault occurs on the upper-layer network of the gateway.
If packet loss occurs during the ping operation, perform the following operations to locate the fault:
- Packet loss on the wired side: A STA Fails to Ping the Gateway (Packets Are Lost on the Wired Side)
- Packet loss on the wireless side: STA Packet Loss (Wireless Side)
- Check whether the wired network between the AP and gateway is normal.
# Ping the switch connected to the AP from the gateway and observe the ping packets.
- If the ping packets between the gateway and switch are stable, the wired network between the gateway and switch is normal. Check the wireless network starting from 3.
- If the ping packets between the gateway and switch are unstable, check the wired network between the gateway and switch. Check the wired network starting from 13.
If the gateway cannot ping the switch (for example, the switch is a Layer 2 device), ping the AP from the AC to check whether the wired network is faulty.
- Check whether the service VLAN and management VLAN are properly configured.
The following table lists the recommended configurations of the management VLAN and service VLAN in different forwarding modes.
For ease of description, VLAN IDs in the table are examples.
Table 6-1 Recommended configurations of the management VLAN and service VLAN in different forwarding modesForwarding Mode
Service VLAN ID
Management VLAN ID
Configuration Impact
Recommended Configuration
Direct forwarding
1
100
Service packets are tagged with the management VLAN ID, causing service disorder.
Not recommended
100
1
The broadcast domain of VLAN 1 is too large and broadcast packets are flooded, causing network congestion and affecting user experience.
Not recommended
1
1
The broadcast domain of VLAN 1 is too large and broadcast packets are flooded, causing network congestion and affecting user experience.
Not recommended
100
100
Data forwarding is abnormal.
Not recommended
100
50
Standard recommended configuration.
Recommended
Tunnel forwarding
1
100
The broadcast domain of VLAN 1 is too large and broadcast packets are flooded, causing network congestion and affecting user experience.
Not recommended
100
1
The broadcast domain of VLAN 1 is too large and broadcast packets are flooded, causing network congestion and affecting user experience.
Not recommended
1
1
MAC address flapping occurs, causing a data forwarding exception.
Not recommended
100
100
MAC address flapping occurs, causing a data forwarding exception.
Not recommended
100
50
Standard recommended configuration.
Recommended
- Run the display vlan brief command to check the mapping between VLAN IDs and interfaces.
<AC> 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 - Run the interface GigabitEthernet 0/0/x command to enter the interface view and check whether the management VLAN and service VLAN are correctly configured on each interface.
If the management VLAN and service VLAN are not correctly configured (for example, VLAN 1 is used as both the service VLAN and management VLAN), configure the management VLAN and service VLAN by referring to Table 6-1.
<AC> 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
- Run the display vlan brief command to check the mapping between VLAN IDs and interfaces.
- Check whether the AP's CPU usage is normal.
If the CPU usage of the AP is always high (higher than 80%), various service exceptions occur, causing packet loss and long network delay.
# Check the CPU usage of the AP to determine whether the CPU usage is normal.
<AP> 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
There are many causes for high CPU usage. Rectify the fault according to The CPU Usage Is High.
- Check whether the AP's channel utilization is normal.
All STAs on a WLAN share and compete for bandwidth resources. If there are a large number of STAs or many broadcast and multicast packets (multicast and broadcast packets are sent at a low rate and consume many air interface resources) on the WLAN, STAs may preempt channels of each other. As a result, the channel utilization is high, the WLAN is unstable, the ping packet delay is long, and packet loss occurs.
- AC+Fit AP
# Run the display radio all command on the AC to check the channel utilization of the AP.
In the AC+central AP+RU scenario, you need to run the ap data-collection enable command in the WLAN view to enable the central AP to buffer RU data when querying the RU channel utilization on the AC.
<Huawei> 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
# Run the display ap traffic statistics wireless radio radio-id command to check the channel utilization of the AP.
In the central Fat AP+RU scenario, to query the RU channel utilization on the central Fat AP, run the ap data-collection enable command in the WLAN view to enable the central Fat AP to buffer RU data.
<Huawei> display ap traffic statistics wireless radio 0 ----------------------------------------------------------------------- ... Wireless channel utilization(%) :70 ... -----------------------------------------------------------------------
Generally, if the channel utilization exceeds 60%, network fluctuation may occur. The causes and solutions of high channel utilization are as follows:
- The radio environment is severely interfered. In this case, you need to properly plan AP channels to reduce interference. You can manually switch the channel to a channel with low channel utilization or perform calibration when services are not affected.
- There are a large number of multicast and broadcast packets on the network. For details about how to check the multicast and broadcast packets on the network, see 8.
- AC+Fit AP
- Check whether the remaining buffer resources of the AP are normal.
The forwarding module of the AP and the Wi-Fi packet receiving and sending module share a buffer resource pool. If buffer resources are insufficient, packet loss occurs.
# Run the display memory-pool info command on the AP to check whether the remaining buffer resources are normal.
<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 ...If the remaining buffer resources of the AP are less than 100, the buffer resources of the AP are insufficient and packet loss occurs. Contact technical support personnel.
- Check whether the packet sending queue is congested or fully occupied.
When packets arrive at the AP Wi-Fi driver module, they are buffered in the queue for scheduling and sending. If the buffer queue of the Wi-Fi driver module is fully occupied or severely congested, packet loss and long delay may occur.
If the buffer queue of the AP Wi-Fi driver module is congested, the buffer queue is occupied by some STAs. For example, when a STA has weak signals or leaves the Wi-Fi coverage area, packets sent to the STA cannot be sent out and are blocked in the buffer queue of the AP.
- Check the packet sending queue of the Wi-Fi driver module on the AP to determine whether the packet sending queue is congested or fully occupied.
- For an AP that supports only 802.11n, such as AP6x10xN, check the packet sending queue of the Wi-Fi driver module of the AP.
In V200R006C10 and earlier versions, run the display interface radio radio-id txq-buf command.
In V200R006C20 and later versions, run the display wifi txq-buf radio radio-id command. This command is used as an example.<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
- For an AP that supports only 802.11ac, such as AP5x30xN, check the packet sending queue of the Wi-Fi driver module of the AP.
In V200R006C10, run the debugging wlandrv setplv printlevel_num command.
In V200R006C20, run the debugging wifi trace-print level printlevel_num command.
In V200R007 and later versions, run the display wifi txq-buf radio radio-id command. This command is used as an example.
<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 ------------------------------
- For an AP that supports 802.11ax, such as AirEngine 8760-X1-PRO, check the packet sending queue of the Wi-Fi driver module of the AP.
In V200R019C10, run the display lmac txq-buf radio radio-id command.
[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 ------------------------------------------------------------------
Generally, the buffer queue of the Wi-Fi driver module is not occupied continuously. Therefore, if the value of any field in the preceding command output continuously increases or is always high when no service is running, the queue is congested. Contact technical support personnel.
- For an AP that supports only 802.11n, such as AP6x10xN, check the packet sending queue of the Wi-Fi driver module of the AP.
- If the buffer queue of the AP Wi-Fi driver module is congested, check the queue usage of each STA.
In V200R006C10 and earlier versions, run the display sta-statistics radio radio-id list command.
In V200R006C20 to V200R019C00, run the display wifi sta-statistics radio radio-id command. This command is used as an example.
<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
In V200R019C10, run the display lmac sta-statistics queue-status radio radio-id command.
[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
Packets sent to STAs have multiple priorities, and each priority corresponds to a queue. The preceding command output shows the number of buffers (num_mpdu_in_frameq) occupied by all STAs associated with the AP radio in each queue. If the value is greater than 20, the STAs occupy the packet sending queue. Contact technical support personnel.
- Check the packet sending queue of the Wi-Fi driver module on the AP to determine whether the packet sending queue is congested or fully occupied.
- Check whether the statistics about multicast and broadcast packets received on the AP interface are correct.
On a WLAN, multicast and broadcast packets are not retransmitted. To ensure the success rate of the receiver, the receiver sends multicast and broadcast packets at a low rate. If a large number of multicast and broadcast packets are sent to the air interface, air interface resources are wasted and the channel utilization keeps increasing, affecting user experience. As a result, the delay is long and packet loss occurs.
# Check statistics about multicast and broadcast packets received on the AP's interface and the rate at which multicast and broadcast packets increase. You can run the command several times to check the increase of packet statistics.
<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%If the rate at which broadcast or multicast packets increase exceeds 100 pps, the interface receives a large number of broadcast or multicast packets.
The solution is as follows:- Enable Layer 2 network isolation.
# Configure Layer 2 isolation on the interface of the switch or AC. The AC is used as an example.
<AC> system-view [AC] interface GigabitEthernet 0/0/1 [AC-GigabitEthernet0/0/1] port-isolate enable [AC-GigabitEthernet0/0/1] quit
# Configure Layer 2 user isolation in the AC traffic profile.
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
- Enable rate limiting for broadcast and multicast packets on the switch or AC. The AC is used as an example.
[AC] interface GigabitEthernet 0/0/1 [AC-GigabitEthernet0/0/1] broadcast-suppression packets 1000 [AC-GigabitEthernet0/0/1] multicast-suppression packets 1000
- Enable Layer 2 network isolation.
- Run the rf-ping command to check whether the signal strength and rate of the faulty STA are normal.
If the signal strength of a STA is weak, the STA may retransmit received and sent packets. The rate of a wireless communications system dynamically changes, and retransmission causes the sender to reduce a rate to ensure a communication success rate.
Common causes for low signal strength of a STA are as follows:
- Obstacles exist between the STA and associated AP, such as walls or buildings.
- No AP coverage is planned in the area where the STA is located.
- The STA is far away from the AP.
Perform the following procedure to find the causes:
- Run the rf-ping -c number sta-mac command on the AC to check the signal strength and rate of the faulty STA and check whether the communication on the wireless side is normal.
<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
In the preceding information, pay attention to the values of Tx rate and RSSI.
- If the signal strength is normal but the rate changes repeatedly, radio interferences exist on the network. In this case, you need to plan channels and adjust the power of the AP.
- If the signal strength of the STA is lower than -70 dBm, the signal strength of the STA is weak. In this case, check whether there are coverage holes on the Wi-Fi network. If there are, eliminate the coverage holes. In addition, check whether APs are densely distributed. If so, adjust the power or AP location to ensure roaming experience.
- Check whether the STA is associated with a remote AP.
# Run the display station sta-mac sta-mac command on the AC to check the RSSI of a STA.
<AC> display station sta-mac b878-2eb4-2689 ------------------------------------------------------------------------------ ... Station's RSSI(dBm) : -28 ... ------------------------------------------------------------------------------
# Run the display station neighbor sta-mac mac-address command on the AC to check neighbor information on a STA.
<AC> display station neighbor sta-mac b878-2eb4-2689 UL info: Uplink measurement neighbor info DL info: Downlink measurement neighbor info -------------------------------------------------------------------------------------------------------------------------------- Device MAC Device ID Device Name Radio ID Channel UL info(RSSI/HH:MM:SS) DL info[RCPI/RSNI/HH:MM:SS] -------------------------------------------------------------------------------------------------------------------------------- 00e0-fc76-e360 0 00e0-fc76-e360 1 165 -44/15:05:11 68/40/2022-10-14/06:28:12 -------------------------------------------------------------------------------------------------------------------------------- Total neighbors: 1, total records: 1
If the RSSI of a neighbor in the neighbor list is higher than that of the AP associated with the STA, the STA may be associated with a remote AP. In this case, you are advised to enable smart roaming. The configuration is as follows:
<AC> system-view [AC] wlan [AC-wlan-view] rrm-profile name wlan-rrm [AC-wlan-rrm-prof-wlan-rrm] smart-roam enable //In V200R008 and later versions, smart roaming is enabled by default. If smart roaming is disabled, run the undo smart-roam disable command to enable it.
- Check whether packet loss occurs on the AP by tracing packets.
- Ping the STA from the AC and use the packet tracing function to trace the transmission of ICMP packets from the network side to the STA.In V200R006C20 and later versions, run the following commands.
<AP> system-view [AP] diagnose [AP-diagnose] debugging wifi pkt-print clear //Clear the current filtering condition so that you can set a new filtering condition. [AP-diagnose] debugging wifi pkt-print counter clear //Clear the current statistics to facilitate the query of new statistics. [AP-diagnose] debugging wifi pkt-print condition icmp //Set a filtering condition. [AP-diagnose] debugging wifi pkt-print condition dst-mac 482c-a042-6e54 //Set a filtering condition. The destination MAC address is the MAC address of the STA. [AP-diagnose] debugging wifi pkt-print on print-num 1000 //Set the maximum number of packets that meet the filtering condition and are counted. [AP-diagnose] debugging wifi pkt-print counter query //Check the statistics. 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
In V200R006C10 and earlier versions, run the following commands.<AP> system-view [AP] diagnose [AP-diagnose] debugging wifi print condition clear //Clear the current filtering condition so that you can set a new filtering condition. [AP-diagnose] debugging wifi print condition counter clear //Clear the current statistics to facilitate the query of new statistics. [AP-diagnose] debugging wifi print 3 //The value 3 indicates that only packet statistics are collected. The packet content is not displayed. [AP-diagnose] debugging wifi print condition icmp //Set a filtering condition. [AP-diagnose] debugging wifi print condition dst-mac 2469-a593-6d9a //Set a filtering condition. The destination MAC address is the MAC address of the STA. [AP-diagnose] debugging wifi print on print-num 1000 //Set the maximum number of packets that meet the filtering condition and are counted. [AP-diagnose] debugging wifi print condition counter query //Check packet statistics. 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
As shown in the preceding information, the first item is the count when packets enter the Wi-Fi driver module, and the following items are counts of packets in different processes of the Wi-Fi driver module until packets are sent successfully. In normal cases, the statistics of each process should be the same. If the statistics are different or all 0s, the Wi-Fi driver module discards packets or does not receive packets.
- Ping the STA from the AC and use the packet tracing function to trace the transmission of ICMP response packets from the STA to the network side.
In V200R019C10, run the following commands.
[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
In V200R006C20 to V200R019C00, run the following commands.<AP> system-view [AP] diagnose [AP-diagnose] debugging wifi pkt-print clear //Clear the current filtering condition so that you can set a new filtering condition. [AP-diagnose] debugging wifi pkt-print counter clear //Clear the current statistics to facilitate the query of new statistics. [AP-diagnose] debugging wifi pkt-print condition icmp //Set a filtering condition. [AP-diagnose] debugging wifi pkt-print condition source-mac 482c-a042-6e54 //Set a filtering condition. The source MAC address is the MAC address of the STA. [AP-diagnose] debugging wifi pkt-print on print-num 1000 //Set the maximum number of packets that meet the filtering condition and are counted. [AP-diagnose] debugging wifi pkt-print counter query //Check the statistics. 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
In V200R006C10 and earlier versions, run the following commands.<AP> system-view [AP] diagnose [AP-diagnose] debugging wifi print condition clear //Clear the current filtering condition so that you can set a new filtering condition. [AP-diagnose] debugging wifi print condition counter clear //Clear the current statistics to facilitate the query of new statistics. [AP-diagnose] debugging wifi print 3 //The value 3 indicates that only packet statistics are collected. The packet content is not displayed. [AP-diagnose] debugging wifi print condition icmp //Set a filtering condition. [AP-diagnose] debugging wifi print condition src-mac 2469-a593-6d9a //Set a filtering condition. The source MAC address is the MAC address of the STA. [AP-diagnose] debugging wifi print on print-num 1000 //Set the maximum number of packets that meet the filtering condition and are counted. [AP-diagnose] debugging wifi print condition counter query //Check packet statistics. 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
As shown in the preceding information, the last item is the count when packets enter the Wi-Fi driver module, and the following items are counts of packets in different processes of the Wi-Fi driver module until packets are sent to the forwarding module. In normal cases, the statistics of each process should be the same. If the statistics are different or all 0s, the Wi-Fi driver module discards packets or does not receive packets.
If packet loss occurs during packet sending and receiving, contact technical support personnel.
- Disable the packet tracing function after the fault is rectified.
In V200R019C10, run the following commands.
[AP-diagnose] debugging lmac pkt-print condition clear //Clear the current filtering condition. [AP-diagnose] debugging lmac pkt-print off //Disable the statistics collection function.
In V200R006C20 to V200R019C00, run the following commands.[AP-diagnose] debugging wifi pkt-print clear //Clear the current filtering condition. [AP-diagnose] debugging wifi pkt-print off //Disable the statistics collection function.
In V200R006C10 and earlier versions, run the following commands.
[AP-diagnose] debugging wifi print condition clear //Clear the current filtering condition. [AP-diagnose] debugging wifi print off //Disable the statistics collection function.
- Ping the STA from the AC and use the packet tracing function to trace the transmission of ICMP packets from the network side to the STA.
- Check whether the WMM function is disabled.
On the AC, check whether the WMM function is disabled in the radio profile of the AP. If the WMM function is disabled, the current STA rate can only be the rate defined by 802.11g. In this case, you need to enable the WMM function.
<AC> display radio-5g-profile name default ------------------------------------------------------------ ...... WMM switch : disable ...... ------------------------------------------------------------ <AC> system-view [AC] wlan [AC-wlan-view] radio-5g-profile name default [AC-wlan-radio-5g-prof-default] undo wmm disable
- Check whether a STA with a low link setup rate transmits services of heavy traffic.
When an AP is associated with a low-rate STA that transmits services of heavy traffic, other STAs connected to the AP may fail to access the network. After the STA stops providing services, other STAs can access the network.
- Run the display station ap-id X command to check whether the AP is associated with the STA with a low link setup rate.
<AC> 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
When services are running, if the link setup rate (Tx or Rx) of the STA is less than 30 Mbit/s, the link setup rate of the STA is low.
- Run the display station statistics sta-mac sta-mac command to check STA statistics.
<AC> 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% ------------------------------------------------------------------------------
Generally, if the traffic of a STA exceeds 10 Mbit/s, the STA transmits services of heavy traffic. You need to determine the situation based on the actual network conditions.
To ensure that other STAs can access the network, perform the following operations:
- Limit the rate of a single STA based on the network situation.
<AC> 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
- Enable smart roaming.
<AC> system-view [AC] wlan [AC-wlan-view] rrm-profile name wlan-rrm [AC-wlan-rrm-prof-wlan-rrm] smart-roam enable //In V200R008 and later versions, smart roaming is enabled by default. If smart roaming is disabled, run the undo smart-roam disable command to enable it.
- Run the display station ap-id X command to check whether the AP is associated with the STA with a low link setup rate.
- Check whether ARP packets are discarded on the intermediate device on the wired network side.
If a large number of ARP packets are lost on the intermediate device, the two communication parties cannot learn the ARP entries of each other in a timely manner. As a result, the network is intermittently disconnected.
# Run the display cpu-defend statistics wired command on an intermediate device (such as a switch) to check whether ARP packets are discarded on the intermediate device due to CPCAR on ARP packets.<LSW> 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
If the ARP Request packet loss rate exceeds 50%, the intermediate device discards a large number of ARP packets.
The solution is as follows:
- If the CPU usage is low, increase the rate limit for sending ARP Request packets to the CPU.
<LSW> system-view [LSW] cpu-defend policy test //Create a CPU attack defense policy. [LSW-cpu-defend-policy-test] packet-type arp-request rate-limit 256 wired //Adjust the rate limit of ARP request packets. [LSW-cpu-defend-policy-test] quit [LSW] cpu-defend-policy test //Apply the CPU attack defense policy.
- Configure attack source tracing to prevent ARP flood attacks by STAs.
[LSW] cpu-defend policy test [LSW-cpu-defend-policy-test] auto-defend protocol arp [LSW-cpu-defend-policy-test] auto-defend threshold 50 //Set the threshold for attack source tracing to 50 pps. If the packet rate exceeds the threshold, the device considers that an attack occurs. [LSW-cpu-defend-policy-test] auto-defend action deny timer 60 //After detecting an attack, the device discards the packet and blacklists the STA for 60s. [LSW-cpu-defend-policy-test] quit [LSW] cpu-defend-policy test //Apply the CPU attack defense policy.
- If the CPU usage is low, increase the rate limit for sending ARP Request packets to the CPU.
- Check whether a loop occurs on the wired network.
If a loop occurs on the network, MAC address flapping and network congestion may occur, causing communication failures, packet loss, and long network delay.
- Run the display interface brief command on the switch to check the packet statistics on the interface and observe the incoming and outgoing traffic.
[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
If the difference between the incoming and outgoing traffic on an interface is small, there is a high probability that a loop occurs on the network. In this case, check detailed statistics of the corresponding interface.
- Run the display interface interface-type interface-num command on the switch to check detailed statistics on the corresponding interface and observe the rate at which multicast and broadcast packets increase. You can run the command several times to check the increase of packet statistics.
[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%If the rate at which multicast or broadcast packets increase exceeds 500 pps, a loop may occur on the network. In this case, you need to check the network cable connection and the configuration of the corresponding interface to eliminate loops.
- Run the display interface brief command on the switch to check the packet statistics on the interface and observe the incoming and outgoing traffic.
- Check whether the AP's IP address conflicts.
If an AP's IP address conflicts, the SSID is unstable and STAs frequently go offline.
# Run the display ap all command to check IP addresses of all APs and check whether an IP address conflict occurs.
<AC> 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
- Check whether the CPU usage of the intermediate device on the wired network is normal.
If the CPU usage is always high (higher than 80%), various service exceptions occur, causing packet loss and long network delay.
# Run the display cpu-usage command on the switch to check whether the CPU usage of the intermediate device is normal.
<LSW> 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
There are many causes for high CPU usage. If the CPU usage is always high, rectify the fault according to the troubleshooting procedure in the Switch Maintenance Guide.
- Check whether network cables are properly connected.
If network cables on the intermediate wired network are faulty, a large number of packets are lost and the network delay is long.
# Enter the interface view and run the virtual-cable-test command. If the last four states are OK, the network cables are normal. Otherwise, replace the network cables.[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 -
- Collect fault information.
- Run the display version command on the AC and AP to check the software versions of the AC and AP.
- Collect the results of the preceding troubleshooting procedure.
