Risoluzione dei problemi di frammentazione: Interessi sul controller wireless c9800 con Azure

Introduzione

In questo documento viene descritto un problema noto della piattaforma Azure che comporta la perdita di pacchetti a causa di una gestione errata dei frammenti fuori sequenza.

Sintomi

Prodotti interessati: Catalyst 9800-CL Wireless Controller ospitato in Azure o Identity Service Engine ospitato in Azure.

Configurazione SSID: Configurato per 802.1x EAP-TLS con autenticazione centrale.

Condotta: Durante l'utilizzo di 9800-CL ospitato nella piattaforma Azure con un SSID basato su EAP-TLS è possibile riscontrare problemi di connettività. Durante la fase di autenticazione i client potrebbero incontrare problemi.

Errore sul server ISE

Codice di errore 5411 che indica che il supplicant ha cessato la comunicazione con ISE durante lo scambio del certificato EAP-TLS.

Analisi dettagliata registro:

Di seguito è riportata l'illustrazione di una delle configurazioni interessate: Nel controller wireless 9800, l'SSID è configurato per 802.1x e il server AAA è configurato per EAP-TLS. Quando un client tenta di eseguire l'autenticazione, in particolare durante la fase di scambio dei certificati, invia un certificato che supera le dimensioni MTU (Maximum Transmission Unit) sul controller wireless. Il controller wireless 9800 frammenta quindi questo pacchetto di grandi dimensioni e invia i frammenti in sequenza al server AAA. Tuttavia, questi frammenti non arrivano nell'ordine corretto all'host fisico, causando il rifiuto del pacchetto.

Tracce dell'Autorità registrazione dal controller wireless durante il tentativo di connessione del client:
Il client entra nello stato di autenticazione L2 e il processo EAP è avviato

2023/04/12 16:51:27.606414 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [Client_MAC:capwap_90000004] Attivazione dello stato della richiesta in corso
2023/04/12 16:51:27.606425 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [0000.0000.0000:capwap_90000004] Invio del pacchetto EAPOL in corso
2023/04/12 16:51:27.606494 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [Client_MAC:capwap_90000004] Pacchetto EAPOL inviato - Versione: 3,Tipo EAPOL: Lunghezza payload EAP: 1008, tipo EAP = EAP-TLS
2023/04/12 16:51:27.606496 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [MAC_client:capwap_90000004] Pacchetto EAP - RICHIESTA, ID: 0x25
2023/04/12 16:51:27.606536 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [Client_MAC:capwap_90000004] Pacchetto EAPOL inviato al client
2023/04/12 16:51:27.640768 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [Client_MAC:capwap_90000004] Ricevuto pacchetto EAPOL - Versione: 1,Tipo EAPOL: Lunghezza payload EAP: 6, tipo EAP = EAP-TLS
2023/04/12 16:51:27.640781 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [MAC_client:capwap_90000004] Pacchetto EAP - RISPOSTA, ID: 0x25

Quando il controller wireless invia la richiesta di accesso al server AAA e le dimensioni del pacchetto sono inferiori a 1500 byte (ossia l'MTU predefinita sul controller wireless), la richiesta di accesso viene ricevuta senza complicazioni.

2023/04/12 16:51:27.641094 {wncd_x_R0-0}{1}: [raggio] [1924]: (info): RAGGIO: Invia richiesta di accesso a 172.16.26.235:1812 id 0/6, len 552
2023/04/12 16:51:27.644693 {wncd_x_R0-0}{1}: [raggio] [1924]: (info): RAGGIO: Ricevuto da id 1812/6 172.16.26.235:0, Access-Challenge, len 1141

Talvolta un client può inviare il proprio certificato per l'autenticazione. Se le dimensioni del pacchetto superano l'MTU, il pacchetto verrà frammentato prima di essere inviato ulteriormente.

2023/04/12 16:51:27.758366 {wncd_x_R0-0}{1}: [raggio] [1924]: (info): RAGGIO: Invia richiesta di accesso a 172.16.26.235:1812 id 0/8, len 2048
2023/04/12 16:51:37.761885 {wncd_x_R0-0}{1}: [raggio] [1924]: (info): RAGGIO: Timeout 5 sec avviato
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}: [raggio] [1924]: (info): RAGGIO: Ritrasmissione a (172.16.26.235:1812,1813) per id 0/8
2023/04/12 16:51:32.759255 {wncd_x_R0-0}{1}: [raggio] [1924]: (info): RAGGIO: Ritrasmissione a (172.16.26.235:1812,1813) per id 0/8
2023/04/12 16:51:32.760328 {wncd_x_R0-0}{1}: [raggio] [1924]: (info): RAGGIO: Timeout 5 sec avviato
2023/04/12 16:51:37.760552 {wncd_x_R0-0}{1}: [raggio] [1924]: (info): RAGGIO: Ritrasmissione a (172.16.26.235:1812,1813) per id 0/8
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}: [raggio] [1924]: (info): RAGGIO: Ritrasmissione a (172.16.26.235:1812,1813) per id 0/8

