Manual d'usuari de CISCO IOS-XE Wireless EFT

EFT sense fil IOS-XE

Informació del producte: Guia EFT sense fil IOS-XE 17.11.1

Les solucions Cisco Enterprise Wireless estan dissenyades per proporcionar xarxes sense fils resistents i segures amb una intel·ligència adaptativa i perspicaz. Les solucions es basen en l'arquitectura de xarxa digital de Cisco, preparant-les per a les creixents expectatives dels usuaris, els dispositius IoT i les aplicacions basades en el núvol. Els controladors sense fil Cisco Catalyst de la sèrie 9800 basats en IOS-XE es van presentar el 2018 i des de llavors han experimentat una innovació constant, presentacions de noves plataformes, millores de funcions i addicions de paritat de funcions, convertint-los en els millors de classe empresarial del mercat.

Matriu de compatibilitat

La matriu de compatibilitat per a la Guia EFT sense fil IOS-XE 17.11.1 està disponible al manual de l'usuari.

Característiques a provar

Les característiques a provar inclouen:

• Descàrrega eficient d'imatges AP mitjançant TCP

Proporcionar comentaris i sol·licitar suport

Si trobeu algun problema o teniu comentaris o comentaris addicionals durant el programa EFT, podeu enviar els vostres comentaris a l'equip de TME. Si trobeu problemes o teniu comentaris o comentaris addicionals un cop finalitzat el programa EFT, encara podeu enviar els vostres comentaris a l'equip de TME.

Instruccions d'ús del producte: Guia EFT sense fil IOS-XE 17.11.1

Topologia de xarxa

La topologia de xarxa depèn de la vostra configuració i requisits específics. Consulteu el manual d'usuari per obtenir més informació.

Prerequisits

Prova de configuració

Abans de realitzar les proves, assegureu-vos que teniu:

• Controladors sense fil Cisco Catalyst sèrie 9800
• Punts d'accés Cisco Catalyst 9100
• Dispositius de prova

Camins d'actualització

Les rutes d'actualització estan disponibles al manual d'usuari.

Descàrrega eficient d'imatges AP mitjançant la funció TCPview

Descripció de la característica

La descàrrega eficient d'imatges AP mitjançant la funció TCP permet descàrregues d'imatges AP més ràpides i fiables mitjançant l'ús de TCP.

Ús de funcions

Per utilitzar la descàrrega eficient d'imatges AP mitjançant la funció TCP, seguiu les instruccions del manual d'usuari.

Introducció

Les solucions Cisco Enterprise Wireless són resistents, tenen seguretat integrada i utilitzen una intel·ligència adaptativa i perspicaç que proporciona informació útil sobre la vostra xarxa. Amb les xarxes basades en intencions basades en l'arquitectura de xarxa digital de Cisco, les solucions Cisco Enterprise Wireless van més enllà dels últims estàndards Wi-Fi 6 i WiFi 6E (802.11ax) i estan preparades per a les creixents expectatives dels usuaris, dispositius IoT i núvol de nova generació. aplicacions impulsades.

Guia EFT sense fil IOS-XE 17.11.1

Controladors sense fil Cisco Catalyst 9800 Series: Els controladors Catalyst optimitzen el millor de l'excel·lència de RF amb avantatges oberts i programables de Cisco IOS® XE, el que significa que ja no teniu dos sistemes operatius per gestionar. Aquests controladors modulars, fiables i altament segurs són prou flexibles per desplegar-se a qualsevol lloc, inclòs el núvol que escolliu.

Punts d'accés Cisco Catalyst® 9100: en marxa més enllà de l'estàndard Wi-Fi 6 i 6E, els punts d'accés Cisco Catalyst 9100 proporcionen seguretat integrada, resiliència i flexibilitat operativa, així com una major intel·ligència de xarxa. Aquests punts d'accés amplien la xarxa basada en intencions i escala de Cisco a les creixents demandes de l'Internet de les coses (IoT) alhora que donen suport a les últimes innovacions i tecnologies més recents, fent-los perfectes per a organitzacions de totes les mides.

Per obtenir un final completview i obteniu més informació sobre Cisco Productes i solucions sense fil empresarials, visiteu la pàgina següent: https://www.cisco.com/c/en/us/products/wireless/index.html – ~recursos

Els controladors sense fil Cisco Catalyst 9800 Series basats en IOS-XE es van introduir al mercat a finals de 2018 amb la versió 16.10.1 d'IOS-XE. Hi ha hagut innovacions constants, presentacions de noves plataformes, millores de funcions i addicions de paritat de funcions durant els darrers dos anys per fer que els controladors sense fils Cisco Catalyst 9800 Series i els punts d'accés Cisco Catalyst 9100 siguin els millors de classe empresarial del mercat.

Aquest document ofereix una funció sobreview, configuració i escenaris de prova per a algunes funcions sense fil seleccionades segons l'interès del client, per a una prova de camp primerenca de la versió 17.11.1 d'IOS-XE. Ens complau donar-vos la benvinguda a l'EFT de la versió del programari sense fil IOS-XE 17.11.1. Cisco reconeix i aprecia el temps i l'esforç que avaluaran les funcions d'aquesta versió de programari i espera que trobeu que compleix les vostres expectatives. Aquest programari i la documentació que l'acompanya se us proporcionen en virtut de l'acord de confidencialitat entre vosaltres, la vostra organització i Cisco. Si us plau, no comenteu aquest projecte i les seves característiques fora de les discussions sobre les llistes de correu relacionades amb Cisco Beta. Aquest programari és un programari de publicació prèvia i, com a tal, mai s'ha d'utilitzar en un entorn operatiu comercial o amb dades de missió crítica. Us recomanem que instal·leu aquest programari en una xarxa/sistema de prova inicialment i després passeu a les proves de producció a mesura que us sentiu més còmodes. Si us plau, utilitzeu el programari com ho faríeu normalment en les vostres tasques diàries i informeu de qualsevol problema que trobeu.

Proporcionar comentaris i sol·licitar suport
A continuació s'ofereixen detalls sobre com proporcionar comentaris. A més, tingueu en compte que al llarg del projecte podem demanar comentaris sobre àrees específiques del programari. Els vostres comentaris són vitals per a Cisco Systems perquè us proporcionin les característiques i la utilitat que necessiteu per dur a terme la vostra missió individual. Aquest EFT representa una oportunitat per veure si s'adapta a les vostres necessitats i per aportar informació sobre la seva idoneïtat. L'administrador d'EFT us ha comunicat les dates d'inici i els terminis del programa EFT mitjançant una comunicació separada. Durant el període d'EFT, almenys una actualització del programari d'EFT estarà disponible durant la fase d'EFT. Per incloure tantes correccions com sigui possible en aquesta versió actualitzada; us animem a vosaltres i al vostre personal a provar aquest programari i proporcionar comentaris tan aviat com sigui possible al programa. Hi haurà un tall en el qual congelarem el desenvolupament per provar i llançar la imatge d'actualització. L'actualització contindrà correccions importants i es recomana a tots els participants que actualitzin un cop estigui disponible el programari d'actualització EFT. Si trobeu problemes o teniu comentaris o comentaris addicionals un cop finalitzat el programa d'EFT, encara us donem la benvinguda, com sempre!

