Comprender las depuraciones inalámbricas y la recopilación de registros en los controladores de LAN inalámbrica Catalyst 9800

Introducción

Este documento describe y proporciona una descripción general de todas las funciones y capacidades de Cisco IOS® XE aprovechadas para la resolución de problemas de flujos de trabajo inalámbricos en Cisco Catalyst 9800 Series Wireless LAN Controllers. Es genérico y se aplica a muchos escenarios de uso.

Prerequisites

Requirements

• Conocimiento básico de los controladores de LAN inalámbrica (WLC).
• Conocimiento básico de los flujos de casos de uso involucrados en el uso de un WLC.

Componentes Utilizados

Este documento cubre los controladores 9800-CL, 9800-L, 9800-40 y 9800-80. Se basa principalmente en la versión 16.12 de Cisco IOS® XE.

Antecedentes

Cisco IOS® XE que se ejecuta en 9800 WLC está compuesto esencialmente por un Linux Kernel (binOS) con Cisco IOS® y todos los procesos inalámbricos implementados como demonios. Todos los demonios de proceso se pueden incluir en el término genérico Plano de control (CP) y son responsables del control y aprovisionamiento de puntos de acceso (CAPWAP), movilidad, gestión de recursos de radio (RRM). Gestión no autorizada, protocolo de servicio de movilidad de red (NMSP) que se dirigen a y desde el WLC 9800.

El plano de datos (DP) se refiere a los componentes de reenvío de datos en el WLC 9800.

En todas las iteraciones de 9800 (9800-40, 9800-80, 9800-CL, 9800-SW, 9800-L), el plano de control sigue siendo bastante común. Sin embargo, el plano de datos varía con 9800-40 y 9800-80 mediante el procesador Quantum Flow (QFP) de hardware similar a ASR1k, mientras que 9800-CL y 9800-L utilizan la implementación de software del procesador Cisco Packet Processor (CPP). 9800-SW simplemente aprovecha el chipset Doppler en los switches Catalyst 9k Series para el reenvío de datos.

Flujo de paquetes dentro del WLC 9800

Cuando un paquete ingresa al WLC 9800 desde los puertos físicos, si se determina que es tráfico de control, se envía a los procesos del plano de control correspondientes. Para una unión AP, esto sería todo el intercambio capwap y dtls originado en AP. En el caso de la unión del cliente, éste sería todo el tráfico originado desde el cliente hasta que el cliente vaya al estado RUN siga la trayectoria PUNT.

A medida que los diversos demonios procesan el tráfico entrante, el tráfico de retorno resultante (respuesta capwap, punto11, punto1x, respuesta dcp) originado en el WLC 9800 que se envía al cliente se inyecta nuevamente en el plano de datos para que se envíe al puerto físico. A medida que procesamos las uniones AP, la unión del cliente, los intercambios de movilidad, el plano de datos debe programarse para que pueda manejar el reenvío del tráfico de datos. Esto ocurre con varios componentes programados secuencialmente en la ruta de programación indicada en la imagen.

Cisco IOS® XE proporciona un conjunto de herramientas versátil para rastrear el paquete desde el momento en que ingresa al WLC 9800 hasta que el tráfico procesado deja la caja. La siguiente sección presenta estas herramientas junto con los comandos utilizados para invocar estas herramientas desde la interfaz de línea de comandos (CLI).

Seguimiento del plano de control

Esta sección describe los comandos y herramientas disponibles para ver el procesamiento hecho por los procesos del plano de control después de que el paquete destinado a 9800 WLC haya sido arrancado de DP o antes de inyectar el paquete de respuesta originado desde 9800 WLC al DP para enviar la interfaz física

Syslog

Los registros generados por el WLC 9800 son el primer medio para verificar el estado general del sistema. Cualquier violación del umbral predefinido para los recursos del sistema como la CPU, la memoria y las memorias intermedias se informa en el registro. Además, cualquier error generado por cualquier subsistema se escribe en los registros. Para ver los registros, navegue hasta Solución de problemas > Syslog

o ejecute el comando CLI:

# show logging

Esta salida muestra los registros generales así como algunos registros específicos de la red inalámbrica. Sin embargo, a diferencia de Cisco IOS® heredado, ninguna depuración inalámbrica suele llegar a este resultado de registro.

