Inleiding

In dit document wordt het detectiemechanisme voor het CAPWAP Access Point Path Maximum Transmission Unit (PMTU) beschreven voor IOS® XE en COS, problemen en oplossingen.

Scenario en scope

PMTU-problemen worden meestal gezien wanneer een CAPWAP-toegangspunt (AP) op een externe locatie zich registreert bij een draadloze LAN-controller (WLC) via een WAN, vooral wanneer het pad VPN, GRE of een netwerksegment met een MTU lager dan de standaard 1500 bytes omvat.

We onderzoeken ook verificatie met Extensible Authentication Protocol Transport Layer Security (EAP-TLS). Omdat EAP-TLS grote certificaten uitwisselt, verhoogt een gereduceerd MTU-pad het risico op fragmentatie.

Alle logs zijn vastgelegd op codeversie 17.9.3. Uitgangen worden afgekapt om alleen relevante lijnen weer te geven.

CAPWAP Control vs. Data (waarover wordt onderhandeld)

CAPWAP-besturing:
Het controlekanaal behandelt kritieke beheerberichten zoals join-verzoeken, configuratieuitwisselingen en bewaar levende signalen. Deze berichten worden beveiligd met behulp van DTLS en zijn de primaire focus van het Path MTU (PMTU) onderhandelingsproces om betrouwbare en efficiënte controle vliegtuig communicatie te garanderen.

CAPWAP-gegevens:
Dit kanaal draagt ingekapseld clientverkeer, meestal ook beschermd door DTLS in de meeste implementaties. Terwijl PMTU-onderhandeling plaatsvindt op het controlekanaal, bepalen de resulterende PMTU-waarden indirect de maximale pakketgrootte voor de inkapseling van het gegevensvlak, wat de betrouwbaarheid en fragmentatie van de datatransmissie van de client beïnvloedt.

Voorbeelden

• Controlepakketten: voeg verzoeken en antwoorden, configuratie-updates en echo / keepalive-berichten toe.
• Gegevenspakketten: ingekapselde clientframes die worden verzonden tussen het toegangspunt (AP) en de draadloze LAN-controller (WLC).

Feiten: maximaal formaat CAPWAP-pakket

IOS AP (voorbeeld)

Verzonden PMTU-pakketgrootte: 1499 bytes = Ethernet + CAPWAP PMTU

• Ethernet = 14 bytes
• CAPWAP PMTU = 1485 bytes 
  • Externe IP = 20 bytes
  • UDP = 25 bytes
  • DTLS = 1440 bytes

AP-COS (voorbeeld)

Verzonden PMTU-pakketgrootte: 1483 bytes = Ethernet + CAPWAP PMTU

• Ethernet = 14 bytes
• CAPWAP PMTU = 1469 bytes
  • Buitenste IP = 20 bytes
  • UDP = 25 bytes
  • DTLS = 1424 bytes

Driefasige PMTU-controles

Beide platforms testen drie hardgecodeerde PMTU-waarden: 576, 1005 en 1485. Het verschil is hoe elk platform de Ethernet-header telt: 

• IOS-toegangspunten bevatten de Ethernet-header niet in de 576/1005/1485-waarden.

  • Totaal frame = Ethernet (14) + PMTU (576/1005/1485) ⇒ 590, 1019, 1499 bytes (draadgrootte).

• AP-COS bevat de Ethernet-header wel in de waarden 576/1005/1485.

  • Totaal frame = PMTU (bevat al Ethernet). Deze pakketten zijn 14 bytes kleiner op de draad dan IOS AP-equivalenten.

CAPWAP PMTU Discovery Mechanism

IOS AP-gedrag

Fase AP-verbinding

Tijdens de CAPWAP-join onderhandelt het toegangspunt over een maximale CAPWAP PMTU van 1485 bytes met de DF-bitset. 5 seconden wachten op een reactie.

• Als er geen reactie of een ICMP "Fragmentatie nodig" arriveert, daalt het toegangspunt terug naar 576 bytes om snel te voltooien en probeert het vervolgens PMTU te verhogen nadat het RUN heeft bereikt.

Packet capture (voorbeeld)

Pakketnummer 106 U ziet een 1499-byte sonde (DF-set). Geen respons van dezelfde grootte geeft aan dat het pakket het pad niet kon doorkruisen zonder fragmentatie. U ziet dan ICMP "Fragmentatie nodig."

Het bijbehorende foutopsporingsniveau op AP-niveau ("debug capwap client path-mtu") laat zien dat het toegangspunt het eerst probeerde met 1485 bytes en 5 seconden wachtte op een reactie. Als er geen reactie is, stuurt het een ander pakket met een kleinere lengte, omdat dit nog steeds in de join-fase zit en we geen tijd hebben om te verspillen. Het gaat naar de minimumwaarde om het toegangspunt te laten deelnemen aan de WLC, zoals aangegeven in het debug-log:

*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

En als je op dit moment #show capwap client rcb draait, zie je dat de CAPWAP AP MTU op 576 bytes staat:

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 

RUN-toestandsfase

Nadat het toegangspunt zich met succes heeft aangesloten bij de draadloze LAN-controller, ziet u het PMTU Discovery Mechanism in het spel, waar u na 30 seconden kunt zien dat het toegangspunt begint te onderhandelen over een hogere PMTU-waarde door een ander CAPWAP-pakket te verzenden met een DF-bitset van die grootte van de volgende hoogste PMTU-waarde.

In dit voorbeeld heeft de AP de waarde 1005 bytes geprobeerd. Omdat IOS het Ethernet uitsluit van het PMTU-veld, ziet u 1019 bytes op de draad. Als de WLC reageert, wordt de PMTU bijgewerkt naar 1005 bytes. Als dat niet het geval is, wacht 30 seconden en probeert het opnieuw. 

