Validierung des 802.11ax-Wireless-Durchsatzes und Validierungstests

Einleitung

Dieses Dokument beschreibt die Vorgehensweise zum Testen des Wireless-Durchsatzes eines Access Points mit Schwerpunkt auf 802.11ax und den zu erwartenden Durchsatz.

Voraussetzungen

Anforderungen

In diesem Dokument wird davon ausgegangen, dass die Konfiguration mit 802.11ax/Wi-Fi 6 Access Points (APs) bereits funktioniert, sodass die Client-Konnektivität gewährleistet ist.

Verwendete Komponenten

Die Informationen in diesem Dokument beziehen sich auf die 802.11ax/Wi-Fi 6-Technologie und -Geschwindigkeiten.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Verstehen

Wi-Fi 6 kann auf mehreren Bändern betrieben werden: 2,4 GHz, 5 GHz und sogar das 6 GHz-Band gemäß der Wi-Fi 6E-Zertifizierung.

802.11ac wurde in zwei Phasen bereitgestellt. Die zweite Welle brachte die 160-MHz-Kanalunterstützung, zusammen mit MU-MIMO und einem theoretischen Maximum von 8 Signalströmen.

Diese Zahlen sind nur die theoretischen Zahlen aus dem Standard. Unterschiede gelten je nach AP-Datenblatt.

802.11ax ist nicht direkt in Datenraten Geschwindigkeiten definiert, sondern ist eine Kombination aus 12 Modulation Codierung Schema (MCS 0 bis MCS 11), eine Kanalbreite von 20 MHz (1 Kanal) bis 160 MHz (8 Kanäle), eine Reihe von räumlichen Strömen (in der Regel 1 bis 2, gab es einige 3 räumliche Ströme Produkte, aber sie gesehen werden immer weniger).

Das kurze, mittlere oder lange Guard Interval (GI) fügt ebenfalls eine 10%ige Modifikation hinzu.

In der folgenden Tabelle können Sie eine Datenrate in Mbit/s auswerten, wenn Sie alle diese Faktoren kennen:

Eine vollständigere Tabelle finden Sie unter: https://mcsindex.com/

Hinweis: Die Datenrate entspricht NICHT dem erwarteten erreichbaren Durchsatz. Dies hängt mit der Art des 802.11-Standards zusammen, der einen hohen Verwaltungsaufwand (Management-Frames, Konflikte, Kollisionen, Bestätigungen usw.) aufweist und von der Verbindung SNR, RSSI und anderen wichtigen Faktoren abhängen kann.

Es ist eine Faustregel:

Erwarteter Durchsatz = Datenrate x 0,65

Nehmen wir ein Beispiel aus dem wirklichen Leben. Ein Cisco 9120 AP mit einem modernen Wi-Fi 6-fähigen Smartphone für 2 Signalströme. Wenn wir uns in einer Umgebung mit hoher Dichte befinden, in der 20-MHz-Kanäle verwendet werden, liegt die maximale Datenrate, die je nach Schutzintervall verwendet wird, zwischen 240 und 280 Mbit/s. Das bedeutet, dass in einer sauberen Umgebung und unter Testbedingungen ein Client Daten zwischen 160 und 200 Mbit/s übertragen könnte (65 bis 70 % der Protokolleffizienz). Dies gilt nur bei einem wirklich großen Übertragungs- oder Geschwindigkeitstest, bei dem das Protokoll für maximalen Datendurchsatz optimiert ist. Bei Verwendung anderer Anwendungen sinkt der Durchsatz, da die Latenz auch bei Protokollen eine Rolle spielt, die Pakete pingen und auf Bestätigungen warten, bevor sie weitergeleitet werden.

Beachten Sie auch, dass es sich bei Wireless-Netzwerken um gemeinsam genutzte Umgebungen handelt. Dies bedeutet, dass die Anzahl der mit dem WAP verbundenen Clients den effektiven Durchsatz untereinander aufteilt. Wenn ein Client einen Geschwindigkeitstest durchführt, kann er zwischen 160 und 200 Mbit/s erreichen, d. h. zwei Clients, die gleichzeitig einen Geschwindigkeitstest durchführen, sehen jeweils 80 bis 100 Mbit/s. Wenn vier Clients gleichzeitig einen Geschwindigkeitstest durchführen, sehen sie jeweils 40 bis 50 Mbit/s usw.