Nota: Si el WLC9800 está configurado para redirigir estos registros a un servidor syslog externo, entonces usted también debe verificar los registros en el servidor syslog externo.

Seguimiento siempre activo

Cada proceso del plano de control en el WLC9800 se registra constantemente en el nivel de registro de Aviso a su propio búfer dedicado. Esto se denomina seguimiento siempre activo. Se trata de una capacidad única que le permite obtener datos contextuales sobre una falla que se ha producido sin que se requiera la reproducción de la condición de falla.

Por ejemplo, si está familiarizado con AireOS, para cualquier solución de problemas de conectividad del cliente, necesitará habilitar depuraciones y reproducir el estado del problema de conectividad del cliente para identificar la causa raíz. Con el seguimiento siempre activo, puede volver la vista atrás a los rastros ya capturados e identificar si se trata de una causa raíz común.  Dependiendo del volumen de registros generados, podemos mirar hacia atrás varias horas o varios días.

Ahora, mientras que los seguimientos se registran por proceso individual, es posible verlos de forma completa para un contexto particular de interés como MAC del cliente o MAC AP o dirección IP AP. Para hacerlo, ejecute el comando

# show logging profile wireless filter mac  to-file bootflash:

Para ver los registros por proceso, ejecute el comando

# show logging process  to-file bootflash:

Nota: Hay varias opciones de filtrado en estas CLI, incluidos el módulo, el nivel de registro, la marca de hora de inicio, etc. Para ver y explorar estas opciones, ejecute el comando

# show logging profile wireless ?
# show logging process  ?

Seguimiento de fallos

Para obtener una instantánea rápida de las condiciones de falla conocidas habitualmente, está disponible la función de seguimiento de fallos. Esto analiza todos los seguimientos del sistema en el momento dado para que coincidan con las condiciones de falla predefinidas y presenta la vista de resumen así como estadísticas. 

Para obtener una vista de resumen, ejecute el comando

# show logging trace-on-failure summary

Para ver las condiciones de falla predefinidas así como las estadísticas correspondientes a estas condiciones, ejecute el comando

# show wireless stats trace-on-failure 

Una vez que conozca la falla, para recopilar seguimientos específicos del contexto de la falla, ejecute el comando

# show logging profile wireless filter uuid  to-file bootflash:tof-FILENAME.txt

Estos se pueden ver en la sesión de terminal o exportarse para el análisis fuera de línea con los comandos

# more bootflash:tof-FILENAME.txt
OR
# copy bootflash:tof-FILENAME.txt { tftp: | ftp: | scp: | https: } tof-FILENAME.txt

Depuración condicional y seguimiento de RadioActive

La depuración condicional permite habilitar el registro del nivel de depuración para funciones específicas según las condiciones de interés. El seguimiento de RadioActive lo lleva un paso más allá al agregar la capacidad de imprimir condicionalmente la información de depuración entre procesos, subprocesos para la condición de interés. Esto significa que la arquitectura subyacente es completamente abstracta.

Nota: En 16.12, el seguimiento radioactivo se implementa solamente para la resolución de problemas de unión de AP usando direcciones MAC de radio y Ethernet, unión del cliente usando dirección MAC del cliente, así como problemas de movilidad usando la conectividad ip de peer de movilidad y CMX usando la dirección ip CMX como condiciones de interés.

Nota: El uso de la dirección MAC frente a la dirección IP como condición proporciona resultados diferentes, ya que diferentes procesos son conscientes de diferentes identificadores para la misma entidad de red (AP o cliente o peer de movilidad).

Utilizando la solución de problemas de conectividad del cliente, como ejemplo, la depuración condicional se ejecuta para que el cliente mac llegue a la vista de extremo a extremo en el plano de control.

Rastreo radiactivo a través de la interfaz de usuario web

Vaya al menú Solución de problemas de la página y elija Rastreo radiactivo

Haga clic en Agregar e ingrese una dirección MAC de cliente o AP que desee resolver problemas.  A partir de 16.12, sólo se pueden agregar direcciones mac a través de la GUI. Puede agregar una dirección IP a través de la CLI.

