CISCO IOS-XE Wireless EFT brugermanual

IOS-XE trådløs EFT

Produktinformation: IOS-XE 17.11.1 Wireless EFT Guide

Cisco Enterprise Wireless-løsningerne er designet til at give et robust og sikkert trådløst netværk med adaptiv og indsigtsfuld intelligens. Løsningerne er bygget på Cisco Digital Network Architecture, hvilket gør dem klar til de voksende brugerforventninger, IoT-enheder og cloud-drevne applikationer. Cisco Catalyst 9800-seriens trådløse controllere baseret på IOS-XE blev introduceret i 2018 og har siden gennemgået konstant innovation, nye platformsintroduktioner, funktionsforbedringer og tilføjelser til funktionsparitet, hvilket gør dem til de bedste i virksomhedsklassen på markedet.

Kompatibilitetsmatrix

Kompatibilitetsmatrixen til IOS-XE 17.11.1 Wireless EFT Guide er tilgængelig i brugermanualen.

Funktioner at teste

Funktionerne, der skal testes, omfatter:

• Effektiv download af AP-billeder via TCP

Give feedback og anmode om support

Hvis du støder på problemer eller har yderligere kommentarer eller feedback under EFT-programmet, kan du give din feedback til TME-teamet. Hvis du finder problemer eller har yderligere kommentarer eller feedback, efter at EFT-programmet er afsluttet, kan du stadig give din feedback til TME-teamet.

Produktbrugsvejledning: IOS-XE 17.11.1 Wireless EFT Guide

Netværkstopologi

Netværkstopologien afhænger af din specifikke opsætning og dine krav. Se brugervejledningen for mere information.

Forudsætninger

Test opsætning

Før du udfører testene, skal du sikre dig, at du har:

• Cisco Catalyst 9800 Series trådløse controllere
• Cisco Catalyst 9100 Access Points
• Test enheder

Opgrader stier

Opgraderingsstierne er tilgængelige i brugermanualen.

Effektiv AP Image Download via TCP Feature Overview

Funktionsbeskrivelse

Den effektive AP-billeddownload gennem TCP-funktionen giver mulighed for hurtigere og mere pålidelige AP-billeder ved brug af TCP.

Funktionsbrug

For at bruge den effektive AP-billeddownload via TCP-funktionen skal du følge instruktionerne i brugervejledningen.

Indledning

Cisco Enterprise Wireless-løsninger er robuste, har integreret sikkerhed og anvender adaptiv og indsigtsfuld intelligens, der giver nyttig indsigt i dit netværk. Med hensigtsbaseret netværk bygget på Cisco Digital Network Architecture går Cisco Enterprise Wireless-løsninger ud over de nyeste Wi-Fi 6 og WiFi 6E (802.11ax) standarder og er klar til de voksende brugerforventninger, IoT-enheder og næste generations cloud- drevne applikationer.

IOS-XE 17.11.1 Trådløs EFT-guide

Cisco Catalyst 9800 Series trådløse controllere: Catalyst-controllerne strømliner det bedste af RF-ekspertise med åbne, programmerbare Cisco IOS® XE-fordele, hvilket betyder, at du ikke længere har to operativsystemer at administrere. Disse modulære, pålidelige og yderst sikre controllere er fleksible nok til at blive implementeret hvor som helst – inklusive dit valg af cloud.

Cisco Catalyst® 9100 Access Points: Igang ud over Wi-Fi 6- og 6E-standarderne giver Cisco Catalyst 9100-adgangspunkterne integreret sikkerhed, robusthed og driftsfleksibilitet samt øget netværksintelligens. Disse adgangspunkter udvider Ciscos hensigtsbaserede netværk og skalerer til de voksende krav fra Internet of Things (IoT), mens de fuldt ud understøtter de nyeste innovationer og nyeste teknologier, hvilket gør dem perfekte til organisationer i alle størrelser.

For at få et komplet overståetview og lær mere om Cisco Enterprise Wireless-produkter og -løsninger, besøg venligst følgende side: https://www.cisco.com/c/en/us/products/wireless/index.html – ~ressourcer

Cisco Catalyst 9800 Series trådløse controllere baseret på IOS-XE blev introduceret på markedet i slutningen af ​​2018 med IOS-XE Release 16.10.1. Der har været konstante innovationer, nye platformsintroduktioner, funktionsforbedringer og tilføjelser til funktionsparitet i løbet af de sidste par år for at gøre Cisco Catalyst 9800 Series Wireless Controllere og Cisco Catalyst 9100 Access Points til de bedste i virksomhedsklassen på markedet.

Dette dokument indeholder en funktion overview, konfiguration og testscenarier for nogle få udvalgte trådløse funktioner baseret på kundernes interesse, til en tidlig prøveversion af IOS-XE Release 17.11.1. Vi er glade for at byde dig velkommen til EFT for IOS-XE Wireless Software Release 17.11.1. Cisco anerkender og værdsætter den tid og indsats, der vil være at evaluere funktionerne i denne softwareudgivelse, og håber, at du vil finde ud af, at den lever op til dine forventninger. Denne software og den medfølgende dokumentation leveres til dig i henhold til tavshedspligten mellem dig, din organisation og Cisco. Diskuter venligst ikke dette projekt og dets funktioner uden for diskussionerne på Cisco Beta-relaterede mailinglister. Denne software er pre-release software og bør som sådan aldrig bruges i et kommercielt driftsmiljø eller med missionskritiske data. Vi anbefaler, at du først installerer denne software på et testnetværk/-system og derefter går over til produktionstest, da du er mere komfortabel med det. Brug venligst softwaren, som du plejer i dine daglige opgaver, og rapporter eventuelle problemer, du finder.

Give feedback og anmode om support
Detaljer om at give feedback er givet nedenfor. Bemærk også, at vi under hele projektet kan bede om feedback på specifikke områder af softwaren. Din feedback er afgørende for Cisco Systems, for at give dig de funktioner og de funktioner, du har brug for for at realisere din individuelle mission. Denne EFT repræsenterer en mulighed for at se, om dette opfylder dine behov, og for at give input vedrørende dets egnethed. EFT-programmets startdatoer og tidslinjer er blevet meddelt dig under en separat meddelelse fra EFT-administratoren. I løbet af EFT-perioden vil mindst én EFT-softwareopdatering være tilgængelig i EFT-fasen. For at inkludere så mange rettelser som muligt i denne opdateringsudgivelse; du og dine medarbejdere opfordres til at teste denne software og give feedback så tidligt i programmet som muligt. Der vil være en cut-off, på hvilket tidspunkt vi vil fryse udviklingen for at teste og frigive opdateringsbilledet. Opdateringen vil indeholde vigtige rettelser, og alle deltagere anbefales at opgradere, når EFT-opdateringssoftwaren er tilgængelig. Hvis du finder problemer eller har yderligere kommentarer eller feedback, efter at EFT-programmet er afsluttet, tager vi som altid gerne din feedback velkommen!

