Inhoud

Inleiding

Achtergrond

De maximale verwachte doorvoersnelheid bepalen

Stel de basislijn-ervaring in

Zoek naar afwijkingen van de ervaring

Het vinden van bewijs van een probleem (passief testen)

1. Het client assurance-dashboard op Cisco Catalyst Center

2. Het dashboard en het apparaat 360 van de netwerkverzekering op Cisco Catalyst Center

3. AI-analyse

Actief testen van de infrastructuur

Problemen met doorvoersnelheid oplossen

Inleiding

In dit document wordt beschreven hoe u doorvoerproblemen in grote Wi-Fi-netwerken kunt bewaken en oplossen.

Achtergrond

In Wi-Fi netwerken zijn er niet veel soorten eindgebruikers die problemen ervaren.

De gemelde problemen kunnen variëren van:

- cliënten die geen verbinding kunnen maken;

- klanten die plotseling worden losgekoppeld of;

- de waargenomen snelheid van de toepassing op de gebruikersvoorziening niet bevredigend is.

Achter deze eenvoudige symptomen kunnen honderden soorten problemen liggen, waarvan de meeste niet eens betrekking hebben op echte Wi-Fi netwerken zoals DNS-problemen, problemen met internetverbindingen, enzovoort.

Beheerservers zoals Cisco Catalyst Center helpen de beheerder bij het oplossen van specifieke problemen. Dit artikel gaat niet in detail in op de vele soorten dagelijkse problemen die eenvoudig kunnen worden gezien en opgelost via Catalyst Center. In plaats daarvan richt dit document zich op de meer vage feedback van eindgebruikers dat het netwerk traag is.

Hoe dat te testen? Hoe de daadwerkelijke doorvoersnelheid in uw netwerk te valideren? Hoe de snelheidsgerelateerde problemen te trainen in werkbare items om de algemene eindgebruikerservaring te verbeteren?

Dit zijn allemaal vragen waarop dit document een antwoord probeert te geven.

De maximale verwachte doorvoersnelheid bepalen

De eerste vraag in elk netwerk is: wat is de maximumsnelheid die potentieel en realistisch kan worden bereikt?

Aangezien Wi-Fi een gedeeld medium is, hangt de snelheid die wordt ervaren rechtstreeks af van het aantal clients en apparaten die Wi-Fi op hetzelfde moment gebruiken op hetzelfde kanaal. Daarom impliceert deze vraag naar de werkelijke maximumsnelheid die direct kan worden bereikt dat er één clientapparaat en één toegangspunt is in een rustige geïsoleerde plaats waar niemand gebruik maakt van hetzelfde Wi-Fi-kanaal. Onder deze omstandigheden leiden de factoren om de maximumsnelheid te bepalen tot:

- Het gebruikte Wi-Fi-protocol (Wi-Fi 5, Wi-Fi 6, ...)

- De hardwaremogelijkheden van de client en het toegangspunt (aantal antennes, aantal ruimtelijke stromen, Ethernet-verbinding van het toegangspunt, ...)

- De configuratie (kanaalbreedte, ...)

Het kennen van deze factoren staat u toe om een schatting te hebben van wat de maximum echt-levenproductie u zou kunnen hopen om in laboratoriumomstandigheden te bereiken.

Om een snel idee te krijgen, controleert u bij welke gegevenssnelheid uw klant rapporteert om met het toegangspunt worden verbonden. Dit gegevenstarief is niet de daadwerkelijke productie u in uw tests kunt bewijzen. Dit komt doordat Wi-Fi een half-duplex medium is dat wat beheer overhead heeft (frames moeten worden erkend, bakens moeten worden verzonden) en ook korte stiltes tussen frames voor een betere ontvangst en decodering. Dit betekent dat, wanneer gegevens worden verzonden, het wordt verzonden aan het gedocumenteerde gegevenstarief, maar de gegevens worden niet altijd verzonden. Beheer- en controleframes worden met een veel lagere gegevenssnelheid verzonden om de ontvangst te garanderen. Een schatting is dat je kunt overwegen om 65 tot 70% van de gegevenssnelheid te bereiken die gebruikt wordt in een echte doorvoertest. Als uw client bijvoorbeeld meldt dat er verbinding is gemaakt en gegevens worden verzonden met een snelheid van 866 Mbps, moeten de werkelijke tests een overdrachtsnelheid van ongeveer 600 Mbps melden.

