Guía de solución de problemas para problemas de interoperabilidad de clientes inalámbricos con CUWN
Contenido
Introducción
Este documento describe detalladamente qué información debe recopilarse inicialmente para investigar y resolver de forma eficaz estos problemas de interoperabilidad inalámbrica cuando surjan con la solución Unified Wireless Network (CUWN) de Cisco. La necesidad de este enfoque integral cobra cada vez más importancia con el crecimiento constante del número y las combinaciones de dispositivos cliente inalámbricos y radios de punto de acceso (AP).
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- Puntos de acceso inalámbricos de Cisco
- Controladores de LAN inalámbrica (WLC)
- Dispositivos de red relacionados
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Antecedentes
Puede ser común encontrar que dados los diversos dispositivos cliente que existen y que siguen siendo desarrollados. Pueden surgir varios problemas con respecto a establecer, mantener o simplemente sacar el máximo partido de su conexión a la red inalámbrica y a la infraestructura de soporte.
A menudo, esto puede derivar en un simple problema de configuración por parte del dispositivo cliente y/o de la propia infraestructura inalámbrica. Sin embargo, en algunos casos esto puede atribuirse a un problema de interoperabilidad con respecto a un dispositivo cliente específico y los componentes que lo soportan (es decir, suplicante, adaptador WLAN, controlador inalámbrico, etc.), y/o los AP en cuestión. Como ingenieros de tecnología inalámbrica, estos problemas de interoperabilidad suponen una oportunidad para identificar, solucionar y resolver los problemas que puedan llegar a ser complejos.
Podría solicitarse información adicional sobre lo que se describe en este artículo, que debería recopilarse caso por caso, dado el número ilimitado de variables que podrían dictar tales requisitos. Sin embargo, la información detallada aquí es una guía genérica para abordar cualquier posible problema de interoperabilidad del cliente inalámbrico.
Yo. Definición del problema
El primer paso para abordar eficazmente cualquier problema con la intención de ser resueltos es definir con precisión la cuestión que se examina. Para ello, asegúrese de que, como mínimo, se formulan estas preguntas y de que sus respuestas están claramente documentadas:
- ¿Se limita el problema a un modelo específico de AP y/o tipo de radio (es decir, 2,4 GHz frente a 5 GHz)?
- ¿Se observa el problema solamente en versiones específicas del software WLC?
- ¿Se experimenta el problema solo con versiones específicas de tipos de cliente y/o software (es decir, versión de sistema operativo, versión de controlador WLAN, etc.)?
- ¿Hay otros dispositivos inalámbricos que no experimenten este problema? En caso afirmativo, ¿cuáles son?
- ¿Se puede reproducir el problema mientras el cliente está conectado a una configuración inalámbrica simplificada como un SSID abierto, con una anchura de canal de 20 MHz y 802.11ac desactivados? (es decir, ¿el problema ocurre sólo en el modo 802.11n frente al modo 802.11ac?).
- Si el problema no se puede reproducir con un SSID abierto, ¿en qué configuración de seguridad mínima se ve el problema? (es decir, PSK o 802.1X en la WLAN).
- ¿Cuáles fueron las versiones de software y configuración en funcionamiento anteriores?
II. Configuración de WLC y registros generales
Run-Config
Sin excepción, es absolutamente necesario recopilar la configuración del WLC del cliente para una revisión detallada de las funciones usadas por el cliente, su configuración específica y otros detalles de ese tipo. Para hacerlo, debe establecer una sesión Telnet/SSH en los WLC en cuestión y guardar el resultado de estos comandos CLI en un archivo de texto:
config paging disable show run-config
Siempre se prefiere el resultado completo de run-config, ya que incluye información detallada con respecto a los APs unidos y la información de RF asociada, etc. Aunque en algunos casos y situaciones, como cuando usted trabaja inicialmente con un WLC con un gran número de APs unidos (es decir, 8510 WLC con 2500+ APs). Se podría preferir recopilar inicialmente sólo la configuración del WLC sin esa información de AP para una revisión rápida, ya que el show run-config completo podría tardar 30 minutos o más en completar el número dado de APs. Sin embargo, todavía podría ser necesario recopilar el resultado completo de run-config más adelante.
Para ello, puede recopilar opcionalmente el resultado de estos comandos CLI en un archivo de texto:
config paging disable show run-config no-ap show wlan apgroups
Archivo de configuración WLC
Además de la salida show run-config o show run-config no-ap, también se recomienda recolectar una copia de seguridad completa de la configuración del WLC. Esto es de ayuda, si es necesario que TAC/HTTS y BU Escalation lleven a cabo una recreación de laboratorio, para intentar reproducir el problema del cliente en un entorno de laboratorio de Cisco. Una copia de seguridad del WLC se puede recolectar a través de la GUI o la CLI del WLC en cuestión, con el uso de TFTP o FTP para guardar el archivo de configuración en el servidor TFTP/FTP externo. El siguiente ejemplo muestra el uso de la GUI y la CLI para guardar una copia de seguridad del WLC, con el uso de TFTP:
GUI
Comandos > Cargar archivo > Configuración > Cargar como se muestra en la imagen.
CLI
transfer upload datatype config
transfer upload mode tftp transfer upload serverip <TFTP-Server_IP-address> transfer upload path / transfer upload filename <desired-filename> transfer upload start
Syslogs desde el WLC
En este momento, también desea recopilar los registros actuales del WLC para una revisión adicional según sea necesario. Lo ideal es que desee recopilar estos registros inmediatamente después de la prueba con un cliente inalámbrico donde se reproduzca el problema notificado. Si el cliente exporta los registros del WLC a un servidor syslog externo, entonces usted quiere recuperarlos de ahí. De lo contrario, puede guardar el msglog y traplog almacenados actualmente localmente en el WLC guardando este resultado de sesión CLI en otro archivo de texto:
config paging disable show msglog show traplog
III. Información y detalles del dispositivo cliente
El siguiente paso consiste en recopilar toda la información y los datos específicos relativos a los dispositivos cliente en uso que experimenten un posible problema de interoperabilidad inalámbrica. Esa información debería incluir, entre otras cosas, las siguientes:
- Tipo de cliente (es decir, tablet, smartphone, ordenador portátil, etc.)
- Modelo y creación de dispositivos
- versión de SO
- modelo de adaptador WLAN
- versión del controlador del adaptador WLAN
- Suplicante utilizado (es decir, Windows Zero Config / Auto Config, Intel PROSet, etc.)
- Seguridad configurada para su uso por el cliente inalámbrico y WLAN (es decir, Open, PSK, EAP-PEAP/MSCHAPv2, etc.)
- Tenga en cuenta los parámetros de cliente que se han cambiado de la configuración predeterminada proporcionada por el proveedor en cuestión (es decir, estado de suspensión, parámetros de itinerancia, U-APSD, etc.).
IV. Topología de red
Para agilizar aún más los esfuerzos de resolución de problemas y el proceso de análisis de causa raíz (RCA), siempre se recomienda proporcionar un diagrama de topología de red detallado y completo. El diagrama de topología de red no sólo debe incluir detalles sobre la red y la infraestructura inalámbrica, sino que también debe proporcionar una perspectiva de los dispositivos inalámbricos en cuestión que funcionan dentro de la red (es decir, impresoras/escáneres, las VLAN de cliente que se utilizan, etc.) y de sus ubicaciones en relación entre sí.
Se pueden utilizar varias herramientas (por ejemplo, Microsoft Visio, Draw.io, etc.) y una variedad de estilos para crear un diagrama de red de este tipo. El aspecto importante consiste simplemente en garantizar que la información adecuada se refleje claramente en el diagrama que se presenta para que lo examinen todas las partes y proveedores interesados. Topología de red de ejemplo que captura información básica pero útil con respecto a la infraestructura y los dispositivos cliente, como se muestra en la imagen.
V. Seguimiento de los detalles adicionales y los detalles
Para ayudar a garantizar que la información adecuada se recopile en el momento de cualquier prueba con los dispositivos cliente con los que los usuarios finales experimentan problemas. Se recomienda crear de forma preventiva una hoja de cálculo o similar para registrar todos los problemas del cliente y los detalles relacionados observados en el momento de la prueba, como este ejemplo:
| Dirección MAC | Nombre de usuario | Descripción del síntoma notificado | Tiempo que el usuario final observó el síntoma | Ping default gateway Y/N | Estado de la señal Wi-Fi (conectado/tratando de conectarse) | Record ipconfig /all (o equivalente) |
| xxyy.aabb.0011 | test_user1 | Se desconecta de forma intermitente del punto de acceso. | Se perdió conectividad de red y asociación inalámbrica desde AP3. | N | Intentando conectarse | ifconfig en0 en0: indicadores=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 éter xx:yy:aa:bb:00:11 inet6 fe80::848:cb8f:881a:4cbf%en0 prefijo 64 scopeid seguro 0x4 inet 192.168.10.237 netmask 0xffff00 broadcast 192.168.10.255 nd6 options=201<PERFORMNUD,DAD> medios: autoselect estado: activo |
El objetivo de este ejercicio es ayudar a documentar y determinar un patrón común de interés, así como a obtener una imagen precisa de los problemas que se plantean. Una vez que esta hoja de cálculo esté preparada para su uso en la recopilación de datos, estará listo para comenzar las pruebas. A continuación se exponen algunas consideraciones adicionales, aunque importantes:
VI. WLC - Comandos show y debug
Cuando se llevan a cabo pruebas para reproducir y resolver posibles problemas de interoperabilidad del cliente inalámbrico, es imperativo recopilar depuraciones y registros adicionales de la infraestructura inalámbrica en uso. Estas dos secciones pueden explicar en detalle los registros específicos y el resultado inicial de la depuración que se deben recopilar del WLC y los AP, respectivamente.
Comandos Debug WLC
config sessions timeout 0
debug client <MAC_address> debug dhcp message enable
Con respecto a la naturaleza del problema en cuestión, también puede agregar estos debugs del WLC caso por caso:
- debug aaa detail enable - utilícelo si hay problemas relacionados con la autenticación con el servidor AAA
- debug aaa events enable: utilice esto si hay problemas relacionados con la autenticación con el servidor AAA
- debug aaa all enable: utilice esto para problemas de autenticación; el resultado de esta depuración es verboso, así que utilícelo sólo cuando sea absolutamente necesario (es decir, para casos de anulación de AAA, etc.)
- debug mobility handoff - use cuando haya problemas de roaming entre WLCs
Una vez que el problema se reproduzca con el cliente inalámbrico en cuestión, se recopilará y documentará toda la información descrita en las secciones anteriores y posteriores. Para ejecutar estos comandos CLI, debe inhabilitar los debugs en el WLC.
debug disable-all
Comandos show WLC
config paging disable show time show client detail <MAC_address> ping <client_IP-address> <repeat count [1-100]>
Como se mencionó anteriormente, asegúrese de ejecutar los debugs del WLC en una sesión Telnet/SSH y recopile el resultado para estos comandos show en otro Telnet/SSH al WLC. Debe hacer lo mismo para recopilar los debugs de AP y mostrar el resultado de los comandos detallados en esta sección.
VII. AP - Comandos show y debug
Puntos de acceso Cisco IOS ligeros
Antes de iniciar cualquier depuración en cualquier AP de IOS ligero involucrado en la prueba, como los puntos de acceso de Cisco 2600, 2700, 3700 o modelo anterior. Primero debe ejecutar estos comandos CLI en el AP, para evitar un tiempo de espera en el momento de una sesión Telnet/SSH/console a los AP en cuestión cuando su cliente prueba:
debug capwap console cli config t line vty 0 4 exec-timeout 0 session-timeout 0
También puede seguir estos pasos para utilizar la conexión de la consola y reemplazar la instrucción line vty 0 4 por line console 0 en su lugar, para inhabilitar los tiempos de espera de la sesión y exec para una conexión serial/de consola en consecuencia.
- line console 0: utilice para modificar los parámetros de tiempo de espera de la sesión serial
- line vty 0 4: utilice para modificar los parámetros de tiempo de espera de sesión Telnet/SSH
Comandos show AP
Antes de comenzar la prueba, primero debe recopilar una muestra de estos comandos show en el AP. Debe recopilar el resultado de estos comandos show al menos dos veces para cada prueba que involucre al cliente inalámbrico en cuestión; tanto antes como después de completar la prueba.
term len 0 show clock show tech show capwap client mn show int do1 dfs show logging more event.log show trace dot11_rst display time format local show trace dot11_rst show trace dot11_bcn display time format local show trace dot11_bcn
Comandos de depuración AP
Una vez que haya recolectado el resultado inicial de los comandos show mencionados anteriormente, ahora puede habilitar las depuraciones en el mismo punto de acceso en una sesión Telnet/SSH separada como se muestra. Asegúrese de guardar el resultado completo en un archivo de texto.
debug dot11 {d0|d1} monitor addr <client_MAC-address>
debug dot11 {d0|d1} trace print clients mgmt keys rxev txev rcv xmt txfail ba
term mon
Leyenda
| Indicador | Descripción |
| d0 | Radio de 2,4 GHz (ranura 0) |
| d1 | Radio de 5 GHz (ranura 1) |
| mgmt | Paquetes de administración de seguimiento |
| ba | Información ACK del bloque de seguimiento |
| rcv | Seguimiento de paquetes recibidos |
| claves | Teclas de conjunto de seguimiento |
| rxev | Seguimiento de eventos recibidos |
| txev | Eventos de transmisión de seguimiento |
| txrad | Transmisión de seguimiento a radio |
| xmt | Seguimiento de paquetes de transmisión |
| txfail | Errores de transmisión de seguimiento |
| tarifas | Cambios en la velocidad de seguimiento |
Para inhabilitar los debugs en el AP una vez que se complete el proceso de prueba y recolección de datos, puede ejecutar este comando CLI en el AP:
u all
Puntos de acceso AP-COS
Para los puntos de acceso compatibles con 802.11ac wave 2 y posteriores, como los modelos 1800, 2800 y 3800. Estos nuevos AP modelo introducen un sistema operativo completamente nuevo para las plataformas de punto de acceso denominadas AP-COS. Por lo tanto, no todos los comandos que se utilizaron anteriormente en los puntos de acceso ligeros basados en Cisco IOS tradicionales, como se detalla anteriormente, todavía se aplican. Si cuando resuelve un problema implica un problema de interoperabilidad con varios dispositivos STA cliente y APs modelo AP-COS, entonces esta información debe ser recolectada de los puntos de acceso AP-COS involucrados con la prueba equivalente.
Antes de iniciar cualquier depuración en cualquier AP del modelo AP-COS involucrado en la prueba. Primero debe ejecutar este comando CLI en el AP, para evitar un tiempo de espera en el momento de una sesión Telnet/SSH/console a los AP en cuestión cuando su cliente prueba:
exec-timeout 0
Comandos show AP-COS
Antes de comenzar la prueba, primero debe recopilar una muestra de estos comandos show en el AP. Debe recopilar el resultado de estos comandos show al menos dos veces para cada prueba que involucre al cliente inalámbrico en cuestión; tanto antes como después de completar la prueba.
term len 0
show clock show tech
show client statistics <client_MAC-address>
show cont nss status
show cont nss stats
show log
serie 1800 | Comandos de depuración AP-COS
Estas depuraciones son específicas de la serie 18xx de puntos de acceso. Esto se debe al hecho de que los conjuntos de chips utilizados para la serie 1800 de AP difieren de los encontrados en los puntos de acceso de las series 2800/3800 y, por lo tanto, se requiere un conjunto diferente de depuraciones en este escenario por comparación. Los debugs correspondientes para los AP de las series 2800/3800 se tratan en la siguiente sección.
Una vez que haya recolectado el resultado inicial de los comandos show mencionados anteriormente, debe habilitar ahora los debugs en los mismos puntos de acceso 1800 en una sesión Telnet/SSH separada como se muestra. Asegúrese de guardar el resultado completo en un archivo de texto.
debug dot11 client level events addr <client_MAC-address> debug dot11 client level errors addr <client_MAC-address> debug dot11 client level critical addr <client_MAC-address> debug dot11 client level info addr <client_MAC-address> debug dot11 client datapath eapol addr <client_MAC-address> debug dot11 client datapath dhcp addr <client_MAC-address> debug dot11 client datapath arp addr <client_MAC-address>
En algunos casos, es posible que necesite también habilitar los debugs adicionales en el AP 18xx para resolver problemas adicionales de interoperabilidad del cliente. Sin embargo, esto sólo debe hacerse si un ingeniero del TAC de Cisco lo solicita para una solicitud o caso de servicio correspondiente.
Debido a que las depuraciones adicionales podrían no sólo ser mucho más detalladas en su salida sino que también pueden introducir carga adicional en el AP, por lo tanto, requiere tiempo adicional para un análisis adecuado. Que bajo ciertas condiciones pueden potencialmente interrumpir el servicio, si muchos dispositivos cliente intentan conectarse al mismo AP bajo la prueba o variables similares.
Para inhabilitar los debugs en el punto de acceso variante AP-COS - ya sea en un AP de las series 1800 o 2800/3800 - una vez que el proceso de prueba y recolección de datos se complete, puede ejecutar este comando CLI en el AP:
config ap client-trace stop
Serie 2800/3800 | Comandos de depuración AP-COS
Una vez que haya recolectado el resultado inicial de los comandos show mencionados anteriormente, debe habilitar ahora las depuraciones en los mismos puntos de acceso 2800/3800 en una sesión Telnet/SSH separada como se muestra. Asegúrese de guardar el resultado completo en un archivo de texto.
config ap client-trace address add <client_MAC-address>
config ap client-trace filter all enable
config ap client-trace output console-log enable
config ap client-trace start
term mon
Para inhabilitar los debugs en el AP de la serie 1800/2800/3800 una vez que se complete el proceso de prueba y recolección de datos, puede ejecutar este comando CLI en el AP:
config ap client-trace stop
VIII. Capturas de paquetes del lado del cliente
Desde el dispositivo cliente en uso si es un ordenador portátil, MacBook o similar, debe recopilar la captura de paquetes en modo promiscuo de la interfaz inalámbrica del dispositivo cliente utilizado para reproducir el problema. Las utilidades comunes como Netmon 3.4 (sólo Windows) o Wireshark se pueden descargar fácilmente y utilizar para recopilar esta captura y guardarla en un archivo *.pcap. Depende del dispositivo, también puede haber medios para recolectar un tcpdump o similar del cliente en cuestión, por lo que puede que necesite consultar con el fabricante del dispositivo cliente para obtener asistencia en este sentido.
Este es un ejemplo para configurar una captura de Wireshark para la interfaz inalámbrica en un MacBook Pro:
Al igual que con cualquier captura de paquetes, independientemente de la utilidad que se utilice para recopilarlo, asegúrese de guardar el archivo en un formato de archivo pcap (es decir, *.pcap, *.pcapng, *.pkt, etc.). Se trata de garantizar que no sólo los ingenieros de Cisco de cualquier departamento puedan ver los archivos de captura de paquetes con facilidad, sino también los ingenieros de otros proveedores y organizaciones (por ejemplo, Intel, Apple, etc.). Esto permite un proceso de colaboración y cooperación más fluido, lo que facilita aún más el trabajo conjunto de Cisco y los proveedores de dispositivos cliente para investigar y resolver cualquier posible problema de interoperabilidad.
IX. Capturas de paquetes sobre el aire (OTA)
Para resolver eficazmente cualquier problema de interoperabilidad inalámbrica potencial o existente, es crucial recopilar una captura de paquetes OTA de calidad del problema. Esto permite el análisis detallado de la comunicación inalámbrica real 802.11 entre el cliente inalámbrico y las radios de punto de acceso en cuestión, además de proporcionar una perspectiva adicional al lado del cliente y los registros, depuraciones, etc. Se trata de un paso crítico que debe realizarse para cada prueba de un posible problema de interoperabilidad inalámbrica, sin excepción.
Sin embargo, a menudo el cliente final no está equipado o preparado correctamente para recopilar capturas de paquetes OTA. Se trata de un obstáculo común al que se enfrentan los ingenieros de redes inalámbricas y que deben trabajar con el cliente para superarlo de diversas maneras. Este artículo de los foros de soporte de Cisco puede servir como un buen punto de partida para ayudar a guiar y educar al cliente en consecuencia:
rastreo inalámbrico 802.11/captura de paquetes
Es de suma importancia que las capturas de paquetes OTA se recopilen en un formato de archivo pcap (es decir, *.pcap, *.pcapng, *.pkt, etc.) e incluye metadatos 802.11 (es decir, RSSI, canal, velocidad de datos, etc.). El rastreador OTA también debe mantenerse en todo momento cerca del dispositivo cliente en cuestión durante las pruebas, para garantizar una perspectiva precisa del tráfico enviado y recibido desde o hacia el dispositivo cliente que se está probando.
La razón de esto se debe al hecho de que las capturas de paquetes agregadas con el uso de esta utilidad se guardan actualmente en un formato de archivo propietario, y no en un formato de estilo pcap que se pueda ver fácilmente en Wireshark u otras utilidades similares. Asegúrese de que su captura de paquetes OTA se encuentre en un formato de archivo no propietario, lo que ayuda a garantizar que todas las partes y proveedores involucrados puedan revisar fácilmente cualquier archivo de captura en todo momento y, en última instancia, ayuda a acelerar cualquier esfuerzo de resolución.
Estos son algunos métodos comunes para recopilar una captura de paquetes OTA:
- AirPCAP con Wireshark
- MacBook Pro
- OmniPeek Professional, OmniPeek Enterprise, etc.
- Asistente remoto OmniPeek (ORA)
- Cisco AP en modo Sniffer
Capturas 802.11n
Para las capturas de paquetes OTA que involucran clientes inalámbricos 802.11n, actualmente hay más flexibilidad y facilidad de uso. Esto se debe a una mayor variedad de adaptadores WLAN USB inalámbricos disponibles que se pueden utilizar fácilmente con varias herramientas, como OmniPeek y otras.
Tenga en cuenta cómo las capacidades de los adaptadores inalámbricos específicos utilizados para recopilar una captura OTA 802.11n se comparan con las capacidades del chipset WLAN real utilizado por los dispositivos cliente que intenta resolver problemas. Por ejemplo, si el dispositivo cliente experimenta un problema potencial de interoperabilidad inalámbrica que utilice un chipset 802.11n con capacidad para 2 secuencias espaciales (2SS). A continuación, se recomienda encarecidamente asegurarse de que el adaptador inalámbrico utilizado para recopilar una captura de paquetes OTA sea también un adaptador 2SS o superior, con especificaciones 802.11n o más recientes.
Capturas OTA 802.11ac
Para 3 capturas de secuencia espacial (3SS) 802.11ac, puede utilizar las capacidades nativas de rastreo de un MacBook Pro modelo 2014 o posterior que ejecute Mac OS X 10.10.x o superior. Si soluciona problemas de un dispositivo cliente 802.11ac de flujo espacial 2, también puede utilizar un MacBook Air para capturas 802.11ac. El modelo de aire de MacBooks utiliza sólo chipsets WLAN 2SS actualmente en el momento de escribir este artículo. Puede consultar el siguiente artículo de foros de soporte de Cisco para obtener instrucciones sobre cómo recopilar capturas de paquetes OTA con el uso de Mac OS X, a través de diversos métodos:
Sniffing inalámbrico con Mac OS X 10.6+
También puede utilizar una serie 2702/2802/3702/3802 o un AP similar en modo de sniffer para recopilar una captura de paquetes 802.11ac adecuada con 3SS. También puede consultar el siguiente recurso para obtener una lista actual de adaptadores inalámbricos 802.11ac disponibles. Algunos de los cuales pueden ser potencialmente utilizados con herramientas comunes como OmniPeek y otros para recopilar una captura de paquetes 802.11ac (es decir, chipsets de Ralink, Atheros, etc.):
https://wikidevi.com/wiki/List_of_802.11ac_Hardware#Wireless_adapters
También puede utilizar una serie 2702/2802/3702/3802 o un AP similar en modo de sniffer para recopilar una captura de paquetes 802.11ac adecuada con 3SS. Para mayor comodidad, se pueden encontrar instrucciones paso a paso sobre cómo configurar un Cisco AP en modo de sniffer y recopilar una captura de paquetes OTA en el siguiente artículo de foros de soporte de Cisco:
Para solucionar problemas de escenarios de itinerancia con un dispositivo cliente inalámbrico, el desafío común es recopilar de manera efectiva una captura de paquetes OTA a través de varios canales. Este método de monitorear simultáneamente múltiples canales 802.11 se logra mediante la recolección de captura de paquetes OTA agregada. Se recomienda utilizar varios adaptadores WLAN USB compatibles con 802.11ac con un software de análisis de red compatible para lograr esto. Algunos adaptadores WLAN USB compatibles con 802.11ac comunes incluyen el adaptador WiFI Savvius para OmniPeek (802.11ac), Netgear A6210 o similares.
X. Summary
A continuación se ofrece un breve resumen de la información que debe recopilarse para solucionar de forma eficaz un problema potencial de interoperabilidad de clientes inalámbricos con un CUWN. Esta sección tiene por objeto servir de referencia rápida, según sea necesario.
Yo. Definición del problema
- ¿Se limita el problema a un modelo específico de puntos de acceso o tipos de radio (2,4 GHz frente a 5 GHz)?
- ¿Se observa el problema sólo en versiones específicas del software del controlador de LAN inalámbrica (WLC)?
- ¿Se experimenta el problema solo con versiones específicas de tipos de cliente y/o software (es decir, versión de sistema operativo, versión de controlador WLAN, etc.)?
- ¿Hay otros dispositivos inalámbricos que no experimenten este problema? En caso afirmativo, ¿cuáles son?
- ¿Se puede reproducir el problema mientras el cliente está conectado a un SSID abierto, un ancho de canal de 20 MHz y 802.11ac inhabilitados? (es decir, ¿el problema ocurre sólo en el modo 11n frente al modo 11ac?)
- Si el problema no se puede reproducir con un SSID abierto, ¿en qué configuración de seguridad mínima se ve el problema? (es decir, PSK o 802.1X en la WLAN)
- ¿Cuáles fueron las versiones de software y configuración en funcionamiento anteriores?
II. Registros y configuración del WLC
Recopile esto de la CLI del WLC en cuestión:
- config paging disable
- show run-config
Alternativamente, también puede recopilar sólo estos resultados según sea necesario:
- config paging disable
- show run-config no-ap
- show wlan apgroups
Copia de seguridad de la configuración del WLC a través de TFTP, FTP, etc. (GUI: Comandos > Cargar archivo > Configuración)
Syslogs desde el WLC
III. Información del dispositivo del cliente
- Tipo de cliente (es decir, tablet, smartphone, ordenador portátil, etc.)
- Modelo y creación de dispositivos
- versión de SO
- modelo de adaptador WLAN
- versión del controlador del adaptador WLAN
- Suplicante utilizado (es decir, Windows Zero Config / Auto Config, Intel PROSet, etc.)
- Seguridad configurada para su uso por el cliente inalámbrico y WLAN (es decir, Open, PSK, EAP-PEAP/MSCHAPv2, etc.)
IV. Diagrama de topología de red
Esto debería incluir una representación y/o detalles con respecto a los dispositivos inalámbricos en la red (es decir, impresoras/escáneres, WLC, etc.)
V. Creación de una hoja de cálculo para registrar todos los problemas de los clientes
Ejemplo:
| Dirección MAC | Nombre de usuario | Descripción del síntoma notificado | Tiempo que el usuario final observó el síntoma | Ping default gateway Y/N | Estado de la señal Wi-Fi (conectado/tratando de conectarse) | Record ipconfig /all (o equivalente) |
El objetivo de este ejercicio es ayudar a identificar un patrón común y mostrar un panorama más preciso de los problemas que se abordan.
VI. Comandos show y debug en el WLC
Recopile estos debugs del WLC a través de la CLI:
- config sessions timeout 0
- debug client <MAC_address>
- debug dhcp message enable
Agregue las depuraciones adicionales caso por caso:
- debug aaa detail enable - utilícelo si hay problemas relacionados con la autenticación con el servidor AAA
- debug aaa events enable: utilice esto si hay problemas relacionados con la autenticación con el servidor AAA
- debug aaa all enable: utilice esto para problemas de autenticación; esto es verboso, así que utilícelo sólo cuando sea necesario (es decir, para casos de anulación de AAA, etc)
- debug mobility handoff - utilizar cuando hay problemas de roaming entre WLC
Recopile el resultado de los comandos show del WLC a través de la CLI:
- config paging disable
- show time
- show client detail <mac-address of client> (observe el estado del cliente en el WLC)
- Hacer ping al cliente desde el WLC
Una vez finalizada la prueba, utilice este comando para detener todas las depuraciones actuales en el WLC:
- debug disable-all
VII. Comandos show y debug en el AP
AP Cisco IOS ligeros
Esta sección detalla las depuraciones requeridas para los puntos de acceso de las series 1700/2700/3700 o modelos anteriores.
Para evitar un tiempo de espera de sesión AP en el momento de una sesión Telnet/SSH/console, utilice estos comandos:
- debug capwap console cli
- config t
- line console 0 : utilice para modificar los parámetros de tiempo de espera de la sesión serial
- line vty 0 4 : utilice para modificar los parámetros de tiempo de espera de sesión Telnet/SSH
- exec-timeout 0
- session-timeout 0
- term len 0
Antes de iniciar la prueba, recopile un ejemplo de estos comandos show en el AP. Como mínimo, recopile dos muestras de este resultado, tanto antes como después de completar las pruebas con el uso de estos comandos show AP a través de la CLI:
- term len 0
- show clock
- show tech
- show capwap client mn
- show int do1 dfs
- show logging
- more event.log
- show trace dot11_rst display time format local
- show trace dot11_rst
- show trace dot11_bcn display time format local
- show trace dot11_bcn
Recopile estos debugs AP a través de la CLI:
- debug dot11 { d0 | d1 } monitor addr <MAC_address>
- debug dot11 { d0 | d1 } trace print clients mgmt keys rxev txev rcv xmt txfail ba
- term mon
Una vez finalizada la prueba, utilice este comando para inhabilitar las depuraciones:
- todos
AP-COS AP
Esta sección detalla los debugs requeridos para los AP de las series 1800/2800/3800.
Para evitar un tiempo de espera de sesión AP en el momento de una sesión Telnet/SSH/console, utilice estos comandos:
- exec-timeout 0
Antes de iniciar la prueba, recopile una muestra de los siguientes comandos show en el AP. Como mínimo, recopile dos muestras de este resultado, tanto antes como después de completar las pruebas con el uso de estos comandos show AP a través de la CLI:
- term len 0
- show clock
- show tech
- show client statistics <client_MAC-address>
- show cont nss status
- show cont nss stats
- show log
Para los puntos de acceso de la serie 1800, recopile estos debugs AP a través de la CLI:
- debug dot11 client level events addr <client_MAC-address>
- debug dot11 client level errors addr <client_MAC-address>
- debug dot11 client level Critical addr <client_MAC-address>
- debug dot11 client level info addr <client_MAC-address>
- debug dot11 client datapath eapol addr <client_MAC-address>
- debug dot11 client datapath dhcp addr <client_MAC-address>
- debug dot11 client datapath arp addr <client_MAC-address>
- term mon
Para los puntos de acceso de las series 2800/3800, recopile estos debugs AP a través de la CLI:
- config ap client-trace address add <client_MAC-address>
- config ap client-trace filter all enable
- config ap client-trace output console-log enable
- config ap client-trace start
- term mon
Una vez finalizada la prueba, utilice este comando para inhabilitar las depuraciones:
- config ap client-trace stop
VIII. Capturas del lado del cliente
Recopile un Netmon 3.4 promiscuo (sólo Windows XP o 7) o captura de paquetes Wireshark del adaptador WLAN del dispositivo cliente.
IX. Capturas de OTA
Capturas 802.11n
- AirPCAP con Wireshark
- MacBook Pro
- OmniPeek Professional, Enterprise, etc.
- Asistente remoto OmniPeek (ORA)
- Cisco AP en modo Sniffer
Capturas 802.11ac
- Para las capturas de 11ac 3SS, puede utilizar un Macbook Pro 2014 o posterior que ejecute 10.10.x o superior (si es posible, no utilice MacBook Air para las capturas de 11ac, ya que en la actualidad es un solo dispositivo 2SS).
- También puede utilizar un 2702, 3702 o un Cisco AP similar en el modo de sniffer.
- Para escenarios de itinerancia y con el uso de software de análisis de red profesional como OmniPeek de Savvius. Se recomienda utilizar varios adaptadores WLAN USB compatibles con 802.11ac, como el adaptador Savvius WiFI para OmniPeek (802.11ac), Netgear A6210 o similares.
XI. Apéndice A - Consejos y trucos adicionales
Windows:
Para recopilar información adicional sobre la conexión inalámbrica actual y otros detalles relacionados directamente desde un PC con Windows. Puede utilizar estos comandos relacionados con netsh wlan en la línea de comandos de Windows (CMD):C:\Users\engineer>netsh wlan show ?
These commands are available:
Commands in this context:
show all - Shows complete wireless device and networks information.
show allowexplicitcreds - Shows the allow shared user credentials settings.
show autoconfig - Shows whether the auto configuration logic is enabled or
disabled.
show blockednetworks - Shows the blocked network display settings.
show createalluserprofile - Shows whether everyone is allowed to create all
user profiles.
show drivers - Shows properties of the wireless LAN drivers on the system.
show filters - Shows the allowed and blocked network list.
show hostednetwork - Show hosted network properties and status.
show interfaces - Shows a list of the wireless LAN interfaces on
the system.
show networks - Shows a list of networks visible on the system.
show onlyUseGPProfilesforAllowedNetworks - Shows the only use GP profiles on GP
configured networks setting.
show profiles - Shows a list of profiles configured on the system.
show settings - Shows the global settings of wireless LAN.
show tracing - Shows whether wireless LAN tracing is enabled or disabled.
C:\Users\engineer>netsh wlan show interfaces
There are 3 interfaces on the system:
Name : Wireless Network Connection 8
Description : WildPackets Conceptronic Nano Wireless 150Mbps USB
Adapter #5
GUID : 6beec9b0-9929-4bb4-aef8-0809ce01843e
Physical address : c8:d7:19:34:d5:85
State : disconnected
Name : Wireless Network Connection 4
Description : WildPackets Conceptronic Nano Wireless 150Mbps USB
Adapter
GUID : 23aa09d4-c828-4184-965f-4e30f27ba359
Physical address : 48:f8:b3:b7:02:6e
State : disconnected
Name : Wireless Network Connection
Description : Intel(R) Centrino(R) Advanced-N 6200 AGN
GUID : 8fa038f8-74e0-4167-98f9-de0943f0096c
Physical address : 58:94:6b:3e:a1:d0
State : connected
SSID : snowstorm
BSSID : 00:3a:9a:e6:28:af
Network type : Infrastructure
Radio type : 802.11n
Authentication : WPA2-Enterprise
Cipher : CCMP
Connection mode : Profile
Channel : 157
Receive rate (Mbps) : 300
Transmit rate (Mbps) : 300
Signal : 80%
Profile : snowstorm
Hosted network status : Not started
C:\Users\engineer>netsh wlan show networks bssid | more
Interface name : Wireless Network Connection
There are 21 networks currently visible.
SSID 1 : snowstorm
Network type : Infrastructure
Authentication : WPA2-Enterprise
Encryption : CCMP
BSSID 1 : 00:3a:9a:e6:28:af
Signal : 99%
Radio type : 802.11n
Channel : 157
Basic rates (Mbps) : 24 39 156
Other rates (Mbps) : 18 19.5 36 48 54
BSSID 2 : 00:3a:9a:e6:28:a0
Signal : 91%
Radio type : 802.11n
Channel : 6
Basic rates (Mbps) : 1 2
Other rates (Mbps) : 5.5 6 9 11 12 18 24 36 48 54
-- More --
MacOS (anteriormente OS X)
Para recolectar el resultado equivalente como el comando ipconfig /all en un PC con Windows, puede utilizar en su lugar el comando común Linux/Unix de ifconfig para enumerar información detallada para todas las interfaces de red en un MacBook de Apple. Si es necesario, también puede especificar que se reciba la salida sólo para la interfaz inalámbrica nativa para un MacBook dado (en0 o en1, depende del modelo). Como este ejemplo:
bash-3.2$ ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 14:10:9f:de:df:f3 inet6 fe80::1610:9fff:fede:dff3%en0 prefixlen 64 scopeid 0x4 inet 10.150.128.40 netmask 0xffffe000 broadcast 10.150.159.255 nd6 options=1<PERFORMNUD> media: autoselect status: active
Para obtener información rápida pero detallada sobre la conexión inalámbrica actual en un MacBook. También puede seleccionar el icono WiFi en la esquina superior derecha del escritorio mientras mantiene simultáneamente el botón de opción del teclado, como se muestra en la imagen.
Otra opción útil es utilizar la utilidad de línea de comandos oculta llamada aeropuerto. Se recomienda utilizar esta herramienta únicamente con su propio MacBook o con uno en uso en un entorno de laboratorio. Como algunos administradores de red podrían no querer conceder acceso a esta utilidad en un MacBook de usuario final, utilice el nivel de precaución adecuado. Para continuar, introduzca esto en Terminal en el MacBook en cuestión:
sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/bin/airport
Ahora puede llamar a la utilidad CLI del aeropuerto con facilidad. Un ejemplo de esto incluye:
bash-3.2$ airport -I
agrCtlRSSI: -61
agrExtRSSI: 0
agrCtlNoise: -90
agrExtNoise: 0
state: running
op mode: station
lastTxRate: 216
maxRate: 300
lastAssocStatus: 0
802.11 auth: open
link auth: wpa2
BSSID: 0:3a:9a:e6:28:af
SSID: snowstorm
MCS: 13
channel: 157,1
Para facilitar aún más el proceso de recolección de una única captura de paquetes OTA de canal 802.11 confiable con el uso de las capacidades de un MacBook Pro o similar. Puede aprovechar las capacidades incorporadas en macOS con el uso del método Wireless Diagnostics > Sniffer o similar a lo descrito anteriormente, pero opcionalmente puede utilizar una utilidad de terceros llamada Airtool también (OS X 10.8 y posteriores). La ventaja es una interfaz sencilla para recopilar rápidamente una captura de paquetes OTA, que se guarda directamente en el escritorio con sólo unos clics a través de la interfaz de usuario de la aplicación desde la barra de menús superior de la pantalla.
Puede encontrar más información y descargar enlaces para Airtool en esta URL:
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
14-May-2016 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)