Introduction

Ce document décrit le mécanisme de détection de l'unité de transmission maximale (PMTU) du chemin du point d'accès CAPWAP sur IOS® XE et COS, les problèmes et leur résolution.

Scénario et portée

Les problèmes PMTU apparaissent généralement lorsqu'un point d'accès (AP) CAPWAP sur un site distant s'enregistre auprès d'un contrôleur LAN sans fil (WLC) sur un WAN, en particulier lorsque le chemin inclut un VPN, un GRE ou tout segment de réseau avec un MTU inférieur aux 1 500 octets standard.

Nous examinons également l'authentification avec EAP-TLS (Extensible Authentication Protocol Transport Layer Security). EAP-TLS échangeant de gros certificats, un MTU de chemin réduit augmente le risque de fragmentation.

Tous les journaux ont été capturés sur la version de code 17.9.3. Les sorties sont tronquées pour afficher uniquement les lignes pertinentes.

Contrôle CAPWAP et données (éléments négociés)

Contrôle CAPWAP :
Le canal de contrôle gère les messages de gestion critiques tels que les demandes de jointure, les échanges de configuration et les signaux de test d'activité. Ces messages sont sécurisés à l'aide du protocole DTLS et constituent le point central du processus de négociation de la MTU de chemin (PMTU) afin d'assurer une communication fiable et efficace du plan de contrôle.

Données CAPWAP :
Ce canal transporte le trafic client encapsulé, généralement également protégé par DTLS dans la plupart des déploiements. Pendant la négociation PMTU sur le canal de contrôle, les valeurs PMTU résultantes déterminent indirectement la taille de paquet maximale pour l'encapsulation du plan de données, ce qui a un impact sur la fiabilité et la fragmentation de la transmission des données du client.

Exemples

• Paquets de contrôle : Demandes et réponses de jointure, mises à jour de configuration et messages d'écho/de test d'activité.
• Paquets de données : Trames client encapsulées transmises entre le point d'accès (AP) et le contrôleur LAN sans fil (WLC).

Faits : Paquet CAPWAP de taille maximale

IOS AP (exemple)

Taille de paquet PMTU envoyé : 1 499 octets = Ethernet + PMTU CAPWAP

• Ethernet = 14 octets
• CAPWAP PMTU = 1485 octets 
  • IP externe = 20 octets
  • UDP = 25 octets
  • DTLS = 1 440 octets

AP-COS (exemple)

Taille de paquet PMTU envoyé : 1 483 octets = Ethernet + PMTU CAPWAP

• Ethernet = 14 octets
• CAPWAP PMTU = 1469 octets
  • IP externe = 20 octets
  • UDP = 25 octets
  • DTLS = 1 424 octets

Contrôles PMTU en trois étapes

Les deux plates-formes analysent trois valeurs PMTU codées en dur : 576, 1005 et 1485. La différence réside dans la manière dont chaque plate-forme compte l'en-tête Ethernet : 

• Les AP IOS n'incluent pas l'en-tête Ethernet dans les valeurs 576/1005/1485.

  • Trame totale = Ethernet (14) + PMTU (576/1005/1485) ⇒ 590, 1019, 1499 octets (taille du câble).

• AP-COS inclut l'en-tête Ethernet dans les valeurs 576/1005/1485.

  • Trame totale = PMTU (inclut déjà Ethernet). Ces paquets sont 14 octets plus petits sur le câble que les équivalents IOS AP.

Mécanisme de détection CAPWAP PMTU

Comportement IOS AP

Phase de jonction AP

Pendant la jonction CAPWAP, le point d'accès négocie une PMTU CAPWAP maximale de 1485 octets avec le bit DF défini. Il attend une réponse dans 5 secondes.

• Si aucune réponse ou une « fragmentation requise » ICMP n'arrive, le point d'accès revient à 576 octets pour terminer la jointure rapidement, puis tente d'augmenter la PMTU après qu'il ait atteint RUN.

Capture de paquets (exemple)

Paquet numéro 106 Une sonde de 1 499 octets (ensemble DF) s’affiche. Aucune réponse de même taille n'indique que le paquet n'a pas pu traverser le chemin sans fragmentation. Vous voyez ensuite ICMP « Fragmentation Needed » (Fragmentation requise).

Le niveau AP Debug correspondant ("debug capwap client path-mtu") montre que l'AP a essayé en premier avec 1485 octets et a attendu une réponse pendant 5 secondes. En l'absence de réponse, il envoie un autre paquet de demande de jointure d'une longueur inférieure, car il est toujours en phase de jointure et nous n'avons pas de temps à perdre. Il va à la valeur minimale pour obtenir l'AP pour rejoindre le WLC, comme indiqué dans le journal de débogage :