For at vi kan spore fundne problemer, give kommentarer eller stille spørgsmål, kan du sende din forespørgsel til: polariswireless-beta@cisco.com

Catalyst 9800 IOS XE 17.11.1 Software EFT-billeder: Nedenstående placering kan bruges til at trække de seneste EFT-billeder:

Catalyst 9800 platforme:

• Catalyst 9800-CL trådløs controller til skyen – https://software.cisco.com/download/beta/1572566934
• Catalyst 9800-80 trådløs controller – https://software.cisco.com/download/beta/1536549615
• Catalyst 9800-L trådløs controller – https://software.cisco.com/download/beta/1597144509
• Catalyst 9800-40 trådløs controller – https://software.cisco.com/download/beta/1388071271

EWC (Embedded Wireless Controller på AP):

• Catalyst 9130AXI Access Point – https://software.cisco.com/download/beta/773616253
• Catalyst 9120AXI Access Point – https://software.cisco.com/download/beta/792652702
• Catalyst 9117AXI Access Point – https://software.cisco.com/download/beta/811480614
• Catalyst 9115AXI Access Point – https://software.cisco.com/download/beta/811599778

Endnu en gang tak for din tid til at hjælpe Cisco med at opfylde dine behov. Vi værdsætter dette forhold og ser frem til dine kommentarer og fortsatte støtte. Tøv ikke med at kontakte os, hvis du har spørgsmål nu eller på et hvilket som helst tidspunkt under EFT.
Trådløse funktioner målrettet til EFT (Early Field Trial) i IOS-XE Release 17.11.1:

Enkelhed:

• C9800 Jumbo Frame Support til Radius/AAA-pakker
• Forbedring af klientstyring under rullende AP-opgradering
• Effektiv download af AP-billeder via TCP
• Deaktiver intelligent 2.4 GHz-radioer
• Brugervenlighed: AAA CLI anmodning
• RPC til Syslog-konfiguration

Sikkerhed: 

• Forbedringer af den indbyggede Captive Portal
• Multigodkendelseskombination af 802.1xw/AAA-tilsidesættelse (Dynamic Vlan Assignment) og LWA (samtykke) på C9800
• En lokationsegnet attribut i Access-Request-meddelelserne som en del af RFC5580
• C9800 optimering af klientekskluderingstid med WPA3 SAE

Forbindelse: 

• Mesh: Baggrundsscanning
• Zero Wait DFS: Support på C9136

Bæredygtighed:

• Kan ikke forespørge OID'er fra CISCO-LWAPP-AP-MIB på 9800- Migration standset
• SNMP OID'er – Fase 2

Netværkstopologi

Forudsætninger

Test opsætning

Opgrader stier
Med henblik på dette EFT-program anbefaler Cisco at følge nedenstående opgraderingssti

• 17.3.6 -> 17.11.1 EFT-billede (Cisco-kvalificeret)
• 17.6.4 -> 17.11.1 EFT-billede (Cisco-kvalificeret)
• 17.10.1 -> 17.11.1 EFT-billede (Cisco-kvalificeret)

Note: Hvis kunderne har C9130, der kører 17.3.x, skal du først opgradere til 17.11.x for at opgradere til 17.6.
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-3/release-notes/rn-17-39800.html#Cisco_Concept.dita_9d1727be-e4ff-48e0-bbfd-cdb60f7b4054

Kompatibilitetsmatrix

Funktioner at teste

C9800 Jumbo Frame Support til Radius/AAA-pakker

Feature Overview:

I alle Polaris-udgivelser (indtil dato) udføres radiuspakken Fragmentering som standard ved 1396 bytes i det mellemliggende lag. Hvilket betyder, at "interface IP MTU-konfiguration" ikke overholdes. Dette fører til nedenstående problemer som f.eks. Fragmenteringsstørrelsen er løst, og Jumbo Frames understøttes ikke. Ved at tilføje denne funktion vil interface IP MTU-konfigurationen blive respekteret. Hvilket ville dække alle mulige kundebrugstilfælde med ensartet adfærd på udgående RADIUS-pakker. Med det nye design bliver RADIUS-pakken fragmenteret ved den grænseflade IP MTU-konfigurerede værdi. Brugeren skal konfigurere den påkrævede IP MTU-værdi under interfacekonfigurationen, og for at bruge den konfigurerede IP MTU-værdi for RADIUS-transaktionen skal brugeren konfigurere interfacenavnet under den tilsvarende RADIUS-gruppe.

Forudsætning:

• Denne funktion vil blive understøttet på alle platforme fra 17.11.1-versionen. · Jumbo-pakkeunderstøttelse er tilgængelig på ISE 3.1 version og fremefter

Konfiguration:

Interface konfiguration: interface ingen switchport mtu 5000 -> opsætning af Max MTU Range ip-adresse xxxx xxxx ip mtu -> opsæt IP MTU

Radiuskonfiguration på controller: aaa gruppeserverradius RADIUS_GROUP servernavn radius_server1 ip radius kildegrænseflade

ISE-konfiguration interface ip mtu

Note: Hvis IP MTU ændres på ISE, skal du forvente en genstart af netværkstjenesten for ISE.

Verifikation

Pakkefangst på Radius-pakker:

Forbedring af klientstyring under rullende AP-opgradering

Feature Overview:
Under softwareopgraderinger tillader den rullende AP-opgradering, at der er minimal nedetid for netværksforbindelsen. Dette skyldes, at når en AP går til genindlæsning med det nye billede, vil de omkringliggende AP'er være klar til at betjene klienter. Når et AP er valgt til at genindlæse, skal de klienter, der i øjeblikket er tilsluttet det, roame til et andet AP. For at gøre dette vil AP ikke længere svare på klienttilslutningsanmodninger, og det vil sende 802.11v BSS overgangsstyringsrammer til alle klienter, der understøtter 802.11v. Dette vil give dem besked, at AP vil genindlæse og roame til et nyt AP. For klienter, der ikke understøtter 802.11v eller ikke roamer, vil controlleren de-autentificere alle klienter, der er forbundet til AP.

For mere information om Rolling AP Upgrade, tjek venligst dette link:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-6/configguide/b_wl_17_6_cg/m_hitless_upgrade.html

Forudsætning:

• Cisco Catalyst 9800 trådløs LAN-controller, der kører IOS XE 17.11.1

Konfiguration og verifikation:

• Sådan aktiverer du klientstyring: C9800# conf t C9800(config)# ap opgradering staggered kundestyring
• Sådan deaktiveres klientstyring: C9800# conf t C9800(config)# ingen ap-opgradering staggered kundestyring
• Sådan konfigurerer du de-autentificering af klienter under opgradering, før AP genindlæses: C9800# conf t C9800(config)# ap opgradering staggered klient-død
• Sådan konfigurerer du ikke-afgodkendelse af klienter under opgradering, før AP genindlæses: C9800# conf t C9800(config)# ingen ap-opgradering staggered klient-død

