Problembehebung bei Fragmentierung: Affecting c9800 Wireless Controller mit Azure

Einleitung

In diesem Dokument wird ein bekanntes Problem mit der Azure-Plattform beschrieben, das zu Paketverlusten aufgrund der fehlerhaften Behandlung von nicht sequenzierten Fragmenten führt.

Symptome

Betroffene Produkte: Catalyst 9800-CL Wireless Controller auf Azure oder Identity Service Engine auf Azure gehostet.

SSID-Einrichtung: Konfiguriert für 802.1x EAP-TLS mit zentraler Authentifizierung.

Durchführung: Bei der Verwendung des auf der Azure-Plattform gehosteten 9800-CL mit einer EAP-TLS-basierten SSID können Verbindungsprobleme auftreten. Die Clients können während der Authentifizierungsphase auf Schwierigkeiten stoßen.

Fehler auf ISE-Server

Fehlercode 5411, der angibt, dass der Supplicant während des EAP-TLS-Zertifikataustauschs nicht mehr mit der ISE kommuniziert.

Detaillierte Protokollanalyse:

Nachfolgend finden Sie eine Abbildung einer der betroffenen Konfigurationen: Im Wireless-Controller 9800 ist die SSID für 802.1x eingerichtet, und der AAA-Server ist für EAP-TLS konfiguriert. Wenn ein Client die Authentifizierung versucht, insbesondere während der Phase des Zertifikataustauschs, sendet der Client ein Zertifikat, das die maximale Größe der Übertragungseinheit (MTU) auf dem Wireless-Controller überschreitet. Der Wireless-Controller 9800 fragmentiert dann dieses große Paket und sendet die Fragmente der Reihe nach an den AAA-Server. Diese Fragmente gelangen jedoch nicht in der richtigen Reihenfolge an den physischen Host, was zu Paketverlusten führt.

Hier sind die RA-Ablaufverfolgungen des Wireless Controllers, wenn der Client versucht, eine Verbindung herzustellen:
Client wechselt in L2-Authentifizierungsstatus, und der EAP-Prozess wurde gestartet

2023/04/12 16:51:27.606414 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [Client_MAC:capwap_90000004] Eingeben des Anforderungsstatus
2023/04/12 16:51:27.606425 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [0000.0000.0000:capwap_90000004] EAPOL-Paket wird gesendet
2023/04/12 16:51:27.606494 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [Client_MAC:capwap_90000004] EAPOL-Paket gesendet - Version: 3,EAPOL-Typ: EAP, Nutzlastlänge: 1008, EAP-Type = EAP-TLS
2023/04/12 16:51:27.606496 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [Client_MAC:capwap_90000004] EAP-Paket - ANFORDERUNG, ID: 0 x 25
2023/04/12 16:51:27.606536 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [Client_MAC:capwap_90000004] EAPOL-Paket an Client gesendet
2023/04/12 16:51:27.640768 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [Client_MAC:capwap_90000004] EAPOL-Paket empfangen - Version: 1,EAPOL-Typ: EAP, Nutzlastlänge: 6, EAP-Typ = EAP-TLS
2023/04/12 16:51:27.640781 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [Client_MAC:capwap_90000004] EAP-Paket - ANTWORT, ID: 0 x 25

Wenn der Wireless-Controller die Zugriffsanforderung an den AAA-Server sendet und die Paketgröße weniger als 1500 Byte beträgt (dies ist die Standard-MTU auf dem Wireless-Controller), wird die Zugriffsanforderung ohne Komplikationen empfangen.

2023/04/12 16:51:27.641094 {wncd_x_R0-0}{1}: [Radius] [19224]: (Info): RADIUS: Senden Sie eine Zugriffsanfrage an 172.16.26.235:1812 id 0/6, len 552
2023/04/12 16:51:27.644693 {wncd_x_R0-0}{1}: [Radius] [19224]: (Info): RADIUS: Empfangen von ID 1812/6 172.16.26.235:0, Access-Challenge, len 1141

Manchmal sendet ein Client sein Zertifikat zur Authentifizierung. Wenn die Paketgröße die MTU überschreitet, wird sie fragmentiert, bevor sie weiter gesendet wird.

