Ontwerpgids CX - Draadloos voor grote openbare netwerken

Inleiding

Dit document beschrijft ontwerp- en configuratierichtlijnen voor grote openbare Wi-Fi-netwerken.

CX-ontwerphandleiding

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.

Toepassingsgebied en definities

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 netwerken

Grote openbare en evenementennetwerken zijn in veel opzichten uniek, dit document onderzoekt en biedt richtlijnen op deze belangrijke gebieden.

• Grote openbare netwerken zijn intens; er zijn duizenden apparaten in een gereduceerde RF-ruimte (Radio Frequency) en aanzienlijke roaming als mensen rondlopen, kunnen sommige evenementen en locaties meer statisch zijn met bandbreedtepieken op zeer specifieke tijden. De infrastructuur moet al deze statuswijzigingen zo sierlijk mogelijk afhandelen voor klanten die het gebied binnenkomen en zich verplaatsen.  
• Het gemak van onboarding is een prioriteit. Een klant is een tevreden klant. Dit betekent dat u de klantenkoppeling zo snel mogelijk naar het netwerk wilt maken. Een client die niet is aangesloten op Wi-Fi scant naar beschikbare toegangspunten die ongewenste RF-energie genereert, wat zich vertaalt in extra congestie en verloren capaciteit via de lucht.
• De RF-implementatie moet zo zorgvuldig mogelijk worden ontworpen. Een goed RF-ontwerp met richtantennes is een must als een zeer hoge dichtheid vereist is, of als de locatie grote open ruimtes en / of hoge plafonds heeft.
• Een andere belangrijke ontwerpdrive is compatibiliteit. Sommige functies zijn standaard in de 802.11-specificatie, terwijl andere functies eigen zijn, geen van beide vormt een probleem voor klanten. De realiteit is echter anders en er zijn veel slecht geprogrammeerde clientstuurprogramma's die zich misdragen wanneer ze worden geconfronteerd met gecompliceerde bakens of functies / instellingen die ze niet begrijpen.
• Problemen oplossen is een uitdaging vanwege schaal- en tijdsbeperkingen. Als iets niet werkt met een specifieke klant, kunt u niet met die eindgebruiker werken om het probleem te begrijpen. Gebruikers kunnen moeilijk te vinden zijn, maar kunnen ook niet-coöperatief zijn vanwege de voorbijgaande aard van hun bezoek aan de locatie.
• Veiligheid is een belangrijke factor. Er is minder controle door de zeer grote hoeveelheid bezoekers en een veel groter aanvalsoppervlak.

Externe verwijzingen

disclaimer

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.

Ontwerp het netwerk

RF-overwegingen

Venue types

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:

• Stadions en arena's
• Conferentieplaatsen
• Grote auditoria

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:

• cruiseschip
• vliegveld
• Winkelcentrum / Mall

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

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.

esthetiek

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-netwerken

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.

Enkelvoudige 5 GHz vs. dubbele 5 GHz

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.

antennes

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.

Hoge dichtheid en 6 GHz

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.

beheer van radiobronnen

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.

• DCA wordt uitgevoerd volgens een configureerbaar schema (standaard 10 minuten).
• TPC werkt volgens een automatisch schema (standaard 10 minuten).

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.

• TPC moet beperkt zijn tot een beperkt bereik van waarden met de TPC min/max-instelling, indien nodig, en altijd afgestemd op het RF-ontwerp.
  • Schakel TPC Channel Aware in in omgevingen met hoge dichtheid.

• Het DCA-programma moet worden gewijzigd ten opzichte van de standaardinstelling van 10 minuten.
  • Gebruik geen ED-RRM in HD-omgevingen.
  • Schakel Vermijden van laden Cisco AP uit.
  • Rogue AP-vermijdingsopties zoals Vermijd buitenlandse AP-interferentie kunnen resulteren in een instabiele omgeving als er veel schurken zijn. Het is altijd beter om de schurk te verwijderen dan te proberen erop te reageren.
• RRM-beslissingen kunnen worden beïnvloed door toegangspunten / antennes die elkaar niet goed horen, zoals in het geval van richtantennes die van elkaar wegwijzen.
• Sommige antennes (bijvoorbeeld C9104) ondersteunen geen RRM en hebben altijd een statische configuratie nodig.
• RRM lost geen slecht RF-ontwerp op.

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.