Effektiv download af AP-billeder via TCP

Feature Overview:
Før IOS XE 17.11.1 brugte AP-billedet download under softwareopgraderinger CAPWAP-kontroltunnelen. CAPWAP kontroltunnelen er dog ofte optaget, da den bruges til mange andre formål. Desuden er downloadtiden for billedet begrænset af CAPWAP-vinduets størrelse. Der er også en stor belastning på C9800, da AP-image-downloads får WNCD-processerne til at udnytte CPU'en kraftigt. Med IOS XE 17.11.1 flytter AP-billeddownloads ud af CAPWAP-kontroltunnelen og ind i out-of-band-dataplanet, hvilket gør det muligt at downloade billeder via HTTPS. Ved at flytte downloadprocessen til HTTPS reduceres belastningen på WNCd-processerne og frigør CAPWAP-kontrolstien. Ved at bruge HTTPS og TCP er billeddownloads desuden hurtigere og mere fleksible, da linktypen og hastigheden kan specificeres. Hvis HTTPS-downloaden mislykkes, er der problemfri fallback til CAPWAP-kontroltunnelen. Som standard vil billedopgraderingen udnytte port 8443 for at undgå indvirkning på WebBrugergrænseflade og telemetri-streams på C9800. Dette kan ændres, så det passer til implementeringen. Mekanismen for download af AP-billeder er som følger:

Forudsætning:

Konfiguration og verifikation:

To aktiver AP-opgradering for at bruge HTTPS: C9800# conf t C9800(config)# ap opgraderingsmetode https

For at konfigurere AP file overførselsport: C9800# conf t C9800(config)# ap file-overfør https-port
Note: Hvis den ikke er konfigureret, vil C9800 bruge port 8443.

Sådan bekræfter du, at download af AP-billede bruger HTTPS: C9800# vis ap-opgraderingsmetode HTTPS: Aktiveret>

Sådan bekræfter du, at download af AP-billede bruger HTTPS: C9800# vis ap file-overfør https oversigt

For at bekræfte, at AP understøtter billeddownload over HTTPS: C9800# vis ap navn SITE4-9120-1 config generelt | sek. Opgradering

Sådan bekræfter du, at AP-billedet downloades via HTTPS: C9800# vis ap navn SITE4-9120-1 config generelt | sek. Opgrader AP-opgradering uden for bånd

Deaktiver intelligent 2.4 GHz-radioer

Feature Overview:

• FRA Fleksibel radioopgave
• XOR Dual-band radioer
• RRM Styring af radioressourcer

At give en konfigurerbar mulighed for at flytte redundante dualband XOR-radioer i netværket til kun at overvåge rolle. Den nuværende IOS-XE-implementering, FRA flytter redundante dual-band (XOR 2.4GHz/5GHz) radioer til enten 5GHz klientservering eller monitorfunktion. Der er intet andet valg end at vælge en bestemt mulighed baseret på implementeringen. Denne funktion giver kunderne mulighed for at konfigurere og vælge efter deres krav. FRA evaluerer kun 2.4 GHz-dækning og afgør, om overlappende dækning skaber interferens. Hvis den opdages, vil funktionen flytte dual-band (XOR 2.4/5GHz) radio til enten en 5GHz klient-server- eller monitorrolle. I henhold til den nuværende implementering er der ingen mulighed at vælge. Denne funktion implementerer en konfigurationsmulighed i 2.4GHz RF profile for at vælge radioen for at gå til kun monitor-tilstand. Som en del af denne funktion vil kunden have en konfigurerbar mulighed for at vælge de redundante dualband (XOR 2.4/5GHz) radioer i netværket til at fungere i en monitorrolle. I øjeblikket er der ingen mulighed for at vælge en FRA, der vil flytte radioer til hverken 5GHz klientservering eller skærm. Med denne mulighed kan kunderne vælge baseret på deres implementering.

Forudsætning:

• Cisco Catalyst 9800 trådløs LAN-controller, der kører IOS XE 17.11.1
• AP'er: C9115, C9120, C9130, C9136, CW9164, CW9166, CW9162

Konfiguration og verifikation:

Standard-RF-Profile [Global Config]:
wlc(config)#ap dot11 24ghz fra handling? monitor Konfigurerer FRA-handling som monitor

GHz RF-Profile
mdc-prod-wc2(config)#ap dot11 24ghz rf-profile madhu-rf-profile-24 mdc-prod-wc2(config-rf-profile)#fra handling ? monitor Konfigurerer FRA-handling som monitor

WebUI-konfiguration [1/2 ] Naviger: Konfiguration > Radiokonfiguration > RRM > FRA > 2.4/5GHz fleksibel radio > FRA-handling

WebUI-konfiguration [2/2 ] Naviger: Konfiguration > Tags & Profiles > RF/Radio > Avanceret > FRA Action
Vælge: Opdater og anvend på enhed

Vis kommandoer

mdc-prod-wc2#sh ap fra

• FRA stat: Aktiveret
• FRA fryse: Handicappet
• FRA Operation State: Op
• FRA-følsomhed: højere (85 %)
• FRA interval: 1 time(r)
• Serviceprioritet: Dækning
• Kundebevidst FRA: Aktiveret
• Klientvalg: 25 %
• Klientnulstilling: 5%
• FRA Action: 2.4 GHz/monitor
• Sidste løb: 3069 sekunder siden

Vis CLI [2/2]

mdc-prod-wc2#sh ap rf-profile <rf-profile navn> detalje | sek FRA

• Kundebevidst FRA: Handicappet
• FRA Action: 2.4 GHz/monitor

mdc-prod-wc2#sh ap navn AP7872.5DED.CB74 config slot 0 | sek Attributattributter for plads 0

• Radiotype: 802.11n – 2.4/5 GHz
• Radiotilstand: Overvåge
• Radioens rolle: Overvåge
• Tildelingsmetode: Auto
• Monitortilstand Årsag: Automatisk skiftet af FRA

Brugervenlighed: AAA CLI anmodning

Feature Overview:
For at øge brugerens læsbarhed på show-kommandoen til AAA-serveren introduceres en ny CLI "show aaa server brief", som viser alle de nødvendige detaljer i tabelformat. Og kolonnen indeholder følgende oplysninger:

• Adgangsanmodninger
• Adgang-Acceptér
• Adgang-Afvis
• Adgang Timeouts
• Udestående adgangstransaktioner
• Oppetid
• Regnskabsanmodninger
• Regnskabssvar
• Regnskabstimeouts
• Udestående regnskabstransaktioner
• Samlet antal anmodninger (godkendelse+konto)
• Samlede svar (godkendelse+konto)

