Laboratori di rete Docs Apri simulatore →

CAPWAP end-to-end: traffico client Wi-Fi decapato al WLC

Slice I chiude il percorso dati di uplink: quando PHONE (client wifi su 10.30.0.50) emette un pacchetto, AP1 lo avvolge in CAPWAP-Data UDP/5247 su WLC1, il WLC rimuove le intestazioni e riemette la richiesta eco ICMP interna sulla sua policy-VLAN in uscita (Vlan30 SVI). DEST (10.30.0.5) riceve il pacchetto decapsulato: pcap mostra sia il frame UDP/5247 codificato sul cavo AP→WLC SIA l'ICMP decapsulato sulla policy VLAN.

Apri questo laboratorio nel browser →

Gratis · senza installazione · senza account

Scenario

Slice I fornisce il decap lato WLC. La catena è ora end-to-end wire-real: 1. Al TELEFONO (client wifi, IP 10.30.0.50, associato a AP1) viene chiesto di emettere un pacchetto a 10.30.0.5. 2. AP1 avvolge il pacchetto ICMP interno in CAPWAP-Data UDP/5247 provenienti dal proprio IP e inviati all'IP mgmt di WLC1. 3. Firewall nel percorso (se presenti) valutano UDP/5247 — pcap mostra il frame encap, gli ACL hit/miss come configurato. 4. Il gestore UDP/5247 di WLC1 decapsula il pacchetto interno e lo riemette come un normale pacchetto IPv4 attraverso il FIB del controller. L'SVI Vlan30 è l'uscita (il profilo policy ha bloccato la VLAN 30; il percorso connesso direttamente al controller per 10.30.0.5/24 avviene tramite l'SVI Vlan30). 5. DEST riceve la richiesta echo interna ICMP: pcap mostra il pacchetto decapato in arrivo sul suo iface. Semantica di copertura: questa sezione viene spedita uplink end-to-end. La direzione del downlink (risposta di DEST → WLC ricompatta come CAPWAP-Data → AP → wireless al client) è un lavoro in avanti, poiché il WLC necessita di una mappatura per client ("quale AP ha attualmente il client 10.30.0.50?") che non creiamo ancora in fase di runtime. Per la maggior parte delle domande degli operatori ("il mio telefono vocale raggiunge il gestore delle chiamate?") la consegna dell'uplink + la query sulla portata di Slice F coprono la risposta. Opzione DHCP 133: già che ci siamo, il simulatore ora espone anche l'opzione 133 (priorità L2 / CoS 802.1p) insieme all'opzione esistente 132 (VLAN vocale). I telefoni IP Cisco utilizzano la coppia: 132 trasporta l'ID VLAN vocale, 133 il CoS da stampare sui frame vocali contrassegnati (in genere 5).

Topologia

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

Cosa farai

  1. Conferma che AP1 si è unito a WLC1 e che il TELEFONO è associato.

  2. Attivare TELEFONO per emettere una richiesta eco ICMP a 10.30.0.5: engine.emitWirelessClientPacket({ deviceId: 'PHONE', dst: parseIPv4('10.30.0.5') }). Pcap dovrebbe mostrare: (a) frame di dati CAPWAP UDP/5247 da AP1 a WLC1, (b) richiesta di eco ICMP decapata da 10.30.0.50 a 10.30.0.5 che lascia l'interfaccia Vlan30 di WLC1, (c) DEST che riceve la richiesta di eco.

Apri questo laboratorio nel browser →

Altri laboratori su questo tema

Questo laboratorio in altre lingue

CAPWAP end-to-end — wifi-client traffic decap'd at the WLCCAPWAP 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 エンドツーエンド - 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