Solución de problemas de fragmentación: Afecta al controlador inalámbrico c9800 con Azure

Introducción

Este documento describe un problema conocido con la plataforma de Azure que conduce a la pérdida de paquetes debido al mal manejo de fragmentos fuera de secuencia.

Síntomas

Productos afectados: Controlador inalámbrico Catalyst 9800-CL alojado en Azure o Identity Service Engine alojado en Azure.

Configuración de SSID: Configurado para 802.1x EAP-TLS con autenticación central.

Conducta: Mientras utiliza el 9800-CL alojado en la plataforma Azure con un SSID basado en EAP-TLS, puede encontrar problemas de conectividad. Los clientes pueden encontrar dificultades durante la fase de autenticación.

Error en el servidor ISE

Código de error 5411 que indica que el solicitante ha dejado de comunicarse con ISE durante el intercambio de certificados EAP-TLS.

Análisis de registro detallado:

A continuación se muestra una ilustración de una de las configuraciones afectadas: En el controlador inalámbrico 9800, el SSID se configura para 802.1x y el servidor AAA se configura para EAP-TLS. Cuando un cliente intenta la autenticación, especialmente durante la fase de intercambio de certificados, el cliente envía un certificado que excede el tamaño de la unidad de transmisión máxima (MTU) en el controlador inalámbrico. A continuación, el controlador inalámbrico 9800 fragmenta este paquete grande y envía los fragmentos secuencialmente al servidor AAA. Sin embargo, estos fragmentos no llegan en el orden correcto al host físico, lo que lleva a la caída de paquetes.

Estos son los rastros de RA del controlador inalámbrico cuando el cliente intenta conectarse:
El cliente ingresa en el estado de autenticación L2 y se inicia el proceso EAP

2023/04/12 16:51:27.606414 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [Client_MAC:capwap_90000004] Ingresando el estado de la solicitud
2023/04/12 16:51:27.606425 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [0000.0000.0000:capwap_90000004] Enviando paquetes EAPOL
2023/04/12 16:51:27.606494 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [Client_MAC:capwap_90000004] Paquete EAPOL enviado - Versión: 3,Tipo EAPOL: EAP, longitud de carga útil: 1008, EAP-Tipo = EAP-TLS
2023/04/12 16:51:27.606496 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [Client_MAC:capwap_90000004] Paquete EAP - REQUEST, ID: 0x25
2023/04/12 16:51:27.606536 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [Client_MAC:capwap_90000004] Paquete EAPOL enviado al cliente
2023/04/12 16:51:27.640768 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [Client_MAC:capwap_90000004] Paquete EAPOL recibido - Versión: 1,Tipo EAPOL: EAP, longitud de carga útil: 6, EAP-Tipo = EAP-TLS
2023/04/12 16:51:27.640781 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [Client_MAC:capwap_90000004] Paquete EAP - RESPUESTA, ID: 0x25

Cuando el controlador inalámbrico envía la solicitud de acceso al servidor AAA y el tamaño del paquete es inferior a 1500 bytes (que es la MTU predeterminada en el controlador inalámbrico), el desafío de acceso se recibe sin ninguna complicación.

2023/04/12 16:51:27.641094 {wncd_x_R0-0}{1}: [radius] [19224]: (información): RADIUS: Send Access-Request to 172.16.26.235:1812 id 0/6, len 552
2023/04/12 16:51:27.644693 {wncd_x_R0-0}{1}: [radius] [19224]: (información): RADIUS: Recibido desde id 1812/6 172.16.26.235:0, Access-Challenge, len 1141

A veces, un cliente puede enviar su certificado para la autenticación. Si el tamaño del paquete excede la MTU, se fragmentará antes de enviarse más lejos.