Als u de configuratieparameters in gebruik en de hardwaremogelijkheden van de betrokken apparaten kent, kunt u ook uitzoeken welke maximale gegevenssnelheid (en dus doorvoersnelheid, met behulp van de in deze sectie gedocumenteerde procentuele berekening) haalbaar moet zijn.

Als er een verschil is tussen de gerapporteerde gegevenssnelheid en de snelheid die u hoopt te bereiken, kunt u het probleemoplossingsproces starten door de configuratie en de verschillende parameters verifiëren om te begrijpen waar de kloof is.

Een voorbeeld: als u een access point model C9120 uitzending op 20Mhz kanaalbreedte in de 5GHz band en een typische 2 spatial streams Wi-Fi 6 client, kunt u berekenen dat, in een perfect schone RF (Radio Frequency) omgeving, met één enkele client kunt u hopen om 160 tot 200Mbps te bereiken in een enkele bestandsoverdracht.

Meer informatie over het testen en valideren van de doorvoersnelheid wordt hier gedocumenteerd: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/212892-802-11ac-wireless-throughput-testing-and.html.

Stel de basislijn-ervaring in

Het is belangrijk om te weten wat er op uw locatie kan worden verwacht in typische omstandigheden. Het is vaak het geval dat een technicus de lege site bezoekt voordat de implementatie wordt geïmplementeerd, snelheidstests uitvoert en de verwachte nummers van documenten registreert.

Dan komen medewerkers of klanten binnen, de site wordt druk, en de werkelijke ervaring verschilt erg.

Nadat een implementatie live gaat, is het een slim idee om technici te sturen om de werkelijke ervaring in elk gebied te meten en een notitie te nemen van hoe het netwerk eruit ziet op een gemiddelde goede dag.

Dit omvat de gemiddelde hoeveelheid cliënten per radio wanneer het netwerk op een bevredigend niveau werkt evenals de gemiddelde productie die met een snelheidstest wordt bereikt.

Zoek naar afwijkingen van de ervaring

Bij het bedienen van uw netwerk is het controleren op grote waarschuwingen of apparaten die plotseling omlaag gaan eenvoudig. Dit document concentreert zich op het harde deel: hoe u een draadloos netwerk kunt herkennen dat nog steeds werkt maar een ondergeschikte eindgebruikerservaring biedt.

Het vinden van bewijs van een probleem (passief testen)

Je hebt je netwerk zelf getest; je weet dat het prima werkt en je houdt je managementsystemen en dashboards in de gaten. Er wordt niets gemeld zoals beneden: je kunt een stap achteruit doen en ontspannen. Of kunt u dat doen?

Als je wacht op echo's van eindgebruikers die klagen over de slechte ervaring, is de kans groot dat je te laat bent. Wanneer eindgebruikers klagen, is het probleem al lange tijd aan de gang en hoor je alleen van de weinige gebruikers die genoeg stem hebben om het te horen.

Talloze gebruikers zijn al gefrustreerd, zeiden niets tegen u of uw helpdesk, maar gaven een slechte reputatie aan uw netwerk.

De vraag is dus: hoe kun je gevallen van slechte ervaring herkennen zodra ze zich voordoen?

1. Het client assurance-dashboard op Cisco Catalyst Center

In het Cisco Catalyst Center-betrouwbaarheidsdashboard hebt u een algemene grafiek van de gezondheid van uw clients.

Er zijn altijd een aantal klanten die niet in staat zijn om verbinding te maken omdat iemand de verkeerde sleutel heeft ingevoerd, of het apparaat zit aan de rand van uw dekking, dus niet hopen om 100% van gezonde klanten te bereiken, maar vertrouwd zijn met wat een goed percentage van gezonde klanten voor uw omgeving is.

In de jaren '90 zijn is meestal goed nieuws.

Met een snelle blik kunt u zien wat er gebeurt met de klanten die niet gezond zijn:

- Zijn ze ver verwijderd van het toegangspunt (Access points)?

- Is dit een verificatieprobleem?

Op deze grafiek kunt u gemakkelijk de verhouding van elke categorie zien.

In dezelfde reeks ideeën kun je naar de onderkant van die pagina en filter bladeren om de clientapparaten weer te geven die worden gemeld als slecht. U kunt dan proberen om te zien of er een patroon is:

- Ze zijn mogelijk allemaal aangesloten op de 2,4 GHz band (waarvan bekend is dat het in veel gevallen een slechtere ervaring geeft);

