Inleiding
Dit document beschrijft een bekend probleem met het Azure-platform dat leidt tot pakketverlies als gevolg van de verkeerde behandeling van fragmenten buiten de reeks.
Symptomen
Betrokken producten: Catalyst 9800-CL draadloze controller gehost op Azure of Identity Service Engine gehost op Azure.
SSID instellen: geconfigureerd voor 802.1x EAP-TLS met centrale verificatie.
Gedrag: als u de 9800-CL gebruikt die op het Azure-platform wordt gehost met een op EAP-TLS gebaseerde SSID, kunt u problemen met de connectiviteit ondervinden. Klanten kunnen problemen ondervinden tijdens de authenticatiefase.
Fout op ISE-server
Foutcode 5411 die aangeeft dat de aanvrager de communicatie met ISE tijdens de EAP-TLS-certificaatuitwisseling heeft gestaakt.
Gedetailleerde loganalyse:
Hier is een illustratie van een van de getroffen configuraties: in de 9800 Wireless-controller is de SSID ingesteld voor 802.1x en is de AAA-server geconfigureerd voor EAP-TLS. Wanneer een client verificatie probeert uit te voeren, met name tijdens de fase voor het uitwisselen van certificaten, verzendt de client een certificaat dat groter is dan de maximale grootte van de transmissie-eenheid (MTU) op de draadloze controller. De 9800 Wireless controller fragmenteert vervolgens dit grote pakket en stuurt de fragmenten achtereenvolgens naar de AAA-server. Deze fragmenten komen echter niet in de juiste volgorde bij de fysieke host aan, wat leidt tot pakketverlies.
Hier zijn de RA-sporen van de draadloze controller wanneer de client probeert verbinding te maken:
Client voert L2-verificatiestatus in en EAP-proces wordt gestart
2023/04/12 16:51:27.606414 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] Status van aanvraag invoeren
2023/04/12 16:51:27.606425 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [0000.0000.0000:capwap_90000004] EAPOL-pakket verzenden
2023/04/12 16:51:27.606494 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] Verzonden EAPOL-pakket - Versie: 3, EAPOL-type: EAP, Payloadlengte: 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-pakket - AANVRAAG, ID: 0x25
2023/04/12 16:51:27.606536 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] EAPOL-pakket verzonden naar client
2023/04/12 16:51:27.640768 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] Ontvangen EAPOL-pakket - Versie: 1, EAPOL-type: EAP, Payloadlengte: 6, EAP-type = EAP-TLS
2023/04/12 16:51:27.640781 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] EAP-pakket - REACTIE, ID: 0x25
Wanneer de draadloze controller het toegangsverzoek naar de AAA-server verzendt en de pakketgrootte kleiner is dan 1500 bytes (de standaard MTU op de draadloze controller), wordt de toegangsuitdaging zonder complicaties ontvangen.
2023/04/12 16:51:27.641094 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Verzend Access-Request naar 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: Ontvangen van id 1812/6 172.16.26.235:0, Access-Challenge, len 1141
Soms kan een klant zijn certificaat voor authenticatie verzenden. Als de pakketgrootte groter is dan de MTU, wordt deze gefragmenteerd voordat deze verder wordt verzonden.
2023/04/12 16:51:27.758366 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Verzend Access-Request naar 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: Gestart time-out van 5 sec
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Doorzenden naar (172.16.26.235:1812,1813) voor id 0/8
2023/04/12 16:51:32.759255 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Doorzenden naar (172.16.26.235:1812,1813) voor id 0/8
2023/04/12 16:51:32.760328 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Gestart time-out van 5 sec
2023/04/12 16:51:37.760552 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Doorzenden naar (172.16.26.235:1812,1813) voor id 0/8
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Doorzenden naar (172.16.26.235:1812,1813) voor id 0/8
We hebben gemerkt dat de pakketgrootte 2048 is, wat de standaard MTU overtreft. Er is dus geen reactie van de AAA-server. De draadloze controller verzendt het toegangsverzoek voortdurend totdat het maximale aantal herhalingen is bereikt. Vanwege het ontbreken van een reactie zal de draadloze controller uiteindelijk het EAPOL-proces resetten.
2023/04/12 16:51:45.762890 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] EAPOL_START op client plaatsen
2023/04/12 16:51:45.762956 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] In staat van binnenkomst
2023/04/12 16:51:45.762965 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] Detachering op client
2023/04/12 16:51:45.762969 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_900000004] Opnieuw opstarten
Dit proces gaat in lus en de client zit alleen vast in de verificatiefase.
De ingesloten pakketopname die is vastgelegd op de draadloze controller, laat zien dat de draadloze controller na verschillende toegangsverzoeken en challenge-uitwisselingen met een MTU van minder dan 1500 bytes een toegangsverzoek van meer dan 1500 bytes verzendt, dat het certificaat van de client bevat. Dit grotere pakket ondergaat fragmentatie. Er is echter geen reactie op dit specifieke toegangsverzoek. De draadloze controller blijft deze aanvraag opnieuw verzenden totdat het maximale aantal herhalingen is bereikt, waarna de EAP-TLS-sessie opnieuw wordt gestart. Deze reeks gebeurtenissen blijft zich herhalen, wat aangeeft dat er een EAP-TLS-lus plaatsvindt terwijl de client probeert te verifiëren. Raadpleeg de onderstaande parallelle pakketopnamen van zowel de draadloze controller als de ISE voor meer informatie.
Draadloze controller EPC:
Packet Capture op WLC
We merken op dat de draadloze controller meerdere dubbele verzoeken stuurt voor een bepaald Access-request ID = 8
Opmerking: Op de EPC merken we ook op dat er één duplicaatverzoek is voor andere ID's. Dit roept de vraag op: wordt dergelijke duplicatie verwacht? Het antwoord op de vraag of deze duplicatie wordt verwacht is ja, dat is het. De reden hiervoor is dat de opname is gemaakt van de GUI van de draadloze controller met de optie 'Monitor Control Plane' geselecteerd. Als gevolg hiervan is het normaal om verschillende exemplaren van RADIUS-pakketten te observeren, omdat ze naar de CPU worden geleid. In dergelijke gevallen moeten Access-verzoeken worden gezien met zowel bron- als bestemmingsMAC-adressen die zijn ingesteld op 00:00:00.
Radius Access-Request Punted to CPU op WLC
Alleen de Access-verzoeken met de opgegeven MAC-adressen van de bron en de bestemming moeten daadwerkelijk door de draadloze controller worden verzonden.
Radius-toegangsverzoek verzonden naar AAA-server
De betreffende Access-verzoeken, aangeduid met ID = 8, die meerdere keren worden verzonden en waarvoor geen reactie van de AAA-server is gezien. Bij nader onderzoek hebben we vastgesteld dat voor Access-request ID=8 UDP-fragmentatie optreedt vanwege de grootte die de MTU overtreft, zoals hieronder wordt geïllustreerd:
Fragmentatie vindt plaats op WLC Packet Capture
Gefragmenteerd pakket - I
Gefragmenteerd pakket - II
opnieuw samengesteld pakket
Om de ISE-logs te verifiëren, hebben we de ISE-logs bekeken en ontdekt dat het toegangsverzoek, dat was gefragmenteerd op de draadloze controller, helemaal niet door de ISE werd ontvangen.
ISE TCP Dumps
Opnamen op ISE-einde
Azure Side Capture met analyse:
Het Azure-team heeft een opname uitgevoerd op de fysieke host binnen Azure. De gegevens die op de vSwitch in de Azure-host zijn vastgelegd, geven aan dat de UDP-pakketten uit de reeks aankomen. Omdat deze UDP-fragmenten niet in de juiste volgorde staan, worden ze door Azure verwijderd. Hieronder staan de opnames van zowel het Azure-einde als de draadloze controller, gelijktijdig genomen voor toegangsverzoek ID = 255, waarbij het probleem van pakketten die niet in orde zijn duidelijk is:
De EPC (Encapsulated Packet Capture) op de draadloze controller geeft de volgorde weer waarin de gefragmenteerde pakketten de draadloze controller verlaten.
Sequentie van gefragmenteerde pakketten op WLC
Op de fysieke host komen de pakketten niet in de juiste volgorde aan
Opnamen op Azure End
Omdat de pakketten in de verkeerde volgorde aankomen en de fysieke node is geprogrammeerd om eventuele out-of-order frames af te wijzen, worden de pakketten onmiddellijk gedropt. Deze onderbreking zorgt ervoor dat het authenticatieproces mislukt, waardoor de client niet verder kan gaan dan de authenticatiefase.
Workaround voorgesteld vanaf het einde van de draadloze controller:
Vanaf versie 17.11.1 implementeren we ondersteuning voor Jumbo Frames in Radius/AAA-pakketten. Met deze functie kan de c9800-controller voorkomen dat AAA-pakketten worden gefragmenteerd, op voorwaarde dat de volgende configuratie op de controller is ingesteld. Om fragmentatie van deze pakketten volledig te voorkomen, is het essentieel om ervoor te zorgen dat elke netwerkhop, inclusief de AAA-server, compatibel is met Jumbo Frame-pakketten. Voor ISE begint de ondersteuning voor Jumbo Frame met versie 3.1 en hoger.
Interfaceconfiguratie op draadloze controller:
C9800-CL(config)#interface
C9800-CL(config-if) # mtu
C9800-CL(config-if) # ip mtu [1500 to 9000]
AAA-serverconfiguratie op draadloze controller:
C9800-CL(config)# aaa group server radius
C9800-CL(config-sg-radius) # server name
C9800-CL(config-sg-radius) # ip radius source-interface
Hier is een korte blik op een Radius-pakket wanneer de MTU (Maximum Transmission Unit) is geconfigureerd tot 3000 bytes op een Wireless LAN Controller (WLC). Pakketten kleiner dan 3000 bytes werden naadloos verzonden zonder dat fragmentatie nodig was:
Packet Capture op WLC met verhoogde MTU
Door de configuratie op deze manier in te stellen, verzendt de draadloze controller pakketten zonder ze te fragmenteren en intact te verzenden. Omdat Azure cloud echter geen jumbo-frames ondersteunt, kan deze oplossing niet worden geïmplementeerd.
Oplossing:
- Vanuit de Encapsulated Packet Capture (EPC) van de draadloze controller hebben we geconstateerd dat de pakketten in de juiste volgorde worden verzonden. Het is dan de verantwoordelijkheid van de ontvangende host om ze op de juiste manier weer in elkaar te zetten en door te gaan met de verwerking, wat in dit geval niet gebeurt aan de Azure-kant.
- Om het probleem van out-of-order UDP-pakketten aan te pakken,
enable-udp-fragment-reorderingmoet de optie worden geactiveerd op Azure.
- U moet contact opnemen met het Azure-ondersteuningsteam voor hulp bij deze kwestie. Microsoft heeft dit probleem onderkend.
Opmerking: dit probleem is niet exclusief voor de Wireless LAN Controller (WLC). Soortgelijke problemen met out-of-order UDP-pakketten zijn ondervonden op verschillende radiuservers, waaronder ISE-, Forti Authenticator- en RTSP-servers, met name wanneer deze binnen de Azure-omgeving werken.