Abbiamo notato che le dimensioni del pacchetto sono 2048, il che supera l'MTU predefinita. Di conseguenza, non è pervenuta alcuna risposta dal server AAA. Il controller wireless invierà in modo permanente la richiesta di accesso fino a raggiungere il numero massimo di tentativi. A causa dell'assenza di risposta, il controller wireless reimposterà il processo EAPOL.

2023/04/12 16:51:45.762890 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [Client_MAC:capwap_90000004] Invio di EAPOL_START sul client
2023/04/12 16:51:45.762956 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [Client_MAC:capwap_90000004] Attivazione dello stato iniziale in corso
2023/04/12 16:51:45.762965 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [MAC_client:capwap_90000004] Invio di !AUTH_ABORT sul client
2023/04/12 16:51:45.762969 {wncd_x_R0-0}{1}: [dot1x] [1924]: (info): [Client_MAC:capwap_90000004] Attivazione dello stato di riavvio

Questo processo viene eseguito in loop e il client è bloccato solo nella fase di autenticazione.

L'acquisizione integrata dei pacchetti acquisita sul controller wireless mostra che dopo diverse richieste di accesso e scambi di richiesta con MTU inferiore a 1500 byte, il controller wireless invia una richiesta di accesso superiore a 1500 byte, che contiene il certificato del client. Questo pacchetto più grande viene frammentato. Non è tuttavia disponibile alcuna risposta a questa specifica richiesta di accesso. Il controller wireless continua a inviare questa richiesta finché non raggiunge il numero massimo di tentativi, dopodiché la sessione EAP-TLS viene riavviata. Questa sequenza di eventi continua a ripetersi, a indicare che si verifica un loop EAP-TLS quando il client tenta di eseguire l'autenticazione. Per una comprensione più chiara, fare riferimento alle acquisizioni simultanee di pacchetti dal controller wireless e dall'ISE forniti di seguito.

EPC controller wireless:

Packet Capture su WLC

Si noti che il controller wireless sta inviando diverse richieste duplicate per un particolare ID richiesta di accesso = 8

Nota: L'EPC rileva inoltre che esiste un'unica richiesta di duplicazione per altri codici di identificazione. Da qui la domanda: Si prevede una duplicazione di questo tipo? La risposta alla domanda se si prevede questa duplicazione è sì, lo è. Il motivo è che l'acquisizione è stata effettuata dalla GUI del controller wireless con l'opzione 'Monitor Control Plane' selezionata. Di conseguenza, è normale osservare diverse istanze di pacchetti RADIUS in quanto vengono indirizzati alla CPU. In questi casi, le richieste di accesso devono essere visualizzate con gli indirizzi MAC di origine e di destinazione impostati su 00:00:00.

Richiesta di accesso Radius inoltrata alla CPU sul WLC

Solo le richieste di accesso con gli indirizzi MAC di origine e di destinazione specificati devono essere effettivamente inviate dal controller wireless.

Richiesta di accesso Radius inviata al server AAA

