Laboratorios de redes Docs Abrir simulador →

Reintento CAPWAP, latido y emisión de túnel de cliente wifi

El segmento H hace que CAPWAP se comporte como el protocolo real: los AP reintentan la unión cuando se interrumpe la ruta, intercambian latidos de eco con el controlador cada 30 s una vez unidos y los clientes inalámbricos son ciudadanos de topología de primera clase. PHONE (un wifi-client asociado con AP1) emite un paquete que viaja encapsulado en CAPWAP en UDP/5247 desde AP1 a WLC1, visible en pcap.

Abrir este laboratorio en el navegador →

Gratis · sin instalación · sin cuenta

Escenario

Tres adiciones en este laboratorio: 1. Temporizador de reintento: cuando se pierde la solicitud de unión de AP1 (caída del firewall, ruta incorrecta, colisión de paquetes), el AP reemite cada 5 s. Después de 6 intentos, se da por vencido: pcap muestra una ráfaga limitada en lugar de un giro infinito. 2. Latido de eco: una vez unido, AP1 emite un echo-request (UDP/5246, messageType: 'echo-request') cada 30 s. WLC1 reconoce con echo-response y result: success. Después de 3 respuestas perdidas, el AP vuelve a pasar a phase: 'discovered' y activa una nueva unión, exactamente lo que hacen los AP reales cuando el controlador se queda en silencio. 3. tipo de dispositivo cliente wifi: un nuevo tipo de dispositivo que se asocia lógicamente con un AP. El tráfico saliente es inalámbrico a AP y luego encapsulado en datos CAPWAP (UDP/5247) al controlador. El simulador expone engine.emitWirelessClientPacket(deviceId, innerSummary) para disparar uno: pcap muestra el marco UDP/5247 encapsulado con app: { kind: 'capwap-data', direction: 'uplink', innerSummary, apMac }. El efecto combinado: un ingeniero de redes ahora puede evaluar "¿cuánto tráfico CAPWAP hay en el cable?" leyendo fotogramas capturados; puede ver tormentas de reintento cuando los caminos se rompen; Puede colocar firewalls/IPS a lo largo de la ruta AP-WLC y verlos inspeccionar el tráfico real UDP/5246 + UDP/5247. Lo que aún queda por hacer: la desconexión del lado WLC de UDP/5247 (reemitir la trama interna en la salida de la VLAN de política) y DHCP vía AP para la adquisición de IP del cliente. El segmento H brinda visibilidad de la ruta de datos del *enlace ascendente* (la pieza más útil para el posicionamiento del firewall) y difiere el modelo bidireccional completo.

Topología

1 × router, 1 × controlador inalámbrico, 1 × switch, 1 × punto de acceso, 1 × cliente wifi · Cisco IOS-XE-style

Qué vas a hacer

  1. Después de la convergencia, AP1 debería estar en phase: joined (ruta abierta, sin bloqueo de firewall).

  2. Ejecute el simulador durante 90 segundos. Pcap debe mostrar al menos 2 viajes de ida y vuelta de echo-request (AP1→WLC1) y echo-response (WLC1→AP1) en UDP/5246.

  3. Active PHONE para emitir un paquete a través de la API del motor: engine.emitWirelessClientPacket({ deviceId: 'PHONE', innerSummary: 'icmp echo-request 10.30.0.5' }). El pcap muestra una trama CAPWAP-Data UDP/5247 que sale de AP1 hacia la IP de administración de WLC1 y lleva el resumen interno.

Abrir este laboratorio en el navegador →

Más laboratorios de este tema

Este laboratorio en otros idiomas

CAPWAP retry, heartbeat, and wifi-client tunnel emissionCAPWAP-Wiederholung, Heartbeat und WLAN-Client-Tunnel-EmissionNova tentativa CAPWAP, pulsação e emissão de túnel do cliente wifiNouvelle tentative CAPWAP, battement de cœur et émission de tunnel client Wi-FiCAPWAP पुनः प्रयास, दिल की धड़कन, और वाईफाई-क्लाइंट सुरंग उत्सर्जनCAPWAP 重试、心跳和 w​​ifi 客户端隧道发射Nuovo tentativo CAPWAP, heartbeat ed emissione del tunnel client Wi-FiCAPWAP の再試行、ハートビート、および Wi-Fi クライアント トンネルの送信CAPWAP 재시도, 하트비트 및 Wi-Fi 클라이언트 터널 방출Повторная попытка CAPWAP, контрольный сигнал и эмиссия туннеля Wi-Fi-клиентаCAPWAP yeniden denemesi, kalp atışı ve Wi-Fi istemci tüneli emisyonuThử lại CAPWAP, nhịp tim và phát ra đường hầm wifi-máy khách