Per fer un seguiment dels problemes trobats, fer comentaris o fer preguntes, podeu enviar la vostra consulta a: polariswireless-beta@cisco.com

Imatges EFT del programari Catalyst 9800 IOS XE 17.11.1: La ubicació següent es pot utilitzar per extreure les últimes imatges EFT:

Plataformes Catalyst 9800:

• Controlador sense fil Catalyst 9800-CL per al núvol - https://software.cisco.com/download/beta/1572566934
• Controlador sense fil Catalyst 9800-80 - https://software.cisco.com/download/beta/1536549615
• Controlador sense fil Catalyst 9800-L - https://software.cisco.com/download/beta/1597144509
• Controlador sense fil Catalyst 9800-40 - https://software.cisco.com/download/beta/1388071271

EWC (controlador sense fil integrat a AP):

• Punt d'accés Catalyst 9130AXI - https://software.cisco.com/download/beta/773616253
• Punt d'accés Catalyst 9120AXI - https://software.cisco.com/download/beta/792652702
• Punt d'accés Catalyst 9117AXI - https://software.cisco.com/download/beta/811480614
• Punt d'accés Catalyst 9115AXI - https://software.cisco.com/download/beta/811599778

Un cop més, gràcies pel vostre temps i esforç per ajudar Cisco a satisfer les vostres necessitats. Valorem aquesta relació i esperem els vostres comentaris i el vostre suport continuat. No dubteu a posar-vos en contacte amb nosaltres si teniu cap pregunta ara o en qualsevol moment durant l'EFT.
Funcions sense fil orientades a EFT (Early Field Trial) a la versió 17.11.1 d'IOS-XE:

Simplicitat:

• C9800 Jumbo Frame Suport per a paquets Radius/AAA
• Millora en la direcció del client durant l'actualització de Rolling AP
• Descàrrega eficient d'imatges AP mitjançant TCP
• Desactiva de manera intel·ligent les ràdios de 2.4 GHz
• Usabilitat: Sol·licitud AAA CLI
• RPC per a la configuració de Syslog

Seguretat: 

• Millores al portal captiu integrat
• Combinació d'autenticació múltiple d'anul·lació 802.1xw/AAA (assignació de Vlan dinàmica) i LWA (consentiment) al C9800
• Un atribut amb capacitat per a la ubicació als missatges de sol·licitud d'accés com a part de RFC5580
• Optimització C9800 del temps d'exclusió de clients amb WPA3 SAE

Connectivitat: 

• Malla: exploració de fons
• Zero Wait DFS: suport a C9136

Sostenibilitat:

• No es poden consultar els OID de CISCO-LWAPP-AP-MIB el 9800: la migració s'ha aturat
• OID SNMP - Fase 2

Topologia de xarxa

Prerequisits

Prova de configuració

Camins d'actualització
Amb el propòsit d'aquest programa EFT, Cisco recomana seguir la ruta d'actualització següent

• 17.3.6 -> 17.11.1 Imatge EFT (qualificada Cisco)
• 17.6.4 -> 17.11.1 Imatge EFT (qualificada Cisco)
• 17.10.1 -> 17.11.1 Imatge EFT (qualificada Cisco)

Nota: Si els clients tenen C9130 amb 17.3.x, per actualitzar amb èxit a 17.11, primer actualitzeu a 17.6.x.
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

Matriu de compatibilitat

Característiques a provar

C9800 Jumbo Frame Suport per a paquets Radius/AAA

Funció acabadaview:

En totes les versions de Polaris (fins a la data), per defecte, la fragmentació del paquet de radi es fa a 1396 bytes a la capa intermèdia. El que significa que la "configuració de la MTU IP de la interfície" no es respecta. Això condueix als problemes següents, com ara la mida de la fragmentació es soluciona i els marcs Jumbo no són compatibles. En afegir aquesta funció, es respectarà la configuració de la MTU IP de la interfície. La qual cosa cobriria tots els possibles casos d'ús dels clients amb un comportament coherent en els paquets RADIUS sortints. Amb el nou disseny, el paquet RADIUS es fragmenta al valor configurat de l'IP MTU de la interfície. L'usuari ha de configurar el valor IP MTU requerit a la configuració de la interfície i per utilitzar el valor IP MTU configurat per a la transacció RADIUS, l'usuari ha de configurar el nom de la interfície sota el grup RADIUS corresponent.

Requisit previ:

• Aquesta funció serà compatible amb totes les plataformes a partir de la versió 17.11.1. · El suport de paquets Jumbo està disponible a partir de la versió ISE 3.1

Configuració:

Configuració de la interfície: interfície sense switchport mtu 5000 -> configureu l'adreça IP de Max MTU Range xxxx xxxx ip mtu -> configurar l'IP MTU

Configuració del radi al controlador: grup aaa radi del servidor RADIUS_GROUP nom del servidor radius_server1 radius ip interfície font

Configuració ISE interfície ip mtu

Nota: Si es canvia l'IP MTU a ISE, espereu un reinici del servei de xarxa per a ISE.

Verificació

Captura de paquets en paquets Radius:

Millora en la direcció del client durant l'actualització de Rolling AP

Funció acabadaview:
Durant les actualitzacions de programari, l'actualització Rolling AP permet que hi hagi un temps d'inactivitat mínim de connectivitat de xarxa. Això es deu al fet que quan un AP es torna a carregar amb la nova imatge, els AP circumdants estaran a l'abast dels clients. Quan es selecciona un AP per tornar a carregar, els clients que hi estan connectats actualment han de desplaçar-se a un altre AP. Per fer-ho, l'AP ja no respondrà a les sol·licituds d'unió dels clients i enviarà marcs de gestió de transició BSS 802.11v a tots els clients que admetin 802.11v. Això els notificarà que l'AP es tornarà a carregar i es desplaçarà a un nou AP. Per als clients que no admeten 802.11v o que no fan itinerància, el controlador desautenticarà tots els clients connectats a l'AP.

Per obtenir més informació sobre l'actualització de Rolling AP, consulteu aquest enllaç:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-6/configguide/b_wl_17_6_cg/m_hitless_upgrade.html

Requisit previ:

• Controlador de LAN sense fil Cisco Catalyst 9800 amb IOS XE 17.11.1

Configuració i verificació:

• Per habilitar la direcció del client: C9800# conf t C9800(config)# ap actualització stagorientació del client engrescada
• Per desactivar la direcció del client: C9800# conf t C9800(config)# sense actualització d'aptagorientació del client engrescada
• Per configurar clients de desautenticació durant l'actualització abans que es torni a carregar l'AP: C9800# conf t C9800(config)# ap actualització staggered client-deauth
• Per configurar clients que no es desautentiquen durant l'actualització abans que es torni a carregar l'AP: C9800# conf t C9800(config)# sense actualització d'aptaggered client-deauth

Descàrrega eficient d'imatges AP mitjançant TCP

Funció acabadaview:
Abans d'IOS XE 17.11.1, la descàrrega de la imatge AP durant les actualitzacions de programari utilitzava el túnel de control CAPWAP. No obstant això, el túnel de control CAPWAP està sovint ocupat, ja que s'utilitza per a molts altres propòsits. A més, el temps de descàrrega de la imatge està limitat per la mida de la finestra CAPWAP. També hi ha una gran càrrega al C9800, ja que les descàrregues d'imatges AP fan que els processos WNCD utilitzen molt la CPU. Amb IOS XE 17.11.1, les descàrregues d'imatges AP es mouen fora del túnel de control CAPWAP i cap al pla de dades fora de banda, permetent que les descàrregues d'imatges es produeixin a través d'HTTPS. En moure el procés de descàrrega a HTTPS, la càrrega dels processos WNCd es redueix i allibera la ruta de control CAPWAP. A més, utilitzant HTTPS i TCP, les descàrregues d'imatges són més ràpides i flexibles, ja que es pot especificar el tipus d'enllaç i la velocitat. Si la descàrrega HTTPS falla, hi ha una alternativa perfecta al túnel de control CAPWAP. De manera predeterminada, l'actualització de la imatge aprofitarà el port 8443 per evitar l'impacte en el WebInterfície d'usuari i fluxos de telemetria al C9800. Això es pot canviar per adaptar-se al desplegament. El mecanisme per a la descàrrega d'imatges AP és el següent:

Requisit previ:

Configuració i verificació:

To habiliteu l'actualització d'AP per utilitzar HTTPS: C9800# conf t C9800(config)# ap mètode d'actualització https

Per configurar l'AP file port de transferència: C9800# conf t C9800(config)# ap file-transfereix el port https
Nota: Si no es configura, el C9800 utilitzarà el port 8443.

Per verificar que la descàrrega de la imatge AP utilitza HTTPS: C9800# mostra el mètode d'actualització de l'ap HTTPS: activat>

Per verificar que la descàrrega de la imatge AP utilitza HTTPS: C9800# mostrar ap file-transferir https resum

Per verificar que l'AP admet la descàrrega d'imatges mitjançant HTTPS: C9800# mostra el nom de l'ap SITE4-9120-1 config general | seg Actualització

Per verificar que la imatge AP es baixa a través d'HTTPS: C9800# mostra el nom de l'ap SITE4-9120-1 config general | s Actualitza l'AP Actualitza la capacitat fora de banda

Desactiva de manera intel·ligent les ràdios de 2.4 GHz

Funció acabadaview:

• FRA Tasca de ràdio flexible
• XOR Ràdios de doble banda
• RRM Gestió de recursos radiofònics

Per proporcionar una opció configurable per moure ràdios XOR de banda dual redundants a la xarxa només per supervisar la funció. Implementació actual d'IOS-XE, FRA trasllada ràdios redundants de banda dual (XOR 2.4 GHz/5 GHz) a la funció de servei de client de 5 GHz o a la funció de monitor. No hi ha més remei que seleccionar una opció concreta en funció del desplegament. Aquesta característica permetrà als clients configurar i triar segons els seus requisits. FRA només avalua la cobertura de 2.4 GHz i determina si la cobertura superposada està creant interferències. Si es detecta, la funció traslladarà la ràdio de banda dual (XOR 2.4/5GHz) a una funció de servei de client de 5GHz o de monitor. Segons la implementació actual, no hi ha cap opció per triar. Aquesta característica implementa una opció de configuració al RF pro de 2.4 GHzfile per seleccionar la ràdio per passar al mode només monitor. Com a part d'aquesta funció, el client tindrà una opció configurable per seleccionar les ràdios redundants de doble banda (XOR 2.4/5GHz) a la xarxa per funcionar en funció de monitor. Actualment, no hi ha cap opció per triar un FRA que traslladi les ràdios al servei de client de 5 GHz o al monitor. Amb aquesta opció, els clients poden triar en funció del seu desplegament.

Requisit previ:

• Controlador de LAN sense fil Cisco Catalyst 9800 amb IOS XE 17.11.1
• AP: C9115, C9120, C9130, C9136, CW9164, CW9166, CW9162

Configuració i verificació:

Per defecte-RF-Profile [Configuració global]:
wlc(config)#ap dot11 24ghz fra action ? monitor Configura l'acció FRA com a monitor

GHz RF-Profile
mdc-prod-wc2(config)#ap dot11 24ghz rf-profile madhu-rf-profile-24 mdc-prod-wc2(config-rf-profile)#fra action ? monitor Configura l'acció FRA com a monitor

WebConfiguració de la IU [1/2] Navega: Configuració > Configuració de la ràdio > RRM > FRA > Ràdio flexible de 2.4/5 GHz > Acció FRA

WebConfiguració de la IU [2/2] Navega: Configuració > Tags & Profiles > RF/Ràdio > Avançat > Acció FRA
Seleccioneu: Actualitza i aplica al dispositiu

Mostra ordres

mdc-prod-wc2#sh ap fra

• Estat de FRA: Habilitat
• Congelació FRA: Inhabilitat
• Estat d'operació FRA: Amunt
• Sensibilitat FRA: superior (85%)
• Interval FRA: 1 hora(s)
• Prioritat de servei: Cobertura
• Client Aware FRA: Habilitat
• Selecció del client: 25%
• Restabliment del client: 5%
• Acció de la FRA: 2.4 GHz/monitor
• Última tirada: Fa 3069 segons

Mostra la CLI [2/2]

mdc-prod-wc2#sh ap rf-profile <rf-profile nom> detall | sec FRA

• Client Aware FRA: Inhabilitat
• Acció de la FRA: 2.4 GHz/monitor

mdc-prod-wc2#sh nom ap AP7872.5DED.CB74 ranura de configuració 0 | sec Atributs d'atributs per a l'espai 0

• Tipus de ràdio: 802.11n - 2.4/5 GHz
• Mode de ràdio: Monitor
• Paper de ràdio: Monitor
• Mètode d'assignació: Automàtic
• Motiu del mode de monitor: Commutat automàticament per FRA

Usabilitat: sol·licitud AAA CLI

Funció acabadaview:
Per augmentar la llegibilitat de l'usuari a l'ordre show per al servidor AAA, s'introdueix una nova CLI "show aaa server brief" que mostrarà tots els detalls necessaris en format tabular. I la columna inclou la informació següent:

