Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

I. Definición del problema

II. Configuración del WLC y registros generales

Run-Config

Archivo de configuración de WLC

GUI

CLI

Registros del sistema desde el WLC

III. Información y detalles del dispositivo del cliente

IV. Topología de la red

V. Seguimiento de los detalles adicionales y las características

VI. WLC - Comandos Show y Debug

Comandos de depuración WLC

Comandos Show de WLC

VII. AP - Comandos Show y Debug

Puntos de acceso ligeros Cisco IOS®

Comandos Show de AP

Comandos de depuración de PA

Puntos de acceso AP-COS

Comandos Show de AP-COS

serie 1800 | Comandos de depuración de AP-COS

Serie 2800/3800 | Comandos de depuración de AP-COS

VIII. Capturas de paquetes del lado cliente

IX. Capturas de paquetes por aire (OTA)

Capturas de 802.11n

Capturas OTA de 802.11ac

X. Resumen

I. Definición del problema

II. Configuración y registros de WLC

III. Información sobre el dispositivo del cliente

IV. Diagrama de topología de red

V. Crear una hoja de cálculo para registrar todos los problemas del cliente

VI. Comandos Show y Debug en el WLC

VII. Comandos Show y Debug en el AP

Puntos de acceso ligeros de Cisco IOS®

AP-COS AP

VIII. Capturas de clientes

IX. Capturas OTAC

Capturas de 802.11n

Capturas de 802.11ac

XI. Apéndice A - Consejos y trucos adicionales

Windows:

macOS (anteriormente OS X)

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.

Nota: Este documento está dirigido a ingenieros y administradores de redes inalámbricas con experiencia que ya están familiarizados con el uso, la configuración y la resolución de problemas de estos temas.

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

Nota: Cualquier información o nota adicional con respecto a los dispositivos cliente hasta los cuales incluye capturas de pantalla de sus configuraciones relacionadas con WLAN, y así sucesivamente, también se debe incluir según sea necesario.

IV. Topología de la 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:

Nota: Todos los debugs y capturas de paquetes recolectados deben sincronizarse con el mismo servidor NTP para una correlación más fácil con los registros, y deben tomarse al mismo tiempo para cualquier prueba dada.

Nota: proporcione una marca de tiempo precisa de cuándo se observa el problema y cuándo parece que se recupera (si corresponde).

Nota: Recopile siempre los debugs filtrados por dirección MAC del cliente en el AP y el WLC.

Nota: No ejecute los comandos show y debug en el AP dentro de la misma sesión Telnet/SSH/console, éstos se hacen por separado en una sesión diferente según corresponda.

Nota: Las depuraciones de AP son preferibles para ser tomadas en Telnet/SSH versus la Consola, ya que la consola es típicamente demasiado lenta para ser efectiva.

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.

Nota: Si las pruebas en cuestión implican un escenario de roaming de dispositivo de cliente, por el cual más de un canal 802.11 necesita ser monitoreado en una captura de paquete agregado. Por lo tanto, actualmente no se recomienda utilizar AirMagnet WiFi Analyzer de Fluke Networks.

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.

en un formato legible por Wireshark actual, que incluye metadatos 802.11 (RSSI, canal, velocidad de datos). Puede obtener más información en: https://supportforums.cisco.com/document/75331/80211-wireless-sniffing-packet-capture#sthash.Xhlx5LSS.dpuf

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:

Cisco AP en modo Sniffer

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: Comandos > Cargar archivo > Configuración)

Registros del sistema desde el WLC

III. Información sobre el 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,...)

Nota: Cualquier parámetro de cliente ha cambiado desde la configuración predeterminada proporcionada por el proveedor en cuestión. (estado de suspensión, parámetros de itinerancia, U-APSD, etc.)

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 de clientes

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

https://www.adriangranados.com/apps/airtool