DHCP-via-AP — wifi-clients acquire IPs through CAPWAP
- Services & wireless
- Advanced
- 12 min
- 1 steps
- Cisco IOS-XE-style
Slice L: a wifi-client with ipFromDhcp: true no longer needs a static IP. When its AP completes the join handshake, the WLC allocates the next free IP from the policy-VLAN's DHCP pool and stamps it onto the client. Pcap shows a CAPWAP-Data downlink frame carrying a synthetic DHCP-ACK so operators see the wire-shape of the lease delivery.
Open this lab in your browser →
Free · no install · no account
Scenario
Real Cisco wireless deployments don't hard-code wifi-client IPs. Clients DHCP at association time; the AP relays the broadcast through CAPWAP to the WLC; the WLC's DHCP relay (or local pool) hands out an IP from the policy-VLAN's address space. Slice L delivers the *operational* result of that flow without modeling the full 4-way exchange: - wifiClient.ipFromDhcp: true is a new field. Mutually exclusive with a static ipv4. - At AP-join time, the WLC walks its dhcpPools for one whose subnet matches the policy VLAN. It allocates the next free IP, skipping dhcpExcluded ranges and IPs already held by other devices, and stamps it onto wifiClient.ipv4. - Pcap visibility: a synthesised CAPWAP-Data downlink frame is emitted with a DHCP-ACK inner — app.innerPacket.payload.app.kind === 'dhcp'. The trace gives operators the same "client got an IP via the tunnel" view they'd expect from a real packet capture. What's deferred (still forward work): - Real 4-way exchange: DISCOVER → OFFER → REQUEST → ACK with proper transactions. Today we synthesise just the ACK for the wire trace; the IP decision is the deterministic pool walk. - Helper-address relay: forwarding the inner DHCP request to a separate DHCP server. Today the pool must live on the WLC itself. - Lease expiry on the wireless side: the IP is held until topology change.
Topology
1 × router, 1 × wireless controller, 1 × switch, 1 × access point, 1 × wifi client · Cisco IOS-XE-style
ROUTER— routerWLC1— wireless controllerHUB— switchAP1— access pointPHONE— wifi client
What you will do
After convergence, PHONE should have IP
10.30.0.21allocated from WLC1's WIFI pool (the first free IP after the .1–.20 excluded range).
Open this lab in your browser →
More labs on this topic
- Configure a DHCP serverBeginner · 12 min
- WLAN — broadcast a basic SSIDBeginner · 10 min
- HSRP: configure first-hop redundancyIntermediate · 12 min
- NAT: PAT (overload) for an inside LANIntermediate · 14 min
- HSRP — interface tracking with priority decrementIntermediate · 12 min
- VRF-Lite — two customers on one routerIntermediate · 12 min
This lab in other languages
DHCP-via-AP – WLAN-Clients beziehen IPs über CAPWAPDHCP-via-AP: los clientes wifi adquieren direcciones IP a través de CAPWAPDHCP-via-AP — clientes wifi adquirem IPs através de CAPWAPDHCP-via-AP — les clients Wi-Fi acquièrent des adresses IP via CAPWAPडीएचसीपी-वाया-एपी - वाईफाई-क्लाइंट CAPWAP के माध्यम से आईपी प्राप्त करते हैंDHCP-via-AP — wifi 客户端通过 CAPWAP 获取 IPDHCP-via-AP: i client Wi-Fi acquisiscono IP tramite CAPWAPDHCP-via-AP — Wi-Fi クライアントは CAPWAP を通じて IP を取得しますDHCP-via-AP — Wi-Fi 클라이언트는 CAPWAP를 통해 IP를 얻습니다.DHCP-через-AP — Wi-Fi-клиенты получают IP-адреса через CAPWAP.DHCP-via-AP — Wi-Fi istemcileri IP'leri CAPWAP aracılığıyla alırDHCP-via-AP - máy khách wifi lấy IP thông qua CAPWAP