Puede agregar varias direcciones mac para realizar el seguimiento. Cuando esté listo para iniciar el seguimiento radiactivo, haga clic en iniciar.

Una vez iniciado, el registro de depuración se escribe en el disco acerca de cualquier procesamiento del plano de control relacionado con las direcciones mac rastreadas.

Cuando reprodujo el problema que desea resolver, haga clic en Detener.

Para cada dirección mac depurada, puede generar un archivo de registro que coordine todos los registros pertenecientes a esa dirección mac haciendo clic en Generar.

Elija cuánto tiempo más atrás desea que pase su archivo de registro recopilado y pulse Aplicar al dispositivo.

Ahora puede descargar el archivo haciendo clic en el pequeño icono situado junto al nombre del archivo. Este archivo está presente en la unidad bootflash del controlador y también se puede copiar desde el equipo a través de la CLI.

Rastreos radiactivos a través de CLI

Para habilitar la depuración condicional, ejecute el comando

# debug wireless {mac | ip} {aaaa.bbbb.cccc | x.x.x.x } {monitor-time} {N seconds}

Para ver las condiciones actualmente activadas, ejecute el comando

# show debugging

Estas depuraciones no imprimen ningún resultado en la sesión de terminal, sino que almacenan el archivo de salida de debug en flash para recuperarlo y analizarlo después. El archivo se guarda con la convención de nomenclatura ra_trace_*

Por ejemplo, para la dirección mac aaaa.bbbb.cccc, el nombre de archivo generado es ra_trace_MAC_aaabbbccc_HMMSS.XXX_timezone_DayWeek_Month_Day_year.log

Una ventaja es que se puede utilizar el mismo comando para resolver problemas de unión de AP (MAC de radio AP de entrada y MAC Ethernet), problemas de conectividad del cliente (MAC de cliente de entrada), problemas de túnel de movilidad (ip de peer de entrada), problemas de roaming del cliente (MAC de cliente de entrada). En otras palabras, no tiene que recordar varios comandos como debug capwap, debug client, debug mobility, etc.

Nota: debug wireless también permite apuntar a un servidor FTP y ejecutar un registro aún más detallado usando la palabra clave internal. No recomendamos usarlas en este momento, ya que se están solucionando algunos problemas.

Para depurar el archivo de salida en la sesión de terminal, ejecute el comando

# more bootflash:ra_trace_MAC_*.log 

Para redirigir el resultado de la depuración a un servidor externo para el análisis fuera de línea, ejecute el comando

# copy bootflash:ra_trace_MAC_*.log ftp://username:password@FTPSERVERIP/path/RATRACE_FILENAME.txt

Hay una vista mucho más detallada de los mismos niveles de registro de depuración. para ver esta vista detallada, ejecute el comando

# show logging profile wireless internal filter mac  to-file 

Para inhabilitar la depuración para un contexto específico o antes de que el tiempo de monitor configurado o predeterminado esté activo, ejecute el comando.

# no debug wireless mac <aaaa.bbbb.cccc>

Precaución: La depuración condicional habilita el registro del nivel de depuración, lo que a su vez aumenta el volumen de los registros generados. Al dejar esta ejecución, se reduce el tiempo transcurrido desde el que se pueden ver los registros. Por lo tanto, se recomienda desactivar siempre la depuración al final de la sesión de resolución de problemas.

 Para inhabilitar todos los debugging, ejecute estos comandos

# clear platform condition all
# undebug all

Debugging No Condicional Por Proceso

Para los casos prácticos y procesos, no implementados para el seguimiento radioactivo, puede obtener seguimientos de nivel de depuración. Para establecer el nivel de depuración en un proceso específico, utilice el comando

# set platform software trace <PROCESS_NAME> wireless chassis active R0 { module_name | all-modules } 

Para verificar los niveles de seguimiento de los diversos módulos, ejecute el comando

# show platform software trace level <PROCESS_NAME> chassis active R0

Para ver los seguimientos recopilados, ejecute el comando

# show logging process  to-file 

Seguimiento de paquetes del plano de datos

Cuando un paquete ingresa por primera vez al WLC 9800, algún procesamiento ocurre en el plano de datos para identificar si el tráfico es el plano de control o el plano de datos. La función Packet-Trace proporciona una vista detallada de este procesamiento de Cisco IOS® XE realizado en el plano de datos y la decisión tomada sobre si se debe perforar, reenviar, descartar o consumir el paquete. Esta función en el WLC 9800 funciona exactamente igual que la implementación en ASR!k.

