De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
In dit document wordt beschreven hoe u doorvoerproblemen in grote Wi-Fi-netwerken kunt bewaken en oplossen.
In Wi-Fi netwerken zijn er niet veel soorten eindgebruikers die problemen ervaren.
De gemelde problemen kunnen variëren van:
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 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 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.
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.
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.
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?
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:
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:
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.
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.
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:
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:
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.
Wanneer u een doorvoerprobleem identificeert, zijn er verschillende dingen die kunnen worden bekeken om het probleem te isoleren:
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
04-Mar-2024 |
Eerste vrijgave |