Netzwerk-Labs Docs Simulator öffnen →

CAPWAP-Rundreise – WLAN-Client-Verkehr in beide Richtungen

Slice J schließt den Roundtrip ab: Der WLC fängt nun Pakete ab, die für bekannte WLAN-Clients bestimmt sind, und kapselt sie erneut als CAPWAP-Data-Downlink (UDP/5247) zum zugehörigen AP. Drahtloser Client → DEST → Antwort → WLC → erneute Kapselung → AP – beide Beine in PCAP.

Dieses Lab im Browser öffnen →

Kostenlos · ohne Installation · ohne Konto

Szenario

Slice Ich habe den *Uplink*-Datenpfad geliefert: wifi-client → AP encap → WLC decap → Policy-VLAN egress → DEST. Slice J fügt die Downlink-Hälfte hinzu. Wenn ein Paket am WLC ankommt, das für die IP eines WLAN-Clients bestimmt ist, konsultiert der IPv4-Forwarder des Controllers einen Client-Locator (erstellt aus wifiClient.ipv4 + wifiClient.associatedAp + apJoin.joinedController des AP). Bei einem Treffer wird das Paket in CAPWAP-Daten mit direction: 'downlink' verpackt und vom WLC an die IP des AP gesendet – anstelle der normalen FIB-Suche, die den Client im Richtlinien-VLAN ARP und fehlschlagen würde (der Client verfügt über kein kabelgebundenes Iface). Damit ist der kanonische Roundtrip „Telefon → Anrufmanager → Telefonantwort“ abgeschlossen: 1. PHONE (WLAN-Client bei 10.30.0.50) sendet über engine.emitWirelessClientPacket. 2. AP1 bindet Uplink CAPWAP-Daten (UDP/5247) an WLC1 ein. 3. WLC1 entkapselt, sendet erneut eine innere ICMP-Echo-Anfrage 10.30.0.50 → 10.40.0.5 über Vlan30 → an DEST weitergeleitet. 4. DEST antwortet mit Echo-Antwort 10.40.0.5 → 10.30.0.50, Standardroute über WLC1. 5. WLC1 empfängt die Antwort auf seinem Transit-Iface; Der Wireless-Client-Intercept des Forwarders stimmt mit dst 10.30.0.50 überein. 6. WLC1 verpackt die innere Echo-Antwort in Downlink CAPWAP-Daten und sendet sie an AP1. 7. AP1 empfängt den Downlink-Frame – pcap zeigt ihn an. Was ist aufgeschoben: - Pro-WLAN-ACLs am AP: Das Innere des Downlink-Frames würde anhand der Pro-WLAN-ACL des AP ausgewertet, bevor er das Funkgerät des Clients erreicht. v1 liefert nur die Encap. - Echte drahtlose Lieferung: Der AP modelliert keine 802.11-Frame-Übertragung, daher ist „der Client empfängt“ implizit (sichtbar als PacketDelivered für die Downlink-Ablaufverfolgung bei AP1). Der Downlink-Abfang stimmt mit *jedem* IP-Protokoll überein – ICMP, UDP, TCP, andere –, das für einen bekannten WLAN-Client bestimmt ist. Das innere Paket wird wörtlich in CAPWAP-Daten eingebettet; Der Downlink-Handler des AP rendert es. Der Schleifenschutz schließt unsere eigenen ausgehenden CAPWAP-Frames aus, sodass wir kein Wrap-and-Re-Wrap durchführen.

Topologie

2 × Router, 1 × WLAN-Controller, 1 × Switch, 1 × Access Point, 1 × WLAN-Client · Cisco IOS-XE-style

Das machst du

  1. Bestätigen Sie, dass AP1 WLC1 beigetreten ist und PHONE seine statische IP hat.

  2. Auslöser TELEFON: engine.emitWirelessClientPacket({ deviceId: 'PHONE', dst: parseIPv4('10.40.0.5') }). Pcap sollte Folgendes anzeigen: (a) UDP/5247-Uplink AP1→WLC1, (b) entkappte Echo-Anfrage auf Vlan30, (c) über Gi0/2 an DEST weitergeleitet, (d) Echo-Antwort von DEST kehrt zu WLC1 zurück, (e) UDP/5247-Downlink WLC1→AP1 mit der inneren Echo-Antwort.

Dieses Lab im Browser öffnen →

Weitere Labs zu diesem Thema

Dieses Lab in anderen Sprachen

CAPWAP round-trip — wifi-client traffic both directionsCAPWAP ida y vuelta: tráfico de cliente wifi en ambas direccionesIda e volta CAPWAP - tráfego de cliente wifi em ambas as direçõesCAPWAP aller-retour — trafic client Wi-Fi dans les deux sensCAPWAP राउंड-ट्रिप - वाईफाई-क्लाइंट ट्रैफ़िक दोनों दिशाओं मेंCAPWAP 往返 — wifi 客户端流量双向CAPWAP andata e ritorno: traffico client Wi-Fi in entrambe le direzioniCAPWAP ラウンドトリップ — Wi-Fi クライアント トラフィックの両方向CAPWAP 왕복 — Wi-Fi-클라이언트 트래픽 양방향CAPWAP туда и обратно — трафик Wi-Fi-клиента в обоих направленияхCAPWAP gidiş-dönüş — her iki yönde de Wi-Fi istemci trafiğiChuyến đi khứ hồi CAPWAP - lưu lượng truy cập wifi-client cả hai hướng