- Zij worden mogelijk allemaal gerapporteerd bij een lage signaalsterkte;

- Ze bevinden zich fysiek allemaal in hetzelfde gebied.

2. Het dashboard en het apparaat 360 van de netwerkverzekering op Cisco Catalyst Center

Een bijzonder goede metriek om een specifiek potentieel gebied van problemen te herkennen moet naar de pagina van de Verzekering van het Netwerk van Cisco Catalyst Center gaan. Je hebt een widget die de top access points toont op basis van het aantal klanten:

Als het hoogste toegangspunt in uw netwerk 40 verbonden cliënten heeft, bent u goed. Dit betekent dat alle andere AP's (Access points) een lager aantal clients hebben.

Aan de andere kant, als je de bovenste AP(s) vindt die een ongewoon hoog aantal clients hebben, kun je raden dat de client ervaring daar bijzonder slecht is (tenzij de meeste clients slapen en niet actief zijn op het netwerk).

U kunt dan naar een "per AP"-onderzoek gaan waar u inzoomt op de specifieke top AP's die in deze widget worden gerapporteerd om hun huidige gezondheid te begrijpen.

Een andere methode om te kijken naar het aantal klanten is om naar de kaarten in de pagina van de Netwerkhiërarchie van uw Catalyst Center te gaan. Eenmaal in de vloer bekijken pagina, klik op "View Options" en in de Access points sectie, verander de weergave naar "Assoc. Clients" om het aantal clients per AP weer te geven:

Het voordeel van de kaarttechniek is dat je kunt zien waar de AP met een hoog aantal klanten is en beoordelen of het hoge aantal kan worden gerechtvaardigd (er kan een goede reden zijn voor een publiek om op dat gegeven moment op die locatie samen te komen).

Je kunt ook kijken naar de naburige AP's: als ze een deel van de lading delen, zijn de dingen goed. Als één AP een abnormaal hoog aantal klanten heeft terwijl naburige AP's helemaal geen klanten hebben, wordt de situatie meer verdacht.

Er zou een probleem met naburige APs (als hun cliënttelling nul is) kunnen zijn of het ontwerp van RF kan problematische AP veroorzaken om alle cliënten in vergelijking met zijn buren (bijvoorbeeld wegens een veel hogere macht TX en/of verschillende antennes) aan te trekken.

De kaart geeft u een goed overzicht van de clients die op elke AP zijn gekoppeld

Zodra u potentieel problematische APs hebt geïdentificeerd waar het cliëntaantal uiterst hoog is, kunt u naar die AP naam zoeken en het apparaat 360 pagina openen.

De gezondheidsgrafiek geeft u een overzicht als de gezondheid van die AP op dit moment slecht is of als het voortdurend slecht is geweest in de laatste dag of meer.

Op dezelfde pagina hebt u een lijst met problemen die verband houden met dat toegangspunt. In dit geval is het duidelijk dat beide radio's een hoge benutting ervaren.

De gebeurtenisviewer kan u een idee geven als er specifieke gebeurtenissen zijn geweest die betrekking hebben op dat toegangspunt.

Een voorbeeld zou een algoritme kunnen zijn RRM dat te vaak in werking wordt gesteld en kanaalveranderingen veroorzaakt vaak die verbonden cliënten beïnvloeden, of een radio die constant zich terugstelt toe te schrijven aan diverse problemen of interferentie.

Aan het eind van de 360-pagina van het apparaat kunt u de weergave instellen op "RF", de specifieke radio selecteren en u hebt interessante informatie die u in staat stelt om de bron van het probleem te evalueren.

Het hebben van veel klanten is niet per se een probleem: het hangt allemaal af van hoe actief ze zijn.

Soms, zelfs met een paar klanten, kan de AP zijn handen bezig hebben en bieden een slechte ervaring. De werkelijke indicator is het kanaalgebruik.

Wanneer het kanaalgebruik 100% benadert (zelfs bij het starten van 70%), beginnen klanten zwaar te vechten voor middelgrote toegang, ervaring latentie en botsingen.

Met de grafieken kunt u het totale kanaalgebruik en dit AP-deel van verantwoordelijkheid daarin vergelijken.