RF-configuratie

Kanalen

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.

Gegevenssnelheden

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.

zendvermogen

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.

vermogensbalans

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

RxSOP

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.

Het netwerk schalen

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.

Aantal toegangspunten

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:

• Capaciteiten van de klant.
• Signaal-ruisverhouding van de cliënt op dat specifieke tijdstip.
• Aantal andere clients die op dat specifieke tijdstip zijn verbonden.
• Mogelijkheden van andere klanten op dat specifieke moment.
• Activiteit van andere klanten op dat specifieke moment.
• Interferentie op dat specifieke moment.

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.

WLC-platform

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.

WLC Hoge beschikbaarheid

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.

Externe systemen

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.

DNS/DHCP

Enkele tips voor DHCP:

• Zorg ervoor dat de DHCP-pool ten minste drie keer zo groot is als het aantal klanten dat wordt verwacht. IP's blijven enige tijd toegewezen, zelfs nadat de client is losgekoppeld, dus afhankelijk van de verblijftijd van gasten kan dit meer IP-adressen verbruiken. Probeer de leasetijd af te stemmen op de verwachte duur van het bezoek van de gebruiker aan de locatie, het heeft geen zin om een IP-adres voor een week toe te wijzen als een typische bezoekduur twee uur is, dit helpt om verouderde leases uit te schakelen.
• Het gebruik van één groot subnet voor clients wordt aanbevolen, de WLC heeft een proxy ARP-functie en stuurt uitzendingen niet standaard door (anders dan DHCP). Het gebruik van een groot (bijvoorbeeld /16) clientsubnet voor uw klanten vormt geen probleem. Een enkel groot VLAN is eenvoudiger dan een VLAN-groep met veel VLAN's. Het configureren van veel kleinere subnetten (bijvoorbeeld /24) en VLAN's-groepen heeft geen invloed op het broadcast-domein en resulteert alleen in een ingewikkeldere configuratie, wat resulteert in problemen zoals vieze VLAN's en het bijhouden van verschillende DHCP-pools die niet gelijkmatig kunnen worden gebruikt. Deze aanbeveling is van toepassing op toegangspunten in de lokale modus en centraal geschakeld verkeer. In het geval van FlexConnect met lokale switching wordt het niet ondersteund om meer dan 100 (of 300 na 17,9) AP's in hetzelfde subnet te plaatsen, omdat ze veel uitzendingen hebben. Flexconnect vereist dat AP's hetzelfde VLAN bedienen om naadloze roaming te ondersteunen en daarom wordt het niet aangeraden om grote subnetten in dit scenario te ondersteunen.
  
• Houd DHCP in de overbruggingsmodus op de draadloze controller met de DHCP-relayfunctionaliteit die wordt afgehandeld door de Layer 3-gateway van het subnet. Dit zorgt voor maximale efficiëntie en eenvoud. Het idee is om de draadloze controller helemaal niet bij het DHCP-proces te betrekken.
• Gebruik DHCP Required op elk openbaar WLAN, ongeacht de verificatiemethode. Hoewel dit een klein percentage van mislukte clientassociaties kan veroorzaken, kan dit aanzienlijke beveiligingsproblemen voorkomen door clients die zichzelf statische IP-adressen proberen toe te wijzen of door clients die zich misdragen en proberen een eerder IP-adres zonder toestemming te hergebruiken.

Het netwerk beheren

De juiste configuratie

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.

SSID's

Hoeveel SSID's?

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.

WPA2/3 Persoonlijk

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.

WPA2/3 Enterprise

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)

GastSSID's

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.

Conclusie over het aantal SSID's

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.

Legacy SSID versus hoofd SSID concepten

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.

SSID-functies

