Solucionar problemas de fragmentação: Afetando o c9800 Wireless Controller com o Azure

Introdução

Este documento descreve um problema conhecido com a plataforma Azure que leva à perda de pacotes devido ao manuseio incorreto de fragmentos fora de sequência.

Sintomas

Produtos afetados: O Catalyst 9800-CL Wireless Controller hospedado no Azure ou o Identity Service Engine hospedado no Azure.

Configuração de SSID: Configurado para EAP-TLS 802.1x com autenticação central.

Conduta: Ao utilizar o 9800-CL hospedado na plataforma Azure com um SSID baseado em EAP-TLS, você pode encontrar problemas de conectividade. Os clientes podem encontrar dificuldades durante a fase de autenticação.

Erro no servidor ISE

Código de erro 5411 indicando que o requerente parou de se comunicar com o ISE durante a troca de certificado EAP-TLS.

Análise detalhada de log:

Aqui está uma ilustração de uma das configurações afetadas: No controlador sem fio 9800, o SSID é configurado para 802.1x e o servidor AAA é configurado para EAP-TLS. Quando um cliente tenta a autenticação, particularmente durante a fase de troca de certificado, o cliente envia um certificado que excede o tamanho da unidade de transmissão máxima (MTU) no controlador sem fio. Em seguida, o controlador sem fio 9800 fragmenta esse grande pacote e envia os fragmentos sequencialmente para o servidor AAA. No entanto, esses fragmentos não chegam na ordem correta no host físico, levando à queda do pacote.

Aqui estão os rastreamentos de RA do controlador sem fio quando o cliente está tentando se conectar:
O cliente entrando no estado de autenticação L2 e o processo EAP é iniciado

04/2023/12 16:51:27.606414 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [Client_MAC:capwap_90000004] Entrando no estado de solicitação
04/2023/12 16:51:27.606425 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [0000.0000.0000:capwap_90000004] Enviando pacote EAPOL
04/2023/12 16:51:27.606494 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [Client_MAC:capwap_90000004] Pacote EAPOL enviado - Versão: 3,Tipo EAPOL : EAP, Comprimento do payload: 1008, Tipo de EAP = EAP-TLS
04/2023/12 16:51:27.606496 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [Client_MAC:capwap_90000004] Pacote EAP - SOLICITAÇÃO, ID: 0x25
04/2023/12 16:51:27.606536 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [Client_MAC:capwap_90000004] Pacote EAPOL enviado ao cliente
04/2023/12 16:51:27.640768 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [Client_MAC:capwap_90000004] Pacote EAPOL recebido - Versão: 1,Tipo EAPOL : EAP, Comprimento do payload: 6, Tipo de EAP = EAP-TLS
04/2023/12 16:51:27.640781 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [Client_MAC:capwap_90000004] Pacote EAP - RESPOSTA, ID: 0x25

Quando o controlador Wireless envia a solicitação de acesso ao servidor AAA e o tamanho do pacote está abaixo de 1500 bytes (que é o MTU padrão no controlador Wireless), o desafio de acesso é recebido sem complicações.

04/2023/12 16:51:27.641094 {wncd_x_R0-0}{1}: [raio] [19224]: (informações): RADIUS: Enviar solicitação de acesso para 172.16.26.235:1812 id 0/6, len 552
04/2023/12 16:51:27.644693 {wncd_x_R0-0}{1}: [raio] [19224]: (informações): RADIUS: Recebido de id 1812/6 172.16.26.235:0, Access-Challenge, len 1141

Às vezes, um cliente pode enviar seu certificado para autenticação. Se o tamanho do pacote exceder a MTU, ele será fragmentado antes de ser enviado posteriormente.