Deze screenshot toont een succesvolle AP-onderhandeling van 1005 PMTU (zie pakketten # 268 en # 269). Merk op dat deze pakketten verschillende groottes hebben, wat te wijten is aan het feit dat de WLC een ander algoritme heeft voor PMTU-berekening.

Hier toont het bijbehorende foutopsporingsniveau op AP-niveau (debug capwap client pmtu) waar de AP met succes de 1005 bytes PMTU heeft onderhandeld en de AP PMTU-waarde heeft bijgewerkt.

*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

En als je dat doet (#show capwap client rcb) op dit moment vind je dat de CAPWAP AP MTU op 1005 bytes, Hier is de show output:

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 

Na 30 seconden probeert het toegangspunt opnieuw te onderhandelen over de volgende hogere waarde van 1485 bytes, maar het toegangspunt heeft ICMP onbereikbaar ontvangen terwijl de status van het toegangspunt is ingeschakeld. De ICMP onbereikbaar heeft een volgende hop waarde, en de AP eert deze waarde en gebruikt het om zijn eigen PMTU berekenen zoals we kunnen zien in de debugs.

*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

Het corresponderende AP-niveau vangt op

Let op het onbereikbare ICMP-pakketnummer 281 en vervolgens probeert de AP een PMTU te onderhandelen met het eren van de volgende ICMP-hopwaarde op 1300 bytes op pakketnummer 288 en respons op 289:

COSAP-gedrag

Er zijn verschillen in het ontdekkingsmechanisme voor AP-COS AP's. We beginnen bij AP join.

Fase AP-verbinding

Bij join verzendt het toegangspunt een join-verzoek met de maximale waarde en wacht het vijf seconden.

Als er geen reactie is, probeert het opnieuw en wacht het nog eens vijf seconden. 

Als er nog steeds geen reactie is, stuurt het een ander Join Request met 1005 bytes. Als dat lukt, wordt PMTU bijgewerkt en gaat het verder (bijvoorbeeld het downloaden van afbeeldingen). Als de 1005-byte DF-sonde de controller nog steeds niet kan bereiken, zakt deze naar het minimum van 576 en probeert het opnieuw.

Hier is de debug capwap client pmtu op het AP-niveau:

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

Merk op dat de pakketgrootte 1483 bytes is, wat de pmtu-waarde is zonder de ethernetheader zoals verwacht voor AP-COS. U ziet dit op pakketnummer 1168 hier:

RUN-toestandsfase

Nadat het toegangspunt de status RUN heeft bereikt, probeert het elke 30 seconden de PMTU te verbeteren door CAPWAP-pakketten met DF-set en de volgende harde gecodeerde waarde te verzenden.

Hier is de AP-niveau debug (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

Hier zijn de bijbehorende AP-opnames. kijk naar pakketnummer 1427 en 1448:

Conclusie (algoritme samenvatting)

Samengevat werkt het CAPWAP PMTUD-algoritme op Access Points als volgt.

Stap 1. De initiële CAPWAP PMTU wordt onderhandeld tijdens de AP join-fase.

Stap 2. 30 seconden later probeert het toegangspunt de huidige CAPWAP PMTU te verbeteren door de volgende vooraf gedefinieerde hogere waarde (576, 1005, 1485 bytes) te verzenden.

Stap 3 (optie 1). Als de WLC reageert, past u de huidige CAPWAP PMTU aan op de nieuwe waarde en herhaalt u stap 2.

Stap 3 (optie 2). Als er geen reactie is, houdt u de huidige CAPWAP PMTU en herhaalt u stap 2.

Stap 3 (optie 3). Als er geen respons is en een ICMP Unreach (Type 3, Code 4) een next-hop MTU bevat, past u de CAPWAP PMTU aan die waarde aan en herhaalt u stap 2.

OPMERKING: Zie de oplossingen om ervoor te zorgen dat de juiste CAPWAP PMTU wordt gebruikt wanneer een ICMP-waarde voor de volgende hop wordt opgegeven.

Gerelateerde CDET's

Afgiftenummer 1:

Cisco bug ID CSCwf52815

AP-COS AP's voldoen niet aan de waarde van ICMP Unreach next-hop wanneer sondes met een hogere waarde mislukken.
Oplossingen: 8.10.190.0, 17.3.8, 17.6.6, 17.9.5, 17.12.2.
IOS AP's eren de next-hop-waarde en updaten PMTU.

Afgiftenummer 2:

Cisco bug ID CSCwc05350

Asymmetrische MTU (WLC→AP verschilt van AP→WLC) leidde tot PMTU-flapperen wanneer ICMP de maximale bidirectionele PMTU niet weergaf.
Oplossingen: 8.10.181.0, 17.3.6, 17.6.5, 17.9.2, 17.10.1.
Oplossing: configureer dezelfde MTU in beide richtingen op apparaten die MTU (router, firewall, VPN-concentrator) tussen WLC en AP regelen.

Gerelateerde AP Side Cisco bug ID CSCwc05364: COS-AP verbeteren PMTU mechanisme om te kunnen identificeren van de maximale directionele MTU grootte voor asymmetrische MTUs 

Gerelateerde WLC-kant Cisco bug ID CSCwc48316: verbeter PMTU-berekeningen voor AP om twee verschillende MTU's te kunnen hebben, de ene upstream en de andere (gemarkeerd als gesloten door DE omdat ze geen plannen hebben om dit aan te pakken)

Nummer van uitgifte 3:

Cisco bug ID CSCwf91557