CAPWAP Tunnels and Forwarding Modes
Key Takeaways
- CAPWAP is the control/data encapsulation protocol between Fit APs and the AC; control uses UDP 5246 and data uses UDP 5247.
- CAPWAP control is commonly protected with DTLS so configuration and management messages are not plain text on the underlay.
- Centralized (tunnel) forwarding sends user data through the CAPWAP data tunnel to the AC; local (direct) forwarding bridges user data onto the local wired network at the AP.
- Split MAC architecture divides 802.11 MAC functions between the AP (real-time) and the AC (non-real-time management).
- Port numbers and tunnel-versus-local behavior are high-frequency exam traps; always map where frames are encrypted and where they exit to VLANs.
CAPWAP: the language between Fit AP and AC
Once you accept Fit AP + AC architecture, you need the protocol that glues them together: CAPWAP (Control And Provisioning of Wireless Access Points). CAPWAP carries control-plane messages (join, keepalives, configuration, statistics) and, when tunnel mode is used, data-plane user frames between the AP and the AC.
HCIA loves three concrete facts:
- Control plane → UDP port 5246
- Data plane → UDP port 5247
- Control is often secured with DTLS (Datagram TLS) so management is not exposed in cleartext across campus underlays
Memorize the ports as a pair: 5246 control, 5247 data. Mixing them is a classic wrong-answer trap. Also note CAPWAP uses UDP, not TCP, for these well-known ports—another distractor.
| Plane | Port | Typical content | Security note |
|---|---|---|---|
| Control | UDP 5246 | Discovery/join, config download, keepalives, stats | Commonly DTLS-protected |
| Data | UDP 5247 | Encapsulated client frames (when centralized/tunnel forwarding) | Tunnel endpoint is the AC |
Firewalls between APs and ACs must allow these UDP flows (and related discovery) or APs will never stay online even if PoE and DHCP work.
Discovery, join, config, service (process model)
Think of CAPWAP lifecycle as four phases you can narrate in any oral or multiple-choice scenario:
1) Discovery
The AP already has an IP address. It must learn which AC to use:
- DHCP Option 43 (very common) carrying AC IP information
- DNS resolution of a well-known AC name (design-dependent)
- Static AC IP configured on the AP
- Layer 2 discovery when AP and AC share a broadcast domain (small or lab topologies)
Discovery answers: “Who is my controller?”
2) Join (and secure control channel)
The AP establishes the CAPWAP control channel to the AC on UDP 5246. DTLS negotiation commonly protects this channel. The AC authenticates the AP (certificates/PSK-style AP authentication depending on product config) and accepts it into the managed inventory.
Join answers: “May this AP be managed by me?”
3) Configuration
The AC pushes radio parameters, SSID/VAP bindings, security profiles, VLAN mappings, and forwarding mode. The AP applies the working set and reports status. Firmware upgrade workflows also run through the controller relationship in enterprise operations (details vary by platform train).
Config answers: “What SSIDs, channels, and policies should this AP run?”
4) Service
Radios enable; clients scan, authenticate, associate, and pass data. CAPWAP keepalives maintain the control relationship. If the control tunnel dies, Fit APs generally cannot remain fully managed; service impact depends on product behavior and whether local forwarding still has a last-known config—but exam focus is that healthy CAPWAP control is required for normal Fit operation.
Service answers: “Users can associate and traffic flows per policy.”
Split MAC architecture
Split MAC means 802.11 MAC functions are divided between AP and AC rather than all living in one box:
| Function class | Typically on AP | Typically on AC |
|---|---|---|
| Real-time / time-sensitive | Beaconing, probing response handling, encryption/decryption on air (design-dependent), frame ack timing | — |
| Non-real-time management | Local execution of pushed config | Association state tracking at system level, auth integration, RF/policy orchestration, configuration master |
| Data path | Depends on forwarding mode | Centralized mode: tunnel termination and wired handoff |
You do not need every 802.11 state machine for HCIA. You need the idea: Fit designs split intelligence so the edge stays real-time while the AC stays authoritative for policy and management. This is why Fat AP “all-in-one” vs Fit “split” is a meaningful architecture contrast.
Forwarding modes: centralized vs local
This is the highest-value operational concept after port numbers.
Centralized forwarding (tunnel / CAPWAP data)
In centralized (also called tunnel) forwarding, user data frames from wireless clients are encapsulated in the CAPWAP data tunnel (UDP 5247) and sent to the AC. The AC decapsulates and forwards frames onto the wired campus (toward the user gateway/VLAN).
Implications:
- All user traffic hairpins through the AC path (capacity planning matters).
- AC is both control and data choke point—redundancy and uplink bandwidth are critical.
- Easy to apply central security inspection or consistent VLAN handoff at the AC.
- Branch AP to central AC over WAN can be bandwidth-heavy if you tunnel all video/voice.
Exam phrasing: user data goes through the CAPWAP data tunnel to the AC.
Local forwarding (direct / local switching)
In local (direct) forwarding, after a client associates and is authorized, the AP bridges user frames onto the local wired network (into the correct service VLAN on the access switch) without sending that user data through the AC data tunnel. CAPWAP control still exists for management; the data plane is local.
Implications:
- User traffic takes the shortest wired path to the local gateway—better for bandwidth and latency.
- Access switches and trunks must carry service VLANs correctly to the AP port.
- AC remains vital for control, but user data plane failure modes differ.
- Preferred in many modern campus designs for capacity reasons (product defaults vary by release and profile).
| Mode | User data path | CAPWAP data 5247 for users? | Underlay need |
|---|---|---|---|
| Centralized / tunnel | Client → AP → AC → wired | Yes (typical) | Solid AP–AC bandwidth |
| Local / direct | Client → AP → local switch/VLAN | Not for user payload | Correct local service VLANs |
Mixed / flexible designs (awareness)
Some deployments map guest SSID to tunnel mode (force traffic to a central scrubbing point) and staff SSID to local mode (performance). HCIA may not require deep mixed-mode CLI, but understanding that forwarding mode is a per-service policy choice prevents absolute statements like “CAPWAP always carries all user data.”
Where encryption is terminated (exam trap)
Separate two different “encryption” stories:
- Air interface security — WPA2/WPA3 protects frames between client and AP (wireless hop). The AP (or coordinated crypto engine) is the usual wireless encryption endpoint for that hop.
- CAPWAP control security — DTLS protects AP–AC control messages on the wired underlay.
- CAPWAP data tunnel — encapsulates user frames toward the AC in centralized mode; this is not the same thing as the client’s WPA2 PTK on air.
Wrong mental model: “Because DTLS exists, clients do not need WPA2/WPA3.” Clients still need WLAN security on the air. DTLS protects the controller channel, not the coffee-shop attacker next to the user.
Wrong mental model: “In local forwarding there is no CAPWAP.” Control CAPWAP still manages the Fit AP; only user data is local.
WMM QoS basics (wireless priority)
WMM (Wi-Fi Multimedia) maps traffic to 802.11 access categories so voice and video compete more fairly on the shared medium:
| Access category (concept) | Typical traffic |
|---|---|
| Voice | VoIP handsets, real-time voice |
| Video | Conferencing, streaming |
| Best effort | General data |
| Background | Bulk / low priority |
WMM does not replace wired QoS end-to-end, but HCIA expects recognition that wireless QoS uses access categories and that voice SSIDs often get preferential treatment in design. CAPWAP and wired DSCP mapping may preserve priority marks depending on configuration—details are product-specific; the concept is priority on air via WMM.
Troubleshooting with a CAPWAP mindset
| Symptom | Likely plane | Checks |
|---|---|---|
| AP never appears on AC | Discovery / IP / firewall | DHCP Option 43, routing to AC, UDP 5246 |
| AP joins then drops | Control stability | Keepalives, DTLS, underlay loss |
| Clients associate but no IP / no gateway | Data VLAN path | Local vs tunnel mode, DHCP relay, gateway VLAN |
| Only tunnel-mode SSIDs fail | AC data path | AC uplink, 5247 path, AC load |
| Only local-mode SSIDs fail | Access switch trunk | allow-pass service VLANs to AP |
Exam traps for this section
- TCP 5246 instead of UDP 5246 for control.
- Swapping 5246/5247.
- Assuming local forwarding means “no AC” or “Fat AP.”
- Assuming centralized forwarding means clients associate directly to the AC radio (they still associate to APs).
- Confusing DTLS on CAPWAP with WPA3 on air.
Transition
Tunnels move management and optionally data. Clients still must authenticate and encrypt on the wireless hop. The next section covers WPA2-PSK vs enterprise, WPA3 SAE, and related WLAN security basics you will see on H12-811.
Which protocol and port does CAPWAP use by default for control-plane messages between an AP and an AC?
In centralized (tunnel) forwarding with split MAC, how is wireless user data typically delivered to the wired network?
What is a primary characteristic of local (direct) forwarding on a Fit AP?
Which statement correctly separates CAPWAP DTLS from client WLAN encryption?