Valideren van 802.11ax draadloze doorvoersnelheid en validatietests

Inleiding

Dit document beschrijft de manier waarop de draadloze doorvoersnelheid van een access point kan worden getest met de focus op 802.11ax en welke doorvoersnelheid u kunt verwachten.

Voorwaarden

Vereisten

Voor dit document is de configuratie al actief met 802.11ax/Wi-Fi 6 access points (AP’s) die al clientconnectiviteit bieden

Gebruikte componenten

De informatie in dit document is gericht op 802.11ax/Wi-Fi 6 technologie en snelheden.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

begrijpen

Wi-Fi 6 kan werken op verschillende banden: 2,4 GHz, 5 GHz en zelfs de 6GHz band volgens de Wi-Fi 6E certificering.

802.11ac kwam in twee golven. De tweede golf bracht de 160Mhz kanaalondersteuning, samen met MU-MIMO en een theoretisch maximum van 8 ruimtelijke stromen.

Deze getallen zijn alleen de theoretische getallen van de standaard, verschillen zijn van toepassing afhankelijk van het specifieke AP datasheet.

802.11ax is niet direct gedefinieerd in gegevenssnelheden, maar is eerder een combinatie van 12 modulatie coderingsschema (MCS 0 tot MCS 11), een kanaalbreedte variërend van 20mhz (1 kanaal) tot 160Mhz (8 kanalen), een aantal ruimtelijke stromen (meestal 1 tot 2, zijn er ongeveer 3 ruimtelijke stromen producten maar ze worden minder en minder gezien).

Het korte, middellange of lange Guard Interval (GI) voegt hier ook een 10% wijziging aan toe.

Hier is een tabel om een data-rate in Mbps te evalueren bij het kennen van al die factoren:

Een vollediger tabel is te vinden op: https://mcsindex.com/

Opmerking: de gegevenssnelheid is NIET gelijk aan de verwachte haalbare doorvoersnelheid. Dit is gerelateerd aan de aard van 802.11 standaard die veel administratieve overheadkosten heeft (managementframes, geschil, botsing, bevestigingen,...) en het kan afhangen van de koppeling SNR, RSSI en andere belangrijke factoren.

Het is een vuistregel:

Verwachte doorvoersnelheid = gegevenssnelheid x 0,65

Neem een voorbeeld uit het echte leven. Een Cisco 9120 AP met een moderne Wi-Fi 6-compatibele smartphone die 2 Spatial Streams kan verwerken. Als we in een omgeving met hoge dichtheid zijn waar 20 MHz kanalen worden gebruikt, is de maximale gegevenssnelheid tussen 240 en 280 Mbps afhankelijk van het wachtinterval. Dit betekent dat, in een schone omgeving en testomstandigheden, we kunnen hebben een klant die gegevens overdraagt tussen 160 tot 200 Mbps mogelijk (65 tot 70% van de protocol efficiëntie). Dit is alleen geldig bij een eigenlijke grote overdracht of snelheidstest waarbij het protocol geoptimaliseerd is voor maximale doorvoersnelheid. Wanneer het gebruiken van andere toepassingen, gaat de productie omlaag aangezien de latentie ook een rol in protocollen speelt die een ping-pong van pakketten doen en op erkenning wachten alvorens zich voorwaarts te bewegen.

Let ook op dat de draadloze verbinding een gedeelde omgeving is, dit betekent dat de hoeveelheid clients die zijn aangesloten op de AP de effectieve doorvoersnelheid tussen elkaar delen. Als een client die een snelheidstest doet tussen 160 en 200MBps kan bereiken, betekent dit dat twee clients die een snelheidstest doen tegelijkertijd elke 80 tot 100Mbps zien. Als vier clients tegelijkertijd een snelheidstest uitvoeren, zien ze 40 tot 50 Mbps elk en zo ...

