10.2 Centralized vs Distributed Forwarding and Network Planes

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 OpenExamPrep 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.”

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.

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.