2023/04/12 16:51:27.758366 {wncd_x_R0-0}{1}: [Radius] [19224]: (Info): RADIUS: Senden Sie eine Zugriffsanfrage an 172.16.26.235:1812 id 0/8, len 2048
2023/04/12 16:51:37.761885 {wncd_x_R0-0}{1}: [Radius] [19224]: (Info): RADIUS: Timeout nach 5 Sekunden gestartet
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}: [Radius] [19224]: (Info): RADIUS: Erneut übertragen an (172.16.26.235:1812,1813) für ID 0/8
2023/04/12 16:51:32.759255 {wncd_x_R0-0}{1}: [Radius] [19224]: (Info): RADIUS: Erneut übertragen an (172.16.26.235:1812,1813) für ID 0/8
2023/04/12 16:51:32.760328 {wncd_x_R0-0}{1}: [Radius] [19224]: (Info): RADIUS: Timeout nach 5 Sekunden gestartet
2023/04/12 16:51:37.760552 {wncd_x_R0-0}{1}: [Radius] [19224]: (Info): RADIUS: Erneut übertragen an (172.16.26.235:1812,1813) für ID 0/8
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}: [Radius] [19224]: (Info): RADIUS: Erneut übertragen an (172.16.26.235:1812,1813) für ID 0/8

Wir haben festgestellt, dass die Paketgröße 2048 beträgt und damit die Standard-MTU übersteigt. Folglich hat der AAA-Server nicht geantwortet. Der Wireless-Controller sendet die Zugriffsanforderung erneut, bis die maximale Anzahl von Wiederholungsversuchen erreicht ist. Da keine Antwort eingeht, setzt der Wireless-Controller den EAPOL-Prozess zurück.

2023/04/12 16:51:45.762890 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [Client_MAC:capwap_90000004] EAPOL_START auf Client veröffentlichen
2023/04/12 16:51:45.762956 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [Client_MAC:capwap_90000004] Eintritt in den Initialstatus
2023/04/12 16:51:45.762965 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [Client_MAC:capwap_90000004] !AUTH_ABORT auf Client veröffentlichen
2023/04/12 16:51:45.762969 {wncd_x_R0-0}{1}: [dot1x] [19224]: (Info): [Client_MAC:capwap_90000004] Neustartstatus wird eingegeben

Dieser Prozess läuft in einer Schleife ab, und der Client befindet sich nur in der Authentifizierungsphase.

Die auf dem Wireless-Controller erfasste Embedded Packet Capture (Integrierte Paketerfassung) zeigt, dass der Wireless-Controller nach mehreren Zugriffsanforderungen und Challenge-Austauschen mit einer MTU von weniger als 1500 Byte eine Zugriffsanforderung sendet, die 1500 Byte überschreitet und das Zertifikat des Clients enthält. Dieses größere Paket wird fragmentiert. Es gibt jedoch keine Antwort auf diese spezielle Zugriffsanfrage. Der Wireless-Controller sendet diese Anforderung erneut, bis die maximale Anzahl von Wiederholungen erreicht ist. Danach wird die EAP-TLS-Sitzung neu gestartet. Diese Ereignissequenz wiederholt sich immer wieder, was darauf hinweist, dass beim Authentifizierungsversuch des Clients eine EAP-TLS-Schleife auftritt. Weitere Informationen finden Sie in den nachfolgenden Informationen zur gleichzeitigen Paketerfassung vom Wireless-Controller und der ISE.

Wireless Controller-EPC:

Paketerfassung auf WLC

Wir stellen fest, dass der Wireless Controller mehrere doppelte Anforderungen für eine bestimmte Zugriffsanforderungs-ID sendet = 8

Anmerkung: Beim EPC stellen wir auch fest, dass es eine einzige Duplikatanforderung für andere IDs gibt. Daraus ergibt sich die Frage: Ist mit einer solchen Doppelarbeit zu rechnen? Die Antwort auf die Frage, ob diese Verdoppelung zu erwarten ist, lautet ja, ja. Der Grund hierfür ist, dass die Erfassung über die grafische Benutzeroberfläche des Wireless-Controllers erfolgt und die Option "Kontrollebene überwachen" ausgewählt wurde. Daher ist es normal, mehrere Instanzen von RADIUS-Paketen zu beobachten, da sie an die CPU weitergeleitet werden. In solchen Fällen müssen für Access-Anforderungen sowohl die Quell- als auch die Ziel-MAC-Adresse auf 00:00:00 eingestellt sein.

Radius-Zugriffsanfrage auf CPU auf WLC gestartet

Nur die Zugriffsanforderungen mit den angegebenen Quell- und Ziel-MAC-Adressen müssen tatsächlich vom Wireless-Controller gesendet werden.

RADIUS-Zugriffsanfrage an AAA-Server gesendet

Es handelt sich um Access-Anfragen, die mit ID = 8 identifiziert werden und mehrfach versendet werden und für die keine Antwort vom AAA-Server einging. Bei der weiteren Untersuchung stellten wir fest, dass bei der Zugriffsanforderungs-ID=8 eine UDP-Fragmentierung auftritt, weil die Größe die MTU übersteigt, wie unten dargestellt:

