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.
Dit document beschrijft ontwerp- en configuratierichtlijnen voor grote openbare Wi-Fi-netwerken.

CX Design Guides zijn geschreven door specialisten van Cisco Technical Assistance Center (TAC) en Cisco Professional Services (PS) en peer-reviewed door experts binnen Cisco; de gidsen zijn gebaseerd op de toonaangevende praktijken van Cisco en de kennis en ervaring die is opgedaan met talloze klantimplementaties gedurende vele jaren. Netwerken die zijn ontworpen en geconfigureerd in overeenstemming met de aanbevelingen in dit document helpen veelvoorkomende valkuilen te voorkomen en de werking van het netwerk te verbeteren.
Dit document bevat ontwerp- en configuratierichtlijnen voor grote openbare draadloze netwerken.
Definitie: Grote openbare netwerken - draadloze implementaties, vaak met hoge dichtheid, die netwerkconnectiviteit bieden voor duizenden onbekende en/of onbeheerde clientapparaten.
In dit document wordt vaak aangenomen dat het doelnetwerk diensten levert voor grote en/of tijdelijke evenementen. Het past ook in statische permanente netwerken voor locaties die veel gasten ontvangen. Een winkelcentrum of luchthaven heeft bijvoorbeeld overeenkomsten met het Wi-Fi-netwerk van een stadion of concertgebouw - in die zin dat er geen controle is over eindgebruikers en ze bestaan meestal slechts voor een paar uur of voor de dag.
Draadloze dekking voor grote evenementen of locaties heeft zijn eigen set van eisen, die de neiging om anders te zijn dan het bedrijfsleven, de productie, of zelfs grote onderwijsnetwerken. Grote openbare netwerken kunnen duizenden mensen hebben, geconcentreerd in slechts één of enkele gebouwen. Ze kunnen zeer frequent clientroaming hebben, constant of tijdens pieken, plus het netwerk moet zo compatibel mogelijk zijn met alles wat betreft draadloze clientapparaten, zonder controle over de configuratie of beveiliging van clientapparaten.
Deze gids bevat algemene RF-concepten voor hoge dichtheid en implementatiedetails. Veel van de radioconcepten in deze handleiding zijn van toepassing op alle netwerken met hoge dichtheid, waaronder Cisco Meraki. Implementatiedetails en configuraties zijn echter gericht op Catalyst Wireless met behulp van de Catalyst 9800 Wireless Controller, omdat dit de meest gebruikte oplossing is voor grote openbare netwerken.
In dit document worden de termen draadloze controller en draadloze LAN-controller (WLC) door elkaar gebruikt.
Grote openbare en evenementennetwerken zijn in veel opzichten uniek, dit document onderzoekt en biedt richtlijnen op deze belangrijke gebieden.
|
Documentnaam |
bron |
Location (Locatie) |
|
Configuratie best practices van de Cisco Catalyst 9800-reeks |
Cisco |
|
|
Problemen met draadloze LAN-controller CPU oplossen |
Cisco |
|
|
Wi-Fi-doorvoer valideren: test- en controlehandleiding |
Cisco |
|
|
Implementatiehandleiding voor Cisco Catalyst CW9166D1 Access Point |
Cisco |
|
|
Implementatiegids voor Catalyst 9104 Stadium Antenna (C-ANT9104) |
Cisco |
|
|
Monitor Catalyst 9800 KPI's (belangrijke prestatie-indicatoren) |
Cisco |
|
|
Problemen met Catalyst 9800-clientconnectiviteit oplossen Flow |
Cisco |
|
|
Configuratiehandleiding voor de draadloze controller uit de Cisco Catalyst 9800-reeks (10 .12) |
Cisco |
|
|
Wi-Fi 6E: het volgende grote hoofdstuk in Wi-Fi White Paper |
Cisco |
Dit document bevat aanbevelingen op basis van bepaalde scenario's, aannames en kennis die is opgedaan met tal van implementaties. U en de lezer zijn echter verantwoordelijk voor het bepalen van het netwerkontwerp, het bedrijf, de naleving van regelgeving, beveiliging, privacy en andere vereisten, inclusief het volgen van de richtlijnen of aanbevelingen in deze handleiding.
Deze gids richt zich op grote gastnetwerken, meestal open voor het publiek, en met beperkte controle over eindgebruikers en typen clientapparaten. Dit soort netwerken kan op verschillende locaties worden ingezet en kan tijdelijk of permanent zijn. De primaire use case is meestal het verstrekken van internettoegang aan bezoekers, hoewel dit zelden de enige use case is.
Typische locaties:
Vanuit het oogpunt van RF heeft elk van deze locatietypen zijn eigen set nuances. De meeste van deze voorbeelden zijn meestal permanente installaties, afgezien van conferentielocaties, omdat deze permanent kunnen zijn of tijdelijk kunnen worden opgezet voor een specifieke beurs.
Andere locaties:
Luchthavens en cruiseschepen zijn ook voorbeelden van toepassingen die passen in de categorie van grote openbare netwerken; deze hebben echter aanvullende overwegingen die specifiek zijn voor elk geval en maken vaak gebruik van interne omnidirectionele toegangspunten.
Dekkingsstrategieën zijn grotendeels afhankelijk van het locatietype, de gebruikte antennes en de beschikbare antennemontagelocaties.
overhead
Overheaddekking heeft altijd de voorkeur waar mogelijk.
Overheadoplossingen hebben het duidelijke voordeel dat alle clientapparaten meestal een directe zichtlijn hebben naar de antenne-overhead, zelfs in drukke scenario's. Overheadoplossingen die gebruikmaken van richtingsantennes bieden een meer gecontroleerd en goed gedefinieerd dekkingsgebied, waardoor ze minder ingewikkeld zijn vanuit het oogpunt van radioafstemming, terwijl ze superieure load balancing en roamingkenmerken voor clients bieden. Zie het gedeelte over de energiebalans voor aanvullende informatie.
AP's boven de clients
kant
Zijdelings gemonteerde richtingantennes zijn een populaire keuze en werken goed in verschillende scenario's, vooral wanneer montage boven het hoofd niet mogelijk is vanwege hoogte- of montagebeperkingen. Bij het gebruik van zijbevestiging is het belangrijk om het type gebied te begrijpen dat door de antenne wordt bedekt, bijvoorbeeld is het een open buitenruimte of een dichte binnenruimte? Als het dekkingsgebied een gebied met hoge dichtheid is met veel mensen, moet de antenne zoveel mogelijk worden verhoogd omdat de signaalverspreiding door een mensenmenigte altijd slecht is. Onthoud dat de meeste mobiele apparaten lager in de taille worden gebruikt, niet boven het hoofd van de gebruiker! De hoogte van de antenne is minder belangrijk wanneer het dekkingsgebied een gebied met een lagere dichtheid is.
De antenne is altijd beter
omnidirectioneel
Het gebruik van omnidirectionele antennes (intern of extern) moet in het algemeen worden vermeden in scenario's met een zeer hoge dichtheid, dit is te wijten aan het potentieel hoge impactgebied voor interferentie tussen twee kanalen. Omnidirectionele antennes mogen niet worden gebruikt op een hoogte boven 6 m (niet van toepassing op buitenunits met hoge versterking).
Onder de stoel
In sommige arena’s of stadions kunnen er situaties zijn waarin er geen geschikte antenne montagelocaties zijn. Het laatst overgebleven alternatief is om dekking van onderaf te bieden door toegangspunten onder de stoelen te plaatsen waar gebruikers zitten. Dit type oplossing is moeilijker correct te implementeren en is meestal duurder omdat er aanzienlijk meer toegangspunten en specifieke installatieprocedures nodig zijn.
De grootste uitdaging bij de inzet van onderstoelen is het grote verschil in dekking tussen een volledige locatie en een lege locatie. Een menselijk lichaam is zeer efficiënt in het verzwakken van radiosignalen, wat betekent dat wanneer er een menigte mensen rond het AP is, de resulterende dekking aanzienlijk kleiner is in vergelijking met wanneer die mensen er niet zijn. Deze menselijke factor voor de demping van mensenmassa maakt het mogelijk meer toegangspunten in te zetten, waardoor de totale capaciteit kan toenemen. Wanneer de locatie echter leeg is, is er geen verzwakking van het menselijk lichaam en aanzienlijke interferentie, en dit leidt tot complicaties wanneer de locatie gedeeltelijk vol is.
Opmerking: De inzet van onderzitters is een geldige maar ongebruikelijke oplossing, die per geval moet worden geëvalueerd. De inzet van onderzetters wordt in dit document niet verder besproken.
Bij sommige implementaties speelt de esthetische kwestie een rol. Dit kunnen gebieden zijn met specifieke architectonische ontwerpen, historische waarde of ruimtes waar reclame en / of branding dicteert waar apparatuur kan (of niet kan) worden gemonteerd. Specifieke oplossingen kunnen nodig zijn om eventuele plaatsingsbeperkingen te omzeilen. Sommige van deze oplossingen omvatten het verbergen van het toegangspunt/de antenne, het schilderen van het toegangspunt/de antenne, het monteren van de apparatuur in een behuizing of gewoon het gebruik van een andere locatie. Het schilderen van de antenne maakt echter de garantie ongeldig, als u ervoor kiest om de antenne te schilderen, gebruik dan altijd niet-metalen verf. Cisco verkoopt over het algemeen geen behuizingen voor antennes, maar veel zijn gemakkelijk verkrijgbaar via verschillende providers.
Al deze oplossingen hebben invloed op de prestaties van het netwerk. Draadloze architecten beginnen altijd met het voorstellen van optimale montageposities voor de beste radiodekking, en deze beginposities bieden meestal de beste prestaties. Wijzigingen in deze posities leiden vaak tot antennes worden verplaatst van hun optimale locaties.
Locaties waar antennes worden gemonteerd zijn vaak verhoogd, dit kunnen plafonds, catwalks, dakstructuren, balken, loopbruggen en elke locatie die enige hoogte biedt over het beoogde dekkingsgebied. Deze locaties worden meestal gedeeld met andere installaties, zoals: audioapparatuur, airconditioning, verlichting en verschillende detectoren / sensoren. Audio- en verlichtingsapparatuur moet bijvoorbeeld op zeer specifieke locaties worden gemonteerd - maar waarom is dit? Simpelweg omdat audio- en verlichtingsapparatuur niet correct werkt wanneer deze in een doos of achter een muur is verborgen, en iedereen erkent dit.
Hetzelfde geldt voor draadloze antennes, ze werken het beste wanneer er een zichtlijn is naar het draadloze clientapparaat. Het prioriteren van esthetiek kan (en heeft vaak) een negatief effect hebben op draadloze prestaties, waardoor de waarde van de investering in infrastructuur afneemt.
Rogue Wi-Fi-netwerken zijn draadloze netwerken die een gemeenschappelijke RF-ruimte delen, maar niet worden beheerd door dezelfde operator. Deze kunnen tijdelijk of permanent zijn en omvatten infrastructuurapparaten (AP's) en persoonlijke apparaten (zoals mobiele telefoons die een Wi-Fi-hotspot delen). Rogue Wi-Fi-netwerken zijn een bron van interferentie en in sommige gevallen ook een veiligheidsrisico. De impact van malafide software op draadloze prestaties mag niet worden onderschat. Wi-Fi-uitzendingen zijn beperkt tot een relatief klein bereik van het radiospectrum dat wordt gedeeld tussen alle Wi-Fi-apparaten, elk misdragen apparaten in de buurt hebben het potentieel om de netwerkprestaties voor veel gebruikers te verstoren.
In het kader van grote openbare netwerken worden deze meestal zorgvuldig ontworpen en afgestemd met behulp van gespecialiseerde antennes. Een goed RF-ontwerp dekt alleen de gebieden die nodig zijn, vaak met behulp van gerichte antennes met afgestemde zend- en ontvangstkenmerken voor maximale efficiëntie.
Aan de andere kant van het spectrum bevinden zich apparaten van consumentenkwaliteit of apparaten die worden geleverd door internetproviders. Deze hebben ofwel beperkte opties voor fijne RF-aanpassing, of zijn geconfigureerd voor maximaal bereik en waargenomen prestaties, vaak met een hoog vermogen, lage gegevenssnelheden en brede kanalen. De introductie van dergelijke apparaten in een groot evenementennetwerk kan grote schade aanrichten.
Wat kan er worden gedaan?
In het geval van persoonlijke hotspots is er heel weinig dat kan worden gedaan, omdat het bijna onmogelijk zou zijn om tienduizenden mensen die een locatie binnenkomen te controleren. In het geval van infrastructuur, of semi-permanente apparaten, zijn er enkele opties. Mogelijke remediëring begint met eenvoudig onderwijs, eenvoudige signalering voor bewustwording, door middel van ondertekende radiobeleidsdocumenten, eindigend met actieve handhaving en spectrumanalyse. In alle gevallen moet een zakelijke beslissing worden genomen over de bescherming van het radiospectrum binnen de gegeven locatie, samen met concrete stappen om die zakelijke beslissing af te dwingen.
Het beveiligingsaspect van malafide netwerken speelt een rol wanneer apparaten die worden beheerd door een derde partij dezelfde SSID adverteren als het beheerde netwerk. Dit staat gelijk aan een honeypot-aanval en kan worden gebruikt als een methode om gebruikersreferenties te stelen. Het wordt altijd aanbevolen om een bedrieglijke regel te maken om te waarschuwen voor de detectie van infrastructuur-SSID's die worden geadverteerd door niet-beheerde apparaten. In het veiligheidsgedeelte worden schurken gedetailleerder besproken.
Dual 5GHz verwijst naar het gebruik van beide 5GHz-radio's op ondersteunde toegangspunten. Er is een belangrijk verschil tussen dubbele 5GHz met behulp van externe antennes en dubbele 5GHz met behulp van interne antennes (bijvoorbeeld micro / macro-cellen op omnidirectionele AP's). In het geval van externe antennes is dubbele 5GHz vaak een nuttig mechanisme, dat extra dekking en capaciteit biedt en tegelijkertijd het totale aantal toegangspunten verlaagt.
Micro/Macro/Meso
Interne toegangspunten hebben beide antennes dicht bij elkaar (binnen het toegangspunt) en zijn onderhevig aan beperkingen met betrekking tot het maximale Tx-vermogen bij gebruik van dubbele 5 GHz. De tweede radio is beperkt tot een laag Tx-vermogen (dit wordt afgedwongen door de draadloze controller), wat leidt tot een grote onbalans van Tx-vermogen tussen de radio's. Dit kan ertoe leiden dat de primaire radio (met een hoger vermogen) veel klanten aantrekt, terwijl de secundaire radio (met een lager vermogen) onderbenut is. In dit geval voegt de tweede radio energie toe aan het milieu zonder dat dit ten goede komt aan klanten. Als dit scenario wordt waargenomen, kan het beter zijn om de tweede radio uit te schakelen en gewoon een andere (enkele 5GHz) AP toe te voegen als extra capaciteit nodig is.
Verschillende AP-modellen hebben verschillende configuratieopties, de tweede 5GHz-radio kan op hogere energieniveaus werken in nieuwere macro- / meso-AP's zoals de 9130 en 9136, en sommige interne Wi-Fi 6E-AP's zoals de 9160-serie kunnen zelfs in macro / macro werken. Controleer altijd de mogelijkheden van uw exacte AP-model. De tweede 5GHz-sleuf is ook beperkt in het kanaalgebruik, wanneer één sleuf in één UNII-band werkt, is de andere sleuf beperkt tot een andere UNII-band, wat van invloed is op de kanaalplanning en vervolgens ook op het beschikbare zendvermogen. Houd altijd rekening met het Tx-vermogensverschil tussen dubbele 5GHz-radio's, dit geldt in alle gevallen, inclusief interne toegangspunten.
FRA
Flexible Radio Assignment (FRA) werd geïntroduceerd als een technologie om de dekking van 5 GHz te verbeteren door extra 2,4 GHz-radio's over te schakelen naar de 5 GHz-modus, of mogelijk ongebruikte 5 GHz-radio's naar de monitormodus (voor toegangspunten die dit ondersteunden). Aangezien dit document betrekking heeft op grote openbare netwerken, wordt ervan uitgegaan dat de dekkingsgebieden en het radioontwerp goed gedefinieerd zijn met behulp van richtingsantennes, daarom verdient een deterministische configuratie de voorkeur boven een dynamische. Het gebruik van FRA wordt niet aanbevolen voor grote openbare netwerken.
Optioneel kan FRA worden gebruikt wanneer het netwerk is ingesteld om te helpen bepalen welke radio's moeten worden omgezet naar 5 GHz, maar als u eenmaal tevreden bent met het resultaat, wordt u geadviseerd om FRA te bevriezen.
regelgevende instantie
Elk regulerend domein definieert welke kanalen beschikbaar zijn voor gebruik en hun maximale vermogensniveaus, er zijn ook beperkingen op welke kanalen binnen versus buiten kunnen worden gebruikt. Afhankelijk van de regelgeving kan het soms niet mogelijk zijn om een dual 5GHz-oplossing effectief te gebruiken. Een voorbeeld hiervan is het ETSI-domein waar 30dBm is toegestaan op UNII-2e kanalen, maar slechts 23dBm op UNII1/2. In dit voorbeeld, als het ontwerp het gebruik van 30dBm vereist (meestal vanwege de grotere afstand tot de antenne), kan het gebruik van een enkele 5GHz-radio de enige haalbare oplossing zijn.
Grote openbare netwerken kunnen elk type antenne gebruiken en kiezen meestal de meest geschikte antenne voor de taak. Het mengen van antennes binnen hetzelfde dekkingsgebied maakt het radio-ontwerpproces uitdagender en moet indien mogelijk worden vermeden. Grote openbare netwerken hebben echter vaak grote dekkingsgebieden met verschillende montagemogelijkheden, zelfs binnen hetzelfde gebied, waardoor het in sommige gevallen nodig is om antennes te mengen. In deze gids worden interne omnidirectionele antennes niet in detail besproken en wordt meer aandacht besteed aan externe directionele antennes.
In deze tabel staan de meest gebruikte externe antennes.
Antennelijst
Belangrijkste factoren om te overwegen bij het kiezen van een antenne zijn de antennebundelbreedte en afstand / hoogte waarop de antenne is gemonteerd. De tabel toont 5GHz-bundelbreedte voor veelgebruikte antennes, waarbij de nummers tussen haakjes afgeronde (en gemakkelijker te onthouden) waarden tonen.
De voorgestelde afstanden in de tabel zijn geen harde regels, alleen richtlijnen op basis van ervaring. Radiogolven reizen met de snelheid van het licht en stoppen niet gewoon na het bereiken van een willekeurige afstand. De antennes werken allemaal buiten de voorgestelde afstand, maar de prestaties dalen naarmate de afstand toeneemt. De hoogte van de installatie is een belangrijke factor tijdens de planning.
Het onderstaande diagram toont twee mogelijke montagehoogten voor dezelfde antenne op ~ 33ft (10m) en ~ 66ft (20m) in een gebied met hoge dichtheid. Merk op dat het aantal clients dat de antenne kan zien (en accepteren van verbindingen) toeneemt met de afstand. Het handhaven van kleinere celgroottes wordt uitdagender met grotere afstanden.
De algemene regel is hoe hoger de dichtheid van de gebruikers, hoe belangrijker het is om de juiste antenne voor de gegeven afstand te gebruiken.
Een stadion antenne
De C9104 stadionantenne is zeer geschikt voor het afdekken van gebieden met een hoge dichtheid op grote afstanden, zie de Catalyst 9104 Stadium Antenna (C-ANT9104) Implementatiehandleiding voor meer informatie.
Veranderingen in de tijd
Veranderingen in de fysieke omgeving in de loop van de tijd zijn gebruikelijk in bijna alle draadloze installaties (bijvoorbeeld beweging van binnenmuren of verbouwing van zitplaatsen). Regelmatige bezoeken ter plaatse en visuele inspecties zijn altijd een aanbevolen praktijk geweest. Voor evenementennetwerken is er de extra complexiteit van het omgaan met audio- en verlichtingssystemen, en in veel gevallen ook andere communicatiesystemen (zoals 5G). Al deze systemen worden vaak geïnstalleerd op verhoogde locaties boven de gebruikers, wat soms resulteert in strijd om dezelfde ruimte. Een goede locatie voor een draadloze stadionantenne is vaak ook een goede locatie voor een 5G-antenne! Naarmate deze systemen in de loop van de tijd worden bijgewerkt, kunnen ze worden verplaatst naar locaties waar ze uw draadloze systeem belemmeren en / of actief verstoren. Het is belangrijk om de andere installaties bij te houden en te communiceren met de teams die ze installeren, om ervoor te zorgen dat alle systemen op geschikte locaties worden geïnstalleerd zonder dat ze elkaar (fysiek of elektromagnetisch) verstoren.
Op het moment van schrijven van dit document is er een beperkte selectie van 6GHz-compatibele externe antennes. Alleen de geïntegreerde CW9166D1-AP/antenne werkt op 6 GHz. Gedetailleerde specificaties voor de antenne zijn beschikbaar in de implementatiegids voor Cisco Catalyst CW9166D1 Access Point. De CW9166D1 biedt 6 GHz dekking met een beambreedte van 60 ° x 60 ° en kan effectief worden gebruikt voor elke implementatie die voldoet aan de voorwaarden voor dit type antenne. Auditoria en magazijnen zijn bijvoorbeeld goede kandidaten voor de inzet van de CW9166D1, omdat de geïntegreerde eenheid directionele antenne-functionaliteit biedt voor gebruik binnenshuis.
9166D1
In de context van grote openbare netwerken hebben deze vaak verschillende grote gebieden en vereisen het gebruik van een combinatie van antennes op verschillende hoogtes. Het kan een uitdaging zijn om een groot openbaar netwerk end-to-end te implementeren met slechts een 60 ° x60 ° -antenne vanwege afstandsimmitaties. Daarom kan het ook een uitdaging zijn om end-to-end dekking te bieden op 6 GHz met alleen de CW9166D1 voor een groot openbaar netwerk.
Een mogelijke aanpak is om 5GHz te gebruiken als de primaire dekkingsband, terwijl 6GHz alleen in specifieke gebieden wordt gebruikt om geschikte clientapparaten naar de schonere 6GHz-band te verplaatsen. Dit type aanpak maakt gebruik van 5GHz-alleen antennes in grotere gebieden, terwijl het gebruik van de 6GHz antennes waar mogelijk en waar extra capaciteit nodig is.
Neem bijvoorbeeld een grote evenementenhal op een handelsconferentie, de hoofdzaal gebruikt stadionantennes om primaire dekking te bieden op 5 GHz, de hoogte van de installatie vereist het gebruik van stadionantennes. De CW9166D1 kan niet worden gebruikt in de grote zaal in dit voorbeeld vanwege afstandsbeperkingen - maar kan effectief worden gebruikt in een aangrenzende VIP-hal of persruimte waar een hogere dichtheid vereist is. Clientroaming tussen de 5GHz- en 6GHz-banden wordt later in dit document besproken.
regelgevende instantie
Net als bij 5GHz verschillen de beschikbare voeding en kanalen voor 6GHz aanzienlijk tussen regelgevende domeinen. Met name is er een groot verschil in beschikbaar spectrum tussen FCC- en ETSI-domeinen, evenals strikte richtlijnen rond beschikbaar Tx-vermogen voor gebruik binnenshuis en buitenshuis, respectievelijk Low Power Indoor (LPI) en Standard Power (SP). Met 6GHz omvatten extra beperkingen de vermogenslimieten van de client, het gebruik van externe antennes en de kanteling van de antenne en (voorlopig alleen in de VS) de vereiste voor automatische frequentiecoördinatie (AFC) voor SP-implementaties.
Voor meer informatie over Wi-Fi 6E zie Wi-Fi 6E: The Next Great Chapter in Wi-Fi White Paper.
Radio Resource Management (RRM) is een reeks algoritmen die verantwoordelijk zijn voor de besturing van radioactiviteit. Deze gids verwijst naar twee belangrijke RRM-algoritmen, namelijk Dynamic Channel Assignment (DCA) en Transmit Power Control (TPC). RRM is een alternatief voor statische kanaal- en stroomconfiguratie.
Cisco Event Driven RRM (ED-RRM) is een DCA-optie die het mogelijk maakt om een kanaalwijzigingsbeslissing te nemen buiten het standaard DCA-schema, meestal als reactie op ernstige RF-omstandigheden. ED-RRM kan een kanaal onmiddellijk veranderen wanneer buitensporige niveaus van interferentie worden gedetecteerd. In lawaaierige en/of instabiele omgevingen die ED-RRM mogelijk maken, bestaat het risico van buitensporige kanaalwijzigingen, wat een potentieel negatief effect heeft op clientapparaten.
Het gebruik van RRM wordt aangemoedigd en heeft over het algemeen de voorkeur boven statische configuratie - echter met bepaalde kanttekeningen en uitzonderingen.
In alle gevallen moet RRM worden ingezet met inzicht in de verwachte uitkomst en afgestemd zijn om te werken binnen grenzen die geschikt zijn voor de gegeven RF-omgeving. In de volgende paragrafen van dit document worden deze punten nader onderzocht.
Over het algemeen geldt: hoe meer kanalen, hoe beter. Bij implementaties met hoge dichtheid kunnen er ordes van grootte meer AP's en radio's worden ingezet dan beschikbare kanalen, wat een hergebruikverhouding van grote kanalen impliceert, en, samen met dat, hogere niveaus van interferentie tussen co-kanalen. Alle beschikbare kanalen moeten worden gebruikt en het beperken van de lijst met beschikbare kanalen wordt over het algemeen afgeraden.
Er kunnen gevallen zijn waarin een specifiek (en afzonderlijk) draadloos systeem naast elkaar moet bestaan in dezelfde fysieke ruimte, en toegewezen kanaal (kanalen) moet worden toegewezen aan het, op hetzelfde moment het verwijderen van de toegewezen kanaal (en) uit de DCA-lijst van het primaire systeem. Dit soort kanaaluitsluitingen moet zeer zorgvuldig worden geëvalueerd en alleen worden gebruikt wanneer dat nodig is. Een voorbeeld hiervan kan een point-to-point link zijn die in een open gebied naast het primaire netwerk werkt, of een persgebied in een stadion. Als meer dan één of twee kanalen worden uitgesloten van de DCA-lijst, is dit een reden voor herevaluatie van de voorgestelde oplossing. In sommige gevallen, zoals stadions met een zeer hoge dichtheid, kan het uitsluiten van zelfs een enkel kanaal soms geen haalbare optie zijn.
Dynamic Channel Assignment (DCA) kan worden gebruikt met op WLC gebaseerde RRM of AI-verbeterde RRM.
Het standaard DCA-interval is 10 minuten, wat kan resulteren in frequente kanaalwijzigingen in instabiele RF-omgevingen. De standaard DCA-timer moet in alle gevallen worden verhoogd van de standaard 10 minuten, het specifieke DCA-interval moet worden afgestemd op de operationele vereisten voor het netwerk in kwestie. Een voorbeeld configuratie kan zijn: DCA interval 4 uur, ankertijd 8. Dit beperkt kanaalwijzigingen tot eenmaal per 4 uur, vanaf 8 uur 's ochtends.
Omdat interferenties onvermijdelijk zijn, brengt het aanpassen ervan aan elke DCA-cyclus niet noodzakelijkerwijs waarde met zich mee, omdat veel van die interferenties tijdelijk zijn. Een goede techniek is om de eerste paar uur automatische DCA te gebruiken en het algoritme en het kanaalplan te bevriezen als je iets stabiels hebt waar je blij mee bent.
Wanneer de WLC opnieuw wordt opgestart, draait DCA gedurende 100 minuten in de agressieve modus om een geschikt kanaalplan te vinden. Het is een goed idee om het proces handmatig opnieuw te starten wanneer er belangrijke wijzigingen worden aangebracht in het RF-ontwerp (bijvoorbeeld het toevoegen of verwijderen van meerdere toegangspunten of het wijzigen van de kanaalbreedte). Als u dit proces handmatig wilt starten, gebruikt u deze opdracht.
ap dot11 [24ghz | 5ghz | 6ghz] rrm dca restart
Opmerking: Kanaalwijzigingen kunnen storend zijn voor clientapparaten.
2,4 GHz
De 2.4GHz band is vaak bekritiseerd. Het heeft slechts drie niet-overlappende kanalen en veel andere technologieën dan Wi-Fi gebruiken het, waardoor ongewenste interferenties ontstaan. Sommige organisaties staan erop om er service aan te verlenen, dus wat is een redelijke conclusie? Het is een feit dat de 2,4 GHz-band geen bevredigende ervaring biedt voor eindgebruikers. Erger nog, door te proberen service te bieden op 2,4 GHz, heeft u invloed op andere 2,4 GHz-technologieën zoals Bluetooth. In grote locaties of evenementen verwachten veel mensen nog steeds dat hun draadloze headset werkt wanneer ze een oproep plaatsen of hun slimme wearables blijven werken zoals gebruikelijk. Als uw dichte Wi-Fi werkt op 2,4 GHz, heeft u invloed op die apparaten die niet eens uw 2,4 GHz Wi-Fi gebruiken.
Een ding is zeker, als je echt 2,4 GHz Wi-Fi-service moet bieden, is het het beste om dat te doen op een afzonderlijke SSID (wijden aan IoT-apparaten of noem het "legacy"). Dit betekent dat dual-band-apparaten niet onvrijwillig verbinding maken met 2,4 GHz en dat alleen single-band 2,4 GHz-apparaten er verbinding mee maken.
Cisco adviseert en ondersteunt het gebruik van 40MHz-kanalen in 2,4GHz niet.
5 GHz
Typische implementatie voor draadloze verbindingen met hoge dichtheid. Gebruik waar mogelijk alle beschikbare kanalen.
Het aantal kanalen varieert afhankelijk van het regelgevingsdomein. Overweeg de impact van radar op de specifieke locatie, gebruik waar mogelijk DFS-kanalen (inclusief TDWR-kanalen).
20 MHz kanaalbreedte wordt sterk aanbevolen voor alle implementaties met hoge dichtheid.
40MHz kan op dezelfde basis als 2.4GHz worden gebruikt, dat is alleen wanneer (en waar) absoluut nodig.
Evalueer de behoefte aan en het echte voordeel van 40MHz-kanalen in de specifieke omgeving. 40MHz-kanalen vereisen een hogere signaal-ruisverhouding (SNR) om een mogelijke verbetering van de doorvoer te realiseren, als een hogere SNR niet mogelijk is, dienen 40MHz-kanalen geen nuttig doel. Netwerken met hoge dichtheid geven prioriteit aan het gemiddelde voor alle gebruikers boven een potentieel hogere doorvoer voor één gebruiker. Het is beter om meer AP's op 20MHz-kanalen te plaatsen dan AP's die 40MHz gebruiken, omdat het secundaire kanaal alleen wordt gebruikt voor gegevensframes en daarom veel minder efficiënt wordt gebruikt dan twee verschillende radiocellen, die elk op 20MHz werken (in termen van totale capaciteit, niet in termen van doorvoer van één client).
6 GHz
De 6GHz band is nog niet in alle landen beschikbaar. Bovendien hebben sommige apparaten een Wi-Fi-adapter met een capaciteit van 6 GHz, maar hebben ze een BIOS-update nodig om ingeschakeld te worden voor het specifieke land waarin u het apparaat gebruikt. De meest populaire manier waarop klanten 6GHz-radio's nu ontdekken, is via de RNR-advertentie (Reduced Neighbor Report) op de 5GHz-radio, deze adverteert het bestaan van 6GHz-netwerken voor klanten op 5GHz. Dit betekent dat 6GHz niet alleen mag werken zonder een 5GHz-radio op hetzelfde toegangspunt. 6GHz is er om klanten en verkeer van de 5GHz-radio te ontladen en om typisch een betere ervaring voor de capabele klanten te bieden. 6GHz-kanalen maken het mogelijk om grotere kanaalbandbreedten te gebruiken, maar het hangt sterk af van het aantal kanalen dat beschikbaar is in het regelgevende domein. Met 24 6GHz-kanalen beschikbaar in Europa, is het niet onredelijk om te gaan voor 40MHz-kanalen om een betere maximale doorvoer te bieden in vergelijking met de 20MHz die u waarschijnlijk gebruikt in 5GHz. In de VS, met bijna een verdubbeling van het aantal kanalen, is het gebruik van 40MHz een no-brainer en zelfs gaan voor 80MHz is niet onredelijk voor een evenement met een grote dichtheid. Grotere bandbreedten mogen niet worden gebruikt in evenementen of locaties met een hoge dichtheid.
De gegevenssnelheid die een client onderhandelt met een toegangspunt is grotendeels een functie van de signaal-ruisverhouding (SNR) van die verbinding, en het tegenovergestelde is ook waar, hogere gegevenssnelheden vereisen hogere SNR. In feite is het meestal SNR die de maximaal mogelijke verbindingssnelheid bepaalt - maar waarom is dit belangrijk bij het configureren van gegevenssnelheden? Dit komt omdat sommige datasnelheden een speciale betekenis hebben.
Klassieke OFDM-gegevenssnelheden (802.11a) kunnen worden geconfigureerd in een van de drie instellingen: Uitgeschakeld, Ondersteund of Verplicht. De OFDM-snelheden zijn (in Mbps): 6, 9, 12, 18, 24, 36, 48, 54 en de client en AP moeten beide een snelheid ondersteunen voordat deze kan worden gebruikt.
Ondersteund - het toegangspunt gebruikt de snelheid
Verplicht - het toegangspunt gebruikt het tarief en verzendt beheerverkeer met dit tarief
Uitgeschakeld - het toegangspunt gebruikt de snelheid niet, waardoor de client een andere snelheid moet gebruiken
Opmerking: Verplichte tarieven worden ook wel basistarieven genoemd
Het belang van het verplichte tarief is dat alle beheerframes met dit tarief worden verzonden, evenals broadcast- en multicastframes. Als er meerdere verplichte tarieven zijn geconfigureerd, gebruiken beheerframes de laagste geconfigureerde verplichte tarieven en gebruiken broadcast en multicast een van de verplichte tarieven (dit punt kan worden geconfigureerd in het RF-profiel).
Beheerframes bevatten bakens die door de client moeten worden gehoord om aan het toegangspunt te kunnen worden gekoppeld. Het verhogen van de verplichte snelheid verhoogt ook de SNR-vereiste voor die transmissie, herinner eraan dat hogere gegevenssnelheden hogere SNR vereisen, en dit betekent meestal dat de klant dichter bij het toegangspunt moet zijn om het baken en de koppeling te kunnen decoderen. Daarom manipuleren we door het manipuleren van de verplichte datasnelheid ook het effectieve associatiebereik van het toegangspunt, waardoor klanten dichter bij het toegangspunt komen of naar een mogelijk roamingbesluit. Klanten die dicht bij het toegangspunt staan, gebruiken hogere gegevenssnelheden en gebruiken minder zendtijd - het beoogde effect is een efficiëntere cel. Het is belangrijk om te onthouden dat het verhogen van de gegevenssnelheid alleen de transmissiesnelheid van bepaalde frames beïnvloedt, het heeft geen invloed op de RF-propagatie van de antenne of het interferentiebereik. Goede RF-ontwerppraktijken zijn nog steeds nodig om interferentie en ruis tussen kanalen te minimaliseren.
Omgekeerd betekent het laten van lagere tarieven als verplicht meestal dat klanten van een veel grotere afstand kunnen associëren, handig in scenario's met een lagere AP-dichtheid, maar met het potentieel om chaos te veroorzaken bij roaming in scenario's met een hogere dichtheid. Iedereen die heeft geprobeerd om een schurkenstaat AP dat is het uitzenden van een 6Mbps weet dat je de AP kan detecteren heel ver weg van de fysieke locatie!
Op het gebied van uitzending en multicast wordt in sommige gevallen een tweede (hogere) verplichte snelheid geconfigureerd om de snelheid van levering van multicast-verkeer te verhogen. Dit is zelden succesvol, omdat multicast nooit wordt erkend en nooit opnieuw wordt verzonden als frames verloren gaan. Aangezien sommige verliezen inherent zijn aan alle draadloze systemen, is het onvermijdelijk dat sommige multicast-frames verloren gaan, ongeacht de geconfigureerde snelheid. Een betere benadering van betrouwbare multicast-levering zijn multicast-naar-unicast-conversietechnieken die de multicast als een unicast-stroom verzenden, wat het voordeel heeft van zowel hogere gegevenssnelheden als betrouwbare (erkende) levering.
Als u slechts één verplicht tarief gebruikt, schakelt u alle tarieven onder het verplichte tarief uit en laat u alle tarieven boven het verplichte tarief zoals ondersteund. Het specifieke tarief dat moet worden gebruikt, hangt af van het gebruiksscenario, zoals eerder vermeld, zijn lagere tarieven nuttig in scenario's met een lagere dichtheid en buitenscenario's waarbij de afstanden tussen toegangspunten groter zijn. Voor netwerken met hoge dichtheid en evenementen moeten lage tarieven worden uitgeschakeld.
Als u niet zeker weet waar u moet beginnen, gebruikt u een verplichte snelheid van 12 Mbps voor implementaties met lage dichtheid en 24 Mbps voor implementaties met hoge dichtheid. Veel grootschalige evenementen, stadions en zelfs zakelijke kantoorimplementaties met hoge dichtheid hebben bewezen betrouwbaar te werken met een verplichte snelheidsinstelling van 24 Mbps. Passende tests worden aanbevolen voor specifieke gebruikssituaties waarbij snelheden van minder dan 12 Mbps of meer dan 24 Mbps nodig zijn.
Opmerking: het is het beste om alle 802.11n / ac / ax-snelheden ingeschakeld te laten (alle tarieven in het gedeelte High Throughput van de WLC GUI), het is zelden nodig om een van deze uit te schakelen.
Aanbevelingen voor de verzendenergie verschillen afhankelijk van het implementatietype. Hier onderscheiden we indoor implementaties met behulp van omnidirectionele antennes, van die met behulp van directionele antennes. Beide soorten antennes kunnen bestaan in een groot openbaar netwerk, hoewel deze meestal verschillende soorten gebieden bestrijken.
Voor omnidirectionele implementaties is het gebruikelijk om automatische Transmit Power Control (TPC) te gebruiken met een statisch geconfigureerde minimumdrempel, en in bepaalde gevallen ook een statisch geconfigureerde maximumdrempel.
Opmerking: TPC-drempelwaarden verwijzen naar zendvermogen voor radio en sluiten antenneversterking uit. Zorg er altijd voor dat de antenneversterking correct is geconfigureerd voor het gebruikte antennemodel, dit gebeurt automatisch in het geval van interne antennes en zelfidentificerende antennes.
Voorbeeld 1
TPC Min.: 5dBm, TPC Max.: Maximum (30dBm)
Dit zou ertoe leiden dat het TPC-algoritme het zendvermogen automatisch zou bepalen, maar nooit onder de geconfigureerde minimumdrempel van 5dBm zou gaan.
Voorbeeld 2
TPC Min.: 2dBm, TPC Max.: 11 dBm
Dit zou resulteren in het TPC-algoritme dat het zendvermogen automatisch bepaalt, maar altijd tussen 2dBm en 11dBm blijft.
Een goede aanpak is om verschillende RF-profielen te maken met verschillende drempelwaarden, bijvoorbeeld laag vermogen (2-5 dBm), gemiddeld vermogen (5-11 dBm) en hoog vermogen (11-17 dBm), en vervolgens omnidirectionele AP's toe te wijzen aan elk RF-profiel als dat nodig is. De waarden van elk RF-profiel kunnen worden aangepast aan de beoogde use case en het dekkingsgebied. Hierdoor kunnen de RRM-algoritmen dynamisch werken terwijl ze binnen vooraf gedefinieerde grenzen blijven.
De benadering voor richtantennes is zeer vergelijkbaar, het enige verschil is het vereiste nauwkeurigheidsniveau. De plaatsing van de richtingsantenne moet worden ontworpen en geverifieerd tijdens een RF-onderzoek voorafgaand aan de implementatie, en de specifieke configuratiewaarden voor de radio zijn doorgaans een resultaat van dit proces.
Als een plafondpatchantenne bijvoorbeeld nodig is om een bepaald gebied vanaf een hoogte van ~26 ft (8 m) te bedekken, moet de RF-enquête bepalen welk minimaal Tx-vermogen vereist is om deze beoogde dekking te bereiken (dit bepaalt de minimale TPC-waarde voor het RF-profiel). Evenzo zouden we uit dezelfde RF-enquête de mogelijke overlap begrijpen die vereist is tussen deze en de volgende antenne, of zelfs het punt waarop we willen dat de dekking eindigt - dit zou de maximale TPC-waarde voor het RF-profiel bieden.
RF-profielen voor directionele antennes worden doorgaans geconfigureerd met dezelfde minimum- en maximumwaarden voor TPC of met een beperkt bereik van mogelijke waarden (meestal <= 3dBm).
RF-profielen hebben de voorkeur om de consistentie van de configuratie te garanderen. Statische configuratie van afzonderlijke toegangspunten wordt niet aanbevolen. Het is een goede gewoonte om RF-profielen te benoemen op basis van het dekkingsgebied, het antennetype en de use case, bijvoorbeeld RF-Auditorium-Patch-Ceiling.
De juiste hoeveelheid Tx-vermogen is wanneer de vereiste SNR-waarde wordt bereikt door de zwakste client in het beoogde dekkingsgebied, en niet meer dan dat. 30dBm is een geweldige SNR-doelwaarde voor klanten onder reële omstandigheden (dat wil zeggen in een locatie vol mensen).
CHD
Coverage Hole Detection (CHD) is een afzonderlijk algoritme voor het identificeren en verhelpen van dekkingsgaten. CHD wordt zowel wereldwijd als per WLAN geconfigureerd. Een mogelijk effect van CHD is de toename van Tx-vermogen om te compenseren voor dekkingsgaten (gebieden met clients die consequent worden gedetecteerd met een slecht signaal), dit effect is op radioniveau en heeft invloed op alle WLAN's, zelfs wanneer het wordt geactiveerd door een enkel WLAN dat is geconfigureerd voor CHD.
Grote openbare netwerken worden meestal geconfigureerd op specifieke energieniveaus met behulp van RF-profielen, sommige kunnen zich in open gebieden bevinden met clients die in en uit de gebieden zwerven, er is geen behoefte aan een algoritme om de AP Tx-stroom dynamisch aan te passen als reactie op deze clientgebeurtenissen.
CHD moet wereldwijd worden uitgeschakeld voor grote openbare netwerken.
De meeste clientapparaten geven de voorkeur aan een hoger ontvangen signaal bij het kiezen van het toegangspunt waaraan moet worden gekoppeld. Situaties waarin een toegangspunt is geconfigureerd met een aanzienlijk hoger Tx-vermogen in vergelijking met andere omliggende toegangspunten moeten worden vermeden. AP's die werken met een hoger Tx-vermogen trekken meer clients aan, wat leidt tot een ongelijke clientverdeling tussen AP's (een enkel AP/radio is bijvoorbeeld overbelast met clients terwijl de omliggende AP's te weinig worden gebruikt). Deze situatie komt vaak voor bij implementaties met grote overlappende dekking van meerdere antennes en in gevallen waarin één toegangspunt meerdere antennes heeft aangesloten.
Stadionantennes zoals de C9104 vereisen bijzondere zorg bij het selecteren van Tx-vermogen omdat de antennebundels elkaar overlappen door het ontwerp, raadpleeg de implementatiehandleiding voor Catalyst 9104 Stadium Antenna (C-ANT9104) voor meer informatie hierover.
In het onderstaande diagram is de middelste antenne geconfigureerd met een hoger Tx-vermogen dan de omliggende antennes. Deze configuratie zal er waarschijnlijk toe leiden dat clients aan de middelste antenne worden 'vastgeplakt'.
Een toegangspunt met een hogere stroomsterkte dan de naburige toegangspunten trekt alle klanten aan
Het volgende diagram toont een meer gecompliceerde situatie, niet alle antennes zijn op dezelfde hoogte en niet alle antennes gebruiken dezelfde kanteling / oriëntatie. Het bereiken van een uitgebalanceerd vermogen is ingewikkelder dan het eenvoudig configureren van alle radio's met hetzelfde Tx-vermogen. In scenario's zoals deze kan een onderzoek naar de locatie na implementatie vereist zijn, zodat de dekking vanuit het oogpunt van het clientapparaat (op de grond) wordt weergegeven. De enquêtegegevens kunnen vervolgens worden gebruikt om de configuratie in evenwicht te brengen voor de beste dekking en clientdistributie.
Het ontwerpen van uniforme AP-plaatsingslocaties die gecompliceerde situaties zoals deze vermijden, is de beste manier om uitdagende RF-tuningsscenario's te voorkomen (hoewel er soms geen andere keuze is!).
Eén AP trekt alle klanten aan, ondanks dat de Tx-kracht vergelijkbaar is, maar hoogte en hoeken spelen een rol
In tegenstelling tot mechanismen zoals Tx-vermogen of gegevenssnelheden die de kenmerken van de zendcel beïnvloeden, probeert RxSOP (Receiver Start of Packet detection) de grootte van de ontvangstcel te beïnvloeden. In wezen kan RxSOP de gedachte van als een ruisdrempel, in die zin dat het definieert het ontvangen signaalniveau waaronder de AP niet probeert te decoderen transmissies. Alle uitzendingen die aankomen met een signaalniveau dat zwakker is dan de geconfigureerde RxSOP-drempel, worden niet verwerkt door het toegangspunt en worden effectief behandeld als ruis.
RxSOP-concept uitgelegd
Het belang van RxSOP
RxSOP heeft meerdere toepassingen. Het kan worden gebruikt om het vermogen van toegangspunten om te verzenden in rumoerige omgevingen te verbeteren, de distributie van clients tussen antennes te regelen en te optimaliseren voor zwakkere en kleverige clients.
In het geval van lawaaierige omgevingen, herinner u eraan dat voordat u een 802.11-frame verzendt, het zendstation (het toegangspunt in dit geval) eerst de beschikbaarheid van het medium moet beoordelen, een deel van dit proces is om eerst te luisteren naar uitzendingen die al plaatsvinden. In dichte Wi-Fi-omgevingen is het gebruikelijk dat veel AP's naast elkaar bestaan in een relatief beperkte ruimte, vaak met behulp van dezelfde kanalen. In dergelijke drukke omgevingen kan het toegangspunt het kanaalgebruik rapporteren van de omliggende toegangspunten (inclusief reflecties) en de eigen transmissie vertragen. Door de juiste RxSOP-drempel in te stellen, kan het toegangspunt die zwakkere transmissies (vermindering van het waargenomen kanaalgebruik) negeren, wat leidt tot frequentere transmissiemogelijkheden en verbeterde prestaties. Omgevingen waarin AP's een aanzienlijk kanaalgebruik melden (bijvoorbeeld > 10%) zonder enige clientbelasting (bijvoorbeeld een lege locatie) zijn goede kandidaten voor RxSOP-afstemming.
Voor clientoptimalisatie met behulp van RxSOP kunt u dit diagram bekijken.
Clientroaming beïnvloed door rxsop
In dit voorbeeld zijn er twee toegangspunten/antennes met goed gedefinieerde dekkingsgebieden. Cliënt B beweegt van het dekkingsgebied van AP1 naar het dekkingsgebied van AP2. Er is een crossover-punt waarop AP2 de client beter hoort dan AP1, maar de client heeft nog niet naar AP2 gezworven. Dit is een goed voorbeeld van hoe het instellen van de RxSOP-drempel de grens van het dekkingsgebied kan afdwingen. Door ervoor te zorgen dat clients altijd op het dichtstbijzijnde toegangspunt zijn aangesloten, worden de prestaties verbeterd doordat verre en/of zwakke clientverbindingen die met lagere gegevenssnelheden worden aangeboden, worden geëlimineerd. Het configureren van de RxSOP-drempels op deze manier vereist een grondig begrip van waar het verwachte dekkingsgebied van elk toegangspunt begint en eindigt.
De gevaren van RxSOP.
Als u de RxSOP-drempelwaarde te agressief instelt, ontstaan er dekkingsgaten, omdat het toegangspunt geldige verzendingen van geldige clientapparaten niet decodeert. Dit kan nadelige gevolgen hebben voor de klant omdat de AP niet reageert; als de transmissie van de klant niet is gehoord, is er immers geen reden om te reageren. Het afstemmen van RxSOP-drempelwaarden moet zorgvuldig gebeuren, waarbij er altijd voor moet worden gezorgd dat de geconfigureerde waarden geen geldige clients binnen het dekkingsgebied uitsluiten. Merk op dat sommige klanten mogelijk niet goed reageren op deze manier genegeerd te worden, te agressieve RxSOP-instellingen geven de klant niet de kans om op natuurlijke wijze rond te lopen, waardoor de klant effectief gedwongen wordt om een andere AP te vinden. Een client die een baken van een AP kan decoderen, gaat ervan uit dat hij in staat is om naar dat AP te verzenden, dus de bedoeling van RxSOP-afstemming is om de grootte van de ontvangende cel af te stemmen op het bakenbereik van het AP. Houd er rekening mee dat een (geldig) clientapparaat niet altijd een directe zichtlijn naar het toegangspunt heeft, het signaal wordt vaak verzwakt door gebruikers die zich van de antenne afwenden of hun apparaten in zakken of zakken dragen.
RxSOP configureren
RxSOP wordt geconfigureerd volgens RF-profiel.
Voor elke band zijn er vooraf ingestelde drempelwaarden (Laag/Gemiddeld/Hoog) die een vooraf gedefinieerde dBm-waarde hebben. De aanbeveling hier is om altijd aangepaste waarden te gebruiken, zelfs als de beoogde waarde een van de beschikbare presets is, dit maakt de configuratie leesbaarder.
RxSop-instellingentabel
Opmerking: RxSOP-wijzigingen vereisen geen radio-reset en kunnen direct worden uitgevoerd.
Over het algemeen is het een slecht idee om een apparaat maximaal te gebruiken van de gedocumenteerde mogelijkheden. Gegevensbladen rapporteren de waarheid, maar de genoemde aantallen kunnen in specifieke omstandigheden van activiteit zijn. Draadloze controllers zijn getest en gecertificeerd om een bepaald aantal clients en toegangspunten en een bepaalde doorvoer te ondersteunen, maar dit veronderstelt niet dat clients elke seconde roamen, dat u extreem lange unieke ACL's voor elke client kunt hebben geconfigureerd of alle beschikbare snuffelfuncties hebt ingeschakeld. Het is daarom belangrijk om alle aspecten zorgvuldig te overwegen om ervoor te zorgen dat het netwerk tijdens de piekuren schaalbaar is en om ook een veiligheidsmarge te behouden voor toekomstige groei.
Een van de eerste taken bij het implementeren van een netwerk is het budgetteren en bestellen van de juiste hoeveelheid apparatuur, en de grootste variabele factor is het aantal en het type toegangspunten en antennes. Draadloze oplossingen moeten altijd gebaseerd zijn op een radiofrequentieontwerp, maar (en helaas) is dit vaak de tweede stap in de levenscyclus van het project. In het geval van eenvoudige indoor enterprise implementaties zijn er tal van schattingstechnieken die, met een redelijke mate van zekerheid, kunnen voorspellen hoeveel AP's nodig kunnen zijn, zelfs voordat een draadloze architect naar de plattegronden kijkt. Voorspellende modellen kunnen in dit geval ook erg handig zijn.
Voor meer uitdagende installaties, zoals industriële, outdoor, grote openbare netwerken, of overal waar externe antennes nodig zijn, eenvoudige schattingstechnieken zijn vaak ontoereikend. Er is enige ervaring vereist met eerdere soortgelijke installaties om het type en de hoeveelheid benodigde apparatuur adequaat in te schatten. Een bezoek aan de site door een draadloze architect is het absolute minimum om inzicht te krijgen in de lay-out van een complexe locatie of faciliteit.
In dit gedeelte worden richtlijnen gegeven voor het bepalen van het minimale aantal toegangspunten en antennes voor de gegeven implementatie. De uiteindelijke hoeveelheden en specifieke montagelocaties zullen altijd worden bepaald door middel van een vereiste analyse en radio-ontwerpproces.
De eerste materiaallijst moet gebaseerd zijn op twee factoren: type antennes en hoeveelheid antennes.
Soort antennes
Er zijn hier geen shortcuts. Het type antenne wordt bepaald door het gebied dat moet worden afgedekt en door de beschikbare montageopties in dat gebied. Het is niet mogelijk om dit te bepalen zonder inzicht in de fysieke ruimte, dit betekent dat een bezoek aan de site vereist is door iemand met een goed begrip van antennes en hun dekkingspatronen.
Aantal antennes
De hoeveelheid benodigde apparatuur kan worden afgeleid uit een goed begrip van het verwachte aantal clientverbindingen.
Apparaten per persoon
Het aantal menselijke gebruikers kan worden bepaald door de zitcapaciteit van een locatie, of het aantal verkochte tickets, of het verwachte aantal bezoekers op basis van historische statistieken. Elke menselijke gebruiker kan meerdere apparaten dragen en het is gebruikelijk om meer dan één apparaat per gebruiker aan te nemen, hoewel het vermogen van een menselijke gebruiker om meerdere apparaten tegelijkertijd actief te gebruiken twijfelachtig is. Het aantal bezoekers dat actief verbinding maakt met het netwerk hangt ook af van het type evenement en/of inzet.
Voorbeeld 1: Het is normaal dat een stadion met 80.000 zitplaatsen geen 80.000 aangesloten apparaten heeft, dit percentage is meestal aanzienlijk lager. Verbonden gebruikersratio's van 20% zijn niet ongewoon tijdens sportevenementen, dit betekent dat voor het stadionvoorbeeld met 80.000 zitplaatsen het verwachte aantal aangesloten apparaten 16.000 kan zijn (80.000 x 20% = 16.000). Dit aantal is ook afhankelijk van het gebruikte onboardingmechanisme, als de gebruiker bepaalde acties moet uitvoeren (zoals klikken op een webportaal), zijn de nummers lager dan wanneer het onboarden van het apparaat automatisch is. Automatische onboarding kan zo eenvoudig zijn als een PSK die is onthouden van een eerdere gebeurtenis, of iets geavanceerder zoals het gebruik van OpenRoaming dat apparaten zonder gebruikersinteractie aan boord neemt. OpenRoaming-netwerken kunnen ervoor zorgen dat de gebruikersratio's ruim boven de 50% liggen, wat een aanzienlijke impact kan hebben op de capaciteitsplanning.
Voorbeeld 2: Het is redelijk om te verwachten dat een technologieconferentie een hoge gebruikersverbindingsverhouding heeft. Deelnemers aan conferenties zijn langer verbonden met het netwerk en verwachten dat ze hun e-mail kunnen openen en dagelijkse taken gedurende de dag kunnen uitvoeren. Het is ook waarschijnlijker dat dit type gebruiker meer dan één apparaat verbindt met het netwerk - hoewel hun vermogen om meerdere apparaten tegelijkertijd te gebruiken twijfelachtig blijft. Voor technologieconferenties is de aanname dat 100% van de bezoekers verbinding maakt met het netwerk, dit aantal kan lager zijn voor afhankelijk van het conferentietype.
In beide voorbeelden is het belangrijk om het verwachte aantal verbonden apparaten te begrijpen en er is geen enkele oplossing voor elk groot openbaar netwerk. In beide gevallen is een antenne aangesloten op een radio en zijn het clientapparaten (geen menselijke gebruikers) die verbinding maken met die radio. Daarom is clientapparaten per radio een bruikbare metriek.
Apparaten per radio
Cisco AP's hebben een maximaal aantal clients van 200 verbonden apparaten per radio voor Wi-Fi 6 AP's en 400 apparaten per radio voor Wi-Fi 6E AP's. Het is echter niet raadzaam om te ontwerpen voor een maximaal aantal klanten. Voor planningsdoeleinden wordt aanbevolen het aantal clients per radio ruim onder 50% van de maximale AP-capaciteit te houden. Bovendien hangt het aantal radio's af van het type toegangspunt en de gebruikte antenne, het gedeelte over single versus dual 5GHz onderzoekt dit in meer detail.
In dit stadium is het een goed idee om het netwerk op te splitsen in verschillende gebieden, met verwachte apparaattellingen per gebied. Dit gedeelte is bedoeld om een minimumaantal toegangspunten en antennes te schatten.
Neem een voorbeeld van drie verschillende dekkingsgebieden, het verwachte aantal klanten wordt voor elk gebied verstrekt en een (gezonde) waarde van 75 clients per radio wordt gebruikt om het aantal vereiste radio's te schatten.
Verwacht aantal radio's/clients per gebied
Deze initiële nummers moeten nu worden gecombineerd met het begrip van welke soorten toegangspunten en antennes in elk gebied worden ingezet en of 5 GHz wordt gebruikt. Berekeningen van 6 GHz volgen dezelfde logica als die van 5 GHz. 2.4GHz wordt in dit voorbeeld niet in aanmerking genomen.
Laten we aannemen dat elk van de drie gebieden een combinatie van 2566P-patchantenne en de 9104-stadionantenne gebruikt, met een combinatie van één en twee 5GHz - dit scenario wordt gebruikt voor illustratiedoeleinden.
Antennes per gebied
Elk gebied vermeldt het type antennes en toegangspunten dat nodig is. Merk op dat in het geval van dubbele 5GHz de verhouding twee antennes op één AP is.
In dit gedeelte wordt een benadering getoond voor het schatten van het eerste aantal antennes en toegangspunten dat nodig is voor een implementatie. De schatting vereist inzicht in de fysieke gebieden, mogelijke montageopties in elk gebied, het type antennes dat in elk gebied moet worden gebruikt en het aantal verwachte clientapparaten.
Elke implementatie is anders en aanvullende apparatuur is vaak nodig om specifieke of uitdagende gebieden te dekken, dit type schatting houdt alleen rekening met de capaciteit van de klant (geen dekking) en dient om de omvang van de benodigde investering te schetsen. De uiteindelijke locaties voor plaatsing van toegangspunten/antennes en de totalen van de apparatuur zijn altijd onderworpen aan een grondig begrip van de use-case en verificatie ter plaatse door een ervaren draadloze professional.
Verwachte doorvoer
Elk draadloos kanaal kan een hoeveelheid beschikbare capaciteit bieden die meestal wordt vertaald naar doorvoer. Deze capaciteit wordt gedeeld tussen alle apparaten die op de radio zijn aangesloten, wat betekent dat de prestaties voor elke gebruiker afnemen naarmate er meer gebruikersverbindingen aan de radio worden toegevoegd. Deze daling van de prestaties is niet lineair en is ook afhankelijk van de exacte mix van aangesloten clients.
Clientmogelijkheden verschillen per apparaat, afhankelijk van de clientchipset en het aantal ruimtelijke streams dat de client ondersteunt. De maximale datasnelheden van de client voor elk aantal ondersteunde ruimtelijke streams worden in de onderstaande tabel weergegeven.
Verwachte maximale werkelijke doorvoer voor elk clienttype
De vermelde percentages zijn theoretische maximale MCS-percentages (Modulation and Coding Scheme) afgeleid van de 802.11-standaard en gaan uit van een signaal-ruisverhouding (SNR) > 30 dBm. Het belangrijkste ontwerpdoel van goed presterende draadloze netwerken is om dit niveau van SNR voor alle clients op alle locaties te bereiken, dit is echter zelden het geval. Draadloze netwerken zijn dynamisch van aard en gebruiken frequenties zonder licentie, verschillende ongecontroleerde interferenties hebben een impact op client-SNR, naast de mogelijkheden van de client.
Zelfs in gevallen waarin het vereiste niveau van SNR wordt bereikt, houden de eerder genoemde percentages geen rekening met de overhead van het protocol en worden ze daarom niet rechtstreeks gekoppeld aan de werkelijke doorvoer (zoals gemeten door verschillende snelheidstesttools). De echte wereld is altijd lager dan het MCS-tarief.
Voor alle draadloze netwerken (inclusief grote openbare netwerken) is de doorvoer van de client altijd afhankelijk van:
Op basis van de variabiliteit van deze factoren is het niet mogelijk om een minimum per client te garanderen voor draadloze netwerken, ongeacht de leverancier van de apparatuur.
Raadpleeg voor meer informatie de handleiding Wi-Fi-doorvoer valideren: testen en bewaken.
Het kiezen van uw WLC-platform kan eenvoudig lijken. Het eerste waar u aan kunt denken, is om te kijken naar het geschatte aantal AP's en het aantal klanten dat u wilt beheren. Het gegevensblad voor elk WLC-platform bevat alle maximaal ondersteunde objecten op het platform: ACL's, aantal clients, sitetags enzovoort. Dat zijn letterlijk maximale aantallen en vaak is er een harde handhaving. U kunt bijvoorbeeld geen 6001 AP's toevoegen aan een 9800-80 die slechts 6000 AP's ondersteunt. Maar is het verstandig om overal naar het maximale te streven?
Draadloze controllers van Cisco zijn getest om die maxima te kunnen bereiken, maar ze kunnen niet noodzakelijkerwijs alle gedocumenteerde maxima in alle omstandigheden tegelijkertijd bereiken. Laten we het voorbeeld van doorvoer nemen, een 9800-80 kan tot 80 Gbps aan clientgegevens doorsturen, maar dit is in het geval waarin elk clientpakket de maximale en optimale grootte van 1500 bytes heeft. Met een mix van pakketgroottes is de effectieve maximale doorvoer lager. Als u DTLS-codering inschakelt, wordt de doorvoer verder verminderd en hetzelfde geldt voor de zichtbaarheid van toepassingen. Het is optimistisch om meer dan 40 Gbps te verwachten van een 9800-80 in realistische omstandigheden op een groot netwerk met veel functies ingeschakeld. Omdat dit sterk varieert, afhankelijk van de functies die worden gebruikt en het type netwerkactiviteit, is de enige manier om een echt idee te krijgen van de capaciteit het gebruik van het gegevenspad te meten met behulp van deze opdracht. Focus op de belasting metriek, dat is een percentage van de maximale doorvoer van de controller kan vooruit.
WLC#show platform hardware chassis active qfp datapath utilization summary
CPP 0: 5 secs 1 min 5 min 60 min
Input: Total (pps) 9 5 5 8
(bps) 17776 7632 9024 10568
Output: Total (pps) 5 3 3 6
(bps) 11136 11640 11440 41448
Processing: Load (pct) 0 0 0 0
WLC#Op dezelfde manier kan de 9800-80 perfect omgaan met 6000 AP's met regelmatige activiteit. 6000 AP's in een openbare ruimte zoals een stadion of een luchthaven tellen echter niet als reguliere activiteit. Gezien de hoeveelheid client roaming en ambient probing, kunnen grote openbare netwerken op maximale schaal een verhoogd CPU-gebruik op één WLC veroorzaken. Als u bewaking en SNMP-traps toevoegt die elke keer dat clients worden verzonden, worden verzonden, kan de belasting snel te veel worden. Een van de belangrijkste kenmerken van een grote openbare locatie of groot evenement is dat er aanzienlijk meer client onboarding-evenementen zijn als mensen zich verplaatsen en constant associëren / disassociëren, dus dit veroorzaakt extra druk op de CPU en het besturingsvlak.
Talrijke implementaties hebben aangetoond dat een enkel (HA) paar van 9800-80 draadloze controllers een grote stadionimplementatie met meer dan 1000 AP's aankan. Het is ook gebruikelijk om de toegangspunten te verdelen over twee of meer controllerparen voor kritieke gebeurtenissen waarbij uptime en beschikbaarheid de belangrijkste aandachtspunten zijn. Wanneer grote netwerken over meerdere WLC's worden verdeeld, is er de extra complexiteit van roaming tussen controllers, waarbij clientroaming zorgvuldig moet worden overwogen in beperkte ruimtes zoals een stadionschaal.
Zie ook de sectie Site Tag in dit document.
Het wordt aangeraden om een High-Availability Stateful Switch Over (HSSO)-paar te gebruiken, dit biedt hardwareredundantie, maar beschermt ook tegen softwarefouten. Met behulp van HSSO is een softwarecrash op één apparaat transparant voor de eindgebruikers, omdat de secundaire WLC het naadloos overneemt. Een ander voordeel van een HA SSO-paar zijn de hitless upgrades die worden aangeboden door de In-Service Software Upgrade (ISSU) -functie.
Als het netwerk groot genoeg is, wordt ook geadviseerd om een extra controller (N+1) te gebruiken. Het kan verschillende doelen dienen die de HSSO niet kan bereiken. U kunt een nieuwe softwareversie op deze WLC testen voordat u het productiepaar upgradet (en er slechts een paar test-AP's naar migreren om een specifiek gedeelte van het netwerk te testen). Sommige zeldzame aandoeningen kunnen beide WLC's in een HA-paar beïnvloeden (wanneer het probleem wordt gerepliceerd naar de stand-by) en hier maakt de N + 1 het mogelijk om een veilige WLC te hebben in een actief-actief scenario waar u AP's geleidelijk van en naar kunt migreren. Het kan ook dienen als een provisioning controller voor het configureren van nieuwe toegangspunten.
De 9800-CLs zijn zeer schaalbaar en krachtig. Opgemerkt moet worden dat ze een veel kleinere capaciteit hebben voor het doorsturen van gegevens (van 2 Gbps naar 4 Gbps voor het SR-IOV-beeld), waardoor ze meestal beperkt blijven tot lokale FlexConnect-switchscenario's (en mogelijk een klein aantal toegangspunten in centrale switching). Ze kunnen echter nuttig zijn als N + 1-apparaten wanneer u extra controllers nodig hebt tijdens een onderhoudsvenster of bij het oplossen van een probleem.
Hoewel dit document zich voornamelijk richt op de draadloze component van grote evenementennetwerken, zijn er ook tal van ondersteunende systemen die aandacht vereisen tijdens de schaling- en ontwerpfase, waarvan sommige hier worden besproken.
kernnetwerk
Grote draadloze netwerken worden meestal geïmplementeerd in centrale switchmodus en met grote subnetten. Dit houdt in dat een zeer groot aantal client MAC-adres en ARP-vermeldingen naar de aangrenzende bekabelde infrastructuur worden geduwd. Het is van cruciaal belang dat de aangrenzende systemen die zijn gewijd aan de verschillende L2- en L3-functies over de juiste middelen beschikken om deze belasting te verwerken. In het geval van L2-switches is een gemeenschappelijke configuratie het aanpassen van de Switch Device Manager (SDM) -sjabloon, die verantwoordelijk is voor de toewijzing van systeembronnen, waarbij een balans wordt gemaakt tussen L2- en L3-functies, afhankelijk van de functie van het apparaat in het netwerk. Het is belangrijk om ervoor te zorgen dat L2-kernapparaten het verwachte aantal MAC-adresvermeldingen kunnen ondersteunen.
Gateway NAT
De meest voorkomende use-case van openbare netwerken is om internettoegang te bieden aan bezoekers. Ergens langs het gegevenspad moet er een apparaat zijn dat verantwoordelijk is voor NAT/PAT-vertaling. Internetgateways moeten beschikken over de vereiste hardwarebronnen en IP-poolconfiguratie om de belasting te verwerken. Vergeet niet dat één draadloos clientapparaat verantwoordelijk kan zijn voor tal van NAT/PAT-vertalingen.
DNS/DHCP
Deze twee systemen zijn essentieel voor een goede klantervaring. Zowel DNS- als DHCP-services vereisen niet alleen de juiste schaling om de belasting te verwerken, maar ook aandacht voor plaatsing binnen het netwerk. Snelle en responsieve systemen, geplaatst op dezelfde locatie als de WLC, zorgen voor de beste ervaring en voorkomen lange onboarding-tijden van de klant.
AAA/webportaal
Niemand houdt van een trage webpagina, het kiezen van een geschikt en goed geschaald systeem voor externe webverificatie is belangrijk voor een goede onboarding-ervaring van de klant. Ook voor AAA moeten RADIUS-verificatieservers kunnen voldoen aan de eisen van het draadloze systeem. Houd er rekening mee dat in sommige gevallen de belasting kan pieken tijdens belangrijke momenten, bijvoorbeeld de rust tijdens een voetbalwedstrijd, die in een kleine hoeveelheid tijd een hoge authenticatielast kan genereren. Het systeem opschalen voor een adequate gelijktijdige belasting is essentieel. Specifieke zorg moet worden genomen bij het gebruik van functies zoals AAA-boekhouding. Vermijd tijdgebaseerde boekhouding ten koste van alles en als u boekhouding gebruikt, probeer dan tussentijdse boekhouding uit te schakelen. Een ander belangrijk punt om te overwegen is het gebruik van load-balancers, hier moeten sessie-pining-mechanismen worden gebruikt om volledige authenticatiestromen te garanderen. Zorg ervoor dat de RADIUS time-out op 5 seconden of hoger blijft.
Als u een 802.1X SSID gebruikt met een groot aantal clients (bijvoorbeeld met OpenRoaming), moet u 802.11r Fast Transition (FT) inschakelen, anders kunnen clients een verificatiestorm veroorzaken telkens wanneer ze rondlopen.
Enkele tips voor DHCP:
Het is verleidelijk om veel opties in te schakelen om te profiteren van alle nieuwste functies van moderne Wi-Fi. Bepaalde functies werken echter geweldig in kleine omgevingen, maar hebben een enorme impact in grote en dichte omgevingen. Bepaalde functies kunnen ook compatibiliteitsproblemen opleveren. Hoewel Cisco-apparatuur voldoet aan alle normen en compatibiliteit biedt met een breed scala aan geteste clients, is de wereld gevuld met unieke clientapparaten die soms stuurprogrammaversies hebben met fouten of incompatibiliteit met bepaalde functies.
Afhankelijk van de mate van controle die je hebt over de klanten, moet je conservatief zijn. Als u bijvoorbeeld de Wi-Fi implementeert voor de grote jaarlijkse bijeenkomst van uw bedrijf, weet u dat de meeste clients bedrijfsapparaten zijn en kunt u de functieset plannen om dienovereenkomstig in te schakelen. Aan de andere kant, als u een Wi-Fi-verbinding op de luchthaven exploiteert, heeft uw gasttevredenheidsniveau rechtstreeks betrekking op hun vermogen om verbinding te maken met uw netwerk en hebt u geen enkele controle over de clientapparaten die mensen kunnen gebruiken.
Het advies is altijd geweest om zo min mogelijk SSID's te gebruiken. Dit wordt verergerd in netwerken met hoge dichtheid, omdat de mogelijkheid om meerdere toegangspunten op hetzelfde kanaal te hebben bijna gegarandeerd is. Veel implementaties gebruiken meestal te veel SSID's, erkennen dat ze te veel SSID's hebben, maar verklaren dat ze niet minder kunnen gebruiken. U moet voor elke SSID een bedrijfs- en technische studie uitvoeren om de overeenkomsten tussen SSID's en opties voor het samenvouwen van meerdere SSID's in één te begrijpen.
Laten we een paar beveiligings- / SSID-typen en het gebruik ervan bespreken.
Een vooraf gedeelde sleutel-SSID is enorm populair vanwege de eenvoud ervan. U kunt de sleutel ergens op badges of op papier of borden afdrukken of op de een of andere manier aan bezoekers communiceren. Soms heeft een vooraf gedeelde sleutel-SSID de voorkeur, zelfs voor een gast-SSID (op voorwaarde dat de sleutel bij alle deelnemers bekend is). Het kan helpen voorkomen dat DHCP zwembad uitputting als gevolg van de opzettelijke aard van de verbinding. Apparaten die langskomen, maken niet automatisch verbinding met het netwerk en kunnen daarom geen IP-adres uit de DHCP-pool gebruiken.
WPA2 PSK biedt geen privacy, omdat verkeer gemakkelijk kan worden ontsleuteld omdat iedereen dezelfde sleutel gebruikt. Integendeel, WPA3 SAE biedt privacy, en zelfs als iedereen de hoofdsleutel heeft, is het niet mogelijk om de coderingssleutel af te leiden die door andere clients wordt gebruikt.
WPA3 SAE is de betere keuze voor beveiliging en veel smartphones, laptops en besturingssystemen ondersteunen het. Sommige IoT-apparaten of slimme wearables kunnen nog steeds beperkte ondersteuning hebben en oudere clients in het algemeen zijn vatbaar voor problemen als ze geen recente stuurprogramma's of firmware-updates hebben ontvangen.
Het kan verleidelijk zijn om een overgangsmodus WPA2 PSK-WPA3 SAE SSID te overwegen om dingen te vereenvoudigen, maar dit is in het veld aangetoond om enkele compatibiliteitsproblemen te veroorzaken. Slecht geprogrammeerde clients verwachten geen twee typen gedeelde sleutelmethoden op dezelfde SSID. Als u zowel WPA2- als WPA3-opties wilt aanbieden, is het raadzaam om afzonderlijke SSID's te configureren.
WPA3 Enterprise (met behulp van AES 128-bits codering) is technisch gezien dezelfde beveiligingsmethode (ten minste zoals geadverteerd in de SSID-bakens) als WPA2 Enterprise, die zorgt voor maximale compatibiliteit.
Voor 802.1X wordt een SSID voor de overgangsmodus geadviseerd omdat compatibiliteitsproblemen niet worden gezien met recente apparaten (problemen werden gemeld met Android 8 of oude Apple IOS-versies). IOS XE 10 .12 en latere releases maken het mogelijk om een enkele Transition Enterprise SSID te hebben waarbij alleen WPA3 wordt gebruikt en geadverteerd op 6 GHz, terwijl WPA2 wordt aangeboden als een optie op de 5 GHz-band. Wij adviseren om WPA3 zo snel mogelijk in te schakelen op Enterprise SSID's.
WPA Enterprise-SSID's kunnen worden gebruikt voor belangrijke gebruikers waarvoor er een identiteitsproviderdatabase is waarmee AAA-parameters (zoals VLAN's of ACL's) kunnen worden geretourneerd, afhankelijk van de gebruikersidentiteit. Dergelijke soorten SSID's kunnen eduroam of OpenRoaming omvatten, die de voordelen van gast-SSID's combineren (door bezoekers in staat te stellen eenvoudig verbinding te maken zonder inloggegevens in te voeren) met de beveiliging van een bedrijfs-SSID. Ze verminderen de complexiteit van onboarding die doorgaans wordt geassocieerd met 802.1X aanzienlijk, omdat klanten niets hoeven te doen om deel te nemen aan de Eudroam- of OpenRoaming-SSID, op voorwaarde dat ze een profiel op hun telefoon hebben (dat gemakkelijk kan worden verstrekt via een evenementenapp)
Een gast-SSID is vaak synoniem met open verificatie. U kunt een webportaal (of niet) erachter toevoegen (afhankelijk van de gewenste vriendelijkheid of lokale vereisten) in de verschillende vormen: externe, lokale of centrale webverificatie, maar het concept blijft hetzelfde. Bij het gebruik van een gastenportaal kan schaalbaarheid snel een probleem worden in grote omgevingen. Raadpleeg het gedeelte Configureren voor schaalbaarheid voor meer informatie hierover.
Voor 6GHz-bewerkingen moet de gast-SSID Enhanced Open gebruiken in plaats van alleen Open. Hiermee kan iedereen nog steeds verbinding maken, maar biedt privacy (een betere privacy dan zelfs WPA2-PSK!) en codering, allemaal zonder sleutel of inloggegevens te verstrekken bij het verbinden op de SSID. De belangrijkste leveranciers van smartphones en besturingssystemen ondersteunen nu Enhanced Open, maar de ondersteuning is nog niet wijdverbreid in het draadloze clientbestand. Enhanced Open Transition-modus biedt een goede compatibiliteitsoptie waarbij apparaten die in staat zijn verbinding te maken met de gecodeerde gast-SSID (met behulp van Enhanced Open) en de niet-compatibele apparaten de SSID nog steeds gebruiken als gewoon geopend zoals voorheen. Hoewel slechts één SSID wordt opgemerkt door eindgebruikers, moet u er rekening mee houden dat deze overgangsmodus twee SSID's in uw bakens uitzendt (hoewel er slechts één zichtbaar is).
In grote evenementen en locaties wordt vaak geadviseerd om een PSK op de gast-SSID te configureren in plaats van deze puur open te laten (de open transitiemodus verbeteren zou beter zijn, maar dat creëert twee SSID's en de compatibiliteit van de client moet nog steeds uitgebreid worden bewezen). Hoewel dit de onboarding een beetje ingewikkelder maakt (je moet de PSK afdrukken op de badges of tickets van mensen of er op de een of andere manier reclame voor maken), vermijdt het informele clients die automatisch verbinding maken met het netwerk zonder dat de eindgebruiker van plan is om het netwerk te gebruiken. Steeds meer leveranciers van mobiele besturingssystemen geven ook de voorkeur aan open netwerken en geven een veiligheidswaarschuwing. In andere situaties kunt u een maximaal aantal voorbijgangers willen verbinden en daarom is open de betere keuze.
Er kan geen bevredigend antwoord zijn op de vraag aan hoeveel SSID's u zich moet houden. Het effect hangt af van de minimale geconfigureerde gegevenssnelheid, het aantal SSID's en het aantal AP's dat op hetzelfde kanaal wordt uitgezonden. Op een groot Cisco-evenement gebruikte de draadloze infrastructuur 5 SSID's: de belangrijkste WPA2 PSK, een WPA 3 SAE SSID voor beveiliging en 6 GHz-dekking, een Enterprise Eduroam SSID voor gemakkelijke toegang voor onderwijsdeelnemers, een OpenRoaming SSID om iedereen die Wi-Fi heeft geconfigureerd vanuit de evenementenapp veilig te verwelkomen en een afzonderlijke 802.1X SSID voor het personeel en de toegang tot het beheernetwerk. Dit was al bijna te veel, maar het effect bleef redelijk dankzij het grote aantal beschikbare kanalen en de directionele antennes die werden gebruikt om kanaaloverlap zoveel mogelijk te verminderen.
Voor een bepaalde periode werd geadviseerd om de 2.4GHz-service te beperken tot een "Legacy" afzonderlijke SSID alleen geadverteerd in 2.4GHz. Dit wordt steeds minder populair als mensen stoppen met het verstrekken van 2.4GHz service helemaal. Het idee kan en moet echter blijven bestaan, maar met andere concepten. U wilt WPA3 SAE uitrollen, maar geeft de overgangsmodus u compatibiliteitsproblemen met uw clients? Beschikt over een WPA2 "Legacy" SSID en een hoofd WPA3 SAE SSID. Door de minst presterende SSID "legacy" te noemen, trekt deze geen klanten aan en kunt u gemakkelijk zien hoeveel clients nog steeds compatibiliteitsproblemen hebben met uw belangrijkste SSID en deze legacy vereisen.
Maar waarom stoppen daar? U hoorde geruchten dat 802.11v problemen veroorzaakte met sommige oudere clients of dat sommige clientstuurprogramma's het niet leuk vinden om Device Analytics ingeschakeld te zien op de SSID? Schakel al die handige functies in op uw geavanceerde hoofd-SSID en laat ze achter op uw legacy/compatibiliteit-SSID. Hiermee kunt u de uitrol van nieuwe functies op uw belangrijkste SSID testen en tegelijkertijd een maximale compatibiliteit bieden voor SSID-clients om op terug te vallen. Dit systeem werkt alleen op deze manier. Als u de tegenovergestelde naam van uw compatibiliteitsgestuurde SSID als uw belangrijkste naam en uw geavanceerde SSID met iets als "<name>-WPA3" doet, merkt u dat mensen vasthouden aan de oude SSID die ze gewend waren en dat de acceptatie vele jaren klein blijft op uw "nieuwe" SSID. Het uitrollen van nieuwe instellingen of functies heeft dan onduidelijke resultaten vanwege het lagere aantal clients dat ermee verbinding maakt.
Site-tags zijn een configuratie-item waarmee toegangspunten kunnen worden gegroepeerd die dezelfde FlexConnect-instellingen delen, evenals AP-profielinstellingen (zoals referenties, SSH-gegevens en landcode). Waarom zijn site tags belangrijk? Site-tags definiëren ook hoe AP's worden behandeld door het WNCD-proces in de Catalyst 9800. Laten we een paar voorbeelden geven om te illustreren:
Eerste voorbeeld van site tag balancing
Tweede voorbeeld van site tag balancing
Voor geografisch grote implementaties met veel sites en veel sitetags wordt aanbevolen dat het aantal sitetags een veelvoud is van het aantal WNCD-processen op het platform dat u gebruikt.
Voor evenementennetwerken die meestal onder één dak of meerdere gebouwen op dezelfde locatie staan, is de aanbeveling echter om het aantal sitetags af te stemmen op het exacte aantal WNCD's op het gegeven platform. Het einddoel is dat elk WNCD-proces (en dus elke CPU-kern die is toegewezen aan draadloze taken) ongeveer hetzelfde aantal client-roam-gebeurtenissen afhandelt, zodat de belasting over alle CPU-kernen wordt verdeeld.
Aantal WNCD-processen voor elk platformtype
Waar het in de kern echt om gaat, is om AP's die zich in dezelfde fysieke buurt bevinden, te groeperen in dezelfde sitetag, zodat de frequente client-roaminggebeurtenissen tussen deze AP's in hetzelfde CPU-proces blijven. Dit betekent dat zelfs als u een enkele grote locatie hebt, het wordt aanbevolen om de locatie in verschillende sitetags te verdelen (zoveel als u WNCD-processen hebt die de locatie beheren) en AP's zo logisch mogelijk in deze te groeperen om logische RF-buurtgroepen te vormen die ook gelijkmatig verdeeld zijn over sitetags.
Vanaf IOS XE 10 .12 kan een load balancing-algoritme worden ingeschakeld, zodat de WLC de AP's groepeert op basis van hun RF-nabijheid. Dit neemt de last uit handen en zorgt voor een evenwichtige spreiding van de AP's over het WNCD-proces. Dit kan handig zijn als u niet gemakkelijk groepen van naburige toegangspunten kunt tekenen om in de juiste hoeveelheid sitetags te worden geplaatst. Een specificiteit van dit algoritme is dat het AP's toewijst aan het WNCD-proces, ongeacht de toewijzing van de sitetag, wat betekent dat het de toewijzing van de sitetag van het AP niet wijzigt. U kunt vervolgens sitetags toewijzen op basis van een configuratielogica en het algoritme de AP's op de meest optimale manier over CPU's laten balanceren.
De op RF gebaseerde functie voor automatische taakverdeling van het toegangspunt is gedocumenteerd in de Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide, Cisco IOS XE Dublin 17.12.x.
Het CPU-gebruik van WNCD-processen moet tijdens grote gebeurtenissen worden gecontroleerd. Als een of meer WNCD-processen een hoge benuttingsgraad vertonen, kan het zijn dat de WNCD te veel AP's of clients verwerkt, of dat de AP's of clients die het behandelt drukker zijn dan het gemiddelde (als ze allemaal constant zwerven, zoals op een luchthaven bijvoorbeeld).
Als het netwerk eenmaal actief is, moet u het nauwlettend in de gaten houden op problemen. In een standaard kantooromgeving kennen gebruikers het netwerk en kunnen ze elkaar helpen in geval van problemen of een intern helpdeskticket openen. In een grotere locatie met veel bezoekers wilt u zich richten op de grootste problemen in plaats van specifieke personen die gewoon een verkeerde configuratie kunnen hebben, dus u moet de juiste monitoringstrategie hebben.
Monitoring van het netwerk vanuit de Catalyst 9800 CLI of GUI is mogelijk, maar het is niet de beste tool om dagelijks te monitoren. Het is het meest direct wanneer u al vermoedens en/of gegevens over het probleem heeft en specifieke opdrachten in realtime wilt uitvoeren. De belangrijkste bewakingsopties zijn Cisco Catalyst Center of mogelijk een aangepast telemetriedashboard. Het is mogelijk om 3rd party monitoring tools te gebruiken, maar wanneer die SNMP gebruiken als een protocol, de gegevens zijn verre van real-time en de gebruikelijke 3rd party monitoring tools zijn niet granulair genoeg met alle draadloze leveranciers specifieke kenmerken. Als u het SNMP-protocol kiest, moet u SNMPv3 gebruiken omdat SNMPv2 een verouderde beveiliging heeft.
Cisco Catalyst Center is de beste optie, omdat u hiermee uw netwerk kunt beheren en bewaken. Meer dan monitoring, het maakt het ook mogelijk om problemen live op te lossen en veel situaties te verhelpen.
Een aangepast telemetrie dashboard kan handig zijn als u wilt zeer specifieke statistieken en widgets weer te geven op een scherm in een always-on mode voor een NOC of SOC. Als er zeer specifieke gebieden van uw netwerk zijn die u in de gaten wilt houden, kunt u speciale widgets bouwen om de netwerkstatistieken in die gebieden op de manier van uw keuze weer te geven.
Voor evenementennetwerken is het een goed idee om RF-statistieken voor het hele systeem te controleren, met name het kanaalgebruik en het aantal clients per AP. Dit kan worden gedaan vanuit de CLI, maar biedt alleen een momentopname op een specifiek tijdstip, kanaalgebruik is meestal dynamisch en is beter geschikt voor monitoring in de loop van de tijd. Voor dit soort monitoring is een custom dashboard meestal een goede aanpak. Andere statistieken die waardevoller zijn wanneer ze in de loop van de tijd worden gecontroleerd, kunnen WNCD-gebruik, aantal clients en hun status en locatiespecifieke statistieken omvatten. Een voorbeeld van locatiespecifieke statistieken is het monitoren van het gebruik en/of de belasting voor een specifieke ruimte of locatie, bijvoorbeeld hal X in het geval van een conferentiecentrum, of zitgedeelte Y in het geval van een evenementenlocatie.
Voor aangepaste monitoring zijn zowel NETCONF RPC (pull) als NETCONF streaming telemetrie (push) geldige benaderingen, hoewel het gebruik van aangepaste streaming telemetrie in combinatie met Catalyst Center enige zorgvuldigheid vereist, omdat er een limiet is aan het aantal telemetrie-abonnementen dat kan worden geconfigureerd op de WLC en Catalyst Center veel van deze vooraf vult (en gebruikt).
Bij het gebruik van NETCONF RPC is een aantal tests vereist om ervoor te zorgen dat de WLC niet wordt overladen met NETCONF-verzoeken, met name belangrijk om in gedachten te houden zijn vernieuwingssnelheden voor sommige van de gegevenspunten en de tijd die nodig is voor de gegevens worden geretourneerd. Het gebruik van AP-kanalen wordt bijvoorbeeld elke 60 seconden vernieuwd (van AP naar WLC) en het verzamelen van RF-statistieken voor 1000 AP's (van WLC) kan enkele seconden duren, in dit voorbeeld zou het niet nuttig zijn om elke 5 seconden de WLC te peilen, een betere aanpak zou zijn om elke 3 minuten RF-statistieken voor het hele systeem te verzamelen.
NETCONF heeft altijd de voorkeur boven SNMP.
Ten slotte kan de bewaking van kernnetwerkcomponenten niet over het hoofd worden gezien, inclusief het gebruik van de DHCP-pool, het aantal NAT-vermeldingen op kernrouters enzovoort. Omdat het falen van een van deze gemakkelijk de oorzaak kan zijn van een draadloze storing.
Er zijn een paar klassieke scenario's waarbij te veel monitoring problemen veroorzaakt:
Als u een SSID hebt met behulp van webverificatie, kan een probleem bestaan uit clients die verbinding maken met die SSID en een IP-adres krijgen, maar zich nooit authenticeren omdat de eindgebruiker niet actief probeert verbinding te maken (het apparaat wordt automatisch verbonden). De controller moet elk HTTP-pakket onderscheppen dat wordt verzonden door die clients die zich in de staat bevinden die webverificatie wordt genoemd en waarvoor WLC-bronnen worden gebruikt. Als uw netwerk eenmaal actief is, houdt u periodiek het aantal clients in de gaten dat zich op een bepaald moment in de wachtstand voor webverificatie bevindt om te zien hoe het zich verhoudt tot basislijnnummers. Hetzelfde geldt voor clients in de staat IP Learn. U hebt altijd klanten in die staat wanneer ze hun DHCP-proces uitvoeren, maar weten wat een goed werknummer voor uw netwerk is, helpt om een basislijn in te stellen en momenten te identificeren waarop dit nummer te hoog kan zijn en een groter probleem aangeeft.
Voor grote locaties is het niet ongebruikelijk om ~ 10% van de klanten in Web Auth Pending-staat te zien.
Als het netwerk eenmaal actief is, zijn er twee typische soorten klachten van eindgebruikers: ze kunnen geen verbinding maken of moeite hebben om verbinding te maken (verbreekt verbindingen), of de Wi-Fi werkt trager dan verwacht. Dit laatste is erg lastig te identificeren omdat het eerst afhangt van de verwachtingen van de snelheid en de realtime dichtheid van een bepaald gebied. Laten we een paar bronnen behandelen die nuttig kunnen zijn bij uw dagelijkse monitoring van een groot openbaar locatienetwerk.
Wi-Fi-doorvoer valideren: test- en controlehandleiding. In dit document van cisco.com wordt beschreven hoe u een netwerk kunt controleren om problemen met de doorvoer op te sporen. Het gaat door het uitzoeken hoeveel doorvoer klanten redelijkerwijs kunnen verwachten in uw netwerk wanneer de dingen stil zijn en om in te schatten hoeveel deze schattingen naar beneden gaan als het aantal klanten en de belasting toeneemt. Dit is essentieel om te evalueren of een klacht van een eindgebruiker over doorvoer vanuit technisch oogpunt legitiem is of niet, en of u dat gebied opnieuw moet ontwerpen voor de belasting waarmee het mogelijk wordt geconfronteerd.
Wanneer klanten connectiviteitsproblemen melden, nadat deze zijn geïsoleerd en opgehelderd met Catalyst Center, bekijkt u Problemen oplossen met Catalyst 9800 Client Connectivity Flow.
Ten slotte, als een algemene goede praktijk, houden een oogje op de algemene belangrijkste metrics van de WLC met behulp van Monitor Catalyst 9800 KPI's (Key Performance Indicators).
Vermijd het maken van SVI's voor client-VLAN's op de WLC. Beheerders die oudere AireOS-WLC's gebruiken, hebben de neiging om een laag 3-interface te maken voor elke client-VLAN, maar dit is zelden vereist. Interfaces verhogen de aanvalsvector van het besturingsvlak en kunnen meer ACL's vereisen met complexere vermeldingen. De WLC is standaard toegankelijk op elk van de interfaces, er is meer werk nodig om een WLC met meer interfaces te beschermen. Het bemoeilijkt ook de routering, dus het is het beste om het te vermijden.
Vanaf IOS XE 17.9 zijn de SVI-interfaces niet langer nodig voor mDNS-spionage of DHCP-relaisscenario's. Er zijn daarom zeer weinig redenen om een SVI-interface in een client-VLAN te configureren.
Voor grote openbare netwerken is het raadzaam om het standaard geaggregeerde sonde-interval dat door toegangspunten wordt verzonden, te wijzigen. Standaard werken de toegangspunten de WLC elke 500 ms bij over de sondes die door clients worden verzonden. Deze informatie wordt gebruikt voor taakverdeling, bandselectie, locatie en 802.11k-functies. Als er veel clients en toegangspunten zijn, is het raadzaam om het updateinterval aan te passen om problemen met de prestaties van het besturingsvlak in de WLC te voorkomen. De aanbevolen instelling is 50 geaggregeerde sonderesponsen elke 64 seconden. Zorg er ook voor dat uw toegangspunten geen sondes van lokaal beheerde MAC-adressen rapporteren, omdat het geen zin heeft om degenen te volgen die overwegen dat een enkele client veel lokaal beheerde MAC's zou kunnen gebruiken tijdens het scannen om tracking opzettelijk te voorkomen.
wireless probe limit 50 64000
no wireless probe locally-administered-macVeel netwerkbeheerders zijn nog steeds in ontkenning van IPv6. Er zijn slechts twee aanvaardbare opties met IPv6: ofwel u ondersteunt het en moet overal adequate configuratie implementeren, of u doet het niet en u moet het blokkeren. Het is onaanvaardbaar om niet te geven om IPV6 en het op sommige plaatsen ingeschakeld te laten zonder de juiste configuratie. Dat zou die hele IP-wereld achterlaten waar uw netwerkbeveiliging blind voor zou zijn.
Als u IPv6 inschakelt, is het verplicht om een virtueel IPv6-adres te configureren in het bereik 2001: DB8::/32 (dat is een vaak vergeten stap).
Het is belangrijk op te merken dat, hoewel IPv6 veel afhankelijk is van multicast voor zijn basisbewerkingen, het nog steeds kan werken als u het doorsturen van multicast op de WLC uitschakelt. Multicast forwarding verwijst naar het doorsturen van multicast-gegevens van clients en niet naar de Neighbor Discovery, Router Solications en andere vereiste protocollen om IPv6 te gebruiken.
Als uw internetverbinding of internetprovider IPv6-adressen verstrekt, kunt u besluiten om IPv6 voor uw klanten toe te staan. Dat is een andere beslissing dan het inschakelen van IPv6 in uw infrastructuur. Uw toegangspunten kunnen alleen in IPv4 blijven werken, maar kunnen nog steeds IPv6-clientgegevensverkeer in hun CAPWAP-pakketten vervoeren. Als u IPv6 ook op uw infrastructuur inschakelt, moet u nadenken over de bescherming van de clienttoegang tot uw toegangspunten, WLC en subnetbeheer.
Controleer de RA-frequentie van de gateways van uw client. De WLC biedt een RA-afknijpbeleid dat het aantal RA's beperkt dat naar de klanten wordt doorgestuurd, omdat deze soms spraakzaam kunnen worden.
Over het algemeen is het het beste om mDNS volledig uitgeschakeld te houden in een grote locatie-implementatie.
mDNS-bridging verwijst naar het concept om de mDNS-pakketten als een Layer 2-multicast te verzenden (dus naar het hele clientsubnet). mDNS werd populair in scenario's voor thuiskantoren en kleine kantoren, waar het heel praktisch is om services in uw subnet te ontdekken. In een groot netwerk betekent dit echter het verzenden van het pakket naar alle clients in het subnet, wat problematisch is vanuit een verkeersperspectief in een groot openbaar netwerk. Aan de andere kant veroorzaakt bridging geen overhead voor de AP- of WLC-CPU, omdat het wordt beschouwd als regulier dataverkeer. mDNS Proxy of mDNS-gateway verwijst naar het concept van het gebruik van de WLC als een directory voor alle services in het netwerk. Dit maakt het mogelijk om mDNS-diensten over Layer 2-grenzen op een efficiënte manier aan te bieden en ook het totale verkeer te verminderen. Met mDNS-gateway verzendt een printer bijvoorbeeld zijn periodieke serviceaankondiging via mDNS met een zelfde subnet Layer 2 multicast, maar de WLC stuurt deze niet door naar alle andere draadloze clients. In plaats daarvan neemt het een notitie van de aangeboden dienst en registreert het deze in zijn servicedirectory. Wanneer een klant vraagt om diensten van een bepaald type beschikbaar, de WLC antwoordt namens de printer met de aankondiging. Dit voorkomt dat alle andere draadloze clients te horen over onnodige verzoeken en service-aanbod en alleen een antwoord krijgen wanneer ze vragen welke diensten zijn rond. Hoewel het de verkeersefficiëntie aanzienlijk verbetert, veroorzaakt het een overhead op de WLC (of het toegangspunt, als u vertrouwt op AP mDNS in FlexConnect-scenario's) vanwege het snuffelen van mDNS-verkeer. Als u mDNS-gateway gebruikt, is het van cruciaal belang om het CPU-gebruik in de gaten te houden.
Het overbruggen van het leidt tot een multicast storm in uw grote subnet en snuffelen (met de mDNS gateway-functie) veroorzaakt veel CPU-gebruik. Schakel het wereldwijd en op elk WLAN uit.
Sommige beheerders schakelen mDNS in omdat een paar services het op specifieke plaatsen nodig hebben, maar het is belangrijk om te begrijpen hoeveel ongewenst verkeer dit toevoegt. Apple-apparaten adverteren vaak zelf en zijn voortdurend op zoek naar services, waardoor een achtergrondgeluid van mDNS-zoekopdrachten ontstaat, zelfs als niemand specifiek gebruik maakt van een service. Als u mDNS moet toestaan vanwege een bepaalde bedrijfsvereiste, schakelt u het globaal in en schakelt u het vervolgens alleen in op het WLAN waar het vereist is en probeert u het bereik te beperken waar mDNS is toegestaan.
In grote openbare netwerken kunnen veel dingen gebeuren zonder dat de beheerder ervan op de hoogte is. Mensen vragen kabeldruppels op willekeurige plaatsen, of steken een switch van huiskwaliteit op een locatie om meer schakelpoorten voor hun shenanigans te hebben, … Ze proberen deze dingen meestal zonder eerst toestemming te vragen. Dit betekent dat, zelfs zonder dat een slechte actor in het spel komt, de veiligheid al in gevaar kan worden gebracht door goedwillende klanten en / of werknemers. Het wordt dan heel gemakkelijk voor een slechte acteur om gewoon rond te lopen en een kabel te vinden om aan te sluiten en te zien welke netwerktoegang ze van daaruit krijgen. Het configureren van 802.1X-verificatie op alle switchpoorten is een bijna vereiste voor het handhaven van behoorlijke beveiliging in een groot netwerk. Catalyst Center kan u helpen bij het automatiseren van deze uitrol en er kunnen uitzonderingen worden gemaakt voor specifieke apparaten die geen 802.1X-verificatie ondersteunen, maar proberen zo min mogelijk te vertrouwen op MAC-gebaseerde verificatie omdat dat (oprecht) geen echte beveiliging is.
Uw strategie om schurken te bestrijden hangt af van een paar factoren. Veel beheerders gaan instinctief voor zeer strenge regels, maar de belangrijkste vragen zijn:
Met betrekking tot de impact van rogue-detectie hebben 9120 en 9130s een speciale CleanAir-chip die zorgt voor het off-channel scannen (en dus voor rogue-detectie) waardoor de impact op de client-serving radio bijna nul is. 9160-serie AP's met hun CleanAir Pro-chip hebben een vergelijkbare scanmogelijkheid zonder impact, maar andere AP's die niet over de CleanAir-chip beschikken, moeten hun client-serving radio uit het kanaal halen om te scannen op schurken of om containment te doen. Het AP-model dat u gebruikt, speelt daarom een rol bij de beslissing om speciale AP's in de monitormodus te gebruiken voor opsporing en inperking van malafide praktijken of niet.
Opmerking: mobiele telefoons die een Wi-Fi-hotspot delen, werken in de 'infrastructuur'-modus, net als traditionele toegangspunten, verwijst de 'ad-hoc'-modus naar een directe verbinding tussen mobiele apparaten en komt minder vaak voor.
Rogue containment is vaak verboden door regelgevende regels, dus het is essentieel dat u contact opneemt met uw lokale autoriteit voordat u het inschakelt. Het bevatten van een bedrieger betekent niet dat de bedrieger op afstand wordt afgesloten, maar dat de clients die proberen verbinding te maken met het bedrieglijke toegangspunt worden gespamd met deauthenticatieframes, zodat ze geen verbinding maken. Dit kan alleen werken op oudere beveiligings-SSID (het werkt niet in WPA3 of wanneer PMF is ingeschakeld in WPA2) omdat uw toegangspunten de deauthenticatieframes niet correct kunnen ondertekenen. Containment heeft een negatieve invloed op de RF-prestaties op het doelkanaal, omdat uw toegangspunten de zendtijd vullen met deauthenticatieframes. Het moet daarom alleen worden beschouwd als een beveiligingsmaatregel om te voorkomen dat uw eigen legitieme klanten per ongeluk worden geassocieerd met een schurkentoegangspunt. Om alle genoemde redenen wordt aanbevolen om geen inperking te doen, omdat het het malafide probleem niet volledig oplost en meer RF-problemen veroorzaakt. Als u containment moet gebruiken, is het alleen zinvol om het in te schakelen voor schurken die een van uw beheerde SSID vervalsen, omdat het een voor de hand liggende honeypot-aanval is.
U kunt automatische insluiting configureren met de optie "onze SSID's gebruiken":
Instellingen voor automatisch bevatten
U kunt ook rogue-regels configureren om te classificeren als kwaadaardige rogue-toegangspunten volgens uw eigen criteria. Vergeet niet om de naam van uw naburige en goedgekeurde SSID's in te voeren als vriendelijke schurken om die van uw alarmlijst te verwijderen.
Schakel AP-verificatie of PMF in om uw toegangspunten te beschermen tegen imitatie.
Een bekabelde bedrieger is een bedrieglijk toegangspunt dat is verbonden met uw bekabelde netwerk, wat uiteraard een verhoogde beveiligingsdreiging is. Detectie van bekabelde bedriegers is ingewikkelder omdat het Ethernet MAC-adres van een bedrieger meestal verschilt van het MAC-adres voor de radio. Cisco Catalyst Center heeft algoritmen die nog steeds proberen te detecteren of een malafide is aangesloten en jaagt op malafide client-MAC's die zowel via de ether worden gehoord als op de bekabelde infrastructuur worden gezien. De beste oplossing om bekabelde bedriegers helemaal te voorkomen, is om al uw switchpoorten te beveiligen met 802.1X-verificatie.
Als u fysiek gaat handelen op een schurkentoegangspunt, is het gebruik van Cisco Spaces de sleutel tot een nauwkeurige locatie van de schurkenstaat. U moet waarschijnlijk nog steeds een keer op de site zoeken, omdat mensen de neiging hebben om malafide AP's soms te verbergen, maar het verminderen van het zoekgebied tot een paar meter maakt het een zeer haalbare onderneming. Zonder Spaces wordt de schurk op de kaart naast het AP weergegeven en wordt het het luidst gedetecteerd, wat zorgt voor een vrij groot zoekgebied. Er bestaan veel draadloze hulpmiddelen en apparaten die u het signaal van het bedrieglijke toegangspunt in realtime laten zien om u te helpen de bedrieger fysiek te lokaliseren.
Niet precies gerelateerd aan schurken, maar omdat CleanAir net werd behandeld, is het belangrijk op te merken dat het inschakelen van CleanAir geen merkbare negatieve invloed heeft op de prestaties, behalve BLE-bakendetectie, omdat dit de prestaties van 2,4 GHz beïnvloedt. U kunt uw draadloze apparaten configureren om Bluetooth-interferenties volledig te negeren, omdat ze alomtegenwoordig zijn in de wereld van vandaag, en u kunt niet voorkomen dat uw klanten hun Bluetooth inschakelen.
WiPS dekt meer geavanceerde aanvalsvectoren dan alleen het detecteren van de aanwezigheid van een niet-geautoriseerd schurkenapparaat. Bovenop die aanvallen biedt het soms ook een PCAP van het evenement voor Forensics-analyse.
Hoewel dit een zeer nuttige beveiligingsfunctie is voor de onderneming, moet een openbaar netwerk de eeuwige vraag onder ogen zien: wat moet u ertegen doen?
Met de moeilijkheid van het beheren van veel klanten die u niet onder controle hebt, is het mogelijk om de alarmen in twee categorieën te verdelen. De alarmen die u kunt negeren vanuit het Cisco Catalyst Center als u er te veel ziet, zijn:
Deze waarschuwingen kunnen mogelijk worden veroorzaakt door een zich misdragende klant. Het is niet mogelijk om automatisch een denial-of-service-aanval te voorkomen, omdat u in wezen niet kunt voorkomen dat een defecte client de zendtijd bezig houdt. Zelfs als de infrastructuur de client negeert, kan deze nog steeds het medium en de zendtijd gebruiken om te verzenden, waardoor de prestaties van clients eromheen worden beïnvloed.
De andere alarmen zijn zo specifiek dat ze hoogstwaarschijnlijk een daadwerkelijke kwaadaardige aanval weergeven en kunnen nauwelijks gebeuren vanwege slechte clientstuurprogramma's. Het is beter om deze alarmen te blijven volgen:
De draadloze infrastructuur kan soms mitigatie-actie ondernemen, zoals het blokkeren van het overtredende apparaat, maar de enige echte actie om van een dergelijke aanval af te komen, is om fysiek daarheen te gaan en het overtredende apparaat te verwijderen.
Het wordt aanbevolen om alle vormen van uitsluiting van klanten in staat te stellen om verspilde zendtijd te besparen door interactie met defecte klanten.
Het is verleidelijk voor het management en beheerders om te overwegen om de snelheid te beperken gebruikers om te voorkomen dat een gebruiker van de bandbreedte op een specifieke locatie te hogging. Het is echter in het veld vele malen bewezen dat het efficiënter is, vanuit een geaggregeerd luchttijdstandpunt, om geen snelheidsbeperking te doen. Hoe sneller de gebruikers op het netwerk komen en andere activiteiten uitvoeren en hoe sneller ze ook van het netwerk af zijn. Snelheidsbeperkende overdrachtssnelheden voorkomen niet dat een gebruiker grote bestandsoverdrachten uitvoert, het maakt het alleen langzamer en laat pakketten vallen in het proces, wat betekent dat de totale verspilde luchttijd nog meer typisch is dan zonder enige beperking. Het beperken van de snelheid via draadloze verbindingen gebeurt door pakketten te laten vallen nadat het toegangspunt een bepaalde hoeveelheid pakketten heeft doorgestuurd in een bepaald tijdsvenster dat afkomstig is van een client, als u dit niet per toepassing doet, loopt u het risico belangrijk verkeer van de client te laten vallen. Maar als u dit per toepassing doet, heeft dit mogelijk niet het gewenste effect, omdat bepaalde toepassingen meerdere verbindingen gebruiken en dit de doorvoerberekening voor deze toepassing kan bemoeilijken. Cisco CX-experts adviseren om bepaalde applicaties die u niet wilt eerder volledig te laten vallen dan snelheidsbeperking te gebruiken. Dit wordt ook behandeld in Cisco Wireless Meraki Cloud documentatie: https://documentation.meraki.com/Wireless/Operate_and_Maintain/How_Tos/Firewall_and_Traffic_Shaping/Configuring_Bandwidth_Limitations_and_Enabling_Speed_Burst_on_Wireless_Networks
evenals in de documentatie van Cisco Wireless Catalyst https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/215441-configure-qos-rate-limiting-on-catalyst.html
Het wordt aanbevolen om peer-to-peer-blokkering op al uw WLAN's in te schakelen (tenzij u een harde vereiste hebt voor client-to-client communicatie - maar dit moet zorgvuldig worden overwogen en mogelijk beperkt). Deze functie voorkomt dat clients op hetzelfde WLAN met elkaar in contact komen. Dit is geen perfecte oplossing, omdat klanten op verschillende WLAN's nog steeds contact met elkaar kunnen opnemen en klanten die tot verschillende WLC's in de mobiliteitsgroep behoren, deze beperking ook kunnen omzeilen. Maar het fungeert als een eenvoudige en efficiënte eerste laag van beveiliging en optimalisatie. Een ander voordeel van deze functie van peer-to-peer-blokkering is dat het ook voorkomt dat client-to-client ARP voorkomt, waardoor toepassingen andere apparaten op het lokale netwerk niet kunnen ontdekken. Zonder peer-to-peer-blokkering kan het installeren van een eenvoudige toepassing op de client alle andere clients weergeven die in het subnet zijn verbonden met mogelijk hun IP-adres en hostnamen.
Bovendien wordt aanbevolen om zowel een IPv4- als een IPv6-ACL (als u IPv6 in uw netwerk gebruikt) op uw WLAN's toe te passen om client-naar-client communicatie te voorkomen. Het toepassen van een ACL die client-naar-client-communicatie op WLAN-niveau blokkeert, werkt ongeacht of u client-SVI's hebt of niet.
De andere verplichte stap is het voorkomen van draadloze clienttoegang tot elke vorm van beheer van uw draadloze controller.
Voorbeeld:
ip access-list extended ACL_DENY_CLIENT_VLANS
10 deny ip any 10.131.0.0 0.0.255.255
20 deny ip 10.131.0.0 0.0.255.255 any
30 deny ip any 10.132.0.0 0.0.255.255
40 deny ip 10.132.0.0 0.0.255.255 any
50 deny ip any 10.133.0.0 0.0.255.255
60 deny ip 10.133.0.0 0.0.255.255 any
70 deny ip any 10.134.0.0 0.0.255.255
80 deny ip 10.134.0.0 0.0.255.255 any
90 deny ip any 10.135.0.0 0.0.255.255
100 deny ip 10.135.0.0 0.0.255.255 any
110 deny ip any 10.136.0.0 0.0.255.255
120 deny ip 10.136.0.0 0.0.255.255 any
130 deny ip any 10.137.0.0 0.0.255.255
140 deny ip 10.137.0.0 0.0.255.255 any
150 permit ip any anyDeze ACL kan worden toegepast op de beheerinterface SVI:
interface Vlan130
ip access-group ACL_DENY_CLIENT_VLANS inDit wordt gedaan op een WLC met client VLANS 131 tot en met 137 die is gemaakt in de Layer 2 VLAN-database, maar zonder overeenkomstige SVI's, en er bestaat slechts één SVI voor VLAN 130, wat de manier is waarop de WLC wordt beheerd. Deze ACL voorkomt dat alle draadloze clients alle verkeer naar de WLC-beheer- en besturingsvliegtuigen volledig kunnen verzenden. Vergeet niet dat SSH- of Web UI-beheer niet het enige is dat u moet toestaan, omdat een CAPWAP-verbinding met alle toegangspunten ook moet worden toegestaan. Dit is de reden waarom deze ACL een standaardvergunning heeft, maar draadloze clientbereiken blokkeert, in plaats van te vertrouwen op een standaardweigering van alle actie die vereist is om alle toegestane AP-subnetbereiken en beheerbereiken op te geven.
Evenzo kunt u een andere ACL maken die alle mogelijke subnetten voor beheer opgeeft:
ip access-list standard ACL_MGMT
10 permit 10.128.0.0 0.0.255.255
20 permit 10.127.0.0 0.0.255.255
30 permit 10.100.0.0 0.0.255.255
40 permit 10.121.0.0 0.0.255.255
50 permit 10.141.0.0 0.0.255.255U kunt deze ACL vervolgens toepassen voor CLI-toegang:
line vty 0 50
access-class ACL_MGMT in
exec-timeout 180 0
ipv6 access-class ACL_IPV6_MGMT in
logging synchronous
length 0
transport preferred none
transport input ssh
transport output sshDezelfde ACL kan ook worden toegepast voor webbeheerderstoegang.
Multicasts en uitzendingen worden door sommige applicaties zwaarder gebruikt dan andere. Bij het overwegen van een bekabeld netwerk is bescherming tegen uitzendstorm vaak de enige voorzorgsmaatregel die wordt genomen. Een multicast is echter net zo pijnlijk als een uitzending wanneer deze via de ether wordt verzonden en het is belangrijk om te begrijpen waarom. Stel je eerst een pakket voor dat wordt verzonden (via uitzending of multicast) naar al je draadloze clients, dat snel veel bestemmingen oplevert. Elk toegangspunt moet dit frame vervolgens op de meest betrouwbare manier over de lucht verzenden (hoewel het niet als betrouwbaar wordt gegarandeerd) en dat wordt bereikt door een verplichte gegevenssnelheid te gebruiken (het is configureerbaar welke van de verplichte tarieven wordt gebruikt). In termen van leken betekent dit dat het frame wordt verzonden met behulp van een OFDM (802.11a / g) datasnelheid, wat duidelijk niet geweldig is.
In een groot openbaar netwerk is het niet raadzaam om te vertrouwen op multicast om de zendtijd te behouden. In een groot bedrijfsnetwerk kunt u echter een vereiste hebben om multicast ingeschakeld te houden voor een specifieke toepassing, hoewel u deze zoveel mogelijk moet beheersen om de impact ervan te beperken. Het is een goed idee om de toepassingsdetails, multicast-IP, te documenteren en ervoor te zorgen dat andere vormen van multicast worden geblokkeerd. Het inschakelen van Multicast-forwarding is geen vereiste voor het inschakelen van IPv6, zoals eerder uitgelegd. Broadcast forwarding kan het beste volledig uitgeschakeld worden gehouden. Uitzendingen worden soms gebruikt door toepassingen om andere apparaten op hetzelfde subnet te ontdekken, wat duidelijk een beveiligingsprobleem is in een groot netwerk.
Als u het doorsturen van wereldwijde multicast inschakelt, moet u de CAPWAP-instelling voor multicast-AP gebruiken. Als dit is ingeschakeld, verzendt de WLC een multicast-pakket van de bekabelde infrastructuur naar alle geïnteresseerde toegangspunten met één multicast-pakket, waardoor veel pakketduplicatie wordt bespaard. Zorg ervoor dat u voor elk van uw WLC's een andere CAPWAP multicast IP instelt, anders ontvangen AP's multicast-verkeer van andere WLC's, wat niet gewenst is.
Als uw toegangspunten zich in andere subnetten van de Wireless Management Interface van de WLC bevinden (waarschijnlijk in een groot netwerk), moet u multicast-routering op uw bekabelde infrastructuur inschakelen. U kunt controleren of al uw toegangspunten het multicastverkeer correct ontvangen met de opdracht:
show ap multicast momIGMP (voor IPv4 multicast) en MLD (voor IPv6) multicast worden ook geadviseerd om in alle gevallen ingeschakeld te zijn als u op multicast moet vertrouwen. Hiermee kunnen alleen geïnteresseerde draadloze clients (en dus alleen AP's die geïnteresseerde clients hebben) het multicastverkeer ontvangen. De WLC proxy de registratie naar de multicast verkeer en zorgt ervoor dat de registratie in leven, waardoor het offloaden van de klanten.
Grote openbare netwerken zijn complex, elk is uniek met specifieke vereisten en resultaten.
Het respecteren van de richtlijnen in dit document is een goed uitgangspunt en helpt om succes te behalen met uw implementatie terwijl de meest voorkomende problemen worden vermeden. De richtlijnen zijn echter slechts richtlijnen en moeten mogelijk worden geïnterpreteerd of aangepast in de context van de specifieke locatie.
Cisco CX heeft teams van draadloze professionals die zich toeleggen op grote draadloze implementaties, met ervaring in tal van grote evenementen, waaronder sportevenementen en conferenties. Neem contact op met uw accountteam voor verdere hulp.
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
6.0 |
12-Dec-2025
|
Een sectie toegevoegd over snelheidsbeperking |
5.0 |
03-Feb-2025
|
Vaste typefouten en een opmerking over multicast-gegevenssnelheid |
4.0 |
23-Oct-2024
|
Een kleine opmerking toegevoegd over de grootte van het Flexconnect-subnet |
3.0 |
30-Aug-2024
|
Een sectie toegevoegd over de CPU-impact van het bewaken van de WLC. Vaste typefouten. Enkele delen opnieuw geformuleerd |
2.0 |
20-Jul-2024
|
De sectie gegevenssnelheden toegevoegd |
1.0 |
22-May-2024
|
Eerste vrijgave |
Feedback