Network labs Docs Open simulator →

CAPWAP end-to-end — wifi-client traffic decap'd at the WLC

Slice I closes the uplink datapath: when PHONE (wifi-client at 10.30.0.50) emits a packet, the AP1 wraps it in CAPWAP-Data UDP/5247 to WLC1, the WLC peels the headers and re-emits the inner ICMP echo-request on its policy-VLAN egress (Vlan30 SVI). DEST (10.30.0.5) receives the decap'd packet — pcap shows both the encap'd UDP/5247 frame on the AP→WLC wire AND the decap'd ICMP on the policy VLAN.

Open this lab in your browser →

Free · no install · no account

Scenario

Slice I delivers the WLC-side decap. The chain is now wire-real end-to-end: 1. PHONE (wifi-client, IP 10.30.0.50, associated with AP1) is asked to emit a packet to 10.30.0.5. 2. AP1 wraps the inner ICMP packet in CAPWAP-Data UDP/5247 sourced from its own IP and sent to WLC1's mgmt IP. 3. Firewalls in the path (if any) evaluate UDP/5247 — pcap shows the encap'd frame, ACLs hit/miss as configured. 4. WLC1's UDP/5247 handler decaps the inner packet and re-emits it as a normal IPv4 packet through the controller's FIB. The Vlan30 SVI is the egress (the policy profile pinned VLAN 30; the controller's directly-connected route for 10.30.0.5/24 is via the Vlan30 SVI). 5. DEST receives the inner ICMP echo-request — pcap shows the decap'd packet arriving on its iface. Reach semantics: this slice ships uplink end-to-end. The downlink direction (DEST's reply → WLC re-encaps as CAPWAP-Data → AP → wireless to client) is forward work, since the WLC needs a per-client mapping ("which AP currently has client 10.30.0.50?") that we don't yet build at runtime. For most operator questions ("does my voice phone reach the call manager?") uplink delivery + Slice F's reach query cover the answer. DHCP option 133: while we're here, the simulator now also exposes option 133 (L2 priority / 802.1p CoS) alongside the existing option 132 (voice VLAN). Cisco IP phones use the pair: 132 carries the voice VLAN ID, 133 the CoS to stamp on tagged voice frames (typically 5).

Topology

2 × router, 1 × wireless controller, 1 × switch, 1 × access point, 1 × wifi client · Cisco IOS-XE-style

What you will do

  1. Confirm AP1 joined WLC1 and PHONE is associated.

  2. Trigger PHONE to emit an ICMP echo-request to 10.30.0.5: engine.emitWirelessClientPacket({ deviceId: 'PHONE', dst: parseIPv4('10.30.0.5') }). Pcap should show: (a) UDP/5247 CAPWAP-Data frame from AP1 to WLC1, (b) decap'd ICMP echo-request from 10.30.0.50 to 10.30.0.5 leaving WLC1's Vlan30 interface, (c) DEST receiving the echo-request.

Open this lab in your browser →

More labs on this topic

This lab in other languages

CAPWAP End-to-End – WLAN-Client-Verkehr wird am WLC enthauptetCAPWAP de extremo a extremo: tráfico de cliente wifi sin capacidad en el WLCCAPWAP ponta a ponta - tráfego do cliente wifi decapado no WLCCAPWAP de bout en bout — trafic client wifi décapé au niveau du WLCCAPWAP एंड-टू-एंड - WLC पर वाईफाई-क्लाइंट ट्रैफिक डिकैप्डCAPWAP 端到端 — 在 WLC 上解除 wifi 客户端流量限制CAPWAP end-to-end: traffico client Wi-Fi decapato al WLCCAPWAP エンドツーエンド - WLC で Wi-Fi クライアント トラフィックのキャップを解除CAPWAP 종단 간 — WLC에서 Wi-Fi 클라이언트 트래픽의 제한이 해제됩니다.Сквозной CAPWAP — трафик Wi-Fi-клиента ограничивается на WLCCAPWAP uçtan uca — Wi-Fi istemci trafiğinin sınırı WLC'de azaldıCAPWAP end-to-end — giải mã lưu lượng truy cập wifi-client tại WLC