*Jul 11 18:27:15.000: CAPWAP_PATHMTU: CAPWAP_DTLS_SETUP: MTU = 1485
*Jul 11 18:27:15.000: CAPWAP_PATHMTU: Setting default MTU: MTU discovery can start with 576
*Jul 11 18:27:15.235: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.201.234.34 peer_port: 5246
*Jul 11 18:27:15.235: CAPWAP_PATHMTU: Sending Join Request Path MTU payload, Length 1376, MTU 576
*Jul 11 18:27:15.235: %CAPWAP-5-SENDJOIN: sending Join Request to 10.201.234.34
...
*Jul 11 18:27:20.235: %CAPWAP-5-SENDJOIN: sending Join Request to 10.201.234.34
*Jul 11 18:27:21.479: %CAPWAP-5-JOINEDCONTROLLER: AP has joined controller c9800-CL

Et si vous exécutez #show capwap client rcb à ce moment, vous voyez que le MTU de l'AP CAPWAP à 576 octets :

3702-AP#show capwap client rcb 
AdminState : ADMIN_ENABLED 
Primary SwVer : 17.9.3.50 
..
MwarName : c9800-CL 
MwarApMgrIp : 10.201.234.34
OperationState : JOIN 
CAPWAP Path MTU : 576 

Phase d'exécution

Une fois que le point d'accès a rejoint le contrôleur LAN sans fil. Vous voyez le mécanisme de découverte PMTU en jeu, où après 30 secondes, vous pouvez voir le point d'accès commencer à négocier une valeur PMTU plus élevée en envoyant un autre paquet CAPWAP avec un jeu de bits DF de cette taille de la valeur PMTU suivante la plus élevée.

Dans cet exemple, le point d'accès a essayé une valeur de 1005 octets. Comme IOS exclut Ethernet du champ PMTU, vous voyez 1 019 octets sur le câble. Si le WLC répond, l'AP met à jour PMTU à 1005 octets. Si ce n'est pas le cas, il attend 30 secondes et réessaie. 

Cette capture d'écran affiche une négociation AP réussie de 1005 PMTU (voir paquets #268 et #269). Notez que ces paquets ont des tailles différentes, ce qui est dû au fait que le WLC a un algorithme différent pour le calcul de PMTU.

Ici, le niveau AP Debug correspondant (debug capwap client pmtu) montre où l'AP a négocié avec succès le PMTU de 1005 octets et mis à jour la valeur du PMTU de l'AP.

*Jul 11 18:28:39.911: CAPWAP_PATHMTU: PMTU Timer Expired: Trying to send higher MTU packet 576
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: PMTU Timer:Sending Path MTU packet of size 1005
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: MTU = 1005 for current MTU path discovery
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: Ap Path MTU payload with MTU 1005 sent 888
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: Stopping the message timeout timer
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: Setting MTU to : 1005, it was 576
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: Updating MTU to DPAA
*Jul 11 18:28:39.915: CAPWAP_PATHMTU: Sending MTU update to WLC
*Jul 11 18:28:39.915: CAPWAP_PATHMTU: MTU = 1005 for current MTU path discovery
*Jul 11 18:28:39.915: CAPWAP_PATHMTU: Ap Path MTU payload with MTU 1005 sent 21