• Sol·licituds d'accés
• Accés-Acceptació
• Accés-Rebutja
• Temps d'espera d'accés
• Transaccions d'accés pendents
• Temps de funcionament
• Sol·licituds comptables
• Resposta comptable
• Temps d'espera comptable
• Transaccions comptables pendents
• Total de sol·licituds (autenticació+compte)
• Total de respostes (Auth+Act)

Requisit previ:
Controlador de LAN sense fil Cisco Catalyst 9800 amb IOS XE 17.11.1

Configuració i verificació:

Configuració:
No cal configuració.

Verificació:
mostra un resum del servidor aaa

RPC per a la configuració de Syslog

Funció acabadaview:
Aquesta millora de funcions proporciona suport yang RPC per a l'"enviament del registre" de la CLI de manera que puguin enviar el missatge de syslog al dispositiu. Bàsicament, IOS-XE exec CLI envia el registre, envia els registres especificats al servidor syslog. Ajuda a validar tant el servidor de syslog com el dispositiu per enviar i rebre syslogs, ara això es pot aconseguir mitjançant la interfície programable yang.

Requisit previ:
El controlador de LAN sense fil Cisco Catalyst 9800 que executa IOS XE 17.11.1 El suport Yang RPC d'aquest "registre d'enviament" de la CLI proporcionarà un mecanisme per enviar el missatge de syslog al dispositiu. Al seu torn, el dispositiu enviarà aquest missatge a un servidor Syslog configurat. Netconf-yang i restconf s'han de configurar al C9800 C9800#show running-config | en resta restconf C9800#mostra la configuració en execució | a net conf net conf-yang

Generalment, el "registre d'enviament" es configura des de la CLI, però a la 17.11 el podem enviar a través de la interfície programable tal com es mostra a continuació

No hi hauria d'haver cap missatge buit

A WLC veiem que el missatge està imprès al missatge de registre.

Les restriccions a les entrades són les següents:

