¿Tiene una cuenta?
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
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).
Cisco recomienda que tenga conocimiento sobre estos temas:
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.
Nota: El público objetivo de este documento son ingenieros y administradores de redes inalámbricas experimentados que ya están familiarizados con el uso, la configuración y la resolución de problemas de estos temas.
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.
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:
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
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:
Comandos > Cargar archivo > Configuración > Cargar como se muestra en la imagen.
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
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
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:
Nota: Cualquier información o nota adicional con respecto a los dispositivos cliente hasta los cuales se incluyen capturas de pantalla de sus configuraciones relacionadas con WLAN, y así sucesivamente, también se debe incluir según sea necesario.
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.
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:
Nota: Todas las depuraciones y capturas de paquetes recopiladas deben sincronizarse con el mismo servidor NTP para facilitar la correlación con los registros y deben tomarse al mismo tiempo para cualquier prueba dada.
Nota: Proporcione una indicación de fecha y hora precisa del momento en que se observa el problema y del momento en que parece recuperarse (si procede).
Nota: Recopile siempre los debugs filtrados por dirección MAC del cliente tanto en el AP como en el WLC.
Nota: No ejecute los comandos show y debug en el AP dentro de la misma sesión Telnet/SSH/console, éstos se deben realizar por separado en una sesión diferente en consecuencia.
Nota: Los debugs AP son preferibles para ser tomados en Telnet/SSH versus Console, ya que la consola es generalmente demasiado lenta para ser efectiva.
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.
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:
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
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.
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.
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
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
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
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
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
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
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
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.
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.
Nota: Si las pruebas en cuestión implican un escenario de itinerancia del dispositivo cliente, por el cual más de un canal 802.11 debe ser monitoreado en una captura de paquetes agregada. A continuación, 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 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:
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.
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.
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.
Recopile esto de la CLI del WLC en cuestión:
Alternativamente, también puede recopilar sólo estos resultados según sea necesario:
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
Nota: Cualquier parámetro de cliente cambió 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.)
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.)
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.
Recopile estos debugs del WLC a través de la CLI:
Agregue las depuraciones adicionales caso por caso:
Recopile el resultado de los comandos show del WLC a través de la CLI:
Una vez finalizada la prueba, utilice este comando para detener todas las depuraciones actuales en el WLC:
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:
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:
Recopile estos debugs AP a través de la CLI:
Una vez finalizada la prueba, utilice este comando para inhabilitar las depuraciones:
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:
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:
Para los puntos de acceso de la serie 1800, recopile estos debugs AP a través de la CLI:
Para los puntos de acceso de las series 2800/3800, recopile estos debugs AP a través de la CLI:
Una vez finalizada la prueba, utilice este comando para inhabilitar las depuraciones:
Recopile un Netmon 3.4 promiscuo (sólo Windows XP o 7) o captura de paquetes Wireshark del adaptador WLAN del dispositivo cliente.
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 --
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:
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
14-May-2016 |
Versión inicial |