Fragmentierung bei der WLC-Paketerfassung

Fragmentiertes Paket - I

Fragmentiertes Paket - II

Reassembliertes Paket

Um eine Gegenprüfung vorzunehmen, überprüften wir die ISE-Protokolle und stellten fest, dass die Zugriffsanforderung, die auf dem Wireless-Controller fragmentiert war, von der ISE überhaupt nicht empfangen wurde.

ISE TCP-Dumps

Aufzeichnungen am ISE-Ende

Azure Side Capture mit Analyse:

Das Azure-Team führte eine Erfassung auf dem physischen Host in Azure durch. Die auf dem vSwitch im Azure-Host erfassten Daten zeigen an, dass die UDP-Pakete nicht in der richtigen Reihenfolge ankommen. Da diese UDP-Fragmente nicht in der richtigen Reihenfolge sind, werden sie von Azure verworfen. Im Folgenden sind die gleichzeitigen Aufnahmen vom Azure-Ende und vom Wireless-Controller für die Zugriffsanforderungs-ID = 255 aufgeführt, bei denen das Problem der fehlerhaften Pakete deutlich wird:
Die Encapsulated Packet Capture (EPC) auf dem Wireless-Controller zeigt die Sequenz an, in der die fragmentierten Pakete vom Wireless-Controller zurückgelassen werden. 

Sequenz fragmentierter Pakete auf WLC

Auf dem physischen Host kommen die Pakete nicht in der richtigen Reihenfolge an

Aufzeichnungen auf Azure End

Da die Pakete in der falschen Reihenfolge ankommen und der physische Knoten so programmiert ist, dass er alle nicht ordnungsgemäßen Frames zurückweist, werden die Pakete sofort verworfen. Durch diese Unterbrechung schlägt der Authentifizierungsprozess fehl, sodass der Client nicht mehr über die Authentifizierungsphase hinaus arbeiten kann.

Lösung vorgeschlagen vom Ende des Wireless-Controllers:

Ab Version 17.11.1 implementieren wir die Unterstützung für Jumbo Frames in Radius-/AAA-Paketen. Mit dieser Funktion kann der c9800-Controller die Fragmentierung von AAA-Paketen vermeiden, vorausgesetzt, die folgende Konfiguration ist auf dem Controller festgelegt. Um eine vollständige Fragmentierung dieser Pakete zu vermeiden, muss sichergestellt werden, dass jeder Netzwerk-Hop, einschließlich des AAA-Servers, mit Jumbo Frame-Paketen kompatibel ist. Für die ISE beginnt die Jumbo Frame-Unterstützung mit Version 3.1 und höher.
Schnittstellenkonfiguration des Wireless Controllers:

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

AAA-Serverkonfiguration auf dem Wireless-Controller:

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

Im Folgenden wird ein Radius-Paket kurz erläutert, wenn die MTU (Maximum Transmission Unit, maximale Übertragungseinheit) auf einem Wireless LAN Controller (WLC) auf 3.000 Byte konfiguriert ist. Pakete unter 3000 Byte wurden nahtlos und ohne Fragmentierung versendet:

Paketerfassung auf WLC mit erhöhter MTU

Durch diese Konfiguration überträgt der Wireless-Controller Pakete, ohne sie zu fragmentieren, und sendet sie intakt. Da Azure Cloud jedoch keine Jumbo Frames unterstützt, kann diese Lösung nicht implementiert werden.

Lösung:

• Aus der Encapsulated Packet Capture (EPC) des Wireless-Controllers konnten wir feststellen, dass die Pakete in der richtigen Reihenfolge gesendet wurden. Es liegt dann in der Verantwortung des empfangenden Hosts, diese korrekt wieder zusammenzubauen und mit der Verarbeitung fortzufahren, was in diesem Fall nicht auf Azure-Seite geschieht.
• Um das Problem von ungeordneten UDP-Paketen zu beheben, muss dieenable-udp-fragment-reorderingOption auf Azure aktiviert werden.
• Wenden Sie sich an das Azure-Supportteam, um Unterstützung in dieser Angelegenheit zu erhalten. Microsoft hat dieses Problem erkannt.
  
  

  Anmerkung: Beachten Sie, dass sich dieses Problem nicht ausschließlich auf den Wireless LAN Controller (WLC) auswirkt. Ähnliche Probleme mit ungeordneten UDP-Paketen sind auf verschiedenen RADIUS-Servern aufgetreten, einschließlich ISE-, Forti Authenticator- und RTSP-Servern, insbesondere wenn diese in der Azure-Umgebung betrieben werden.