Forudsætning:
Cisco Catalyst 9800 trådløs LAN-controller, der kører IOS XE 17.11.1

Konfiguration og verifikation:

Konfiguration:
Ingen konfiguration nødvendig.

Verifikation:
vis aaa serverkort

RPC til Syslog-konfiguration

Feature Overview:
Denne funktionsforbedring giver yang RPC-understøttelse af CLI 'send log', så de kan sende syslog-meddelelsen til enheden. Grundlæggende sender IOS-XE exec CLI send log, de angivne logfiler til syslog-serveren. Det hjælper med at validere både syslog-server og enhed til at sende og modtage syslogs, nu kan dette opnås gennem den programmerbare yang-grænseflade.

Forudsætning:
Cisco Catalyst 9800 trådløs LAN-controller, der kører IOS XE 17.11.1 Yang RPC-understøttelse af denne CLI 'send log' vil give en mekanisme til at skubbe syslog-meddelelsen til enheden. Til gengæld vil enheden sende denne besked til en konfigureret Syslog-server. Netconf-yang og restconf skal konfigureres på C9800 C9800#show running-config | i hvile restconf C9800#vis running-config | i net conf net conf-yang

Generelt er `send log'en konfigureret fra CLI, men i 17.11 kan vi sende den gennem den programmerbare grænseflade som vist nedenfor

Der bør ikke være nogen tom besked

På WLC ser vi beskeden er udskrevet i log-meddelelsen.

Følgende er begrænsningerne for input:

• Strengen i logmeddelelsen skal være i almindeligt tekstformat.
• En tom logmeddelelse er ikke tilladt.
• Specialtegn er tilladt i logbeskeder, mnemonics og faciliteter.
• Ingen plads er tilladt i facilitetsnavnet og Mnemonics, i modsætning til logmeddelelsen.
• Der er 3 måder at indtaste input på:
  1. Kun logbesked (I dette tilfælde sendes logbesked med standard sværhedsgrad, facilitet og mnemonics).
  2. Alvorlighed sammen med log-besked (I dette tilfælde sendes log-besked med standardfunktion og mnemonics)
  3. Alle 4 muligheder logger besked, sværhedsgrad, facilitet og mnemonics.
• Nedenfor er listen over standardværdier:
  1. Sværhedsgrad 7
  2. Facilitet "SYS"
  3. Mnemonics "USERLOG_DEBUG"

Forbedringer af den indbyggede Captive Portal

Feature Overview:
Internationale kunder på tværs af forskellige juridiske enheder skal overholde alle lokale love. Et lovkrav, der bliver mere tydeligt, er medtagelsen af ​​lokale sprog i alle operationer. Inden for nuværende implementeringer af IOS-XE er logonportalens bannertekstsektion begrænset til omkring 200 tegn. Derudover tillader softwaren ikke indtastning af specielle tegn såsom "ö" eller "à". Inden for 17.11.1 vil CLI-inputgrænsen for bannertekst blive forbedret, så den kan rumme op til 400 tegn. Ydermere vil både bannertekst og bannertitelstrenge vist i HTML-loginsiden nu kunne understøtte specialtegn såsom "ö" eller "à" osv. Da multi-line banneret understøttes via CLI, er det muligt at konfigurere også via YANG. Hvis den angivne inputstreng overskrider den maksimale grænse, vil der blive sendt en fejlmeddelelse, der angiver det samme, og konfigurationen vil blive afvist. Det Webauth login portal banner består af to dele.

1. Banner titel Dette kan tilpasses ved at bruge bannertitel <> CLI under web auth parameter kort. Standardtitelstrengen er "Velkommen til Cisco Web-Autentificeringsnetværk."
2. Bannertekst Dette kan tilpasses ved hjælp af bannertekst <> CLI under web auth parameter kort. Standardtekststrengen er "Cisco er glad for at give web-godkendelsesinfrastruktur til dit netværk. Vær venlig at logge ind."

Begrænsninger:

1. Ingen WebUI-understøttelse af denne funktion.
2. Parser har en begrænsning på 254 tegn pr. linje (inklusive CLI nøgleord). Derfor skal brugeren holde dette på kontoen, mens han giver input

Forudsætning:

• Cisco Catalyst 9800 trådløs LAN-controller, der kører IOS XE 17.11.1
• Brugere skal have kendskab til Lokal Web-Auth, bannertekst og bannertitel.

Fejlfinding:

Nedenfor kan IOS-fejlretning aktiveres for at se, om der var noget problem i bannerkonfigurationen. debug ip-admission all På binos-siden kan vi aktivere wncd alle modul verbose logs og indsamle sporene. RA interne logfiler kan også indsamles til klientrelateret fejlretning. Nedenstående kommandoudgange skal også indsamles. vis parameter-map type webauth name <> test platform software database get sm_exec_context/tbl_webauth_parmmap;navn= sh platform software proces database wncd ch ac R0 detaljer SM_CONFIG_DB “tabel tbl_webauth_parmmap" indhold

Multigodkendelseskombination af 802.1xw/AAA-tilsidesættelse (Dynamic Vlan Assignment) og LWA (samtykke) på C9800

Feature Overview:
I en universitetsopsætning godkender klienter ved hjælp af 802.1X. Som en del af 802.1X-godkendelse presser AAA-serveren de politikker, der skal anvendes for klienten. VLAN er en egenskab, som er skubbet fra AAA-serveren. Da dot1x er sikker og sker uden brugerindblanding, er slutbrugerne ikke klar over, hvilket netværk de er forbundet til. Dette kan føre til problemer, hvis klienterne opretter forbindelse til universitetets Wifi, og brugerne poster upassende indlæg eller besøger upassende websteder.
For at omgå dette problem har universitetet konfigureret til WebAuthentication post 802.1X. Web-Samtykke bruges som led i WebAuth for at informere slutbrugerne om, at de er forbundet til University Wifi. Dog som en del af Web- Samtykke, da der ikke anvendes nogen AAA-politik, fjernes den tidligere anvendte AAA-politik. Dette resulterer i VLAN-ændring og fører til klientafbrydelse. Denne cyklus fortsætter, og klienten får ikke netværksadgang.
For at løse dette problem introduceres CLI. Hvis denne CLI er konfigureret, vil den politik, der anvendes via samtykke, blive flettet med den anvendte politik for 802.1X/MAB.

Forudsætning:

• Cisco Catalyst 9800 trådløs LAN-controller, der kører IOS XE 17.11.1
• Brugere skal have viden om Multi Auth-koncepter, LWA(Consent), AAA-tilsidesættelse.

Aktivering af funktionen fra CLI: Device# configure terminal Device(config)#parameter-map type web auth LWA_consent Device(config-params-parameter-map)#type consent Device(config-params-parameter-map)#consent activation-mode merge
Deaktivering af funktionen fra CLI: Device# configure terminal Device(config)#parameter-map type web auth LWA_consent Device(config-params-parameter-map)#no consent activation-mode merge

Vis kommando med funktionen aktiveret fra CLI: JD_9800-L_1#sh parameter-map type web auth navn LWA_consent

• Parameterkortnavn: LWA_samtykke
• Bannertitel: Samtykketitel
• Bannertekst: Accepter venligst samtykket
• Type: samtykke
• Auth-proxy Init State tid: 300 sek
• Webauth max-http-forbindelse: 200
• Webauth logout-vindue: Aktiveret
• Webauth succes-vindue: Aktiveret
• E-mail med samtykke: Deaktiveret
• Aktiveringstilstand:
• Sovende-klient: Merge
• Webauth login-auth-bypass: Deaktiveret

politik, der anvendes via samtykke, vil blive flettet sammen med den politik, der anvendes for 802.1X/MAB.

Vis kommando med funktion deaktiveret fra CLI:|
JD_9800-L_1#sh parameter-map type webauth navn LWA_consent

• Parameterkortnavn: LWA_consent
• E-mail med samtykke: Deaktiveret
• Aktiveringstilstand: Udskift

politik anvendt via samtykke ville ikke blive flettet sammen med den anvendte politik for 802.1X/MAB.

Begrænsninger:

• Ingen WebUI-understøttelse af denne funktion.
• Ingen SNMP-understøttelse. Kun Yang-understøttelse vil blive tilføjet til denne funktion.
• Når "aktiveringstilstand fletning" ikke er konfigureret på WebGodkend parameterkort, så er standardaktiveringstilstanden REPLACE-ALL. Det betyder, at bruger-profile for samtykke ville erstatte alle tidligere anvendte bruger-profile politikker.

Location-Capable-attribut i adgangs-anmodningsmeddelelserne som en del af RFC5580 Feature Overview:
RFC 5580-placeringsattributterne formidler placeringsrelaterede oplysninger til godkendelse og regnskabsudveksling. Placeringsoplysningerne er nyttige i flere scenarier. Trådløse netværk er implementeret på offentlige steder, såsom indkøbscentre, lufthavne, hoteller og kaffebarer af en række forskellige operatører, såsom udbydere af trådløse internettjenester (WISP'er), mobilnetværksoperatører og faste bredbåndsnetværk. I alle disse scenarier skal netværket muligvis kende brugerens placering for at aktivere lokationsbevidst godkendelse, fakturering eller tjenester. Se venligst IOS-XE 17.9-konfigurationsvejledningen for at konfigurere RFC 5508-placeringsattributter https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-9/configguide/b_wl_17_9_cg/m_rfc-5580-loc-att-on-the-controller.html#Cisco_Reference.dita_aed3a65e9f99-4d8b-bddb-a6c4e9c3fe54

RFC 5580 nævner tre lokationsleveringsmetoder for lokationsoplysninger til AAA-server, som nævnt nedenfor:

1. Stedlevering baseret på Out-of-Band aftale
2. Placeringslevering baseret på indledende anmodning
3. Levering af sted baseret på anmodning fra midt i sessionen

I IOS-XE 17.11-udgivelsen forbedrer vi denne funktion ved at tilføje den lokations-kompatible attribut i adgangsanmodningen til out-of-band-aftalen.

Forudsætning:

1. Cisco Catalyst 9800 trådløs LAN-controller, der kører IOS XE 17.11.1
2. Brugere skal have kendskab til AAA og 802.1x

Konfiguration og verifikation:
Attributten location-Capable sendes kun som en del af adgangsanmodninger i tilfælde af metode 2 (Lokationslevering baseret på indledende anmodning), som er initial-anmodningsbaseret, men vi yder support til denne attribut i out-of-band, som is (Placeringslevering baseret på Out-of-Band-aftale) For at aktivere denne attribut skal følgende kommando konfigureres på C9800. I øjeblikket er det kun understøttet fra CLI C9800(config)#radius-serverattribut trådløs lokationslevering uden for båndet include-location-capable

C9800 optimering af klientekskluderingstid med WPA3 SAE Feature Overview:
SAE-klientekskluderingsmekanismen er designet til at beskytte systemet mod at bruge beregningsressourcer til at behandle ugyldige godkendelsesanmodninger fra ondsindede brugere. Hvis en klient mislykkes med SAE-godkendelse flere gange (op til 5), vil C9800 ekskludere klienten i en ekskluderingsperiode (standard 60 sek.). I løbet af denne ekskluderingstid slettes alle godkendelsesanmodninger fra denne klient. I lokal tilstand behandles SAE-godkendelse på WLC, som tæller antallet af autentificeringsfejl og tilføjer klient til ekskluderingslisten, når optællingen når en foruddefineret tærskel. Klienten får lov til at oprette forbindelse igen efter ekskluderingstimeoutet. Timeoutværdien kan konfigureres for at tillade fleksibilitet til at håndhæve klientekskludering. Før IOS XE 17.11.1 starter SAE-ekskluderingsimplementering ekskluderingsprocessen på klientoprydningstidspunktet efter godkendelsesfejl. Det tager et par flere beskedudvekslinger mellem C9800 og klienten for at nå oprydningstilstanden. Da klienten kan trække sig tilbage før afsendelse af den næste besked, SAE commit, efter autentificeringsfejl, varierer tidsforløbet mellem fejlen og starten af ​​udelukkelsen. Vi kan optimere flowet ved at starte ekskluderingsprocessen lige på tidspunktet for godkendelsesfejl (SAE confirm message mismatch). Dette undgår forsinkelsen og ekskluderer klienten hurtigere.

Forudsætning:

• Cisco Catalyst 9800 trådløs LAN-controller, der kører IOS XE 17.11.1 · Denne funktion er kun til installationer i lokal tilstand.

Konfiguration og verifikation:
Optimeringen til WPA3 SAE-klientekskludering finder sted i baggrunden, og der skal ikke foretages ekstra konfiguration.
Sådan bekræfter du klientekskluderingerne:

• C9800# vis trådløs ekskluderingsliste
• klient mac-adresse f2f8.4a03.a0e8 detalje
• Kundetilstand: Udelukket
• Client MAC-adresse: f2f8.4a03.a0e8
• Klientens IPv4-adresse: N/A
• Klientens IPv6-adresse: N/A
• Klientbrugernavn: N/A
• Ekskluderingsårsag: SAE-godkendelsesfejl
• Godkendelsesmetode: Ingen
• Protokol: N/A
• AP MAC-adresse: 0c75.bdb1.3f20
• AP-navn: AP0C75.BDB1.EDA8
• AP slot: 0
• Trådløst LAN-id: 7
• Trådløst LAN navn:
• VLAN-id: 0

 Mesh: Baggrundsscanningsfunktion overview:
Cisco Mesh-adgangspunkter (MAP) er forbundet over trådløse links i et spændingstræ som topologi. Et MAP, der er forbundet til netværket via ethernet-uplink, er udpeget som root MAP aka RAP. AWPP-protokol bruges til at vedligeholde træet og danne træet. Når et MAP kommer op, forsøger det at lede efter et andet MAP (forælder) at tilslutte sig for til sidst at nå gatewayen via en RAP. Det samme sker, når en MAP mister forbindelsen til sin eksisterende forælder. Denne procedure er kendt som mesh tree konvergens. Dette dokument har til formål at forbedre konvergensproceduren for at gøre den hurtigere og robust. Et MAP i søgning, dets overordnede uplink gennemgår følgende procedurer:

1. Registrering af forældretab (hvis allerede tilsluttet)
2. Scan (passiv) efter en ny forælder på tværs af alle/undersæt af regulatoriske domænekanaler
3. Søg (anmodning/svar) på nyfundet forælder på scannede/operable kanaler
4. Vurder og vælg den bedste nabo
5. Vælg naboen som potentiel forælder og godkend via valgt forælder til WLC
6. Behold/forny IP og
7. Genstart CAPWAP for at tilslutte WLC'en

Denne procedure i dag kan tage fra snesevis af sekunder til et minut. Vi planlægger at implementere følgende for at forbedre det: Mesh-baggrundsscanning og automatisk forældrevalg er mekanismer, der bruges af et MAP til at finde og oprette forbindelse hurtigere til en bedre potentiel forælder på tværs af kanaler og altid bevare sin uplink med en bedste forælder.

Forudsætning:
C9800 kører i det seneste EFT IOS-XE-billede med Mesh-netværk, der kører.

Topologi:

Konfiguration og verifikation:
Sådan aktiverer du baggrundsscanning: I Mesh Profile (trådløs profile mesh default-mesh-profile), aktiver baggrundsscanning (baggrundsscanning)
Verifikation: Tjek baggrundsscanningen i show wireless profile mesh detaljeretfile

Konfigurer: C9800-CL-AWS(config)#wireless profile meshfile_navn> C9800-CL-AWS(config-wireless-mesh-profile)#baggrundsscanning

Verificere: C9800-CL-AWS#show wireless profile mesh detaljeretfile_navn>

• Mesh Profile Navn: <profile_navn>
• Beskrivelse: brugerdefineret mesh profile
• Brogruppenavn: custom_bgn_name
• Baggrundsscanning: AKTIVERET

1. Aktiver baggrundsscanning, og bekræft, at funktionaliteten fungerer som forventet på C9124 MAP.
   1. Aktiver baggrundsscanning, og bekræft, at funktionaliteten fungerer som forventet på C9124 MAP.
   2. Bekræft, at mesh-netværket er OP og kører stabilt.
   3. Aktiver baggrundsscanning.
   4. På C9124 MAP skal du kontrollere, at funktionen er aktiveret og fungerer.
      Bruge:
      • vis mesh-statistik
      • vis mesh-historik for nylig
      • vis mesh tilgrænsende alle
      • vis mesh-konvergens
      • vis mesh res
      • show mesh poser kan konfigurere backhaul
      • vis mesh-poser kan konfigurere slot 1
      • vis mesh poser kan kanaler backhaul
      • vis mesh poser dåsekanaler slot 1
      • vis mesh tasker kan status backhaul
      • vis mesh poser kan status slot 1
      • show mesh tasker kan planlægge backhaul
      • show mesh tasker kan planlægge plads 1
   5. Bekræft, at MAP UT er opmærksom på den fulde kanalliste, som mesh-peers fra den samme BNG opererer på, dvs. den modtager fuldstændig information under RES-forsyning.
   6. Bekræft, at MAP UT er i stand til at etablere fulde tilknytninger med radionaboer, der tilhører samme BGN.
   7. Bekræft, at MAP UT ikke vil oprette naboer med radionaboer, der ikke er medlemmer af samme BGN
2. Bekræft indvirkning på klienttrafik, når baggrundsscanning er aktiveret på C9124
   1. C9124 MAP fungerer på en 5GHz backhaul-kanal.
   2. Trådløse klienter er forbundet til 2.4 GHz klient, der betjener radio og genererer konstant trafik.
   3. Aktiver baggrundsscanning.
   4. Bekræft, at baggrundsscanning ikke har nogen indflydelse på klientens trafik.

Zero Wait DFS: Support på C9136 Feature Overview:

• U-Nii-2 og U-Nii-2C(e) båndene også kendt som "DFS Channels" (Dynamic Frequency Assignment) kræver en 60 sekunders (eller mere) Channel Availability Check (CAC), før de bruges af Wi-Fi for at sikre, at ingen radar er i drift.
• Zero Wait DFS gør det muligt at bruge AP's ressourcer til at udføre en forebyggende CAC, før et kanalskifte påbegyndes, hvilket eliminerer de 60-600 sekunders forsinkelse, der opleves på et kanalskifte til en hvilken som helst DFS-kanal

Før 17.8 IOS-XE-udgivelsen er DFS CAC blevet udført på efterspørgsel som en forløber for at antage WiFi-operationer på en kanal. Denne adfærd er påkrævet for at verificere, at der ikke er nogen driftsradar på den kanal, vi vil antage. Når den først er tilgået, skal scanningen fortsætte under kanaldrift og opgives øjeblikkeligt, hvis radar detekteres. Når RRM tildeler en kanal, tildeler den den "bedste" kanal, der er tilgængelig i den aktuelle DCA-kørsel. Der er også tildelt en næstbedste kanal på det tidspunkt, som er mærket som en fremtidig kanal. I tilfælde af en radardetektering på den aktuelle DFS-kanal, vil den fremtidige kanal blive scannet og derefter brugt. Denne "Mini DCA"-kørsel sikrede, at successionskanalen allerede var et godt valg baseret på kanaltilknytningerne. Hvis den fremtidige kanal tilfældigvis var en DFS-krævet kanal, så ville AP'en scanne 60 sekunder (eller 600 sekunder hvis ETSI TDWR-kanalerne 120, 124, 128) og derefter antage beaconing igen på den nye kanal. Zero Wait DFS-funktionen blev oprindeligt introduceret i IOS-XE 17.9 til ETSI og FCC Catalyst C9130 AP. IOS-XE 17.11-udgivelsen tilføjer understøttelse af Catalyst C9136 AP'erne. Zero Wait DFS er stærkt afhængig af lokale tilsynsmyndigheders regler, og som sådan er der forskelle i de anvendte metoder, men minimal forskel på de oplevede resultater.

ETSI-regulativ:
Konceptet Pre-CAC understøttes. I ETSI, når en kanal er blevet ryddet af CAC, kan den betragtes som ryddet af AP'en og bruges uden yderligere CAC på ubestemt tid, indtil AP'en genstartes.

• Dette gør det muligt for AP at scanne så få eller så mange kanaler, som vi ønsker at holde til fremtidig brug
• Hvis AP skal bruge en fremtidig kanal, kan den gøre det uden at udføre CAC
• Hvis Radar detekteres på den betjenende kanal, kan AP flytte til en Pre-CAC-kanal og udsende med det samme.

Denne funktion fjerner effektivt 10-minutters (600 sekunder) straffen for at bruge en TDWR-kanal (120,124,128) i ETSI.

FCC regulering:
FCC-tilgangen adskiller sig ved, at der ikke er mulighed for Pre-CAC. I FCC er en kanal kun gyldig, så længe en modtager lytter til den og leverer CAC-data. Denne regel betyder, at vi stadig kan CAC et fremtidigt kanalvalg, men det skal løbende CAC'es, hvis vi skal antage det radarfrit og begynde øjeblikkelig operationer. DCA beregner allerede den "næstbedste" kanal i enhver kanaltildeling på tidspunktet for DCA-kørslen. Med den næstbedste kanal har vi allerede valgt en gyldig, hvis lidt mindre optimal, kanal, som ikke vil være i konflikt med resten af ​​de AP'er, der skal bruges i tilfælde af en radardetektering. Denne kanal kan kontinuerligt CAC'es og på denne måde opretholde parathed til øjeblikkelig operationer af AP til enhver tid. Catalyst C9130 og C9136 radiochipsæt har 3 DFS-scanningsmotorer. Kørsel i Tri-Radio-tilstand vil kræve, at to af disse motorer aktiveres, hvis to DFS-kanaler er tildelt. Den 3. går dog ubrugt og kan dedikeres til at scanne den eller de fremtidige kanal(er).

• Dette gør det muligt for AP kontinuerligt at scanne en fremtidig kanal (bestemt af DCA)
• Hvis AP skal bruge en fremtidig kanal, kan den gøre det uden at udføre CAC
• Hvis Radar detekteres på den betjenende kanal, kan AP flytte til den fremtidige kanal og udsende med det samme.

NOTE: Fremtidig kanal CAC udføres kontinuerligt uden indvirkning på betjening af radiooperationer uden klientpåvirkning.

Dual 5 GHz overvejelser:
Pre-CAC dækker alle kanaler og scenarier for ETSI-regionen. Rolling CAC for FCC præsenterer et par mulige scenarier. I FCC kan vi løbende CAC kun én fremtidig kanal. Hvis begge 5 GHz-grænseflader er tildelt DFS-kanaler, kan kun den ene have en fuldt CAC'et og klar fremtidig kanal. I tilfælde af at vi har to grænseflader med DFS-kanaler tildelt, skal den næstbedste kanal for hver stadig opretholde 100 MHz adskillelse fra den anden grænsefladekanal til enhver tid. I mange tilfælde vil dette ende i et andet band sammen. I tilfælde, hvor begge fremtidige kanaler også er DFS, vil grænsefladen med det højeste antal klienter få prioritet for rullende CAC. Hvis den anden grænseflade detekterer radar - vil dens kanalskifte skulle udføre en normal CAC (60 sekunder), før den påtager sig operationer.
Forudsætning:

1. C9136I eller C9130 -B eller -E AP'er
2. C9800 Controller, der kører 17.11.1 EFT-koden
3. Konsoladgang til controlleren

Det er ligetil at teste denne funktion. Alle tilstande kan vises i øjeblikket i CLI show-kommandoer. Konfiguration kan opnås på GUI- eller CLI-niveauer.

Konfiguration og verifikation:
Zero Wait DFS kan aktiveres på globalt niveau for alle AP'er på WLC'en eller gennem en RF profile at administrere en undergruppe af AP'er. Der er ingen konfigurationsmuligheder for denne funktion.

Sådan aktiverer du Zero Wait DFS på GUI'en: På controllerens GUI – vælg Configuration=>RRM=>5 GHz Band=> DCA og vælg Zero Wait DFS-indstillingen, marker afkrydsningsfeltet for at aktivere på globalt niveau.

Sådan aktiverer du globalt fra CLI: C9800-L_17_11(config)#AP dot11 5ghz rrm kanal zero-wait-dfs

For at deaktivere, brug kommandoen nej: C9800-L_17_11(config)#no AP dot11 5ghz rrm kanal zero-waitdfs

I alle tilfælde for at bekræfte, at funktionen er globalt aktiveret, skal du bruge følgende show-kommando til at bestemme den aktuelle globale tilstand for Zero Wait DFS:
C9800-L_17_11#sh ap dot11 5ghz kanal | i nul

• Nul ventetid DFS: Aktiveret

NOTE: Aktivering af Zero Wait DFS vil kun påvirke AP'er, som det er understøttet på, i øjeblikket kun Catalyst C9130AX AP'erne. Andre AP'er, der ikke understøttes, vil ikke blive påvirket af konfigurationsmuligheden.

Aktiver Zero Wait DFS selektivt gennem en RF Profile:
Zero Wait DFS kan også anvendes selektivt gennem en RF -Profile tillader granulært valg af et undersæt af AP'er, som denne indstilling gælder for.
Der er ingen forudsætning for at aktivere på globalt plan:
Fra GUI, naviger fra hovedmenuen til: Konfiguration=> Tags & Profiles => RF/Radio Vælg 5 GHz RF Profile for at ændre eller oprette en ny, og vælg RRM/DCA og marker afkrydsningsfeltet Zero Wait DFS.

For at aktivere Zero Wait DFS i en RF Profile fra CLI:

• C9800-L_17_11(config)#ap dot11 5ghz rf-profile <profile navn>
• C9800-L_17_11(config-rf-profile)#kanal nul-vent-dfs
• C9800-L_17_11(config-rf-profile)#ingen kanal zero-wait-dfs

For at bekræfte tilstanden af ​​Zero Wait DFS for et individuelt AP skal du bruge følgende show-kommandoer:

C9800-L_17_11#sh ap navn C9130i_9f.6e.a0 config slot 1 | s Nul

• Nul Vent DFS-parametre
  • Zero Wait DFS-kapabel: Ja
  • CAC-domæne: FCC
  • Nul ventetid DFS aktiveret: Aktiveret
  • DFS-kanalinkluderingsliste: 60,64,104
• DFS-kanalekskluderingsliste: 52,56,100,108,112,116,120,124,128,132,136,140,144
• Præ-CAC-status: NA (dette er FCC, så der er ingen præ-CAC-kapacitet)
• Reserveret kanal CAC-status: Igangværende (angiver, at off-kanal scanning køres)
• Reserveret kanal: 108
• Reserveret kanalbredde: 40 M

Eksample ovenfor er for en FCC AP nedenfor er example for ETSI

AIRV_VWLC2#sh ap navn AP1416.9D28.0CC4 config slot 1 | s Nul

• Nul Vent DFS-parametre
  • Zero Wait DFS-kapabel: Ja
  • CAC-domæne: ETSI
  • Nul ventetid DFS aktiveret: Aktiveret
  • DFS-kanalinkluderingsliste: 52,132
  • DFS-kanalekskluderingsliste: 56,60,64,100,104,108,112,116,136,140
  • Præ-CAC-status: I gang (ETSI
• Pre-CAC, kører)
  • Reserveret kanal CAC-status: Igangværende (angiver, at scanning uden for kanalen køres)
  • Reserveret kanal: 100
  • Reserveret kanalbredde: 20 MHz

Testcases:

Følg nedenstående trin for at teste Zero Wait DFS.

Note: Det er vigtigt at matche den foreslåede konfiguration, da testradarkommandoen på AP'en kun fungerer på en 20 MHz kanal, og brug af denne mod en AP med bredere kanaler kan få uforudsigelige resultater.

For at teste enten FCC eller ETSI

1. 1. Konfigurer AP'et til et enkelt slot 5 GHz. Deaktiver enten tri-band-tilstand (fungerer som 8×8) eller deaktiver slot 2-radioen.
2. 2. Sørg for, at Zero Wait DFS er konfigureret, og at der er valgt en reservekanal
   1. C9800-L_17_11#sh ap navn config slot 1 | s Nul Nul Vent DFS-parametre
      • Nul ventetid DFS-kapabelt CAC-domæne: Ja: FCC
      • Nul ventetid DFS aktiveret: Aktiveret
      • DFS-kanalinkluderingsliste DFS-kanalekskluderingsliste: 52,60 : 56,64,100,104,108,112,116,120,124,128,132,136,140,144
      • Pre-CAC-status Reserveret kanal CAC-status: NA: Fuldført
      • Reserveret kanal Reserveret kanalbredde: 60 : 20 MHz
3. 3. På AP CLI udføres Test Spectrum Radar kommandoen testspektrum radar signal dot11Radio 1 center-frekvens båndbredde 20 Centerfrekvensen for 20 MHz kanaltildelingen skal indtastes i MHz. for kanal 52 er denne værdi 5260 MHz, kanalbåndbredden skal indstilles til 20 MHz.
4. 4. Når radarsignalet er udløst, bør AP'en straks genoptage driften på "reserve"-kanalen uden den sædvanlige 60 sekunders CAC-forsinkelse.
   1. C9800-L_17_11#sh ap navn C9130i_9f.6e.a0 config slot 1 | s Nul
      1. Nul Vent DFS-parametre Nul Vent DFS-kapabel CAC-domæne: Ja : FCC
      2. Nul ventetid DFS aktiveret: Aktiveret
      3. DFS Channel Inklusionsliste: 60 Nye
   2. Driftskanal den tidligere reservekanal
      1. DFS-kanalekskluderingsliste: 52,56,64,100,104,108,112,116,120,124,128,132,136,140,144
      2. Præ-CAC-status: NA
      3. Reserveret kanal CAC-status: Ind
   3. Progress CAC er i gang for den nye reservekanal
      1. Reserveret kanal: 56
   4. Kanal 56 bliver den nye reservekanal
      1. Reserveret kanalbredde: 20 MHz

Kan ikke forespørge OID'er fra CISCO-LWAPP-AP-MIB på 9800Migration stoppet Feature Overview:
Dette er en AireOS-paritetsfunktion. Få AP MIB OID'er mangler i C9800 WLC'er. Denne funktion er at tilføje støtte til de manglende OID'er.

Forudsætning:
Ingen specifik forudsætning er nødvendig. SNMP skal være aktiveret i C9800.

Konfiguration og verifikation:

1. Få en C9800 frem med det seneste validerede EFT-billede leveret gennem EFT-programmet.
2. Tilslut et adgangspunkt til denne C9800
3. Opret et WLAN og tilslut en klient til dette WLAN
4. Konfigurer SNMP-fællesskaberne (læs/skriv)
5. Sørg for, at C9800 svarer på SNMP-forespørgslerne
6. Valider følgende senest introducerede OID'er (gå/få/kom næste/sæt)
   1. cLApSlotWlanStats
   2. cLApRadioWlanInfoEntry
   3. cLApActiveClientCount
   4. cLApAssociatedClientCount
   5. cLApMemoryCurrentUsage
   6. cLApMemoryAverageUsage
   7. cLApCpuCurrentUsage
   8. cLApCpuAverageUsage
   9. cLApGlobalAPConnectCount
   10. clsSysApConnectCount
   11. cLApWlanStatsAssocClientNum
   12. cLApWlanStatsOnlineUserNum

SNMP OID'er – Fase 2 funktion overview:
Denne funktion er for at imødekomme kundernes anmodning om at understøtte få SNMP-variabler, som er nyttige til 9800-implementeringer.

Følgende er de nye OID-tilføjelser:

• bsnDot11EssNumberOfMobileStations
• bsnDot11EssNumApsUp
• bsnDot11EssNumApsDown
• bsnAPOperation Status
• cLApUpTime
• bsnGlobalDot11SystemMobileStations
• cLApGlobalAPConnectCount

Forudsætning:

• Cisco Catalyst 9800 trådløs LAN-controller, der kører IOS XE 17.11.1
• SNMP-manager skal være aktiveret
• Privat eller offentligt SNMP-fællesskab skal konfigureres

Konfiguration og verifikation:
Start med at kontrollere, om SNMP-manager er aktiveret, og fællesskaber er tilføjet på Cisco Catalyst 9800-controlleren.

• sri-dao#sh løb | jeg
• snmp snmp-servergruppe v3_ro_users v3 priv read preview
• snmp-servergruppe v3_rw_users v3 priv skrive preview
• snmp-server view præview er inkluderet
• snmp-server fællesskab offentlig RO
• snmp-server fællesskab privat RW
• snmp-server community test RW
• snmp-server trap-source Vlan8
• snmp-server pakkestørrelse 5000
• snmp-server aktivere fælder
• snmp-godkendelseslink ned linkup koldstart varmstart
• snmp-serveren muliggør fælder trådløs wireless_mobility
• snmp-server aktivere traps config
• snmp-server aktiverer traps rf
• snmp-server vært 10.104.174.58 offentlig
• SNMP-server vært 9.2.14.175 offentlig
• SNMP-server vært 9.5.11.19 offentlig
• SNMP-server manager
  • felt phy_ ht_cfg.cfg_data. snmp_freq_string
  • field radio_oper_data.phy_ht_cfg.cfg_data. snmp_freq_string
  • field radio_oper_data.phy_ht_cfg.cf8_data. snmp_ freq_string

OID-bekræftelse på Cisco Catalyst 9800-controller:
Brug disse kommandoer på 9800 CLI

SNMP-svar: reqid 25, errstat 17, erridx 1 cLApGlobalAPConnectCount.0 = 4