Et si vous le faites (#show capwap client rcb) à ce moment, vous constatez que le MTU de l'AP CAPWAP à 1005 octets, Voici la sortie de show :

3702-AP#show capwap client rcb 
AdminState : ADMIN_ENABLED 
Primary SwVer : 17.9.3.50 
Name : 3702-AP 
MwarName : c9800-CL 
MwarApMgrIp : 10.201.234.34
OperationState : UP 
CAPWAP Path MTU : 1005 

Après 30 secondes, le point d'accès tente à nouveau de négocier la valeur supérieure suivante de 1485 octets, mais le point d'accès a reçu le message ICMP inaccessible alors que l'état du point d'accès est en cours d'exécution. L'ICMP inaccessible a une valeur de saut suivant, et l'AP honore cette valeur et l'utilise pour calculer sa propre PMTU comme nous pouvons le voir dans les débogages.

*Jul 11 18:29:45.911: CAPWAP_PATHMTU: PMTU Timer:Sending Path MTU packet of size 1485
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: MTU = 1485 for current MTU path discovery
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: Ap Path MTU payload with MTU 1485 sent 1368
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: Received ICMP Dst unreachable
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: Src port:5246 Dst Port:60542, SrcAddr:10.201.166.185 Dst Addr:10.201.234.34
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: Calculated MTU 1293, last_icmp_mtu 1300
*Jul 11 18:29:48.911: CAPWAP_PATHMTU: Path MTU message could not reach WLC, Removing it from the Reliable Queue

Captures du niveau AP correspondant

Notez le numéro de paquet ICMP inaccessible 281, puis le point d'accès tente de négocier une PMTU en honorant la valeur de tronçon suivant ICMP sur 1300 octets sur le numéro de paquet 288 et la réponse sur 289 :

Comportement COS AP

Il existe des différences dans le mécanisme de découverte pour AP-COS APs. Nous commençons par la jonction AP.

Phase de jonction AP

Au moment de la jonction, l'AP envoie une demande de jonction avec la valeur maximale et attend cinq secondes.

En l'absence de réponse, il réessaie et attend cinq secondes supplémentaires. 

S'il n'y a toujours pas de réponse, il envoie une autre requête de jointure de 1 005 octets. Si cela réussit, il met à jour PMTU et continue (par exemple, le téléchargement d'image). Si la sonde DF de 1 005 octets ne parvient toujours pas à atteindre le contrôleur, elle passe au minimum à 576 et recommence.

Voici la commande debug capwap client pmtu au niveau du point d'accès :

Jul 11 19:06:10 kernel: [*07/11/2023 19:06:10.7065] AP_PATH_MTU_PAYLOAD_msg_enc_cb: request pmtu 1485, update FALSE
Jul 11 19:06:10 kernel: [*07/11/2023 19:06:10.7066] Sending Join request to 10.201.234.34 through port 5248, packet size 1376
Jul 11 19:06:10 kernel: [*07/11/2023 19:06:10.7066] Sending Join Request Path MTU payload, Length 1376
..
Jul 11 19:06:15 kernel: [*07/11/2023 19:06:15.3235] AP_PATH_MTU_PAYLOAD_msg_enc_cb: request pmtu 1485, update FALSE
Jul 11 19:06:15 kernel: [*07/11/2023 19:06:15.3235] Sending Join request to 10.201.234.34 through port 5248, packet size 1376
Jul 11 19:06:15 kernel: [*07/11/2023 19:06:15.3235] Sending Join Request Path MTU payload, Length 1376
Jul 11 19:06:15 kernel: [*07/11/2023 19:06:15.3245] chatter: chkcapwapicmpneedfrag :: CheckCapwapICMPNeedFrag ICMP_NEED_FRAG sent to capwapd, needfrag_count 9184
..
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0794] AP_PATH_MTU_PAYLOAD_msg_enc_cb: request pmtu 1005, update FALSE
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0794] Sending Join request to 10.201.234.34 through port 5248, packet size 896
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0794] Sending Join Request Path MTU payload, Length 896
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0831] Join Response from 10.201.234.34, packet size 917
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0832] AC accepted previous sent request with result code: 0
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0832] Received wlcType 0, timer 30
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.5280] WLC confirms PMTU 1005, updating MTU now.
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.5702] PMTU: Set capwap_init_mtu to TRUE and dcb's mtu to 1005
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.5816] CAPWAP State: Image Data
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.5822] AP image version 17.9.3.50 backup 17.6.5.22, Controller 17.9.3.50

Notez que la taille du paquet est de 1483 octets, ce qui correspond à la valeur pmtu sans l'en-tête Ethernet comme prévu pour AP-COS. Vous voyez ceci sur le paquet numéro 1168 ici :

Phase d'exécution

Une fois que le point d'accès atteint l'état RUN. il continue à essayer d'améliorer la PMTU toutes les 30 secondes, en envoyant des paquets CAPWAP avec DF défini et la prochaine valeur codée en dur.

