Study guide
10.2 Centralized vs Distributed Forwarding and Network Planes
CWNA Certified Wireless Network Administrator CWNA-109
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 CWNA-109 Knowledge Domains and Study Strategy
2 RF Fundamentals
2.1 RF Waves, Propagation, Gain and Loss 2.2 Reflection, Multipath, VSWR and Free-Space Path Loss 2.3 RF Units and the Rule of 10s and 3s
3 RF Measurement and Antenna Systems
3.1 Noise Floor, SNR, RSSI and EIRP 3.2 Line of Sight, Fresnel Zone, Polarization and MIMO 3.3 Antenna Types, Charts, Cables and Lightning Protection
4 Industry Bodies and Legacy PHY
4.1 Industry Organizations and OSI Layers 4.2 Legacy 802.11 PHY Standards 4.3 Spread Spectrum, Modulation and MCS
5 Modern 802.11 PHY and Channel Concepts
5.1 Wi-Fi 4 HT and Wi-Fi 5 VHT 5.2 Wi-Fi 6 and Wi-Fi 6E High Efficiency 5.3 Primary Channels, OBSS, Throughput and Guard Interval
6 Spectrum Rules and WLAN Use Cases
6.1 Frequency Bands, DFS and Transmit Power Control 6.2 WLAN, Bridging, Peer-to-Peer and Mesh
7 802.11 Service Sets and Framing
7.1 Stations, BSS, ESS and the Distribution System 7.2 MSDU, MPDU, PSDU, PPDU and Aggregation 7.3 MAC Frame Format and Addressing
8 Frame Types, Discovery, and Association
8.1 Management, Control and Data Frames 8.2 Scanning, Authentication and Association
9 Channel Access, MAC Operations, and Devices
9.1 DCF, EDCA, RTS/CTS and Interframe Spaces 9.2 Roaming, Power Save and Protection Mechanisms 9.3 Access Points, Controllers and Client Devices
10 PoE, Architectures, and Proprietary Features
10.1 Power over Ethernet, PSE and Power Budgets 10.2 Centralized vs Distributed Forwarding and Network Planes 10.3 Airtime Fairness, Band Steering and RRM
11 WLAN Design and Supporting Services
11.1 Data, Voice, Video and Legacy Client Design 11.2 High-Density, Location Services and Guest Access 11.3 DHCP, DNS, Time, VLANs and AAA
12 WLAN Security
12.1 Weak and Deprecated WLAN Security 12.2 AES, WPA2-Personal and WPA2-Enterprise 12.3 WPA3, SAE and Opportunistic Wireless Encryption 12.4 PMF, Fast Roaming, WIPS and Secure Management
13 RF Validation Surveys and Tools
13.1 Post-Implementation Validation Surveys 13.2 Application and Performance Testing 13.3 Validation Tools: Survey, Protocol and Spectrum
14 Interference, Troubleshooting, and Common Faults
14.1 Co-Channel Contention vs Adjacent Channel Interference 14.2 Protocol Analyzers, Spectrum Analyzers and Monitoring 14.3 Common WLAN Faults and Hidden Nodes
10.2 Centralized vs Distributed Forwarding and Network Planes
Key Takeaways Explain This Topic AI
Centralized data forwarding tunnels user frames to a controller or gateway; distributed forwarding locally bridges those frames onto access VLANs at the AP or edge switch.
Management, control, and data planes can be placed independently: a cloud dashboard can own management while user packets never leave the site.
If user data is tunneled, controller throughput, tunnel MTU, and controller availability sit on the forwarding path; local switching moves that risk to the access VLAN design instead.
Outer tunnel headers must carry QoS so voice and video keep priority on the wired network; VLAN and policy may be applied at the tunnel terminus or at the AP switchport depending on forwarding mode.
Last updated: September 2026
A modern enterprise WLAN is not “an AP with an SSID.” It is a distributed radio system whose forwarding path and planes decide where client frames are switched, where policy is applied, and what breaks when a controller, WAN circuit, or cloud dashboard goes away. This independent ExamFinch section teaches CWNA-109 objective 4.2 in vendor-neutral language. One vendor’s “FlexConnect” or “tunneled SSID” is an example of a forwarding choice, not a CLI exam.
Why APs and controllers split work
Most campus APs run a split MAC : time-critical 802.11 functions (queueing, acknowledgements, encryption at the radio) stay on the AP, while configuration, RF coordination, roaming state, and often authentication live on a controller, cloud service, or wireless network management system (WNMS) . Autonomous “fat” APs still exist—each AP is a standalone bridge with its own config—but they scale poorly when you need one policy, one RF domain, and one place to revoke a PSK.
The architectural question is not whether a controller exists. It is which plane is centralized , especially the data plane .
Centralized data forwarding
In centralized (tunneled) forwarding , the AP encapsulates user data—typically in a UDP/IP tunnel such as IETF CAPWAP —and sends it to a controller, cluster, or gateway. The controller decapsulates the frame, applies VLAN, ACL, firewall, and QoS policy, then forwards onto the wired network. From the client’s point of view the AP is still the 802.11 attachment point. From the campus core’s point of view, wireless users often ingress at the controller , not at the closet switch.
Why designs still do this:
Consistent policy. Guest, quarantine, and dynamic RADIUS VLANs can be enforced in one place instead of on every access switch.
Layer 3 roaming. Client IP and security state can stay anchored while the user walks across subnets, because the tunnel end does not move with every AP.
Central visibility. Firewalls, DHCP helpers, and packet captures at the controller see most user traffic.
Costs you must teach honestly:
The controller (or cluster) is on the data path . Its throughput, CPU, and license count become WLAN capacity.
Every user byte traverses the path to the controller. A branch AP tunneling across a thin WAN wastes bandwidth and adds latency for local printers and POS.
Tunnel overhead consumes MTU. If inner frames are 1500 bytes and the outer IP/UDP/CAPWAP headers do not fit, you need inner fragmentation, TCP MSS clamping, or jumbo campus MTU.
If the controller pair is unreachable, tunneled SSIDs stop forwarding unless the product has an explicit fallback (and even then policy may be stale).
Centralized forwarding fits a high-speed campus where APs and controllers share abundant Ethernet, or a guest SSID that must hairpin through a DMZ even when employee SSIDs switch locally.
Distributed (local) forwarding
In distributed forwarding —also called local switching or bridged mode—the AP (or a nearby edge switch) bridges client data onto 802.1Q VLANs at the access layer. A controller may still exist for configuration, RF, and keys. User packets to a local server never visit that controller. Cisco FlexConnect , Aruba locally bridged forwarding, and similar modes on other vendors are all instances of this idea. Learn the idea; do not memorize one vendor’s show command.
Why designs use it:
WAN-friendly branches. Only control and maybe a guest tunnel cross the WAN.
Lower latency to local resources and less controller data-plane load.
Survivability. If the AP has a cached WLAN config, local VLANs can keep working when the controller or cloud path fails (product-specific “standalone” behavior).
Costs:
Every AP switchport must trunk the client VLANs (or use a defined VLAN map). Forget a VLAN on one closet and users associate but get no DHCP.
Access-layer ACLs, DHCP snooping, and private VLANs must be correct everywhere , not only at a controller.
Layer 3 roaming across sites is harder if each branch sources its own subnet; you may need a mobility tunnel just for roamers, which is a hybrid.
Per-SSID hybrids are normal: employee SSID locally switched, guest SSID tunneled to a central firewall. Objective 4.2 wants you to know those knobs are independent.
- Control, management, and data planes
- Name the planes the way operators do, not as synonyms for “Wi-Fi.”
Plane What it carries Typical path If it fails
Management Config, image, inventory, SNMP/telemetry, GUI/API, tickets Browser or WNMS/cloud to controller or AP You cannot change SSIDs; forwarding may still work
Control AP join, radio parameters, association/roam assists, key distribution, RRM coordination AP to controller (or AP to AP in mesh/coop) APs may freeze last config; new clients or RF changes break
Data User MSDUs / IP packets Tunneled to controller or locally switched Users lose applications even if radios still beacon
Cloud-managed Wi-Fi is the teaching example that planes split . The management plane lives in a vendor cloud. The data plane almost always stays on site (local switching). The control plane may be a mix: APs talk to cloud for RF and policy, but time-critical 802.11 control stays on the AP. A cloud outage can block configuration while the warehouse scanners keep working—unless the product also centralizes data, which most cloud APs do not.
Mesh and bridging add an AP-to-AP data plane on a backhaul radio or Ethernet, still separate from the management dashboard.
Scalability and availability
Scale the plane that is actually centralized.
Controller AP count and client count are control-plane and license limits.
If data is tunneled, also scale forwarding throughput , firewall sessions, and DHCP at the controller.
Distributed data plane scales with access-switch capacity and AP uplink (1G versus 2.5G/5G for Wi-Fi 6/6E).
Availability patterns:
N+1 or clustered controllers for control (and for data if tunneled).
Place controllers so tunneled traffic does not tromboned across a WAN.
For distributed mode, treat WAN to controller as a control-plane circuit: size it for CAPWAP/control keepalives and image downloads, not for YouTube.
Document what happens in standalone : which SSIDs stay up, whether 802.1X still works with a local RADIUS, whether new APs can join.
Tunneling, QoS, and VLANs
Tunneling is encapsulation plus a control channel. CAPWAP-style systems typically use a control tunnel (DTLS-protected configuration and RF) and, when centralized, a data tunnel . Do not assume data is encrypted in the tunnel unless the product is configured that way; many campuses encrypt control and leave inner data to 802.11 and wired ACLs.
QoS must survive the handoff from air to wire:
802.11 / WMM user priority maps to access categories (voice, video, best effort, background).
IP DSCP marks should match the application after the AP.
If frames are tunneled, the outer IP header is what core QoS sees. If outer DSCP is zero, voice becomes scavenger traffic across the campus even when inner UP was voice.
Local switching applies 802.1p/DSCP on the access trunk; the closet switch must trust or remap those marks.
VLANs follow the forwarding mode:
Centralized: the controller or gateway is often the 802.1Q edge. RADIUS dynamic VLAN is easy because every client hits the same box. Access switches may need only an AP infrastructure VLAN plus CAPWAP reachability.
Distributed: client VLANs must exist on the AP trunk. Dynamic VLAN still works if the AP or controller programs the bridge table, but the VLAN must already be on that switch.
Design in this order: where must policy be enforced, where must user packets go, which plane can fail independently, then pick centralized, distributed, or hybrid per SSID. CLI syntax is not the architecture.
Loading diagram... Centralized tunneled data versus distributed local switching, with planes split
Read the diagram as three separable decisions, not one vendor mode name. Harborline’s headquarters campus may tunnel guest traffic to a DMZ controller while employee traffic switches in each IDF. The same APs still use a centralized control path for RF and 802.1X keying. A retail branch of the same company may send only control across the WAN. If you only memorize one vendor’s default AP mode, you will miss the hybrid that production networks actually run.
When you troubleshoot, ask which plane is sick. Radios beacon but users have no DHCP: data-plane VLAN or tunnel termination. You cannot log into the GUI but scanners still work: management-plane or cloud path. New APs will not join but existing cells work: control-plane reachability, certificates, or time. That questioning is the architecture skill objective 4.2 is after.