Bovendien betekenen meer klanten meer conflicten en onvermijdelijk meer botsingen. De efficiëntie van de dekkingcel neemt drastisch af naarmate het aantal klanten toeneemt. Het is daarom niet realistisch om enige vorm van SLA voor doorvoersnelheid in te stellen op plaatsen waar u niet de hoeveelheid verbonden cliënten controleert of wat zij op het netwerk in termen van activiteit doen.

Meetlat

Over het algemeen, kunnen wij twee scenario's hebben wanneer u een productietest doet:

• AP's zijn opgenomen in Flexconnect local switching

• AP's zijn in de lokale modus of Flexconnect central switching

Neem deze scenario's een voor een:

(Afbeelding 1)

In het geval van Diagram 1 veronderstellen we dat de AP's in de lokale modus van Flexconnect centrale switching zijn.

Dit betekent dat al het clientverkeer is ingekapseld in CAPWAP-tunnels en wordt afgesloten met de WLC.

(Afbeelding 2)

De rode lijn in Diagram 2 toont de verkeersstroom van de draadloze client.

De iPerf-server moet zo dicht mogelijk bij het stoppunt van het verkeer staan, idealiter in dezelfde switch als de WLC zelf worden aangesloten en hetzelfde VLAN gebruiken.

In het geval van lokale switching voor Flexconnect wordt het clientverkeer op het toegangspunt zelf beëindigd. Hierbij wordt er rekening mee gehouden dat de iPerf-server zo dicht mogelijk bij het afsluitpunt van het draadloze clientverkeer moet worden ingesteld, en steek de iPerf-server in dezelfde switch en hetzelfde VLAN waar het toegangspunt is aangesloten.

In ons geval is dit access switch (Afbeelding 3).

(Afbeelding 3)

De iPerf-tests kunnen in twee categorieën worden onderverdeeld: stroomopwaarts en stroomafwaarts.

Gezien het feit dat de iPerf-server luistert en iPerf-client het verkeer genereert, wordt dit, wanneer de iPerf-server zich aan de bekabelde kant bevindt, beschouwd als een upstream-test.

De draadloze client gebruikt de iPerf-toepassing om het verkeer naar het netwerk te duwen.

De stroomafwaartse test is omgekeerd, wat betekent dat de iPerf-server is ingesteld op de draadloze client zelf en dat de iPerf-client aan de bekabelde kant het verkeer naar de draadloze client duwt, in dit scenario wordt dit als stroomafwaarts beschouwd.

De test moet worden uitgevoerd met TCP en UDP. U kunt deze opdrachten gebruiken om de tests uit te voeren:

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

 

Voorbeeld van iPerf3-uitgangen:

TCP-perf3:

 
[ 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:

Wanneer het gebruiken van UDP, is het belangrijk om ervoor te zorgen er niet aan weinig pakketverlies. Het is mogelijk om zeer hoge doorvoernummers te zien, maar als je een pakketverlies van 50% hebt, heb je die hoeveelheid gegevens niet daadwerkelijk overgedragen.

Soms gedraagt iPerf zich niet en geeft hij niet de gemiddelde bandbreedte aan het eind van de UDP-test.

Het is nog steeds mogelijk om de bandbreedte voor elke seconde op te tellen en deze vervolgens te delen door het aantal seconden:

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

Opmerking: verwacht wordt dat de resultaten van iPerf op de lokale overschakeling van Flexconnect iets beter zijn dan bij het centrale overschakelingsscenario.
Dit wordt veroorzaakt door het feit dat het cliëntverkeer in CAPWAP wordt ingekapseld, dat meer overheadkosten aan het verkeer toevoegt en in het algemeen werkt WLC als knelpunt aangezien het het samenvoegingspunt voor al draadloos cliëntverkeer is.
Bovendien wordt verwacht dat de UDP iPerf-test betere resultaten zal opleveren in een schone omgeving, aangezien het de meest efficiënte overdrachtmethode is wanneer de verbinding betrouwbaar is. TCP kan echter winnen in geval van zware fragmentatie (wanneer TCP MSS wordt gebruikt) of onbetrouwbare verbinding

.

Verifiëren en valideren

Om te controleren bij welke gegevenssnelheid de client is aangesloten, geeft u deze opdracht in WLC CLI uit:

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

U kunt zien dat deze bepaalde client is aangesloten op deze snelheid:

Huidige snelheid..................................... m10 ss2

Dit betekent dat de client de MCS 10 (m10) index gebruikt op 2 ruimtelijke stromen (ss2)

Van de "show wireless client mac <MAC> det" opdracht, is het niet mogelijk om te zien of de client is verbonden op 20/40/80 MHz kanaal bonding.

Dit kan direct op het toegangspunt worden gedaan:

9164 voorbeeld:

#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      \<>

De laatste optie om de aangesloten snelheid te controleren is OTA vangt. In de radioinformatie van het gegevenspakket kunt u de benodigde informatie vinden:

 Deze OTA-opname werd genomen met een 11ac macbook-client.

Problemen oplossen

Als u tijdens de test geen verwachte resultaten krijgt, zijn er verschillende manieren om het probleem op te lossen en de benodigde informatie te verzamelen voordat u een TAC-case opent.

De doorvoerproblemen kunnen door deze factoren worden veroorzaakt:

-Klant

- AP

- bekabeld pad (switching gerelateerde problemen)

- WLC

Probleemoplossing voor clients

• De eerste stap is het updaten van de stuurprogramma's op de draadloze clientapparaten naar de nieuwste versie
• De tweede stap is het doen van de iPerf test met clients die een andere draadloze adapter hebben om te zien of u dezelfde resultaten krijgt

Probleemoplossing AP

Er kunnen scenario's zijn wanneer het toegangspunt verkeer laat vallen, of bepaalde frames of anderszins zich misdraagt.

Om hier meer inzicht in te krijgen, zijn er nood aan Over The Air (OTA) neemt + span sessie op de AP switchport (span moet worden gedaan op de switch waar de AP is aangesloten)

OTA vangt en SPAN moet tijdens de test worden gedaan, die open SSID gebruiken om het verkeer te kunnen zien dat tot AP wordt overgegaan en AP van het verkeer is dat naar de cliënt overgaat en vice versa.

Er zijn verschillende bekende bugs voor dit gedrag:

CSCvg07438 : AP3800: lage doorvoersnelheid vanwege pakketdalingen in AP in zowel gefragmenteerde als niet-gefragmenteerde pakketten

CSCva58429: Cisco 1532i AP: lage doorvoersnelheid (FlexConnect Local Switching + EoGRE)

Probleemoplossing voor bekabeld pad

Er kunnen enkele problemen zijn op de switch zelf, moet u controleren hoeveel druppels op de interfaces en als die tijdens de tests toenemen.

Probeer een andere poort op de switch te gebruiken om de AP of WLC aan te sluiten.

Een andere optie is om een client in te pluggen op dezelfde switch (waar het client-afsluitpunt [AP/WLC] is aangesloten) en deze op hetzelfde VLAN te plaatsen, en vervolgens de tests uit te voeren die zijn bekabeld om op hetzelfde VLAN te worden bedrad om te zien of er problemen zijn met het bekabelde pad.

WLC-probleemoplossing

Het kan zijn dat de WLC het verkeer (wanneer AP's in lokale modus zijn) van de client laat vallen.

U kunt het toegangspunt in de Flexconnect-modus zetten en het WLAN in lokale switching plaatsen, en vervolgens de tests uitvoeren.

Als u ziet dat er significante verschillen zijn in de doorvoersnelheid in de lokale modus (centrale switching) in vergelijking met Flexconnect lokale switching en er is geen probleem op de switch die is aangesloten op WLC, dan is de WLC zeer waarschijnlijk het verkeer aan het laten vallen.

Om dit op te lossen, pas het actieplan toe:

- SPAN neemt op de WLC-switchpoort op (dit moet op de switch gebeuren)

- SPAN neemt op de AP poort op

- OTA van de klant

Door deze probleemoplossing uit te voeren en de resultaten aan TAC te leveren, versnelt dit het proces voor probleemoplossing.