Voici le débogage au niveau AP (debug capwap client pmtu)

Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1341] wtpEncodePathMTUPayload: Total Packet Size: 1485
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1341] wtpEncodePathMTUPayload: Capwap Size is 1376.
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1341] [ENC]AP_PATH_MTU_PAYLOAD: pmtu 1485, len 1352, buffer len 1376
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1341] capwap_build_and_send_pmtu_packet: packet length = 1485 for current path MTU discovery
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1343] Ap Path MTU payload sent, length 1368
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1343] WTP Event Request: AP Path MTU payload sent to 10.201.234.34, seq num 53
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1351] pmtu icmp pkt(ICMP_NEED_FRAG) from click received
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1351] chatter: chkcapwapicmpneedfrag :: CheckCapwapICMPNeedFrag ICMP_NEED_FRAG sent to capwapd, needfrag_count 9187
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1351] PMTU data: dcb->mtu 1005, pmtu_overhead:1184 capwapsize_mtu: 1293 next_hop_mtu 1300, last_icmp_mtu 0 router_path_mtu 0
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1351] PMTU: Last try for next hop MTU failed
Jul 11 19:08:17 kernel: [*07/11/2023 19:08:17.9850] wtpCleanupPMTUPacket: PMTU: Found matching PMTUpacket at:50 position of the Q
..
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6435] wtpEncodePathMTUPayload: Total Packet Size: 1485
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6435] wtpEncodePathMTUPayload: Capwap Size is 1376.
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6436] [ENC]AP_PATH_MTU_PAYLOAD: pmtu 1485, len 1352, buffer len 1376
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6436] capwap_build-and-send_pmtu_packet: packet length = 1485 for current path MTU discovery
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6437] Ap Path MTU payload sent, length 1368
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6438] WTP Event Request: AP Path MTU payload sent to 10.201.234.34, seq num 59
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6446] pmtu icmp pkt(ICMP_NEED_FRAG) from click received
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6446] chatter: chkcapwapicmpneedfrag :: CheckCapwapICMPNeedFrag ICMP_NEED_FRAG sent to capwapd, needfrag_count 9188
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6446] PMTU data: dcb->mtu 1005, pmtu_overhead:1184 capwapsize_mtu: 1293 next_hop_mtu 1300, last_icmp_mtu 0 router_path_mtu 0
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6447] PMTU: Last try for next hop MTU failed
Jul 11 19:08:46 kernel: [*07/11/2023 19:08:46.4945] wtpCleanupPMTUPacket: PMTU: Found matching PMTUpacket at:55 position of the Q

Voici les captures d'AP correspondantes. observez les paquets numéros 1427 et 1448 :

Conclusion (Résumé de l'algorithme)

En résumé, l'algorithme CAPWAP PMTUD sur les points d'accès fonctionne comme ceci.

Étape 1. La PMTU CAPWAP initiale est négociée pendant la phase de jonction AP.

Étape 2. 30 secondes plus tard, le point d'accès tente d'améliorer la PMTU CAPWAP actuelle en envoyant la valeur supérieure prédéfinie suivante (576, 1005, 1485 octets).

Étape 3 (option 1). Si le WLC répond, ajustez la PMTU CAPWAP actuelle à la nouvelle valeur et répétez l'étape 2.

Étape 3 (option 2). En l’absence de réponse, conservez la PMTU CAPWAP actuelle et répétez l’étape 2.

Étape 3 (option 3). S'il n'y a pas de réponse et qu'un ICMP Inaccessible (Type 3, Code 4) inclut un MTU de tronçon suivant, ajustez le PMTU CAPWAP à cette valeur et répétez l'étape 2.

NOTE: Reportez-vous aux correctifs pour vous assurer que la PMTU CAPWAP appropriée est utilisée lorsqu'une valeur de tronçon suivant ICMP est fournie.

CDET apparentés

Numéro de problème 1 :

ID de bogue Cisco CSCwf52815

AP-COS AP ne respectant pas la valeur de tronçon suivant ICMP Unreachable lorsque les sondes de valeur supérieure échouent.
Correctifs : 8.10.190.0, 17.3.8, 17.6.6, 17.9.5, 17.12.2.
Les AP IOS respectent la valeur de tronçon suivant et mettent à jour la PMTU.

Problème numéro 2 :

ID de bogue Cisco CSCwc05350

Le MTU asymétrique (WLC→AP diffère de AP→WLC) a conduit à un battement de PMTU lorsque le protocole ICMP ne reflétait pas le PMTU bidirectionnel maximum.
Correctifs : 8.10.181.0, 17.3.6, 17.6.5, 17.9.2, 17.10.1.
Solution de contournement: configurer le même MTU dans les deux directions sur les périphériques contrôlant le MTU (routeur, pare-feu, concentrateur VPN) entre le WLC et le point d'accès.

ID de bogue Cisco associé côté point d'accès CSCwc05364 : COS-AP améliore le mécanisme PMTU pour pouvoir identifier la taille MTU directionnelle maximale pour les MTU asymétriques 

ID de bogue Cisco relatif au WLC CSCwc48316 : Améliorer les calculs PMTU pour qu'AP puisse avoir deux MTU différents l'un en amont et l'autre (marqué Fermé par DE car ils n'ont pas de plans pour répondre à cela)

Problème numéro 3 :

ID de bogue Cisco CSCwf91557