• Het is het beste om Aironet Extensions uitgeschakeld te houden. Die zijn vooral handig voor site-enquêtes en WGB-bewerkingen, maar veroorzaken soms problemen met sommige oudere clients. Aironet IE adverteert ook de AP-hostnaam die ongewenst is bij beveiligingsbewuste implementaties.
• CCKM is een verouderd protocol (in het voordeel van FT) en moet worden uitgeschakeld.
• Op dit moment is het het beste om AES-128-codering te gebruiken, zelfs in WPA3 vanwege de lage clientondersteuning van hogere coderingen (tenzij u zich een specifieke veiligere en restrictievere SSID kunt veroorloven)
• Detectie van gaten in de dekking kan het beste worden uitgeschakeld (voor alle SSID's). Grote implementaties maken meestal gebruik van gerichte antennes, waarvoor een grondige site-survey nodig is. De vermogensniveaus van elke antenne zouden een resultaat zijn van het RF-ontwerpproces en worden meestal geconfigureerd op specifieke niveaus.
• Adaptieve FT moet worden uitgeschakeld omdat sommige klanten problemen kunnen hebben wanneer FT niet volledig wordt geadverteerd, maar in sommige attributen aanwezig is. FT volledig uitschakelen (voor maximale compatibiliteit) of gaan met FT + 802.1X die de meeste clients (tenzij ze oud of meer IoT-georiënteerd) ondersteunen. Bij het configureren van FT+802.1X kunnen zelfs niet-FT-clients deelnemen aan de SSID. Het enige mogelijke probleem is met sommige clients die het niet zouden tolereren om twee beveiligingsopties op dezelfde SSID te zien.
• 802.11ac MU-MIMO uitschakelen. Het voegt complexiteit toe en heeft een zeer laag voordeel in 802.11ac.
• BSS Target Wake Time uitschakelen. Het heeft momenteel een lage adoptie aan de kant van de klant.
• Schakel agressieve taakverdeling en Band selecteren uit. Band selecteren is niet nodig als u de SSID niet in 2,4 GHz adverteert (of als deze op een speciale SSID staat) en de koppeling van de client met agressieve taakverdeling wordt vertraagd door de client een paar keer af te wijzen voordat deze uiteindelijk wordt geaccepteerd als deze erop staat verbinding te maken met een geladen toegangspunt. Je hebt AP's toch geladen in een drukke omgeving en dit is negatief voor de klantervaring.
• Fastlane+ uitschakelen.
• Schakel Universal Admin uit, deze functie was voor 3700 AP en alleen in het -UX-domein. Het verlaten van het op bladeren open een onnodige aanval vector.
• Houd Opportunistic Key Caching (OKC) ingeschakeld. Het dient als snel roamingmechanisme voor klanten die geen FT ondersteunen.
• Houd WMM toegestaan. Als u het uitschakelt, gaat uw netwerk terug naar het 802.11g-tijdperk en biedt het geen voordeel op het 9800-platform.
• IP Source Guard inschakelen.
• RADIUS-profilering uitschakelen. In een zeer drukke omgeving kan dit buitensporige RADIUS-boekhoudberichten verzenden (wanneer de clients DHCP doen of HTTP-pakketten verzenden) en heeft het een zeer reëel potentieel om uw RADIUS-server te overbelasten.
• Gebruik geen verborgen SSID's. Dit dient geen enkel beveiligingsdoel, de SSID-naam kan nog steeds gemakkelijk worden ontdekt met eenvoudige applicaties of door een snuffelopname te maken. Het verbergen van de SSID vertraagt alle clientroaming omdat ze niet meer profiteren van passief bakenscannen en moeten vertrouwen op actief scannen om naburige AP-informatie te krijgen.
• Probeer niet meer dan vier WLAN's per radio te gebruiken, omdat dit een aanzienlijke invloed heeft op het RF-gebruik. Het is geen harde limiet, het gebruik van vijf WLAN's kan werken, maar wees je zeer bewust van de verspilde zendtijd door steeds meer WLAN's te gebruiken.
• 802.11v en 802.11k zijn standaarden die steeds meer worden ondersteund door populaire clienttypen. Ze vormen meestal geen probleem met betrekking tot de clientverbinding. De voordelen die ze met zich meebrengen, hangen sterk af van hoe clients die protocollen gebruiken en kunnen soms (in het geval van 802.11k) een iets hoger CPU-gebruik veroorzaken. U kunt ze buiten uw IoT- of Legacy-SSID houden, maar ze moeten indien mogelijk worden ingeschakeld op uw productie-SSID.

Site-tag

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:

• Als u vier sitetags configureert op een 9800-80 met acht WNCD-processen, wordt elke sitetag toegewezen aan een ander WNCD-proces (waarbij elk op een afzonderlijke CPU-kern wordt uitgevoerd) en doen vier WNCD-processen niets. Dit betekent dat u niet alle CPU's van uw 9800-80 gebruikt en het wordt niet aanbevolen om deze te laden met de maximaal 6000 ondersteunde toegangspunten.

Eerste voorbeeld van site tag balancing

• Als u 10 side tags configureert op een 9800-80 met acht WNCD-processen, zorgen twee WNCD-processen voor twee site-tags elk, terwijl de overige zes elk één site-tag verwerken.

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).

