Netzwerk-Labs Docs Simulator öffnen →

CAPWAP-Erkennung – AP verbindet sich mit dem Controller über DHCP-Option 138

Führen Sie einen AP durch den CAPWAP-Erkennungs- und Beitrittslebenszyklus. Der ROUTER bedient DHCP mit Option 138, die auf die Verwaltungs-IP von WLC1 verweist. Beim Leasing-ACK stempelt AP1 die Controller-IP in seinen apJoin-Steckplatz, findet WLC1 in der Topologie, gleicht seinen MAC mit einem apRecord ab und wechselt zu phase: joined mit den abgeflachten Richtlinien-/Site-/RF-Tags.

Dieses Lab im Browser öffnen →

Kostenlos · ohne Installation · ohne Konto

Szenario

Mit den Slices A–D können Sie das vom Controller verwaltete Wireless-Modell Ende-zu-Ende auf dem Controller ausdrücken und überprüfen. Slice E schließt die Schleife: Der AP selbst erkennt den Controller und schließt sich ihm an. Der CAPWAP-Erkennungsablauf in diesem Labor modelliert: 1. Der AP bootet mit ipFromDhcp: true und sendet ein DHCPDISCOVER. 2. Der DHCP-Server des Routers antwortet mit einem ANGEBOT und sendet auf ANFRAGE eine Bestätigung, die Option-138 (RFC 5417) enthält und die Verwaltungs-IP von WLC1 überträgt. 3. Der DHCP-Client von AP1 übernimmt die Lease wie gewohnt, *und* stempelt zusätzlich die Option-138-IP in seinen apJoin.controllerIp-Steckplatz. Die Phase wird zu discovered. 4. Die Engine durchläuft dann die Topologie: Welches Gerät besitzt diese IP? In unserem Fall WLC1. Hat WLC1 einen apRecord, der mit dem primären MAC von AP1 (aabb.cc00.dd00) übereinstimmt? Ja. Die Phase wechselt also zu joined, und das Policy-/Site-/RF-Tag-Triplett von apRecord wird auf den apJoin-Status von AP1 *abgeflacht*. 5. AP1 hat jetzt seine effektive Konfiguration, ohne jemals auf die IR des Controllers zurückgreifen zu müssen – absichtlich denormalisiert, damit die Laufzeit Tags direkt lesen kann. Überprüfen Sie beide Seiten: `` AP1# show capwap client summary WLC1# show capwap ap summary ` Die negativen Pfade tauchen als Diagnose auf: - Kein apRecord stimmt mit dem MAC des AP überein → phase: rejected, mit einem Grund wie no apRecord for aabb.cc00.dd00 on controller 'WLC1'. – Die Option-138-IP gehört zu keinem Gerät → phase: discovered` (wir kennen eine AC-IP, aber kein Gerät beansprucht sie; Sie würden dies in der Produktion sehen, wenn der Controller nicht erreichbar ist). Slice E versendet Discovery + Join *state*. Der tatsächliche Datenpfad durch den CAPWAP-Tunnel – drahtlose Client-Pakete, die in den Controller gelangen und im Ausgangs-VLAN des Richtlinienprofils wieder herauskommen – ist für Slice F eine Vorwärtsarbeit.

Topologie

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

Das machst du

  1. Erstellen Sie auf dem ROUTER den DHCP-Pool LAN (10.0.0.0/24, Gateway 10.0.0.1) und geben Sie Option 138 mit der IP von WLC1 (10.0.0.10) bekannt. Ausschließen.1–.20.

  2. Erstellen Sie auf WLC1 das Minimalmodell: Profile, Tags und einen apRecord für aabb.cc00.dd00 (den primären MAC von AP1), der an alle drei Tags gebunden ist.

  3. Nach der Konvergenz sollte AP1 phase: joined melden und die drei Tag-Bindungen vom apRecord von WLC1 erben.

Dieses Lab im Browser öffnen →

Weitere Labs zu diesem Thema

Dieses Lab in anderen Sprachen

CAPWAP discovery — AP joins controller via 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 加入控制器Rilevamento CAPWAP: l'AP si unisce al controller tramite l'opzione DHCP-138CAPWAP 検出 - 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