2023/04/12 16:51:27.758366 {wncd_x_R0-0}{1}: [radius] [19224]: (información): RADIUS: Send Access-Request to 172.16.26.235:1812 id 0/8, len 2048
2023/04/12 16:51:37.761885 {wncd_x_R0-0}{1}: [radius] [19224]: (información): RADIUS: Tiempo de espera iniciado 5 s
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}: [radius] [19224]: (información): RADIUS: Retransmitir a (172.16.26.235:1812,1813) para id 0/8
2023/04/12 16:51:32.759255 {wncd_x_R0-0}{1}: [radius] [19224]: (información): RADIUS: Retransmitir a (172.16.26.235:1812,1813) para id 0/8
2023/04/12 16:51:32.760328 {wncd_x_R0-0}{1}: [radius] [19224]: (información): RADIUS: Tiempo de espera iniciado 5 s
2023/04/12 16:51:37.760552 {wncd_x_R0-0}{1}: [radius] [19224]: (información): RADIUS: Retransmitir a (172.16.26.235:1812,1813) para id 0/8
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}: [radius] [19224]: (información): RADIUS: Retransmitir a (172.16.26.235:1812,1813) para id 0/8

Hemos observado que el tamaño del paquete es 2048, lo que supera la MTU predeterminada. En consecuencia, no ha habido respuesta del servidor AAA. El controlador inalámbrico volverá a enviar la solicitud de acceso de forma persistente hasta que alcance el número máximo de reintentos. Debido a la ausencia de una respuesta, el controlador inalámbrico restablecerá finalmente el proceso EAPOL.

2023/04/12 16:51:45.762890 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [Client_MAC:capwap_90000004] Publicando EAPOL_START en el cliente
2023/04/12 16:51:45.762956 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [Client_MAC:capwap_90000004] Ingresando al estado de inicialización
2023/04/12 16:51:45.762965 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [Client_MAC:capwap_90000004] Publicando !AUTH_ABORT en el cliente
2023/04/12 16:51:45.762969 {wncd_x_R0-0}{1}: [dot1x] [19224]: (información): [Client_MAC:capwap_90000004] Ingresando al estado de reinicio

Este proceso entra en loop y el cliente está atascado en la fase de autenticación solamente.

La captura de paquetes incorporada capturada en el controlador inalámbrico muestra que después de varias solicitudes de acceso y de intercambios de desafío con una MTU inferior a 1500 bytes, el controlador inalámbrico envía una solicitud de acceso superior a 1500 bytes, que contiene el certificado del cliente. Este paquete más grande sufre fragmentación. Sin embargo, no hay respuesta a esta solicitud de acceso en particular. El controlador inalámbrico continúa reenviando esta solicitud hasta que alcanza el número máximo de reintentos, después de lo cual se reinicia la sesión EAP-TLS. Esta secuencia de eventos se repite constantemente, lo que indica que se produce un loop EAP-TLS cuando el cliente intenta autenticarse. Consulte las capturas de paquetes simultáneas del controlador inalámbrico y de ISE que se proporcionan a continuación para obtener una comprensión más clara.

Controlador inalámbrico EPC:

Captura de paquetes en WLC

Observamos que el controlador inalámbrico está enviando varias solicitudes duplicadas para un ID de solicitud de acceso específico = 8

Nota: En el EPC, también observamos que hay una única solicitud duplicada para otras ID. Esto nos lleva a la pregunta: ¿Se prevé tal duplicación? La respuesta a si se espera esta duplicación es sí, lo es. La razón es que la captura se tomó de la GUI del controlador inalámbrico con la opción 'Monitor Control Plane' seleccionada. Como resultado, es normal observar varias instancias de paquetes RADIUS ya que están siendo dirigidos a la CPU. En estos casos, las solicitudes de acceso deben verse con las direcciones MAC de origen y destino establecidas en 00:00:00.

Radius Access-Request Punted to CPU on WLC

Sólo las solicitudes de acceso con las direcciones MAC de origen y destino especificadas deben enviarse realmente desde el controlador inalámbrico.

Solicitud de acceso Radius enviada al servidor AAA

Las solicitudes de acceso en cuestión, identificadas por ID = 8, que se envían varias veces y para las que no se ha visto ninguna respuesta del servidor AAA. Tras una investigación adicional, observamos que para Access-request ID=8, la fragmentación UDP se produce debido al tamaño que supera la MTU, como se ilustra a continuación:

Fragmentación que tiene lugar en la captura de paquetes WLC

Paquete fragmentado: I

Paquete fragmentado - II

Paquete reensamblado

Para llevar a cabo la verificación cruzada, revisamos los registros de ISE y descubrimos que ISE no estaba recibiendo la solicitud de acceso, que se había fragmentado en el controlador inalámbrico.

Volcados de ISE TCP

Capturas al final de ISE

Azure Side Capture con análisis:

El equipo de Azure realizó una captura en el host físico de Azure. Los datos capturados en el vSwitch dentro del host de Azure indican que los paquetes UDP están llegando fuera de secuencia. Debido a que estos fragmentos UDP no están en el orden correcto, Azure los está descartando. A continuación se muestran las capturas del extremo de Azure y del controlador inalámbrico, tomadas simultáneamente para el ID de solicitud de acceso = 255, donde el problema de los paquetes que están fuera de servicio es claramente evidente:
La captura de paquetes encapsulados (EPC) del controlador inalámbrico muestra la secuencia en la que los paquetes fragmentados salen del controlador inalámbrico. 

Secuencia de paquetes fragmentados en WLC

En el host físico, los paquetes no llegan en la secuencia adecuada

Capturas en Azure End

Dado que los paquetes llegan en el orden incorrecto y el nodo físico está programado para rechazar cualquier trama fuera de orden, los paquetes se descartan inmediatamente. Esta interrupción hace que el proceso de autenticación falle, dejando al cliente incapaz de avanzar más allá de la fase de autenticación.

Solución sugerida desde el extremo del controlador inalámbrico:

A partir de la versión 17.11.1, estamos implementando el soporte para tramas Jumbo en paquetes Radius/AAA. Esta función permite que el controlador c9800 evite la fragmentación de paquetes AAA, siempre que se establezca la siguiente configuración en el controlador. Tenga en cuenta que para evitar la fragmentación completa de estos paquetes, es esencial asegurarse de que cada salto de red, incluido el servidor AAA, sea compatible con los paquetes de tramas gigantes. Para ISE, la compatibilidad con tramas gigantes comienza a partir de la versión 3.1.
Configuración de la interfaz en el controlador inalámbrico:

C9800-CL(config)#interface C9800-CL(config-if) # mtu C9800-CL(config-if) # ip mtu [1500 to 9000]

Configuración de servidor AAA en controlador inalámbrico:

C9800-CL(config)# aaa group server radius C9800-CL(config-sg-radius) # server name C9800-CL(config-sg-radius) # ip radius source-interface

A continuación se presenta una breve descripción de un paquete Radius cuando la MTU (unidad de transmisión máxima) se configura en 3000 bytes en un controlador de LAN inalámbrica (WLC). Los paquetes menores de 3000 bytes se enviaron sin problemas sin necesidad de fragmentación:

Captura de paquetes en WLC con MTU aumentada

Al establecer la configuración de esta manera, el controlador inalámbrico transmite los paquetes sin fragmentarlos, enviándolos intactos. Sin embargo, como la nube de Azure no admite tramas jumbo, esta solución no se puede implementar.

Solución:

• En la captura de paquetes encapsulados (EPC) del controlador inalámbrico, observamos que los paquetes se envían en el orden correcto. Es responsabilidad del host receptor volver a ensamblarlos correctamente y continuar con el procesamiento, que, en este caso, no se produce en el lado de Azure.
• Para resolver el problema de los paquetes UDP fuera de servicio,enable-udp-fragment-reorderingdebe activarse la opción en Azure.
• Debe ponerse en contacto con el equipo de soporte técnico de Azure para obtener ayuda con este asunto. Microsoft ha reconocido este problema.
  
  

  Nota: Debe tenerse en cuenta que este problema no es exclusivo del controlador de LAN inalámbrica (WLC). Problemas similares con paquetes UDP fuera de servicio se han encontrado en diferentes servidores RADIUS, incluidos los servidores ISE, Forti Authenticator y RTSP, especialmente cuando funcionan dentro del entorno de Azure.