Darüber hinaus bedeuten mehr Clients mehr Konkurrenz und unweigerlich mehr Kollisionen. Die Effizienz der Abdeckungszelle nimmt drastisch ab, wenn die Anzahl der Clients steigt. Daher ist es unrealistisch, eine Art SLA für den Durchsatz an Orten festzulegen, an denen Sie die Anzahl der verbundenen Clients oder deren Aktivitäten im Netzwerk nicht kontrollieren.

Messung

Im Allgemeinen können bei einem Durchsatztest zwei Szenarien auftreten:

• APs befinden sich im lokalen Flexconnect-Switching

• APs sind im lokalen Modus oder Flexconnect Central Switching

Betrachten Sie diese Szenarien einzeln:

(Schaubild 1)

Im Fall von Diagramm 1 vermuten wir, dass sich die Access Points im lokalen Modus von Flexconnect Central Switching befinden.

Das bedeutet, dass der gesamte Client-Datenverkehr in den CAPWAP-Tunnel gekapselt und auf dem WLC terminiert wird.

(Schaubild 2)

Die rote Linie in Diagramm 2 zeigt den Datenverkehrsfluss vom Wireless-Client.

Der iPerf-Server muss sich so nah wie möglich am Terminierungspunkt des Datenverkehrs befinden, idealerweise an den gleichen Switch wie der WLC selbst angeschlossen sein und das gleiche VLAN verwenden.

Im Fall von lokalem Flexconnect-Switching wird der Client-Datenverkehr auf dem WAP selbst terminiert. Da der iPerf-Server so eingerichtet werden muss, dass er sich in der Nähe des Terminationspunkts des Wireless-Client-Datenverkehrs befindet, muss der iPerf-Server an denselben Switch und dasselbe VLAN angeschlossen werden, an dem der WAP angeschlossen ist.

In unserem Fall handelt es sich um einen Access Switch (Schaubild 3).

(Schaubild 3)

Die iPerf-Tests lassen sich in zwei Kategorien unterteilen: Upstream und Downstream.

Da der iPerf-Server abhört und der iPerf-Client den Datenverkehr generiert, gilt dies als Upstream-Test, wenn der iPerf-Server auf der kabelgebundenen Seite ist.

Der Wireless-Client nutzt die iPerf-Anwendung, um den Datenverkehr in das Netzwerk zu übertragen.

Der Downstream-Test ist umgekehrt, was bedeutet, dass der iPerf-Server auf dem Wireless-Client selbst eingerichtet ist und der iPerf-Client auf der kabelgebundenen Seite den Datenverkehr an den Wireless-Client weiterleitet. In diesem Szenario wird dies als Downstream betrachtet.

Der Test muss mit TCP und UDP durchgeführt werden. Sie können die folgenden Befehle verwenden, um die Tests durchzuführen:

iperf3 -s  <- this command starts iPerf server

iperf3 -c SERVER_ADDRESS -u -b700M <- this command initiates UDP iPerf test with bandwidth of 700 Mbps

iperf3 -c SERVER_ADDRESS <- this command initiates a simple TCP iPerf test

iperf3 -c SERVER_ADDRESS  -w WINDOW_SIZE  -P NUM_OF_PARALLEL_TCP_STREAMS <- this commands initiates a more complex  TCP iPerf test where you can adjust the window size as well the number of parallel TCP streams. 
Please not that in this case you should consider the sum of all the streams as the result

 

Beispiel für iPerf3-Ausgaben:

TCP iPerf3:

 
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.06  sec   188 MBytes   157 Mbits/sec                  receiver
 
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.05  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.05  sec   304 MBytes   254 Mbits/sec                  receiver

   With 10 parallel TCP streams:
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.06  sec  88.6 MBytes  73.9 Mbits/sec                  receiver
[  7]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  7]   0.00-10.06  sec  79.2 MBytes  66.0 Mbits/sec                  receiver
[  9]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  9]   0.00-10.06  sec  33.6 MBytes  28.0 Mbits/sec                  receiver
[ 11]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 11]   0.00-10.06  sec  48.7 MBytes  40.6 Mbits/sec                  receiver
[ 13]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 13]   0.00-10.06  sec  77.0 MBytes  64.2 Mbits/sec                  receiver
[ 15]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 15]   0.00-10.06  sec  61.8 MBytes  51.5 Mbits/sec                  receiver
[ 17]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 17]   0.00-10.06  sec  46.1 MBytes  38.4 Mbits/sec                  receiver
[ 19]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 19]   0.00-10.06  sec  43.9 MBytes  36.6 Mbits/sec                  receiver
[ 21]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 21]   0.00-10.06  sec  33.3 MBytes  27.8 Mbits/sec                  receiver
[ 23]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 23]   0.00-10.06  sec  88.8 MBytes  74.0 Mbits/sec                  receiver
[SUM]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[SUM]   0.00-10.06  sec   601 MBytes   501 Mbits/sec                  receiver
 