Packet Tracer en el WLC 9800 proporciona tres niveles de inspección iguales a ASR1K.

• Estadísticas: proporciona el recuento de paquetes que entran y salen del procesador de red
• Summary-
  • Esto se recopila para un número finito de paquetes que coinciden con la condición específica de interés.
  • El resultado de resumen indica las interfaces de ingreso y egreso, la decisión de búsqueda realizada por el plano de datos y también realiza un seguimiento de los paquetes de inserción, descarte e inyección, si los hay.
  • Esta salida proporciona una vista concisa del procesamiento del plano de datos
• Path Data - Esto proporciona la vista más detallada de la gestión de paquetes DP. Recolectada para el número finito de paquetes, incluye la ID de depuración condicional que se puede utilizar para correlacionar el paquete DP con las depuraciones del plano de control, la marca de tiempo así como los datos específicos de trayectoria-seguimiento de la función. Esta vista detallada tiene dos funciones opcionales
  • La copia de paquetes permite copiar paquetes de entrada y salida en varias capas del paquete (capa 2, capa 3 y capa 4)
  • Feature Invocation array (FIA) es la lista secuencial de funciones que el plano de datos ejecuta en el paquete. Estas funciones derivan de la configuración predeterminada y habilitada por el usuario en el WLC 9800

Para obtener una explicación detallada de la función y las subopciones, refiérase a la Función de Seguimiento de Paquetes Datapath de Cisco IOS XE

Para flujos de trabajo inalámbricos como la conexión AP, la conectividad del cliente, etc., el seguimiento del link ascendente bidireccional

Precaución: El trazador de paquetes del plano de datos sólo analiza el encabezado CAPWAP externo. Por lo tanto, las condiciones como el mac del cliente inalámbrico no producen resultados útiles.

 Paso 1. Definir la condición de interés.

# debug platform condition { interface | mac | ingress | egress | both | ipv4 | ipv6 | mpls | match }

Advertencia: Tanto los comandos - función de condición de la plataforma de depuración como la condición de la plataforma de depuración mac aaaa.bbb.cccc están diseñados para el seguimiento de paquetes del plano de control y no devuelven ningún rastro de paquetes del plano de datos.

Paso 2. Habilitar depuración condicional.

# debug platform condition start

Paso 3. Para ver las condiciones actualmente activadas, ejecute el comando

# show platform conditions

Paso 4. Habilite packet-tracer para un número finito de paquetes. Este número de paquete se define como una potencia de 2 en el rango de 16 a 8192. De forma predeterminada, se capturan los datos de resumen y de función. Opcionalmente, sólo puede obtener una vista de resumen mediante la subopción de sólo resumen. También tiene sub-opciones disponibles para obtener el seguimiento de fia, definiendo el tamaño del paquete en bytes, trace punt, inject o drop packets. y más.

# debug platform packet-tracer packet <packet-number> {fia-trace}

Paso 5. (Opcionalmente) Puede copiar y volcar los paquetes a medida que se les rastrea

# debug platform packet-trace copy packet both size 2048 { l2 | l3 | l4 }

Paso 6. Para ver si packet-trace está recopilando algún resultado, verifique las estadísticas

# show platform packet-trace statistics

Paso 7. Para ver el resultado del packet-trace, ejecute el comando

# show platform packet-tracer summary

 Paso 8. (Opcional) Puede exportar el vaciado de paquetes para su análisis sin conexión por parte del TAC de Cisco

# show platform packet-trace packet all | redirect { bootflash: | tftp: | ftp: } pactrac.txt

Captura de paquetes integrada

La captura de paquetes integrada (EPC) es una función de captura de paquetes que permite ver los paquetes destinados a los WLC de Catalyst 9800, que provienen de ellos y pasan a través de ellos. Estas capturas se pueden exportar para análisis fuera de línea mediante Wireshark. Para obtener más detalles sobre la función, consulte la Guía de configuración de EPC