Le richieste di accesso in questione, identificate da ID = 8, che vengono inviate più volte e per le quali non è stata vista alcuna risposta dal server AAA. In seguito a ulteriori indagini, è stato rilevato che per Access-request con ID=8 la frammentazione UDP è avvenuta a causa delle dimensioni superiori all'MTU, come mostrato di seguito:

Frammentazione all'acquisizione di pacchetti WLC

Pacchetto frammentato - I

Pacchetto frammentato - II

Pacchetto riassemblato

Per la verifica incrociata, abbiamo esaminato i log di ISE e abbiamo scoperto che la richiesta di accesso, che era stata frammentata sul controller wireless, non veniva ricevuta da ISE.

ISE TCP Dump

Clip su ISE End

Azure Side Capture con analisi:

Il team di Azure ha eseguito un'acquisizione sull'host fisico in Azure. I dati acquisiti sullo switch vSwitch nell'host di Azure indicano che i pacchetti UDP stanno arrivando fuori sequenza. Questi frammenti UDP non sono nell'ordine corretto. Azure li sta eliminando. Di seguito sono riportate le clip acquisite sia dall'estremità di Azure che dal controller wireless, acquisite contemporaneamente per l'ID richiesta di accesso = 255, in cui il problema dei pacchetti non in ordine è evidente:
L'EPC (Encapsulated Packet Capture) sul controller wireless visualizza la sequenza in cui i pacchetti frammentati lasciano il controller wireless. 

Sequenza di pacchetti frammentati sul WLC

Sull'host fisico, i pacchetti non arrivano nella sequenza corretta

Acquisizioni in Azure End

Poiché i pacchetti stanno arrivando nell'ordine sbagliato e il nodo fisico è programmato per rifiutare i frame non ordinati, i pacchetti vengono scartati immediatamente. L'interruzione causa il fallimento del processo di autenticazione e impedisce al client di superare la fase di autenticazione.

Soluzione suggerita dall'estremità del controller wireless:

A partire dalla versione 17.11.1, stiamo implementando il supporto per i frame jumbo nei pacchetti Radius/AAA. Questa funzione consente al controller c9800 di evitare la frammentazione dei pacchetti AAA, a condizione che sul controller sia impostata la seguente configurazione. Per evitare la frammentazione completa di questi pacchetti, è essenziale verificare che ogni hop di rete, incluso il server AAA, sia compatibile con i pacchetti Jumbo Frame. Per ISE, il supporto di Jumbo Frame inizia con la versione 3.1 in avanti.
Configurazione interfaccia sul controller wireless:

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

Configurazione server AAA sul controller wireless:

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

Di seguito viene riportato un breve elenco di un pacchetto Radius quando l'MTU (Maximum Transmission Unit) è configurata su 3000 byte su un controller WLC. I pacchetti inferiori a 3000 byte sono stati inviati senza problemi senza bisogno di frammentazione:

Acquisizione dei pacchetti sul WLC con MTU aumentata

Impostando la configurazione in questo modo, il controller wireless trasmette i pacchetti senza frammentarli, inviandoli intatti. Tuttavia, poiché il cloud di Azure non supporta i frame jumbo, non è possibile implementare questa soluzione.

Soluzione:

• Da EPC (Encapsulated Packet Capture) del controller wireless è stato rilevato che i pacchetti vengono inviati nell'ordine corretto. Spetta quindi all'host ricevente ricomporre i frammenti in modo corretto e continuare l'elaborazione che, in questo caso, non viene eseguita sul lato di Azure.
• Per risolvere il problema dei pacchetti UDP non ordinati, è necessario attivare questaenable-udp-fragment-reorderingopzione in Azure.
• È necessario rivolgersi al team di supporto di Azure per assistenza su questo argomento. Microsoft ha riconosciuto questo problema.
  
  

  Nota: Si noti che questo problema non riguarda esclusivamente il controller WLC (Wireless LAN Controller). Problemi simili relativi a pacchetti UDP non ordinati sono stati riscontrati in server RADIUS diversi, inclusi i server ISE, Forti Authenticator e RTSP, in particolare quando operano nell'ambiente di Azure.