UDP iPerf3:

Bei Verwendung von UDP muss sichergestellt werden, dass es nicht zu geringen Paketverlusten kommt. Es sind zwar sehr hohe Durchsatzzahlen möglich, aber bei einem Paketverlust von 50 % wurden diese Daten nicht übertragen.

Manchmal verhält sich iPerf falsch und gibt am Ende des UDP-Tests nicht die durchschnittliche Bandbreite an.

Es ist weiterhin möglich, die Bandbreite für jede Sekunde zusammenzufassen und dann durch die Anzahl der Sekunden zu teilen:

Accepted connection from 192.168.240.38, port 49264
[  5] local 192.168.240.43 port 5201 connected to 192.168.240.38 port 51711
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  53.3 MBytes   447 Mbits/sec  0.113 ms  32/6840 (0.47%)  
[  5]   1.00-2.00   sec  63.5 MBytes   533 Mbits/sec  0.129 ms  29/8161 (0.36%)  
[  5]   2.00-3.00   sec  69.8 MBytes   586 Mbits/sec  0.067 ms  30/8968 (0.33%)  
[  5]   3.00-4.00   sec  68.7 MBytes   577 Mbits/sec  0.071 ms  29/8827 (0.33%)  
[  5]   4.00-5.00   sec  68.0 MBytes   571 Mbits/sec  0.086 ms  55/8736 (0.63%)  
[  5]   5.00-6.00   sec  68.6 MBytes   576 Mbits/sec  0.076 ms  70/8854 (0.79%)  
[  5]   6.00-7.00   sec  66.8 MBytes   561 Mbits/sec  0.073 ms  34/8587 (0.4%)  
[  5]   7.00-8.00   sec  67.1 MBytes   563 Mbits/sec  0.105 ms  44/8634 (0.51%)  
[  5]   8.00-9.00   sec  66.7 MBytes   559 Mbits/sec  0.183 ms  144/8603 (1.7%)  
[  5]   9.00-10.00  sec  64.1 MBytes   536 Mbits/sec  0.472 ms  314/8415 (3.7%)  
[  5]  10.00-10.05  sec   488 KBytes  76.0 Mbits/sec  0.655 ms  2/63 (3.2%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.05  sec  0.00 Bytes  0.00 bits/sec  0.655 ms  783/84688 (0.92%)  
[SUM]  0.0-10.1 sec  224 datagrams received out-of-order

Hinweis: Es wird erwartet, dass die iPerf-Ergebnisse beim lokalen Flexconnect-Switching etwas besser sind als beim Szenario mit zentralem Switching.
Dies wird durch die Tatsache verursacht, dass der Client-Datenverkehr in CAPWAP eingekapselt wird, wodurch mehr Overhead für den Datenverkehr entsteht und der WLC im Allgemeinen als Engpass fungiert, da er der Aggregationspunkt für den gesamten Datenverkehr der Wireless-Clients ist.
Außerdem wird erwartet, dass der UDP iPerf-Test bessere Ergebnisse in einer sauberen Umgebung liefert, da er die effizienteste Übertragungsmethode ist, wenn die Verbindung zuverlässig ist. TCP kann jedoch bei starker Fragmentierung (bei Verwendung von TCP Adjust MSS) oder unzuverlässiger Verbindung gewinnen

.

Überprüfung und Validierung

Führen Sie in der WLC-CLI den folgenden Befehl aus, um zu überprüfen, mit welcher Datenrate der Client verbunden ist:

WLC#show wireless client mac e88d.a6b0.3bca det

Client MAC Address : e88d.a6b0.3bca
Client MAC Type : Universally Administered Address
Client DUID: NA
Client IPv4 Address : 192.168.1.44
Client IPv6 Addresses : fe80::7798:a5a:a957:ec89
Client Username: N/A
AP MAC Address : 18f9.354d.9d60
AP Name: 9164-etage
AP slot : 1
Client State : Associated
Policy Profile : Darchispp
Flex Profile : default-flex-profile
Wireless LAN Id: 2
WLAN Profile Name: Darchis6
Wireless LAN Network Name (SSID): Darchis6
BSSID : 18f9.354d.9d6f
Connected For : 103 seconds
Protocol : 802.11ax - 5 GHz
Channel : 52
Client IIF-ID : 0xa0000003
Association Id : 2
Authentication Algorithm : Open System
Idle state timeout : N/A
Session Timeout : 80000 sec (Remaining time: 79899 sec)
Session Warning Time : Timer not running
Input Policy Name  : None
Input Policy State : None
Input Policy Source : None
Output Policy Name  : None
Output Policy State : None
Output Policy Source : None
WMM Support : Enabled
U-APSD Support : Disabled
Fastlane Support : Disabled
Client Active State : Active
Power Save : ON
Current Rate : m10 ss2
Supported Rates : 54.0
AAA QoS Rate Limit Parameters:
  QoS Average Data Rate Upstream             :  (kbps)
  QoS Realtime Average Data Rate Upstream    :  (kbps)
  QoS Burst Data Rate Upstream               :  (kbps)
  QoS Realtime Burst Data Rate Upstream      :  (kbps)
  QoS Average Data Rate Downstream           :  (kbps)
  QoS Realtime Average Data Rate Downstream  :  (kbps)
  QoS Burst Data Rate Downstream             :  (kbps)
  QoS Realtime Burst Data Rate Downstream    :  (kbps)
Mobility:
  Move Count                  : 0
  Mobility Role               : Local
  Mobility Roam Type          : None
  Mobility Complete Timestamp : 02/26/2024 14:35:10 Central
Client Join Time:
  Join Time Of Client : 02/26/2024 14:35:10 Central
Client State Servers : None
Client ACLs : None
Policy Manager State: Run
Last Policy Manager State : IP Learn Complete
Client Entry Create Time : 103 seconds
Policy Type : WPA3
Encryption Cipher : CCMP (AES)
Authentication Key Management : FT-SAE
AAA override passphrase : No
SAE PWE Method : Hash to Element(H2E)
Transition Disable Bitmap : None
User Defined (Private) Network : Disabled
User Defined (Private) Network Drop Unicast : Disabled
Encrypted Traffic Analytics : No
Protected Management Frame - 802.11w : Yes
EAP Type : Not Applicable
VLAN Override after Webauth : No
VLAN : default
Multicast VLAN : 0
VRF Name : N/A
WiFi Direct Capabilities:
  WiFi Direct Capable           : No
Central NAT : DISABLED
Session Manager:
  Point of Attachment : capwap_90000002
  IIF ID             : 0x90000002
  Authorized         : TRUE
  Session timeout    : 80000
  Common Session ID: 00000000000041B8E5D75432
  Acct Session ID  : 0x00000000
  Auth Method Status List
  	Method : FT-SAE
  Local Policies:
  	Service Template : wlan_svc_Darchispp (priority 254)
  		VLAN             : 1
  		Absolute-Timer   : 80000
  Server Policies:
  Resultant Policies:
  		VLAN Name        : default
  		VLAN             : 1
  		Absolute-Timer   : 80000
DNS Snooped IPv4 Addresses : None
DNS Snooped IPv6 Addresses : None
Client Capabilities
  CF Pollable : Not implemented
  CF Poll Request : Not implemented
  Short Preamble : Not implemented
  PBCC : Not implemented
  Channel Agility : Not implemented
  Listen Interval : 0
Fast BSS Transition Details :
  Reassociation Timeout : 20
11v BSS Transition : Implemented
11v DMS Capable : No
QoS Map Capable : No
FlexConnect Data Switching : Local
FlexConnect Dhcp Status : Local
FlexConnect Authentication : Local
Client Statistics:
  Number of Bytes Received from Client : 64189
  Number of Bytes Sent to Client : 85831
  Number of Packets Received from Client : 808
  Number of Packets Sent to Client : 244
  Number of Data Retries : 66
  Number of RTS Retries : 0
  Number of Tx Total Dropped Packets : 0
  Number of Duplicate Received Packets : 0
  Number of Decrypt Failed Packets : 0
  Number of Mic Failured Packets : 0
  Number of Mic Missing Packets : 0
  Number of Policy Errors : 0
  Radio Signal Strength Indicator : -41 dBm
  Signal to Noise Ratio : 52 dB
Fabric status : Disabled
Radio Measurement Enabled Capabilities
  Capabilities: None
Client Scan Report Time : Timer not running
Client Scan Reports
Assisted Roaming Neighbor List
Nearby AP Statistics:
EoGRE : Pending Classification
Device Classification Information:
  Device Type      : Un-Classified Device
  Device Name      : Unknown Device
  Protocol Map     : 0x000001  (OUI)
Max Client Protocol Capability:
WiFi to Cellular Steering : Not implemented
Cellular Capability : N/A
Advanced Scheduling Requests Details:
  Apple Specific Requests(ASR) Capabilities/Statistics:
    Regular ASR support: DISABLED

Sie können sehen, dass dieser Client mit folgender Geschwindigkeit verbunden ist:

Aktuelle Rate..................................... m10 ss2

Das bedeutet, dass der Client den MCS 10-Index (m10) für zwei räumliche Streams (ss2) verwendet.

Über den Befehl "show wireless client mac <MAC> det" kann nicht ermittelt werden, ob der Client über 20/40/80-MHz-Channel-Bonding verbunden ist.

Dies kann direkt am Access Point erfolgen:

Beispiel für 9164:

#show controllers dot11Radio 2 client E8:8D:A6:B0:3B:CA
              mac radio vap aid state       encr  Maxrate Assoc   Cap is_wgb_wired      wgb_mac_addr
E8:8D:A6:B0:3B:CA     2   0  33   FWD AES_CCM128 MCS112SS HE-6E HE-6E        false 00:00:00:00:00:00
Configured rates for client E8:8D:A6:B0:3B:CA
Legacy Rates(Mbps): 6 9 12 18 24 36 48 54
HE Rates: 1SS:M0-11 2SS:M0-11
HT:yes     VHT:no     HE:yes     40MHz:no     80MHz:yes     80+80MHz:no     160MHz:yes
11w:yes     MFP:no     11h:no     session_timeout: 79950     encrypt_policy: 4
_wmm_enabled:yes     qos_capable:yes     WME(11e):no     WMM_MIXED_MODE:no
short_preamble:no     short_slot_time:no     short_hdr:no     SM_dyn:no
short_GI_20M:no     short_GI_40M:no     short_GI_80M:no     LDPC:no     AMSDU:yes     AMSDU_long:no
su_mimo_capable:no     mu_mimo_capable:no     is_wgb_wired:no     is_wgb:no
HE_DL-MIMO:yes     HE_UL-MIMO:yes     HE_DL-OFDMA:yes     HE_UL-OFDMA:yes     HE_TWT_CAPABLE:no

Additional info for client E8:8D:A6:B0:3B:CA
RSSI: -52
SNR: 41
PS  : Legacy (Sleeping)
Tx Rate: 1297100 Kbps
Rx Rate: 1921600 Kbps
VHT_TXMAP: 0
CCX Ver: 0
Rx Key-Index Errs: 0

Statistics for client E8:8D:A6:B0:3B:CA
              mac   intf TxData TxMgmt TxUC TxBytes TxFail TxDcrd TxCumRetries RxData RxMgmt RxBytes RxErr                      TxRt(Mbps) RxRt(Mbps) idle_counter stats_ago expirat
ion
E8:8D:A6:B0:3B:CA apr2v0    391      4  391  129127      0      0           97    559      4   74055     0 HE-160,2SS,MCS6,GI0.8 ,BF(1297)         12          295  8.674000      79
950

Per TID packet statistics for client E8:8D:A6:B0:3B:CA
Priority Rx Pkts Tx Pkts Rx(last 5 s) Tx (last 5 s)
       0     539     383           84            28
       1       0       0            0             0
       2       0       2            0             0
       3       0       0            0             0
       4       0       0            0             0
       5       0       0            0             0
       6      20       3            5             1
       7       0       3            0             0

 Rate Statistics:
Rate-Index    Rx-Pkts    Tx-Pkts Tx-Retries
         0        176          3          0
         5          0         62          0
         6          4        178         21
         7        250        152         52
         8        100          2         22
         9         51          0          0
        10          1          0          0
        11          0          0          2
webauth done: true
Pre-WebAuth ACLs:
Post-Auth ACLs:
Acl name Quota Bytes left In bytes Out bytes In pkts Out pkts Drops-in Drops-out
iPSK TAG: \<0000000000000000>
              MAC Allow HIT iPSK tag
E8:8D:A6:B0:3B:CA  true   0      \<>

Die letzte Option zum Überprüfen der verbundenen Rate sind OTA-Erfassungen. In der Funkinformation des Datenpakets finden Sie die notwendigen Informationen:

 Diese OTA-Aufnahme wurde mit einem 11ac-Macbook-Client gemacht.

Fehlerbehebung

Falls Sie während des Tests keine erwarteten Ergebnisse erhalten, gibt es mehrere Möglichkeiten, das Problem zu beheben und die erforderlichen Informationen zu sammeln, bevor Sie ein TAC-Ticket erstellen.

Die Durchsatzprobleme können durch folgende Faktoren verursacht werden:

-Kunde

- AP

- Kabelgebundener Pfad (Switching-bezogene Probleme)

- WLC

Client-Fehlerbehebung

• Im ersten Schritt werden die Treiber auf den Wireless-Client-Geräten auf die neueste Version aktualisiert.
• Der zweite Schritt besteht darin, den iPerf-Test mit Clients durchzuführen, die über einen anderen Wireless-Adapter verfügen, um festzustellen, ob Sie die gleichen Ergebnisse erhalten.

AP-Fehlerbehebung

Es kann Szenarien geben, in denen der Access Point Datenverkehr verwirft, bestimmte Frames verwirft oder sich anderweitig falsch verhält.

Um mehr Einblicke in dieses Thema zu erhalten, sind Over The Air (OTA)-Erfassungen und eine übergreifende Sitzung auf dem AP-Switch-Port erforderlich (die Übertragung muss auf dem Switch erfolgen, an dem der AP angeschlossen ist).

Die OTA-Erfassungen und das SPAN müssen während des Tests mithilfe einer offenen SSID erfolgen, damit der an den WAP weitergeleitete Datenverkehr und der Datenverkehr, der an den Client weitergeleitet wird, sichtbar ist und umgekehrt.

Es gibt mehrere bekannte Fehler für dieses Verhalten:

CSCvg07438 : AP3800: Niedriger Durchsatz aufgrund von Paketverlusten im AP in fragmentierten und nicht fragmentierten Paketen

CSCva58429 : Cisco 1532i AP: niedriger Durchsatz (FlexConnect Local Switching + EoGRE)

Fehlerbehebung für kabelgebundene Pfade

Der Switch selbst kann einige Probleme aufweisen. Sie müssen überprüfen, wie viele Drops auf den Schnittstellen vorhanden sind und ob diese während der Tests zunehmen.

Verwenden Sie einen anderen Port am Switch, um den AP oder WLC anzuschließen.

Eine weitere Option besteht darin, einen Client an denselben Switch anzuschließen (an den der Client-Terminierungspunkt [AP/WLC] angeschlossen ist) und in dasselbe VLAN zu verlegen. Anschließend führen Sie die Tests mit kabelgebundenen Komponenten auf demselben VLAN aus, um festzustellen, ob Probleme mit dem kabelgebundenen Pfad bestehen.

WLC-Fehlerbehebung

Möglicherweise verwirft der WLC den Datenverkehr vom Client (wenn sich die Access Points im lokalen Modus befinden).

Sie können den Access Point in den Flexconnect-Modus und das WLAN in das lokale Switching versetzen und anschließend die Tests ausführen.

Wenn Sie sehen, dass es erhebliche Unterschiede im Durchsatz im lokalen Modus (zentrales Switching) im Vergleich zu Flexconnect lokales Switching gibt und es kein Problem auf dem Switch gibt, der mit dem WLC verbunden ist, dann verwirft der WLC höchstwahrscheinlich den Datenverkehr.

Wenden Sie zur Fehlerbehebung folgenden Aktionsplan an:

- SPAN-Erfassung am WLC-Switch-Port (muss am Switch erfolgen)

- SPAN-Erfassung am AP-Port

- OTA-Erfassung des Kunden

Durch die Durchführung dieser Fehlerbehebung und die Übermittlung der Ergebnisse an das TAC wird der Fehlerbehebungsprozess beschleunigt.