Bijvoorbeeld, als het kanaalgebruik 80% is, betekent dit dat 80% van de tijd er "iemand"over het kanaal overbrengt. Als de AP 40% Rx gebruik en 40% Tx gebruik toont, weet u dat alleen deze AP verantwoordelijk is voor het houden van het kanaal bezig (dat wil zeggen, geen andere AP's verzenden) en het is goed gebalanceerd tussen ontvangen en verzenden. Als de gecombineerde Rx- en Tx-benutting van het AP-netwerk ver verwijderd is van het kanaalgebruik, impliceert dit dat een andere AP (schurk of beheerd) hetzelfde kanaal gebruikt en interferentie met hetzelfde kanaal veroorzaakt.

Dit screenshot toont een AP waar het kanaal extreem druk is (91%):

De grafiek toont dat slechts 7% van dit gebruik te wijten is aan andere APs en niet-WiFi bronnen en dat de AP bezig is met het verzenden voor 82% van de tijd en ontvangen voor slechts 2%.

Het aantal clients en de totale doorvoersnelheid zou erop wijzen dat een of meer clients waarschijnlijk grote bestanden downloaden.

Met de interferentiegrafiek kunt u bepalen of het kanaal bezet blijft door Wi-Fi-transmissies of werkelijke interferenties (niet-Wi-Fi):

Als conclusie, en als vuistregel, moet u op APs met de hoogste cliënttelling en het hoogste kanaalgebruik letten. Vervolgens dient u te beoordelen of deze belasting gerechtvaardigd is of niet en of deze een slechte ervaring veroorzaakt voor de eindgebruikers in dat gebied.

3. AI-analyses

AI analytics biedt u intelligentere monitoring. De controle is niet meer gebaseerd op vaste drempels, maar past zich aan uw basisgebruik aan.

Het netwerk heatmap geeft u een evolutie van het aantal klanten, om de AP's met de hoogste aantal klanten in de week te herkennen. U kunt ook gemakkelijk AP's herkennen die constant geen clients verbonden krijgen: het tegenovergestelde probleem is ook een probleem.

Er zou een fysiek probleem kunnen zijn met deze AP's (montageprobleem, probleem met de antennes, enzovoort) of een softwareprobleem als de radio is vastgelopen (en als een reboot van die AP het repareert).

De pagina Trends and Insights geeft u een lijst van AP's die regelmatig hoge kanaalgebruik of clientactiviteit tonen, zodat u gemakkelijk kunt kruiscontroles als dit overeenkomt met uw drukste gebieden of als er iets abnormaal is:

Actief testen van de infrastructuur

Wanneer gebruikers een slechte ervaring in een bepaald gebied melden, wilt u deze actief testen om hun feedback te bevestigen. Het is belangrijk om te begrijpen dat de typische testen veel van echt cliëntverkeer variëren.

Gebruikers proberen doorgaans hun favoriete toepassing te gebruiken en zijn blij als het werkt. Ze verzenden zelden grote bestanden. Hun favoriete toepassing kan een ander gedrag vertonen:

- On Demand Video: dit kan elke hoeveelheid bandbreedte verbruiken (dit is afhankelijk als de video bijvoorbeeld 720p of 4K is).

- Het is zeer tolerant voor jitter als het buffers een paar seconden of minuten video vooraf. Het patroon ziet eruit als een grote bestandsoverdracht voor een korte periode en dan stilte terwijl de video speelt van de buffer tot de volgende pre-loading gebeurt.

- Spraakoproep: dit verbruikt een verwaarloosbare hoeveelheid bandbreedte, maar is extreem gevoelig voor latentie en jitter.

- Dit kan mogelijk QoS (Quality of Service)-tagging gebruiken en kan daarom worden geconfronteerd met een andere (geprioriteerde) ervaring van best-inspanningsverkeer.

- Data: een sociale media applicatie downloadt gegevens door uitbarstingen.

- Het bedrag varieert op basis van de inhoud en hoe snel de gebruiker scrolt.

Een doorvoersnelheid testtoepassing maximaliseert het protocol om de hoogste overdrachtsnelheid te bereiken die mogelijk is: het probeert het medium te boeken en zo veel mogelijk gegevenskaders aaneengeschakeld te verzenden. Dit vertegenwoordigt niet hetzelfde gebruikstype als real-life applicaties (anders dan bestandsoverdrachten) die van nature zeer gepolijst zijn.

Het testen van real-life applicaties bootst het gebruikersgedrag na, maar maakt het onmogelijk om de werkelijke cijfers en getallen te vergelijken. Je krijgt alleen een subjectief gevoel als het netwerk al dan niet soepel is.

Voor het doorvoertesten zijn veel websites populair en geven ze een fatsoenlijk beeld van de eindgebruikerservaring terwijl ze de hele bandbreedte tussen de klant en het internet testen. Als u uw draadloze netwerk echter afzonderlijk van de problemen met de internetverbinding en routing en firewalls wilt valideren, wordt u aangeraden een speciale doorvoertest te gebruiken, zoals Iperf: https://community.cisco.com/t5/wireless-mobility-knowledge-base/iperf-test-for-measuring-the-throughput-speed-of-a-wlan-client/ta-p/3142047.

Dit hulpmiddel staat specifieke het testen tussen een cliënt en een server toe die u in uw netwerk plaatst. Hiermee kunt u de server naar specifieke plaatsen in het netwerk verplaatsen en de doorvoersnelheid over langere en langere netwerksecties testen om elke sectie te valideren. Start met het plaatsen van de Iperf-server op dezelfde switch als het toegangspunt waar de draadloze client zich bevindt in het geval van een lokale switching of een fabric-enabled wireless of op dezelfde switch als de WLC (Wireless LAN Controller) (en in de client VLAN indien mogelijk) in het geval van een Central switching.

Als u een anker WLC gebruikt, moet u de Iperf server op dezelfde switch plaatsen als het anker WLC zoals dat is waar het verkeer wordt geëindigd. Het kan interessant zijn om soms een niet-verankerd WLAN (draadloos LAN) te maken om te zien of de potentieel teleurstellende doorvoerresultaten worden veroorzaakt door de verankering zelf in vergelijking met een niet-verankerd WLAN.

Het is niet echt zinvol om meerdere clients te gebruiken om de doorvoersnelheid tegelijkertijd te testen. Tijdens het testen van de doorvoersnelheid wordt verwacht dat deze client alle beschikbare zendtijd van het kanaal gebruikt. Daarom, als twee cliënten een productie test tezelfdertijd doen, zien zij elk een resultaat dat minstens in de helft wordt verdeeld. Als er meer clients worden gebruikt, beginnen botsingen in getallen voor te komen en zijn de resultaten niet meer representatief.

Er zijn meerdere tools van derden om het testen van netwerken te automatiseren. Houd in acht dat terwijl u de doorvoersnelheid in één gebied test, u effectief alle zendtijd gebruikt voor de duur van de test, en het is dan een slecht idee om het netwerk te vaak te testen omdat het verstorend is voor andere clients.

Problemen met doorvoersnelheid oplossen

Wanneer u een doorvoerprobleem identificeert, zijn er verschillende dingen die kunnen worden bekeken om het probleem te isoleren:

- Isoleer als, voordat u de test start, de RF-omgeving al bezet is. Hoe hoger het kanaalgebruik is (buiten de test), hoe lager het resultaat van de doorvoertest wordt. Als een probleem met het kanaalgebruik wordt gedetecteerd, controleert u of er andere AP's aanwezig zijn in hetzelfde gebied op hetzelfde kanaal en heroverweegt u uw RF-ontwerp. Het verminderen van kanaalbreedte, het elimineren van schuren, het gebruiken van verschillende antennes met meer gerichte dekking zijn alle goede opties. Het toevoegen van meer AP's is niet altijd het beste idee.

- Ontvang een Over-The-Air opname van de doorvoertest en kijk of er veel gegevens opnieuw proberen op een 802.11-laag (in percentage van alle datakaders). Een groot aantal herhalingen betekent dat de RF-omgeving mogelijk het probleem is. Controleer ook welke gegevenssnelheden worden gebruikt, mogelijk suboptimaal protocol of aantal ruimtelijke stromen worden gebruikt. Een grote gegevensoverdracht is zeer karakteristiek in een over-de-lucht opname, ziet u tientallen gegevenskaders met de zelfde bron en de bestemming en met een uiterst kleine delta tijd tussen elkaar gevolgd door een blok ACK. Als de overdracht wordt gekarakteriseerd door een regelmatige ACK na elk gegevenskader, of veel verzoek-to-send/clear-to-send, kan de lage doorvoersnelheid gemakkelijk worden verklaard.

- Controleer of het doorvoerprobleem met alle beveiligingstypen op het WLAN optreedt. Soms kan een specifieke beveiligingsincompatibiliteit tussen de client en het toegangspunt leiden tot een slechte doorvoersnelheid.