Beleidsprofiel

• Schakel ARP en Duplicate Address Detection (DAD) Proxy in, dit stelt de WLC in staat om namens draadloze clients te antwoorden wanneer een apparaat probeert het MAC-adres van een draadloos apparaat te leren. Dit bespaart ook draadloze clientbatterijen.
• Schakel WGB-functies niet in, tenzij dat nodig is.
• DHCP inschakelen om clients met statische IP-adressen te vermijden.
• Houd inactieve time-out kort (300 seconden). Sommige beheerders maken het lang om te voorkomen dat clients opnieuw moeten verifiëren, maar lange inactieve time-out resulteert in spookclientvermeldingen (die van invloed zijn op rapportage) omdat het aantal clients wordt vertraagd van realtime. Het is het beste om de inactieve time-out lager te houden dan de rotatie-timer van de groepssleutel om boekhoudkundige overstromingen te voorkomen wanneer de clients worden verwijderd. Het rotatie-interval van de groepssleutel kan in de web-gebruikersinterface worden geconfigureerd onder Configuratie > Beveiliging > Geavanceerde EAP als "EAP-Broadcast-sleutelinterval"
• Maak de time-out van de sessie 86400 seconden om onnodige verbroken verbindingen en herverificaties te voorkomen.

AP-aanmeldingsprofiel

• Zorg ervoor dat TCP adjust MSS is ingeschakeld.
• Schakel Trust DSCP upstream in. Veel draadloze clients doen helaas geen 802.11e WMM UP-tagging, vertrouwen op het DSCP-veld is een zekere manier om de juiste prioriteit te geven aan spraaktoepassingen.
• Syslog inschakelen voor uw toegangspunten. Als u een IP-server van Syslog configureert, worden de logbestanden van de console van de AP's unicast. Het is niet alleen handig om problemen met AP's op te lossen, maar het is ook beter voor het netwerk dan de standaardinstelling waardoor AP's hun Syslog in het lokale VLAN uitzenden. AP-logboekregistratie kan een aanzienlijke berichtenbelasting genereren, zelfs in gevallen waarin AP Syslog niet wordt gecontroleerd, is het nog steeds een goed idee om het aantal gebeurtenissen te beperken door de juiste berichternst in te stellen en/of een dummy Syslog IP-adres (bijvoorbeeld 0.0.0.0) te configureren om te voorkomen dat berichten worden uitgezonden.
• Maximaliseer CAPWAP-herhalingen en time-out. Problemen worden minder snel gedetecteerd, maar het netwerk is beter bestand tegen kleine tijdelijke pakketdruppels.
• SSH inschakelen en referenties configureren. Schakel de AP-console uit.
• Schakel de AP-monitor in als dat nodig is, maar niet de radio-monitor.
• Schakel malafide detectie in en configureer een RSSI-drempel van -70 dBm.

Monitoring van het netwerk

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 3^rd party monitoring tools te gebruiken, maar wanneer die SNMP gebruiken als een protocol, de gegevens zijn verre van real-time en de gebruikelijke 3^rd 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.

Hoe harder je toezicht houdt, hoe meer je je eigen problemen kunt veroorzaken

Er zijn een paar klassieke scenario's waarbij te veel monitoring problemen veroorzaakt:

• Draadloze sensoren die als clients fungeren, kunnen leuk zijn om de doorvoer en connectiviteit op specifieke plaatsen in het netwerk te meten, maar onthoud dat het instellen van een hoge testfrequentie betekent dat de sensor veel tijd besteedt aan het uitvoeren van grote gegevensoverdrachten en daarom het kanaal en het netwerk daadwerkelijk bezet maakt, zelfs als het niet anders was. Dit is het beste voorbeeld van "hoe harder je controleert, hoe slechter je statistieken eruit zien".
• SNMP is, zoals eerder vermeld, een verouderd protocol dat een grote invloed heeft op de CPU. Door grote SNMP-polling uit te voeren, kunt u uw draadloze netwerk-CPU eenvoudig verzadigen met verzoeken zodra u regelmatig al uw draadloze clients of toegangspunten controleert wanneer u er een groot aantal hebt. Houd altijd rekening met de hoeveelheid objecten die u pollt voordat u een agressief pollinginterval instelt. De SNMP-daemon bevindt zich in het IOSd-proces in IOS-XE, dus wanneer deze op een hoge CPU staat, kan dit van invloed zijn op de rest van de IOS-functionaliteiten.
• Zelfs als telemetrie efficiënter is dan SNMP, kunnen grote draadloze netwerken een zeer groot aantal clients, toegangspunten, maar ook interferers en malafide apparaten hebben. Als uw telemetrieconfiguratie te agressief is ingesteld en de WLC constant moet rapporteren over elke verandering in het signaal van een malafide apparaat, kan dit ook gemakkelijk elk controllerapparaat verzadigen. Zorg ervoor dat u uw "pubd" -proces in de gaten houdt dat verantwoordelijk is voor telemetrie en zorg ervoor dat het niet op hoog CPU-gebruik staat. Als dat zo is, heroverweeg dan uw drempels en zorg ervoor dat u de 9800 best practices volgt.

Specifieke problemen voor grote netwerken

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.

Dag 2 Monitoring: Houdt de gebruikerstevredenheid in de gaten

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).

Configureren voor schaalbaarheid

SVI's en interfaces op de 9800

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.

Geaggregeerde sonderesponsie

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-mac

IPv6

Veel 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.

mDNS

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.

Versterking van het netwerk

Beveiliging

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.

Rogue-toegangspunten

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:

• Als je honderden (zo niet duizenden) malafide meldingen krijgt, heb je dan de menselijke middelen om ze allemaal te bekijken en actie te ondernemen op al deze meldingen?
• Is uw doel om de schurken fysiek te verwijderen om een schoon RF-spectrum te houden? Als dat zo is, heb je veel mensen nodig om deze operatie uit te voeren. Of misschien is het je doel om alleen de veiligheidsfactor in de gaten te houden en er gewoon voor te zorgen dat de schurken geen gevaar vormen? Dit heeft een veel beter beheersbare menselijke werkkosten.
• Het inschakelen van malafide detectie kan een impact hebben op uw zendtijd en malafide insluiting heeft meestal een nog grotere impact, heeft u deze impact geanalyseerd en er rekening mee gehouden?

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

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:

• 10001: DoS: verificatie overstromingsalarm
• 10002: DoS: Verbindingsverzoekalarm
• 10003: DoS: Overstromingsalarm van de omroepsonde
• 10004: DoS: Disassociation Flood Alarm
• 10005: DoS: Disassociatiealarm uitzenden
• 10006: DoS: De-authenticatie Overstromingsalarm
• 10007: DOS: alarm voor deverificatie van uitzending
• 10008: DOS: EAPOL-Logoff-aanvalsalarm
• 10009: CTS overstromingsalarm
• 10010: RTS Association Request Alarm
• 10011: Deauthenticatie Overstroming per paar
• 10021: Airdrop-sessie (deze sessie komt meestal veel voor in elk netwerk en toont gewoon reguliere peer-to-peer-activiteiten tussen Apple-apparaten)
• 10022: Verzoek om misvormde associatie
• 10023: Authenticatiefout Overstroming door handtekening
• 10024: Ongeldige MAC OUI door handtekening
• 10025: Misvormde verificatie

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:

• 10012: Fuzzed beacon
• 10013: Aanvraag voor Fuzzed Probe
• 10014: Fuzzed Probe-respons
• 10015: PS Poll Flood by Signature
• 10016: EAPOL start V1 overstroming door ondertekening
• 10017: Herassociatieverzoek Overstroming per bestemming
• 10018: Beacon Flood by Signature
• 10019: Probe Response Flood by Destination
• 10020: Blok Ack Overstroming door ondertekening
• 10026/10027: RTS en CTS Virtual Carrier Sense Attack

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.

Tarievenbeperkende 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

Toegang tot client beperken

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 any

Deze ACL kan worden toegepast op de beheerinterface SVI:

interface Vlan130

 ip access-group ACL_DENY_CLIENT_VLANS in

Dit 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.255

U 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 ssh

Dezelfde ACL kan ook worden toegepast voor webbeheerderstoegang.

Bescherming tegen verkeersstormen

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 mom

IGMP (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.

 Conclusie

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.