• La cadena del missatge de registre ha d'estar en format de text senzill.
• No es permet un missatge de registre buit.
• Els caràcters especials es permeten als missatges de registre, mnemotècniques i instal·lacions.
• No es permet cap espai al nom de la instal·lació i als mnemotècnics, a diferència del missatge de registre.
• Hi ha 3 maneres d'introduir:
  1. Només el missatge de registre (en aquest cas el missatge de registre s'enviarà amb la gravetat, la facilitat i els mnemotècnics predeterminats).
  2. Gravetat juntament amb el missatge de registre (en aquest cas, el missatge de registre s'enviarà amb la instal·lació i els mnemotècnics predeterminats)
  3. Les 4 opcions registren missatges, gravetat, instal·lacions i mnemotècniques.
• A continuació es mostra la llista de valors per defecte:
  1. Severitat 7
  2. Instal·lació "SYS"
  3. Mnemotècniques "USERLOG_DEBUG"

Millores al portal captiu integrat

Funció acabadaview:
Els clients internacionals de diferents entitats legals han de complir totes les lleis locals. Un requisit legal que es fa més evident és la inclusió de les llengües locals en totes les operacions. Dins de les implementacions actuals d'IOS-XE, la secció de text del bàner del portal d'inici de sessió està limitada a uns 200 caràcters. A més, el programari no permet l'entrada de caràcters especials com ara "ö" o "à". Dins del 17.11.1, el límit d'entrada de la CLI del text del bàner es millorarà per acollir fins a 400 caràcters. A més, tant el text del bàner com les cadenes de títol del bàner que es mostren a la pàgina d'inici de sessió HTML ara seran capaços de suportar caràcters especials com ara "ö" o "à", etc. Com que el bàner multilínia és compatible mitjançant CLI, és possible configurar també a través de YANG. Si la cadena d'entrada proporcionada supera el límit màxim, es llançarà un missatge d'error indicant-ho i la configuració serà rebutjada. El WebEl bàner del portal d'inici de sessió d'auth consta de dues parts.

1. Títol de la pancarta Això es pot personalitzar mitjançant el títol del banner <> CLI sota web mapa de paràmetres d'autenticació. La cadena de títol predeterminada és "Benvingut al Cisco Web- Xarxa d'autenticació.
2. Text de la pancarta Això es pot personalitzar mitjançant el text del banner <> CLI sota web mapa de paràmetres d'autenticació. La cadena de text predeterminada és "Cisco està encantat de proporcionar web-Infraestructura d'autenticació per a la vostra xarxa. Si us plau inicieu sessió."

Limitacions:

1. No WebCompatibilitat d'IU per a aquesta funció.
2. L'analitzador té una limitació de 254 caràcters per línia (incloses les paraules clau de la CLI). Per tant, l'usuari haurà de tenir-ho en compte mentre proporciona l'entrada

Requisit previ:

• Controlador de LAN sense fil Cisco Catalyst 9800 amb IOS XE 17.11.1
• Els usuaris han de tenir coneixements de Local Web-Auth, text del bàner i títol del bàner.

Resolució de problemes:

A continuació es pot activar la depuració d'IOS per veure si hi ha hagut algun problema a la configuració del banner. depurar l'admissió d'ip tot Al costat de binos, podem habilitar wncd tots els registres detallats dels mòduls i recollir els rastres. Els registres interns de RA també es poden recollir per a la depuració relacionada amb el client. També s'han de recollir les sortides de les ordres següents. mostra el tipus de mapa de paràmetres webnom d'auth <> base de dades de programari de plataforma de prova get sm_exec_context/tbl_webauth_parammap;nom= sh plataforma programari procés base de dades wncd ch ac R0 detalls SM_CONFIG_DB "taula tbl_webcontingut auth_parammap”.

Combinació d'autenticació múltiple d'anul·lació 802.1xw/AAA (assignació de Vlan dinàmica) i LWA (consentiment) al C9800

Funció acabadaview:
En una configuració universitària, els clients s'autentiquen mitjançant 802.1X. Com a part de l'autenticació 802.1X, el servidor AAA impulsa les polítiques que s'aplicaran al client. La VLAN és un atribut que s'envia des del servidor AAA. Com que dot1x és segur i es produeix sense cap intervenció de l'usuari, els usuaris finals no són conscients de quina xarxa estan connectats. Això podria provocar problemes si els clients es connecten a la Wifi de la universitat i els usuaris publiquen publicacions inadequades o visiten llocs inadequats.
Per evitar aquest problema, la universitat s'ha configurat per WebAutenticació d'autenticació post 802.1X. Web- El consentiment s'utilitza com a part WebAutoritat per informar els usuaris finals que estan connectats a la Wifi de la Universitat. Tanmateix, com a part de Web-Consentiment, ja que, no s'aplica cap política AAA, s'elimina la política AAA aplicada anteriorment. Això provoca un canvi de VLAN i condueix a la desconnexió del client. Aquest cicle continua i el client no té accés a la xarxa.
Per solucionar aquest problema, s'introdueix la CLI. Si es configura aquesta CLI, la política aplicada mitjançant el consentiment es combinaria amb la política aplicada per a 802.1X/MAB.

Requisit previ:

• Controlador de LAN sense fil Cisco Catalyst 9800 amb IOS XE 17.11.1
• Els usuaris han de tenir coneixements sobre conceptes d'autenticació múltiple, LWA (consentiment), anul·lació d'AAA.

Habilitació de la funció des de la CLI: Dispositiu # configurar el terminal Tipus de dispositiu (config) #paràmetre-mapa web auth LWA_consent Dispositiu(config-params-parameter-map)#type consent Dispositiu(config-params-parameter-map)#consent activation-mode merge
Desactivació de la funció de la CLI: Dispositiu # configurar el terminal Tipus de dispositiu (config) #paràmetre-mapa web auth LWA_consent Dispositiu(config-params-parameter-map)#no consentiment combinació en mode d'activació

Mostra l'ordre amb la funció activada des de la CLI: JD_9800-L_1#sh tipus de mapa de paràmetres web nom d'auth LWA_consent

• Nom del mapa de paràmetres: LWA_consentiment
• Títol del bàner: Títol del consentiment
• Text del bàner: accepteu el consentiment
• Tipus: consentiment
• Temps de l'estat d'inici d'auth-proxy: 300 segons
• WebAuth max-http connexió: 200
• Webauth logout-window: activat
• Webauth success-window: activat
• Correu electrònic de consentiment: desactivat
• Mode d'activació:
• Dorment-Client: Fusionar
• Webauth login-auth-bypass: desactivat

la política aplicada mitjançant el consentiment es combinaria amb la política aplicada per a 802.1X/MAB.

Mostra l'ordre amb la funció desactivada des de la CLI:|
JD_9800-L_1#sh tipus de mapa de paràmetres webnom d'auth LWA_consent

• Nom del mapa de paràmetres: LWA_consent
• Correu electrònic de consentiment: desactivat
• Mode d'activació: substituir

la política aplicada mitjançant el consentiment no es combinaria amb la política aplicada per a 802.1X/MAB.

Limitacions:

• No WebCompatibilitat d'IU per a aquesta funció.
• Sense suport SNMP. Només s'afegiria suport Yang per a aquesta funció.
• Quan la "fusió en mode d'activació" no està configurada al fitxer WebMapa de paràmetres d'autenticació, aleshores el mode d'activació predeterminat és REPLACE-ALL. Això vol dir que user-profile per consentiment substituiria tots els user-pro aplicats anteriormentfile polítiques.

Atribut localitzat als missatges de sol·licitud d'accés com a part de la funció RFC5580 Overview:
Els atributs d'ubicació RFC 5580 transmeten informació relacionada amb la ubicació per a l'autenticació i els intercanvis comptables. La informació d'ubicació és útil en diversos escenaris. Les xarxes sense fil es despleguen en llocs públics, com ara centres comercials, aeroports, hotels i cafeteries per un conjunt divers d'operadors, com ara proveïdors de serveis d'Internet sense fil (WISP), operadors de xarxes cel·lulars i xarxes de banda ampla fixa. En tots aquests escenaris, és possible que la xarxa necessiti conèixer la ubicació de l'usuari per habilitar l'autorització, la facturació o els serveis conscients de la ubicació. Consulteu la guia de configuració d'IOS-XE 17.9 per configurar els atributs d'ubicació RFC 5508 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

La RFC 5580 esmenta tres mètodes de lliurament d'ubicació per a la informació d'ubicació al servidor AAA, tal com s'esmenta a continuació:

1. Lliurament d'ubicació basat en un acord fora de banda
2. Lliurament de la ubicació segons la sol·licitud inicial
3. Lliurament de la ubicació segons la sol·licitud de mitja sessió

A la versió 17.11 d'IOS-XE, estem millorant aquesta característica afegint l'atribut capaç de localitzar a la sol·licitud d'accés a l'acord fora de banda.

Requisit previ:

1. Controlador de LAN sense fil Cisco Catalyst 9800 amb IOS XE 17.11.1
2. Els usuaris han de tenir coneixements d'AAA i 802.1x

Configuració i verificació:
L'atribut Capacitat per a la ubicació s'envia com a part de les sol·licituds d'accés només en el cas del mètode 2 (entrega d'ubicació basada en la sol·licitud inicial), que es basa en la sol·licitud inicial, però estem proporcionant el suport per a aquest atribut fora de banda, que is (Enviament d'ubicació basat en un acord fora de banda) Per habilitar aquest atribut, cal configurar la següent comanda al C9800. Actualment, només s'admet des de la CLI C9800(config)#radius-server atribut lliurament d'ubicació sense fils fora de banda, compatible amb la ubicació

Optimització C9800 del temps d'exclusió de clients amb WPA3 SAE Feature Overview:
El mecanisme d'exclusió de clients SAE està dissenyat per protegir el sistema de l'ús de recursos computacionals en processar sol·licituds d'autenticació no vàlides d'usuaris maliciosos. Si un client falla l'autenticació SAE diverses vegades (fins a 5), ​​el C9800 exclourà el client durant un període d'exclusió (per defecte 60 segons). Durant aquest temps d'exclusió, totes les sol·licituds d'autenticació d'aquest client s'eliminen. En el mode local, l'autenticació SAE es processa a WLC, que compta el nombre d'errors d'autenticació i afegeix el client a la llista d'exclusió quan el recompte arriba a un llindar predefinit. Es permetrà que el client torni a connectar-se després del temps d'exclusió. El valor del temps d'espera es pot configurar per permetre flexibilitat a l'hora d'aplicar l'exclusió del client. Abans de l'IOS XE 17.11.1, la implementació d'exclusió SAE inicia el procés d'exclusió en el moment de la neteja del client després d'un error d'autenticació. Es necessiten un parell d'intercanvis de missatges més entre el C9800 i el client per arribar a l'estat de neteja. Com que el client pot retrocedir abans d'enviar el següent missatge, SAE es compromet, després d'un error d'autenticació, el laps de temps varia entre l'error i l'inici de l'exclusió. Podem optimitzar el flux iniciant el procés d'exclusió just en el moment de l'error d'autenticació (confirmació de la manca de coincidència del missatge SAE). Això evita el retard i exclou el client abans.

Requisit previ:

• Controlador de LAN sense fil Cisco Catalyst 9800 amb IOS XE 17.11.1 · Aquesta característica només és per a desplegaments en mode local.

Configuració i verificació:
L'optimització per a l'exclusió del client WPA3 SAE té lloc en segon pla i no cal fer cap configuració addicional.
Per verificar les exclusions de clients:

• C9800# mostra la llista d'exclusió sense fil
• detall de l'adreça mac del client f2f8.4a03.a0e8
• Estat del client: exclòs
• Adreça MAC del client: f2f8.4a03.a0e8
• Adreça IPv4 del client: N/A
• Adreça IPv6 del client: N/A
• Nom d'usuari del client: N/A
• Motiu d'exclusió: error d'autenticació SAE
• Mètode d'autenticació: cap
• Protocol: N/A
• Adreça MAC AP: 0c75.bdb1.3f20
• Nom AP: AP0C75.BDB1.EDA8
• Ranura AP: 0
• Identificació de la LAN sense fil: 7
• Nom de la LAN sense fil:
• Identificador de VLAN: 0

 Malla: S'ha acabat la funció d'escaneig de fonsview:
Els punts d'accés de Cisco Mesh (MAP) estan interconnectats mitjançant enllaços sense fil en un arbre que abasta com una topologia. Un MAP connectat a la xarxa mitjançant un enllaç ascendent Ethernet es designa com a MAP arrel també conegut com RAP. El protocol AWPP s'utilitza per mantenir l'arbre i formar l'arbre. Quan apareix un MAP, intenta buscar un altre MAP (pare) per unir-se per arribar a la passarel·la eventualment mitjançant un RAP. El mateix passa quan un MAP perd la connectivitat amb el seu pare existent. Aquest procediment es coneix com a convergència d'arbre de malla. Aquest document pretén millorar el procediment de convergència perquè sigui més ràpid i robust. Un MAP a la recerca del seu enllaç ascendent principal se sotmet als procediments següents:

1. Detecció de pèrdua de pares (si ja està connectat)
2. Escaneja (passiu) per trobar un nou progenitor a tots/subconjunts de canals de domini regulador
3. Busqueu (sol·licitud/resposta) al pare nou trobat als canals escanejats/operables
4. Avaluar i triar el millor veí
5. Seleccioneu el veí com a pare potencial i autenticeu-vos a WLC mitjançant el pare seleccionat
6. Retenir/Renovar IP i
7. Reinicieu CAPWAP per tornar a unir-vos al WLC

Aquest procediment avui podria trigar des de desenes de segons fins a un minut. Tenim previst implementar el següent per millorar-lo: L'exploració de fons de malla i la selecció automàtica dels pares són mecanismes que utilitza un MAP per trobar i connectar-se més ràpidament amb un millor pare potencial a través dels canals i mantenir sempre el seu enllaç ascendent amb un millor pare.

Requisit previ:
C9800 funcionant a la darrera imatge EFT IOS-XE amb xarxa Mesh en funcionament.

Topologia:

Configuració i verificació:
Per activar l'exploració en segon pla: a Mesh Profile (professional sense filfile mesh default-mesh-profile), habiliteu l'exploració de fons (escaneig de fons)
Verificació: Comproveu l'exploració en segon pla a Show Wireless Profile malla detalladafile

Configurar: C9800-CL-AWS(config)#wireless profile mallafile_nom> C9800-CL-AWS(config-wireless-mesh-profile)#escaneig de fons

Verificar: C9800-CL-AWS#show wireless profile malla detalladafile_nom>

• Mesh Profile Nom: <profile_nom>
• Descripció: malla personalitzada profile
• Nom del grup del pont: nom_bgn_personalitzat
• Exploració de fons: HABILITAT

1. Habiliteu l'exploració en segon pla i verifiqueu que la funcionalitat funciona com s'esperava a C9124 MAP.
   1. Habiliteu l'exploració en segon pla i verifiqueu que la funcionalitat funciona com s'esperava a C9124 MAP.
   2. Verifiqueu que la xarxa de malla estigui activada i que funcioni de manera estable.
   3. Activa l'exploració en segon pla.
   4. Al MAP C9124, verifiqueu que la funció està habilitada i funciona.
      Ús:
      • mostrar estadístiques de malla
      • Mostra l'historial de malla recent
      • Mostra tot l'adjacència de la malla
      • Mostra la convergència de la malla
      • mostrar res de malla
      • Mostra les bosses de malla poden configurar el backhaul
      • Mostra les bosses de malla poden configurar la ranura 1
      • Mostra les bosses de malla poden canalitzar el backhaul
      • Mostra les bosses de malla canals de la ranura 1
      • Mostra les bosses de malla poden ser el retorn de l'estat
      • Mostra les bosses de malla poden ser la ranura 1
      • Mostra les bosses de malla poden programar el retorn
      • Mostra les bosses de malla poden programar la ranura 1
   5. Verifiqueu que MAP UT conegui la llista completa de canals en què operen els iguals de malla del mateix BNG, és a dir, que està rebent informació completa durant el subministrament de RES.
   6. Verifiqueu que MAP UT sigui capaç d'establir adjacències completes amb els veïns de ràdio que pertanyen al mateix BGN.
   7. Verifiqueu que MAP UT no crearà adjacències amb veïns de ràdio que no siguin membres del mateix BGN
2. Verifiqueu l'impacte en el trànsit del client quan l'exploració en segon pla estigui habilitada al C9124
   1. C9124 MAP funciona en un canal de retorn de 5 GHz.
   2. Els clients sense fil estan connectats al client de 2.4 GHz que serveix ràdio i genera trànsit constant.
   3. Activa l'exploració en segon pla.
   4. Comproveu que l'exploració en segon pla no té cap impacte en el trànsit del client.

Zero Wait DFS: suport a la funció C9136 acabadaview:

• Les bandes U-Nii-2 i U-Nii-2C(e) també conegudes com a "Canals DFS" (assignació de freqüència dinàmica) requereixen una verificació de disponibilitat del canal (CAC) de 60 segons (o més) abans de ser utilitzades per Wi-Fi per garantir que no hi hagi cap radar en funcionament.
• Zero Wait DFS permet utilitzar els recursos de l'AP per realitzar un CAC preventiu abans que s'iniciï un canvi de canal, eliminant el retard de 60-600 segons experimentat en un canvi de canal a qualsevol canal DFS.

Abans de la versió 17.8 d'IOS-XE, DFS CAC s'havia realitzat sota demanda com a precursor d'assumir operacions WiFi en un canal. Aquest comportament és necessari per comprovar que no hi ha cap radar operatiu al canal que assumirem. Un cop accedit, l'exploració ha de continuar durant el funcionament del canal i s'ha d'abandonar immediatament si es detecta radar. Quan RRM assigna un canal, assigna el "millor" canal disponible a l'execució DCA actual. També hi ha un segon millor canal assignat en el moment que s'etiqueta com a canal futur. En el cas d'una detecció de radar al canal DFS actual, el canal futur s'escanejaria i després s'utilitzaria. Aquesta tirada "Mini DCA" va assegurar que el canal de successió ja era una bona opció segons les adjacències del canal. Si aquest canal futur fos un canal requerit per DFS, l'AP escanejaria 60 segons (o 600 segons si els canals ETSI TDWR 120, 124, 128) i després assumiria la balisa al nou canal. La funció Zero Wait DFS es va introduir originalment a IOS-XE 17.9 per a ETSI i FCC Catalyst C9130 AP. La versió IOS-XE 17.11 afegeix suport per als AP Catalyst C9136. Zero Wait DFS depèn en gran mesura de les regles dels organismes reguladors locals i, per tant, hi ha diferències en els mètodes utilitzats, però una diferència mínima amb els resultats experimentats.

Normativa ETSI:
Es recolza el concepte de Pre-CAC. A ETSI, una vegada que un canal ha estat esborrat pel CAC, es pot considerar esborrat per l'AP i s'utilitza sense CAC addicional indefinidament fins que es reinicia l'AP.

• Això permet que l'AP escanegi tants o pocs canals com vulguem tenir per a un ús futur
• Si AP necessita utilitzar un canal futur, pot fer-ho sense realitzar CAC
• Si es detecta radar al canal de servei, AP pot passar a un canal pre-CAC i emetre immediatament.

Aquesta funció elimina efectivament la penalització de 10 minuts (600 segons) per utilitzar un canal TDWR (120,124,128) a ETSI.

Normativa FCC:
L'enfocament de la FCC difereix perquè no hi ha disposicions per a Pre-CAC. A FCC, un canal només és vàlid mentre un receptor l'escolti i proporcioni dades CAC. Aquesta regla significa que encara podem CAC una futura elecció de canal, però s'ha de fer CAC contínuament si volem assumir que està lliure de radar i començar les operacions immediates. DCA ja calcula el "segon millor" canal en qualsevol assignació de canal a partir del moment de l'execució de DCA. Amb el segon millor canal tenim un canal vàlid, encara que una mica menys òptim, ja seleccionat que no entrarà en conflicte amb la resta d'AP que s'utilitzaran en cas de detecció de radar. Aquest canal pot ser contínuament CAC'd i d'aquesta manera mantenir la preparació per a operacions immediates per part de l'AP en qualsevol moment. Els chipsets de ràdio Catalyst C9130 i C9136 tenen 3 motors d'escaneig DFS. L'execució en mode Tri-Radio exigirà que dos d'aquests motors estiguin activats si s'assignen dos canals DFS. Tanmateix, el tercer no s'utilitza i es pot dedicar a escanejar els futurs canals.

• Això permet a l'AP escanejar contínuament un canal futur (determinat per DCA)
• Si AP necessita utilitzar un canal futur, pot fer-ho sense realitzar CAC
• Si es detecta radar al canal de servei, AP pot passar al futur canal i emetre immediatament.

NOTA: El futur CAC del canal es realitza contínuament sense impacte en les operacions de servei de ràdio per a un impacte zero en el client.

Consideracions de 5 GHz duals:
Pre-CAC cobreix tots els canals i escenaris per a la regió ETSI. Rolling CAC per a FCC presenta un parell d'escenaris possibles. A FCC podem CAC contínuament només un canal futur. Si les dues interfícies de 5 GHz tenen canals DFS assignats, només una pot tenir un canal futur totalment CAC i preparat. En el cas que tinguem dues interfícies amb canals DFS assignats, el segon millor canal per a cadascun encara ha de mantenir una separació de 100 MHz del canal d'altres interfícies en tot moment. En molts casos, això acabarà en una banda diferent tots junts. En els casos en què els dos canals de Future també siguin DFS, la interfície amb el nombre més gran de clients tindrà la prioritat per a l'execució de CAC. Si l'altra interfície detecta radar, el seu canvi de canal haurà de realitzar un CAC normal (60 segons) abans d'assumir les operacions.
Requisit previ:

1. C9136I o C9130 -B o -E AP
2. Controlador C9800 que executa el codi EFT 17.11.1
3. Accés a la consola al controlador

Provar aquesta funció és senzill. Tots els estats es poden mostrar actualment a les ordres show CLI. La configuració es pot aconseguir a nivells de GUI o CLI.

Configuració i verificació:
Zero Wait DFS es pot habilitar a nivell global per a tots els AP al WLC o mitjançant un RF Profile per gestionar un subconjunt d'AP. No hi ha opcions de configuració per a aquesta funció.

Per habilitar Zero Wait DFS a la GUI: A la GUI del controlador: seleccioneu Configuració=>RRM=>5 GHz Band=> DCA i trieu l'opció Zero Wait DFS, marqueu la casella per activar-la a nivell global.

Per activar Globalment des de la CLI: C9800-L_17_11(config)#AP dot11 canal rrm de 5 GHz zero-wait-dfs

Per desactivar, utilitzeu l'ordre no: C9800-L_17_11(config)#no AP dot11 canal rrm de 5 GHz zero-waitdfs

En tots els casos, per verificar que la funció està habilitada globalment, utilitzeu l'ordre show següent per determinar l'estat global actual de Zero Wait DFS:
C9800-L_17_11#sh ap dot11 canal de 5 GHz | i Zero

• DFS d'espera zero: Habilitat

NOTA: L'habilitació de Zero Wait DFS només afectarà els AP en què és compatible, actualment només els AP Catalyst C9130AX. Altres AP que no són compatibles no es veuran afectats per l'opció de configuració.

Habiliteu Zero Wait DFS de manera selectiva mitjançant un RF Profile:
Zero Wait DFS també es pot aplicar selectivament mitjançant un RF -Profile permetent la selecció granular d'un subconjunt d'AP als quals s'aplicarà aquesta configuració.
No hi ha cap requisit previ per habilitar a nivell global:
Des de la GUI, navegueu des del menú principal a: Configuració => Tags & Profiles => RF/Ràdio Seleccioneu RF Pro de 5 GHzfile per modificar-ne o crear-ne un de nou i seleccioneu RRM/DCA i marqueu la casella Zero Wait DFS.

Per habilitar Zero Wait DFS en un RF Profile de la CLI:

• C9800-L_17_11(config)#ap dot11 5ghz rf-profile <profile nom>
• C9800-L_17_11(config-rf-profile)#canal zero-wait-dfs
• C9800-L_17_11(config-rf-profile)#cap canal zero-wait-dfs

Per verificar l'estat de Zero Wait DFS per a un AP individual, utilitzeu les ordres show següents:

C9800-L_17_11#sh nom ap C9130i_9f.6e.a0 ranura de configuració 1 | s Zero

• Paràmetres DFS d'espera zero
  • Capable DFS d'espera zero: Sí
  • Domini CAC: FCC
  • Zero Wait DFS activat: activat
  • Llista d'inclusió de canals DFS: 60,64,104
• Llista d'exclusió de canals DFS: 52,56,100,108,112,116,120,124,128,132,136,140,144
• Estat pre-CAC: NA (això és FCC, de manera que no hi ha cap capacitat pre-CAC)
• Estat CAC del canal reservat: en curs (indica que s'està executant l'exploració fora del canal)
• Canal reservat: 108
• Amplada del canal reservat: 40 m

L'Exampel de dalt és per a un AP de la FCC. A continuació hi ha l'example per a ETSI

AIRV_VWLC2#sh ap nom AP1416.9D28.0CC4 ranura de configuració 1 | s Zero

• Paràmetres DFS d'espera zero
  • Capable DFS d'espera zero: Sí
  • Domini CAC: ETSI
  • Zero Wait DFS activat: activat
  • Llista d'inclusió de canals DFS: 52,132
  • Llista d'exclusió de canals DFS: 56,60,64,100,104,108,112,116,136,140
  • Estat pre-CAC: En curs (ETSI
• Pre-CAC, corrent)
  • Estat CAC del canal reservat: En curs (indica que s'està executant l'exploració fora del canal)
  • Canal reservat: 100
  • Amplada de canal reservada: 20 MHz

Casos de prova:

Per provar Zero Wait DFS, seguiu els passos següents.

Nota: És important que coincideixi amb la configuració suggerida, ja que l'ordre del radar de prova de l'AP només funciona en un canal de 20 MHz, el fet d'utilitzar-ho contra un AP amb canals més amplis pot obtenir resultats impredictibles.

Per provar FCC o ETSI

1. 1. Configura l'AP per a una única ranura de 5 GHz. Desactiveu el mode de tres bandes (funcioneu com a 8×8) o desactiveu la ràdio de la ranura 2.
2. 2. Assegureu-vos que Zero Wait DFS està configurat i que s'ha seleccionat un canal de reserva
   1. C9800-L_17_11#sh ap nom ranura de configuració 1 | s Zero Zero Wait Paràmetres DFS
      • Domini CAC compatible amb DFS d'espera zero: Sí: FCC
      • Zero Wait DFS activat: activat
      • Llista d'inclusió de canals DFS Llista d'exclusió de canals DFS: 52,60: 56,64,100,104,108,112,116,120,124,128,132,136,140,144
      • Estat pre-CAC Canal reservat Estat CAC: NA : Complet
      • Canal reservat Amplada del canal reservat: 60 : 20 MHz
3. 3. A l'AP CLI, executeu l'ordre Test Spectrum Radar prova del senyal de radar d'espectre dot11Radio 1 de freqüència central ample de banda 20 La freqüència central de l'assignació de canal de 20 MHz s'ha d'introduir en MHz. per al canal 52, aquest valor és de 5260 MHz, l'amplada de banda del canal s'hauria d'establir en 20 MHz.
4. 4. Un cop activat el senyal de radar, l'AP hauria de reprendre les operacions al canal de "reserva" immediatament, sense el retard habitual de CAC de 60 segons.
   1. C9800-L_17_11#sh nom ap C9130i_9f.6e.a0 ranura de configuració 1 | s Zero
      1. Paràmetres DFS d'espera zero Domini CAC compatible amb DFS d'espera zero: Sí : FCC
      2. Zero Wait DFS activat: activat
      3. Llista d'inclusió de canals DFS: 60 Nou
   2. Canal operatiu l'antic canal de reserva
      1. Llista d'exclusió de canals DFS: 52,56,64,100,104,108,112,116,120,124,128,132,136,140,144
      2. Estat pre-CAC: NA
      3. Estat CAC del canal reservat: En
   3. Progress CAC està en curs per al nou canal de reserva
      1. Canal reservat: 56
   4. El canal 56 serà el nou canal de reserva
      1. Amplada de canal reservada: 20 MHz

No es poden consultar els OID de CISCO-LWAPP-AP-MIB a 9800. La migració s'ha aturat.view:
Aquesta és una funció de paritat d'AireOS. Falten pocs OID AP MIB als WLC C9800. Aquesta característica és per afegir suport als OID que falten.

Requisit previ:
No cal cap requisit previ específic. SNMP hauria d'estar habilitat al C9800.

Configuració i verificació:

1. Obriu un C9800 amb la darrera imatge EFT validada proporcionada mitjançant el programa EFT.
2. Connecteu un punt d'accés a aquest C9800
3. Creeu una WLAN i connecteu un client a aquesta WLAN
4. Configurar les comunitats SNMP (lectura/escriptura)
5. Assegureu-vos que el C9800 respon a les consultes SNMP
6. Valideu els darrers OID introduïts següents (caminar/obtenir/obtenir el següent/establir)
   1. cLApSlotWlanStats
   2. cLApRadioWlanInfoEntry
   3. cLApActiveClientCount
   4. cLApAssociatedClientCount
   5. cLApMemoryCurrentUsage
   6. cLApMemoryAverageUsage
   7. cLApCpuCurrentUsage
   8. cLApCpuAverageUsage
   9. cLApGlobalAPConnectCount
   10. clsSysApConnectCount
   11. cLApWlanStatsAssocClientNum
   12. cLApWlanStatsOnlineUserNum

OID SNMP: s'ha acabat la funció de la fase 2view:
Aquesta característica és per atendre les sol·licituds dels clients per donar suport a poques variables SNMP que són útils per a desplegaments de 9800.

A continuació es mostren les noves incorporacions d'OID:

• bsnDot11EssNumberOfMobileStations
• bsnDot11EssNumApsUp
• bsnDot11EssNumApsDown
• bsnAPOperationStatus
• CLApUpTime
• bsnGlobalDot11SystemMobileStations
• cLApGlobalAPConnectCount

Requisit previ:

• Controlador de LAN sense fil Cisco Catalyst 9800 amb IOS XE 17.11.1
• El gestor SNMP hauria d'estar habilitat
• S'ha de configurar la comunitat SNMP privada o pública

Configuració i verificació:
Comenceu per verificar si el gestor SNMP està habilitat i si s'afegeixen comunitats al controlador Cisco Catalyst 9800.

• sri-dao#sh corre | i
• snmp snmp-server group v3_ro_users v3 priv read preview
• snmp-server group v3_rw_users v3 priv write preview
• servidor snmp view preview està inclòs
• RO pública de la comunitat snmp-server
• RW privat de la comunitat snmp-server
• prova RW de la comunitat del servidor snmp
• snmp-server trap-source Vlan8
• mida del paquet del servidor snmp 5000
• snmp-server habilitat trampes
• Enllaç d'autenticació snmp, enllaç avall, inici calent d'inici en fred
• snmp-server permet trampes wireless_mobility
• snmp-server habilitat trampes config
• snmp-server activa trampes rf
• snmp-server host 10.104.174.58 públic
• Amfitrió del servidor SNMP 9.2.14.175 públic
• Amfitrió del servidor SNMP 9.5.11.19 públic
• Gestor del servidor SNMP
  • camp phy_ ht_cfg.cfg_data. snmp_freq_string
  • camp radio_oper_data.phy_ht_cfg.cfg_data. snmp_freq_string
  • camp radio_oper_data.phy_ht_cfg.cf8_data. snmp_freq_string

Verificació de l'OID al controlador Cisco Catalyst 9800:
Utilitzeu aquestes ordres a 9800 CLI

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