En comparación con AireOS, en lugar de confiar en la captura de paquetes y las capacidades de duplicación de tráfico en el switch de link ascendente, el WLC 9800 permite la captura pcap en la caja misma. En 9800, esta captura se puede configurar tanto desde la interfaz de línea de comandos (CLI) como en la interfaz gráfica de usuario (GUI).

Para configurar a través de la GUI, navegue hasta Solución de problemas > Captura de paquetes > +Agregar

Paso 1. Defina el nombre de la captura de paquetes. Se permite un máximo de 8 caracteres.

Paso 2. Definir filtros, si los hay

Paso 3. Marque la casilla Monitor Control Traffic (Supervisión del tráfico de control) si desea ver el tráfico dirigido a la CPU del sistema e inyectado de nuevo en el plano de datos

Paso 4. Defina el tamaño del búfer. Se permite un máximo de 100 MB

Paso 5. Defina el límite, ya sea por la duración que permite un rango de 1 - 100000 segundos o por el número de paquetes que permite un rango de 1 - 100000 paquetes, según lo deseado

Paso 6. Elija la interfaz de la lista de interfaces de la columna izquierda y seleccione la flecha para moverla a la columna derecha

Paso 7. Guardar y aplicar al dispositivo

Paso 8. Para iniciar la captura, seleccione Inicio

Paso 9. Puede permitir que la captura se ejecute hasta el límite definido. Para detener manualmente la captura, seleccione Detener.

Paso 10. Una vez detenido, un botón Export está disponible para hacer clic con la opción de descargar el archivo de captura (.pcap) en el escritorio local a través de https o servidor TFTP o servidor FTP o disco duro del sistema local o flash.

Nota: CLI proporciona un poco más de granularidad de las opciones, como Limit by. La GUI es suficiente para capturar paquetes para casos prácticos comunes.

Para configurar mediante CLI:

Cree la captura del monitor:

monitor capture CAP interface <uplink_of_the_9800> both

Asociar un filtro. El filtro se puede especificar en línea o se puede hacer referencia a una ACL o a un mapa de clase.

En este ejemplo, es la ACL para hacer coincidir el tráfico entre las 2 direcciones ip del 9800 y otro WLC 5520. Situación típica para la resolución de problemas de movilidad:

conf t

ip access-list extended mobilitywlcs
permit ip host <5520_ip_address> host <9800_ip_address>
     permit ip host <9800_ip_address> host <5520_ip_address>
end

monitor capture MobilityCap access-list mobilitywlcs

Si desea que la captura se ejecute en un búfer circular, le da tiempo para detectar el problema y luego detener la captura y guardarla.

Si lo configura en un búfer de 50 MB, por ejemplo. Se necesita un máximo de 50 MB de disco en el 9800 y es bastante grande para capturar varios minutos de datos con la esperanza de que se produzca el problema.

monitor capture MobilityCap buffer circular size 50

Inicie la captura. Puede acceder a ella desde GUI o CLI:

monitor capture CAP start

La captura ya está activa.

Permitirle recopilar los datos necesarios.

Detenga la captura. Puede hacerlo mediante GUI o CLI:

monitor capture MobilityCap stop

Puede recuperar la captura desde la GUI > Solución de problemas > Captura de paquetes > Exportar.

O bien, cargue en un servidor desde CLI. Ejemplo vía ftp:

monitor capture MobilityCap export ftp://x.x.x.x/MobilityCAP.pcap

Una vez recopilados los datos necesarios, elimine la captura:

no monitor capture MobilityCAP

LED de alarma y alarmas de plataforma crítica

Todos los dispositivos 9800 (9800-L, 9800-40 y 9800-80) tienen un LED ALM en su panel frontal. Si esa luz se pone roja, significa que hay una alarma crítica en la plataforma.

Puede verificar las alarmas que hacen que el LED se vuelva rojo con el comando show Facility-alarm status

WLC#show facility-alarm status
System Totals  Critical: 2  Major: 0  Minor: 0

Source                     Time                   Severity      Description [Index]
------                     ------                 --------      -------------------
TenGigabitEthernet0/1/0    Jul 26 2019 15:14:04   CRITICAL      Physical Port Link Down [1]
TenGigabitEthernet0/1/1    Jul 26 2019 15:14:04   CRITICAL      Physical Port Link Down [1]