Resolución de Problemas de Interoperabilidad del Cliente Inalámbrico con CUWN
Contenido
Introducción
En este documento se describen los problemas de interoperabilidad que surgen con la solución Cisco Unified Wireless Network (CUWN).
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- AP 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.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Antecedentes
Puede ser común encontrar que dados los diversos dispositivos cliente que tanto existen como se siguen desarrollando. Pueden surgir una serie de problemas con respecto al establecimiento, el mantenimiento o simplemente para sacar el máximo partido de su conexión a la red inalámbrica y para admitir la infraestructura.
A menudo, esto puede deberse a un simple problema de configuración por parte del dispositivo cliente o de la propia infraestructura inalámbrica. Sin embargo, en algunos casos esto se puede atribuir a un problema de interoperabilidad con respecto a un dispositivo cliente específico y los componentes que lo soportan (suplicante, adaptador WLAN, controlador inalámbrico,...), y/o los AP en cuestión. Como ingenieros de redes inalámbricas, estos problemas de interoperabilidad suponen una oportunidad para identificar, solucionar y resolver retos potencialmente complejos.
Este documento describe en detalle la información que debe recopilarse inicialmente para investigar y resolver de manera eficaz estos problemas de interoperabilidad inalámbrica cuando surgen con la solución Cisco Unified Wireless Network (CUWN). La necesidad de este enfoque integral es cada vez más importante debido al crecimiento constante del número y las combinaciones de dispositivos cliente inalámbricos y radios de punto de acceso (AP). Es posible que se solicite información adicional a la descrita en este artículo, que debe recopilarse caso por caso, dado el número ilimitado de variables que pueden dictar estos requisitos. Sin embargo, la información que se detalla aquí es una guía genérica para abordar cualquier problema potencial de interoperabilidad de clientes inalámbricos.
I. Definición del problema
El primer paso para abordar eficazmente cualquier problema con la intención de ser resueltos, es definir con precisión el tema en cuestión. Para ello, asegúrese de que, como mínimo, se formulen estas preguntas y de que sus respuestas estén claramente documentadas:
- ¿Está el problema restringido a un modelo específico de AP o tipo de radio (2,4 GHz versus 5 GHz)?
- ¿Se observa el problema solamente en las versiones específicas del software del WLC?
- ¿Se ha producido el problema solo con versiones específicas de tipos de clientes o software (versión de SO, versión de controlador WLAN, etc.)?
- ¿Hay algún otro dispositivo inalámbrico que no experimente este problema? En caso afirmativo, ¿en qué consisten?
- ¿Es el problema reproducible mientras el cliente está conectado a una configuración inalámbrica simplificada como un SSID abierto, con un ancho de canal de 20 MHz y 802.11ac deshabilitado? (es decir, ¿se produce el problema solo en el modo 802.11n frente al modo 802.11ac?).
- Si el problema no se puede reproducir con un SSID abierto, ¿con qué configuración de seguridad mínima se detecta el problema? (PSK u 802.1X en la WLAN).
- ¿Cuáles eran las versiones anteriores de configuración y software que se sabe que son correctas?
II. Configuración de WLC y registros generales
Run-Config
Sin excepción, es absolutamente necesario recoger la configuración del WLC para una revisión detallada de las características utilizadas por el cliente, su configuración específica, y otros detalles tales. Para ello, debe establecer una sesión Telnet/SSH en los WLC en cuestión y guardar la salida 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 AP unidos y la información de RF asociada. Aunque en algunos casos y situaciones, como cuando usted trabaja inicialmente con un WLC con un gran número de AP unidos (8510 WLC con 2500+ AP). Podría ser preferible recopilar inicialmente solo la configuración del WLC sin dicha 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 para completar el número dado de AP. Sin embargo, aún puede ser necesario recopilar el resultado completo de run-config más adelante.
Para ello, puede recopilar opcionalmente la salida de estos comandos CLI en un archivo de texto:
config paging disable show run-config no-ap show wlan apgroups
Archivo de configuración de WLC
Además de la salida show run-config o show run-config no-ap, también se recomienda recopilar una copia de seguridad completa de la configuración del WLC. Esto es de ayuda, si una recreación de laboratorio necesita ser llevada a cabo por TAC/HTTS y la derivación de BU, para intentar reproducir el problema 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. Este ejemplo muestra el uso de la GUI y la CLI para guardar una copia de seguridad del WLC, con el uso de TFTP:
GUI
Commands > Upload File > Configuration > Upload 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
Registros del sistema 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 sería que recopilara estos registros inmediatamente después de la prueba con un cliente inalámbrico y reprodujera el problema notificado. Si el cliente exporta los registros del WLC a un servidor syslog externo, entonces usted desea recuperarlos de allí. De lo contrario, puede guardar el msglog y el traplog actualmente almacenados localmente en el WLC guardando esta salida de la sesión CLI en otro archivo de texto:
config paging disable show msglog show traplog
III. Información y detalles del dispositivo del cliente
El siguiente paso consiste en recopilar tanta información y datos específicos con respecto a los dispositivos cliente en uso que experimentan un posible problema de interoperabilidad inalámbrica. Dicha información debe incluir, entre otras cosas:
- Tipo de cliente (tablet, smartphone, portátil,...)
- Marca y modelo del dispositivo
- Versión del SO
- modelo de adaptador WLAN
- versión del controlador del adaptador WLAN
- Suplicante utilizado (Configuración automática/configuración rápida de Windows, Intel PROSet,...)
- Seguridad configurada para su uso por el cliente inalámbrico y la WLAN (abierta, PSK, EAP-PEAP/MSCHAPv2,...)
- Anote los parámetros de cliente que se hayan modificado con respecto a la configuración predeterminada proporcionada por el proveedor en cuestión (estado de suspensión, parámetros de itinerancia, U-APSD, etc.).
IV. Topología de red
Para acelerar aún más los esfuerzos de resolución de problemas y el proceso de análisis de la causa raíz (RCA), siempre se recomienda proporcionar un diagrama detallado y completo de la topología de red. El diagrama de topología de red no solo debe incluir detalles sobre la red y la infraestructura inalámbrica, sino también proporcionar una perspectiva de los dispositivos inalámbricos en cuestión que funcionan dentro de la red ( impresoras/escáneres, qué VLAN de cliente están en uso,...) y sus ubicaciones entre sí.
Se pueden utilizar varias herramientas (Microsoft Visio, draw.io,...) y diversos estilos para crear un diagrama de red de este tipo. El aspecto importante es simplemente asegurarse de que la información adecuada se refleja claramente en el diagrama proporcionado para su revisión por todas las partes involucradas y proveedores. Un ejemplo de topología de red que captura información básica pero útil con respecto tanto a la infraestructura como a los dispositivos cliente, como se muestra en la imagen.
V. Seguimiento de los detalles adicionales y las características
Para ayudar a garantizar que se recopila la información adecuada 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 | Síntoma observado por el usuario final | Ping default gateway S/N | Estado de la señal WiFi (conectado/intentando conectarse) | Record ipconfig /all (o equivalente) |
| xxyy.aabb.0011 | test_user1 | Se desconecta intermitentemente del punto de acceso. | Pérdida de conectividad de red y asociación inalámbrica desde el AP3. | N | Intentando conectar | ifconfig en0 es0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether xx:yy:aa:bb:00:11 inet6 fe80::848:cb8f:881a:4cbf%en0 prefixlen 64 secure scopeid 0x4 inet 192.168.10.237 netmask 0xffffff00 broadcast 192.168.10.255 nd6 options=201<PERFORMNUD,DAD> medios: selección automática estado: activo |
El objetivo de este ejercicio es ayudar a documentar y determinar un patrón común de interés, así como obtener una imagen precisa del problema o problemas que se presentan. Una vez preparada esta hoja de cálculo para la recopilación de datos, ya puede comenzar las pruebas. A continuación se exponen algunas consideraciones adicionales, aunque importantes:
VI. WLC - Comandos Show y Debug
Cuando se realizan pruebas para reproducir y solucionar posibles problemas de interoperabilidad de clientes inalámbricos, es imprescindible que se recopilen depuraciones y registros adicionales de la infraestructura inalámbrica en uso. Estas dos secciones pueden explicar en detalle los logs específicos y la salida de depuración inicial que se recolecta del WLC y los AP, respectivamente.
Comandos de depuración 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 estas depuraciones de WLC caso por caso:
- debug aaa detail enable - utilice esto 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 los problemas de autenticación; el resultado para esta depuración es detallado así que utilícelo solamente cuando sea absolutamente necesario (para los casos de invalidación de AAA,...)
- debug mobility handoff - se utiliza cuando hay problemas de roaming entre los WLC
Una vez que se reproduzca el problema 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 de 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 recolecte la salida para estos comandos show en otro Telnet/SSH al WLC. Debe hacer lo mismo para recopilar los resultados de los comandos show y debugs AP detallados en esta sección.
VII. AP - Comandos Show y Debug
Puntos de acceso ligeros Cisco IOS®
Antes de iniciar cualquier depuración en cualquier punto de acceso ligero Cisco IOS® involucrado en la prueba, como los puntos de acceso 2600, 2700, 3700 o modelos anteriores de Cisco. 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(s):
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 consola y reemplazar la sentencia line vty 0 4 con line console 0 en su lugar, para inhabilitar los tiempos de espera exec y session para una conexión serial/de consola en consecuencia.
- line console 0 - se utiliza para modificar los parámetros de tiempo de espera de sesión serial
- line vty 0 4 - se utiliza para modificar los parámetros de tiempo de espera de sesión Telnet/SSH
Comandos Show de AP
Antes de comenzar la prueba, primero debe recopilar una muestra de estos comandos show en el AP. Recopile la salida 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 que la prueba haya finalizado.
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 de PA
Una vez que haya recopilado la salida inicial de los comandos show mencionados anteriormente, ahora puede habilitar los debugs en el mismo punto de acceso en una sesión Telnet/SSH separada como se muestra. Asegúrese de guardar todo el resultado 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
| Indicador | Descripción |
| d0 | Radio de 2,4 GHz (ranura 0) |
| d1 | Radio de 5 GHz (ranura 1) |
| admin | Paquetes de administración de seguimiento |
| ba | Información de ACK de bloque de seguimiento |
| rcv | Seguimiento de paquetes recibidos |
| claves | Claves de conjunto de seguimiento |
| rxev | Seguimiento de eventos recibidos |
| txev | Seguimiento de eventos de transmisión |
| txrad | Seguimiento de transmisión a radio |
| xmt | Paquetes de transmisión de seguimiento |
| txfail | Rastrear errores de transmisión |
| tarifas | Cambios de velocidad de seguimiento |
Para inhabilitar los debugs en el AP una vez que se completa la prueba y el proceso de recolección de datos, puede ejecutar este comando CLI en el AP:
u all
Puntos de acceso AP-COS
Para puntos de acceso compatibles con 802.11ac wave 2 y versiones posteriores, como los puntos de acceso de los modelos 1800, 2800 y 3800. Estos nuevos modelos de AP introducen un sistema operativo completamente nuevo para las plataformas de punto de acceso denominadas AP-COS. Como tal, no todos los comandos utilizados anteriormente en los puntos de acceso basados en Cisco IOS® ligeros tradicionales como se detalló anteriormente siguen aplicándose. Si cuando resuelve un problema implica un problema de interoperabilidad con varios dispositivos STA cliente y APs modelo AP-COS, entonces esta información se debe recolectar de los puntos de acceso AP-COS involucrados con la prueba equivalente.
Antes de iniciar cualquier depuración en cualquier AP modelo AP-COS involucrado en la prueba. 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(s):
exec-timeout 0
Comandos Show de AP-COS
Antes de comenzar la prueba, primero debe recopilar una muestra de estos comandos show en el AP. Recopile la salida 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 que la prueba haya finalizado.
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 de AP-COS
Estas depuraciones son específicas de la serie 18xx de puntos de acceso. Esto se debe al hecho de que los chipsets utilizados para la serie 1800 de AP difieren de los encontrados en los puntos de acceso de la serie 2800/3800, y por lo tanto se requiere un conjunto diferente de depuraciones en este escenario en comparación. Las depuraciones correspondientes para los AP de las series 2800/3800 se tratan en la siguiente sección.
Una vez que haya recopilado la salida 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 todo el resultado 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 también necesite habilitar las depuraciones adicionales en el AP 18xx para resolver más problemas de interoperabilidad del cliente. Sin embargo, esto solo debe hacerse si un ingeniero del TAC de Cisco lo solicita para una solicitud o caso de servicio correspondiente.
A medida que los debugs adicionales no solo pueden ser mucho más detallados en su resultado, sino que también pueden introducir carga adicional en el AP, por lo que requiere tiempo adicional para un análisis adecuado. Que bajo ciertas condiciones puede 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 de la variante AP-COS - ya sea en un AP de las series 1800 o 2800/3800 - una vez que se complete el proceso de recolección de datos y prueba, puede ejecutar este comando CLI en el AP:
config ap client-trace stop
Serie 2800/3800 | Comandos de depuración de AP-COS
Una vez que haya recopilado la salida inicial de los comandos show mencionados anteriormente, debe habilitar ahora los debugs en los mismos puntos de acceso 2800/3800 en una sesión Telnet/SSH separada como se muestra. Asegúrese de guardar todo el resultado 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 las series 1800/2800/3800 una vez que se complete la prueba y el proceso de recolección de datos, puede ejecutar este comando CLI en el AP:
config ap client-trace stop
VIII. Capturas de paquetes del lado cliente
Desde el dispositivo cliente en uso, si se trata de 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. Utilidades comunes como Netmon 3.4 (solo 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 del cliente para obtener asistencia en este sentido.
Este es un ejemplo para configurar una captura 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 (*.pcap, *.pcapng, *.pkt,...). Esto se realiza para garantizar que no solo 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 (Intel, Apple,...). Esto permite una cooperación y un proceso de colaboración más fluidos, lo que facilita aún más que tanto Cisco como los proveedores de dispositivos del cliente colaboren mejor para investigar y resolver cualquier posible problema de interoperabilidad.
IX. Capturas de paquetes por 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 802.11 real entre el cliente inalámbrico y la radio o radios de punto de acceso en cuestión, además de dar una perspectiva adicional a los registros y depuraciones de la infraestructura inalámbrica y del lado del cliente. Se trata de un paso fundamental que debe llevarse a cabo para cada prueba de un posible problema de interoperabilidad inalámbrica, sin excepción.
Sin embargo, a menudo el cliente final no está debidamente equipado o preparado para recopilar capturas de paquetes OTA. Se trata de un obstáculo habitual al que se enfrentan los ingenieros de tecnología inalámbrica, que deben trabajar con el cliente para superarlo de diversas formas. Este artículo de los foros de asistencia de Cisco puede ser un buen punto de partida para ayudar a guiar y educar al cliente en consecuencia:
Detección inalámbrica 802.11/captura de paquetes
Es de suma importancia que las capturas de paquetes OTA se recopilen en un formato de archivo pcap (*.pcap, *.pcapng, *.pkt,..) e incluya metadatos 802.11 (RSSI, canal, velocidad de datos,...). El sabueso OTA también debe mantenerse cerca del dispositivo cliente en cuestión en todo momento durante las pruebas, para garantizar una perspectiva precisa del tráfico enviado y recibido hacia/desde el dispositivo cliente probado.
La razón de esto se debe al hecho de que las capturas de paquetes agregados 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 está en un formato de archivo no propietario, esto 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, ayudar 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,...
- Asistente remoto OmniPeek (ORA)
- Cisco AP en modo Sniffer
Capturas de 802.11n
En el caso de las capturas de paquetes OTA que incluyen 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 una serie de herramientas, como OmniPeek y otras.
Tome nota de cómo las capacidades de los adaptadores inalámbricos específicos utilizados para recopilar una captura de OTA 802.11n se comparan con las capacidades del conjunto de chips 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 utiliza un conjunto de chips 802.11n con capacidad para 2 flujos espaciales (2SS). Por lo tanto, 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 posteriores.
Capturas OTA de 802.11ac
Para las capturas de 3 flujos espaciales (3SS) de 802.11ac, puede utilizar las capacidades de rastreo nativas de un MacBook Pro modelo 2014 o posterior con Mac OS X 10.10.x o superior. Si está resolviendo problemas de un dispositivo cliente 802.11ac de 2 flujos espaciales, también puede utilizar un MacBook Air para capturas 802.11ac. El modelo Air de MacBooks usa conjuntos de chips WLAN de 2SS solamente actualmente en el momento de escribir este documento. Puede consultar el artículo de los 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 una variedad de métodos:
Detección inalámbrica con el uso de Mac OS X 10.6+
También puede utilizar un AP de la serie 2702/2802/3702/3802 o similar en el modo del sabueso para recolectar una captura de paquetes 802.11ac adecuada con 3SS. También puede consultar la lista de recursos para obtener una lista actualizada de los adaptadores inalámbricos 802.11ac disponibles. Algunos de los cuales pueden ser potencialmente usados con herramientas comunes como OmniPeek y otros para recolectar una captura de paquetes 802.11ac (chipsets de Ralink, Atheros,...):
https://wikidevi.com/wiki/List_of_802.11ac_Hardware#Wireless_adapters
También puede utilizar un AP de la serie 2702/2802/3702/3802 o similar en el modo del sabueso para recolectar 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 sniffer y recopilar una captura de paquetes OTA en el 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 eficazmente una captura de paquetes OTA a través de varios canales. Este método de supervisión simultánea de varios canales 802.11 se logra mediante la recopilación de captura de paquetes OTA agregados. 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 habituales incluyen el adaptador WiFi Savvius para OmniPeek (802.11ac), Netgear A6210 o similar.
X. Resumen
A continuación se presenta una breve recapitulación de la información que se debe recopilar para resolver eficazmente un problema potencial de interoperabilidad de un cliente inalámbrico con un CUWN. Esta sección está pensada para servir como una sección de referencia rápida, según sea necesario.
I. Definición del problema
- ¿Está el problema limitado a un modelo específico de punto(s) de acceso o tipo de radio (2,4 GHz frente a 5 GHz)?
- ¿Se observa el problema solo en versiones específicas del software del controlador de LAN inalámbrica (WLC)?
- ¿Se ha producido el problema solo con versiones específicas de tipos de clientes o software (versión de SO, versión de controlador WLAN, etc.)?
- ¿Hay algún otro dispositivo inalámbrico que no experimente este problema? En caso afirmativo, ¿en qué consisten?
- ¿Es el problema reproducible mientras el cliente está conectado a un SSID abierto, un ancho de canal de 20 MHz y 802.11ac inhabilitado? (El problema ocurre en el modo 11n frente al modo 11ac solamente)
- Si el problema no se puede reproducir con un SSID abierto, ¿con qué configuración de seguridad mínima se detecta el problema? (PSK u 802.1X en la WLAN)
- ¿Cuáles eran las versiones anteriores de configuración y software que se sabe que son correctas?
II. Configuración y registros de WLC
Recopile esto de la CLI de los WLC en cuestión:
- config paging disable
- show run-config
Alternativamente, también puede recopilar solo 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 vía TFTP, FTP,...(GUI: Commands > Upload File > Configuration)
Registros del sistema desde el WLC
III. Información del dispositivo del cliente
- Tipo de cliente (tablet, smartphone, portátil,...)
- Marca y modelo del dispositivo
- Versión del SO
- modelo de adaptador WLAN
- versión del controlador del adaptador WLAN
- Suplicante utilizado (Configuración automática/configuración rápida de Windows, Intel PROSet,...)
- Seguridad configurada para su uso por el cliente inalámbrico y la WLAN (abierta, PSK, EAP-PEAP/MSCHAPv2,...)
IV. Diagrama de topología de red
Esto incluye una representación y/o detalles con respecto a los dispositivos inalámbricos en la red (impresoras/escáneres, WLC,...)
V. Crear una hoja de cálculo para registrar todos los problemas del cliente
Ejemplo:
| Dirección MAC | Nombre de usuario | Descripción del síntoma notificado | Síntoma observado por el usuario final | Ping default gateway S/N | Estado de la señal WiFi (conectado/intentando conectarse) | Record ipconfig /all (o equivalente) |
El objetivo de este ejercicio es ayudar a identificar un patrón común y mostrar una imagen más precisa de los problemas que se presentan.
VI. Comandos Show y Debug en el WLC
Recopile estas depuraciones 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 - utilice esto 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 los problemas de autenticación; esto es detallado así que utilícelo solamente cuando sea necesario (para los casos de invalidación de AAA y similares)
- debug mobility handoff - se utiliza cuando los problemas de itinerancia entre los WLC
Recopile el resultado para 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)
- Haga ping al cliente desde el WLC
Una vez que se completa la prueba, utilice este comando para detener todos los debugs actuales en el WLC:
- debug disable-all
VII. Comandos Show y Debug en el AP
AP ligeros Cisco IOS®
Esta sección detalla las depuraciones requeridas para las series 1700/2700/3700 o los puntos de acceso de 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
- consola de línea 0: se utiliza para modificar los parámetros de tiempo de espera de sesión serial
- line vty 0 4: se utiliza 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 una muestra de estos comandos show en el AP. Como mínimo, recopile dos muestras de este resultado, tanto antes como después de la finalización de las pruebas con el uso de estos comandos show de 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 estas depuraciones de 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 completada la prueba, utilice este comando para inhabilitar los debugs:
- u all
AP-COS AP
Esta sección detalla las depuraciones requeridas 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 comandos show en el AP. Como mínimo, recopile dos muestras de este resultado, tanto antes como después de la finalización de las pruebas con el uso de estos comandos show de 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 estas depuraciones de 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 estas depuraciones de 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 completada la prueba, utilice este comando para inhabilitar los debugs:
- config ap client-trace stop
VIII. Capturas del lado del cliente
Recopile una promiscua captura de paquetes Netmon 3.4 (sólo Windows XP o 7) o Wireshark del adaptador WLAN del dispositivo cliente.
IX. Capturas de OTA
Capturas de 802.11n
- AirPCAP con Wireshark
- MacBook Pro
- OmniPeek Professional, Enterprise,
- Asistente remoto OmniPeek (ORA)
- Cisco AP en modo Sniffer
Capturas de 802.11ac
- Para las capturas de 11ac 3SS, puede utilizar un Macbook Pro 2014 o posterior que ejecute 10.10.x o superior (no utilice MacBook Air para capturas de 11ac si es posible, ya que actualmente es un dispositivo solo 2SS).
- También puede utilizar un AP de Cisco 2702, 3702 o similar en el modo de sabueso.
- Para escenarios de roaming 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 WiFi Savvius para OmniPeek (802.11ac), Netgear A6210 o similar.
XI. Apéndice A: consejos y trucos adicionales
Windows:
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 la salida equivalente como el comando ipconfig /all en una PC con Windows, puede utilizar el comando común Linux/Unix de ifconfig para enumerar información detallada para todas las interfaces de red en una MacBook de Apple. Según sea necesario, también puede especificar que se reciba la salida solo 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
Con el fin de obtener información rápida pero detallada con respecto a 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 pulsado 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. Es muy recomendable utilizar esto solo con su propio MacBook o uno en uso en un entorno de laboratorio. Dado que algunos administradores de red pueden no desear conceder acceso a esta utilidad en el MacBook de un usuario final, utilice el nivel de precaución adecuado según corresponda. Para continuar, ingrese 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 lo cual incluye lo siguiente:
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 recopilación de una captura de paquetes OTA de canal 802.11 única y fiable con el uso de las capacidades de un MacBook Pro o similar. Puede aprovechar las capacidades integradas en macOS con el uso del método Wireless Diagnostics > Sniffer o similar como se mencionó anteriormente, pero también puede utilizar una utilidad de terceros llamada Airtool (OS X 10.8 y posterior). La ventaja es una interfaz sencilla para recopilar rápidamente una captura de paquetes OTA, que se guarda directamente en el escritorio con solo unos pocos 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 enlaces de descarga para Airtool en esta URL:
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
2.0 |
14-Feb-2023 |
Recertificación |
1.0 |
14-May-2016 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)