Laboratori di rete Docs Apri simulatore →

Rilevamento CAPWAP: l'AP si unisce al controller tramite l'opzione DHCP-138

Guida un AP attraverso la scoperta di CAPWAP e il ciclo di vita dell'adesione. Il ROUTER serve DHCP con l'opzione-138 che punta all'IP di gestione di WLC1; al momento dell'ACK di lease, AP1 contrassegna l'IP del controller nel relativo slot apJoin, trova WLC1 nella topologia, confronta il suo MAC con un apRecord e passa a phase: joined con i tag policy/sito/rf appiattiti.

Apri questo laboratorio nel browser →

Gratis · senza installazione · senza account

Scenario

Le sezioni A–D consentono di esprimere e ispezionare il modello wireless gestito dal controller end-to-end sul controller. La fetta E chiude il ciclo: l'AP stesso scopre il controller e si unisce ad esso. Il flusso di scoperta CAPWAP modellato da questo laboratorio: 1. L'AP si avvia con ipFromDhcp: true e trasmette un DHCPDISCOVER. 2. Il server DHCP del ROUTER risponde con un'OFFERTA e su RICHIESTA invia un ACK che include opzione-138 (RFC 5417) che trasporta l'IP di gestione di WLC1. 3. Il client DHCP di AP1 accetta il lease come al solito, *e* inoltre contrassegna l'IP opzione-138 nel suo slot apJoin.controllerIp. La fase diventa discovered. 4. Il motore quindi analizza la topologia: quale dispositivo possiede quell'IP? Nel nostro caso WLC1. WLC1 ha un apRecord che corrisponde al MAC primario di AP1 (aabb.cc00.dd00)? SÌ. Quindi la fase passa a joined e la tripletta policy/sito/tag rf di apRecord viene *appiattita* nello stato apJoin di AP1. 5. AP1 ora ha la sua configurazione effettiva senza mai accedere all'IR del controller: denormalizzato di proposito in modo che il runtime possa leggere direttamente i tag. Ispezionare entrambi i lati: `` AP1# show capwap client summary WLC1# show capwap ap summary ` I percorsi negativi emergono come diagnostica: - Nessun apRecord corrisponde al MAC dell'AP → phase: rejected, con un motivo come no apRecord for aabb.cc00.dd00 on controller 'WLC1'. - L'IP opzione-138 non appartiene a nessun dispositivo → phase: discovered` (conosciamo un IP AC ma nessun dispositivo lo rivendica; lo vedresti in produzione quando il controller non è raggiungibile). Slice E scoperta delle navi + unisciti a *state*. Il percorso dati effettivo attraverso il tunnel CAPWAP (pacchetti client wireless che entrano nel controller ed escono nella VLAN di uscita del profilo policy) è un lavoro avanzato per Slice F.

Topologia

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

Cosa farai

  1. Sul ROUTER, crea il pool DHCP LAN (10.0.0.0/24, gateway 10.0.0.1) e pubblicizza l'opzione-138 con l'IP di WLC1 (10.0.0.10). Escludere.1–.20.

  2. Su WLC1, crea il modello minimo: profili, tag e un apRecord per aabb.cc00.dd00 (MAC primario di AP1) associato a tutti e tre i tag.

  3. Dopo la convergenza, AP1 dovrebbe riportare phase: joined ed ereditare i tre collegamenti di tag dall'apRecord di WLC1.

Apri questo laboratorio nel browser →

Altri laboratori su questo tema

Questo laboratorio in altre lingue

CAPWAP discovery — AP joins controller via DHCP option-138CAPWAP-Erkennung – AP verbindet sich mit dem Controller über DHCP-Option 138Descubrimiento CAPWAP: AP se une al controlador a través de la opción DHCP-138Descoberta CAPWAP – AP junta-se ao controlador via DHCP opção-138Découverte CAPWAP — AP rejoint le contrôleur via l'option DHCP-138CAPWAP खोज - AP DHCP विकल्प-138 के माध्यम से नियंत्रक से जुड़ता हैCAPWAP 发现 — AP 通过 DHCP option-138 加入控制器CAPWAP 検出 - AP は DHCP オプション 138 経由でコントローラに接続しますCAPWAP 검색 - AP가 DHCP 옵션-138을 통해 컨트롤러에 연결됩니다.Обнаружение CAPWAP — точка доступа подключается к контроллеру через опцию DHCP-138.CAPWAP keşfi — AP, DHCP seçenek-138 aracılığıyla denetleyiciye katılırKhám phá CAPWAP - AP tham gia bộ điều khiển thông qua tùy chọn DHCP-138