04/2023/12 16:51:27.758366 {wncd_x_R0-0}{1}: [raio] [19224]: (informações): RADIUS: Enviar solicitação de acesso para 172.16.26.235:1812 id 0/8, len 2048
04/2023/12 16:51:37.761885 {wncd_x_R0-0}{1}: [raio] [19224]: (informações): RADIUS: Iniciado o tempo limite de 5 segundos
04/2023/12 16:51:42.762096 {wncd_x_R0-0}{1}: [raio] [19224]: (informações): RADIUS: Retransmitir para (172.16.26.235:1812,1813) para id 0/8
04/2023/12 16:51:32.759255 {wncd_x_R0-0}{1}: [raio] [19224]: (informações): RADIUS: Retransmitir para (172.16.26.235:1812,1813) para id 0/8
04/2023/12 16:51:32.760328 {wncd_x_R0-0}{1}: [raio] [19224]: (informações): RADIUS: Iniciado o tempo limite de 5 segundos
04/2023/12 16:51:37.760552 {wncd_x_R0-0}{1}: [raio] [19224]: (informações): RADIUS: Retransmitir para (172.16.26.235:1812,1813) para id 0/8
04/2023/12 16:51:42.762096 {wncd_x_R0-0}{1}: [raio] [19224]: (informações): RADIUS: Retransmitir para (172.16.26.235:1812,1813) para id 0/8

Observamos que o tamanho do pacote é 2048, o que ultrapassa o MTU padrão. Consequentemente, não houve resposta do servidor AAA. A controladora Wireless reenviará persistentemente a solicitação de acesso até atingir o número máximo de tentativas. Devido à ausência de resposta, o controlador sem fio reiniciará o processo EAPOL.

04/2023/12 16:51:45.762890 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [Client_MAC:capwap_90000004] Publicando EAPOL_START no cliente
04/2023/12 16:51:45.762956 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [Client_MAC:capwap_90000004] Entrando no estado init
04/2023/12 16:51:45.762965 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [Client_MAC:capwap_90000004] Publicação !AUTH_ABORT no cliente
04/2023/12 16:51:45.762969 {wncd_x_R0-0}{1}: [dot1x] [19224]: (informações): [Client_MAC:capwap_90000004] Entrando no estado de reinicialização

Esse processo entra em loop e o cliente fica preso somente na fase de autenticação.

A Captura de pacotes incorporada capturada no controlador sem fio mostra que, após várias solicitações de acesso e trocas de desafio com uma MTU menor que 1500 bytes, o controlador sem fio envia uma solicitação de acesso superior a 1500 bytes, que contém o certificado do cliente. Esse pacote maior sofre fragmentação. No entanto, não há resposta a essa solicitação de acesso específica. O controlador sem fio continua a reenviar essa solicitação até atingir o número máximo de novas tentativas, após o qual a sessão EAP-TLS será reiniciada. Essa sequência de eventos continua se repetindo, indicando que há um loop EAP-TLS ocorrendo quando o cliente tenta se autenticar. Consulte as capturas de pacotes simultâneos da controladora Wireless e do ISE fornecidas abaixo para obter uma compreensão mais clara.

Controlador sem fio EPC:

Captura de pacotes na WLC

Observamos que o controlador sem fio está enviando várias solicitações duplicadas para um ID de solicitação de acesso específico = 8

Note: No que respeita ao EPC, verificamos também que existe uma única solicitação em duplicado para outros ID. Isso faz com que a pergunta: Espera-se uma tal duplicação? A resposta à questão de saber se esta duplicação é esperada é sim, é. O motivo é que a captura foi feita na GUI do controlador sem fio com a opção "Monitor Control Plane" selecionada. Como resultado, é normal observar várias instâncias de pacotes RADIUS desde que estejam sendo direcionados para a CPU. Nesses casos, as solicitações de Acesso devem ser vistas com os endereços MAC origem e destino definidos como 00:00:00.

Solicitação de Acesso Radius Pontilhada para a CPU na WLC

Somente as solicitações de Acesso com os endereços MAC origem e destino especificados devem realmente ser enviadas para fora do controlador Wireless.

Solicitação de Acesso Radius Enviada ao Servidor AAA

As solicitações de Acesso em questão, identificadas pelo ID = 8, que são enviadas várias vezes e para as quais nenhuma resposta foi vista do servidor AAA. Após investigação adicional, observamos que para o ID de solicitação de acesso=8, a fragmentação de UDP está ocorrendo devido ao tamanho que ultrapassa o MTU, conforme ilustrado abaixo:

Fragmentação ocorrendo na captura de pacotes de WLC

Pacote Fragmentado - I

Pacote Fragmentado - II

Pacote remontado

Para verificar, revisamos os registros do ISE e descobrimos que a solicitação de acesso, que havia sido fragmentada no controlador sem fio, não estava sendo recebida pelo ISE.

Despejos de TCP ISE

Capturas no final do ISE

Captura Lateral do Azure com análise:

A equipe do Azure realizou uma captura no host físico dentro do Azure. Os dados capturados no vSwitch dentro do host Azure indicam que os pacotes UDP estão chegando fora de sequência. Como esses fragmentos UDP não estão na ordem correta, o Azure os está descartando. Abaixo estão as capturas da extremidade do Azure e da controladora Wireless, tiradas simultaneamente para ID de solicitação de acesso = 255, onde o problema de pacotes fora de ordem é claramente evidente:
O Encapsulated Packet Capture (EPC) no controlador Wireless exibe a sequência em que os pacotes fragmentados saem do controlador Wireless. 

Sequência de pacotes fragmentados no WLC

No host físico, os pacotes não estão chegando na sequência correta

Capturas no Fim do Azure

Como os pacotes estão chegando na ordem errada e o nó físico está programado para rejeitar quadros fora de ordem, os pacotes são descartados imediatamente. Essa interrupção faz com que o processo de autenticação falhe, deixando o cliente incapaz de progredir além da fase de autenticação.

Sugestão de solução alternativa da extremidade do controlador sem fio:

Começando com a versão 17.11.1, estamos implementando suporte para Jumbo Frames em pacotes Radius/AAA. Esse recurso permite que o controlador c9800 evite a fragmentação de pacotes AAA, desde que a seguinte configuração seja definida no controlador. Observe que, para evitar a fragmentação total desses pacotes, é essencial garantir que cada salto de rede, incluindo o servidor AAA, seja compatível com pacotes de Jumbo Frame. Para o ISE, o suporte a Jumbo Frame começa com a versão 3.1 em diante.
Configuração da interface no controlador sem fio:

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

Configuração do servidor AAA no controlador sem fio:

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

Aqui está uma breve visão de um pacote Radius quando a MTU (Unidade Máxima de Transmissão) é configurada para 3000 bytes em uma controladora Wireless LAN (WLC). Pacotes menores que 3000 bytes foram enviados perfeitamente sem a necessidade de fragmentação:

Captura de pacotes em WLC com aumento de MTU

Definindo a configuração dessa maneira, o controlador sem fio transmite pacotes sem fragmentá-los, enviando-os intactos. No entanto, como a nuvem do Azure não oferece suporte a quadros jumbo, essa solução não pode ser implementada.

Solução:

• A partir do Encapsulated Packet Capture (EPC) da controladora Wireless, observamos que os pacotes estão sendo enviados na ordem correta. Em seguida, é responsabilidade do host receptor remontá-los corretamente e continuar com o processamento, o que, neste caso, não ocorre no Azure.
• Para resolver o problema de pacotes UDP fora de ordem, aenable-udp-fragment-reorderingopção precisa ser ativada no Azure.
• Você deve entrar em contato com a equipe de suporte do Azure para obter assistência sobre este assunto. A Microsoft reconheceu este problema.
  
  

  Note: Deve-se observar que esse problema não é exclusivo da controladora Wireless LAN (WLC). Problemas semelhantes com pacotes UDP fora de ordem foram encontrados em diferentes servidores radius, incluindo ISE, Forti Authenticator e servidores RTSP, particularmente quando eles operam dentro do ambiente Azure.