WLAN architectures
Requirement / business driver
Choose how APs are controlled and where client data flows - the decision that drives scale, the data path, and WAN behaviour.
Options
- Autonomous APs - standalone, per-AP config; only for a handful of APs.
- Centralized controller (CAPWAP) - APs join an on-prem WLC; central switching tunnels client data to the WLC.
- FlexConnect / remote - WLC-managed but local switching (data stays at the branch) and local auth, so the site survives WAN loss.
- Cloud-managed - cloud controller, local data path, low-ops multi-site.
AP modes (7.2.f)
Local (serving), FlexConnect, Monitor/Sensor (WIPS/analytics), Bridge/Mesh (outdoor/backhaul), Sniffer. The mode follows the role the AP plays in the design.
Bridging and the WGB - wired islands over wireless
802.11 only defines bridging at the AP; a client that relays for other MACs sits outside the standard, which is why bridge links live in the autonomous-IOS world and carry a vendor-interop constraint. Three radio roles cover the deployment models: a root anchors the wired network; a non-root bridge forms a point-to-point L2 extension to it (building-to-building without fibre), or several non-roots form a point-to-multipoint star of L2 links back to one root; and a workgroup bridge (WGB) associates to an ordinary root AP as a client and relays for the wired devices behind it. The 802.11 header's four address fields (RA/TA/DA/SA) make relaying possible, but the behaviour is proprietary: a Cisco-mode WGB signals its infrastructure-client nature via Aironet IE (which the serving SSID must allow), buying multiple wired MACs and VLANs behind one WGB plus mobility tuning - at the price of Cisco-to-Cisco lock-in. A universal-mode WGB stays standards-clean by masquerading as its single wired device's MAC - it associates to any vendor's AP but carries exactly one wired client. The selection criterion is therefore interop vs capability.
Mobile WGB doctrine (trains, AGVs, hospital carts): the WGB roams like a client, so shape its triggers to the RF design - prune the scan list to the channels the infrastructure actually uses (DFS channels scan passively and slowly), align the RSSI roam threshold to the designed cell edge (roam near -70 dBm if that is where the next AP should win) on a 2-4 s evaluation period, and gate roams behind a minimum data-rate so a still-serviceable link is not abandoned mid-operation. Fast-secure roaming on IOS WGBs is CCKM-only, so the serving SSID must offer CCKM alongside whatever the general client population uses (Roaming - L2 vs L3 mobility).
FlexConnect survivability - the fine print
"FlexConnect survives WAN loss" is per-WLAN, not per-AP: each WLAN sits in an authentication x switching state, and that state decides what standalone mode keeps. Central auth + central switching dies with the WAN - existing clients are deauthenticated and the AP stops beaconing that WLAN. Central auth + local switching keeps existing, already-authenticated clients working (their data path never needed the WLC), and open/PSK joins still succeed in standalone because the AP can run those handshakes itself - but new EAP joins and EAP roams fail. Local auth + local switching is full survivability: the AP authenticates by itself, either as a local EAP server (small user database, limited methods) or as an authenticator talking straight to a reachable RADIUS server - which quietly means every such AP becomes an AAA client on that server, an operational-scale decision rather than a checkbox. The WAN itself is gated: roughly under 100 ms AP-to-WLC RTT for full function (~300 ms tolerable for data-only), about 128 kbps of control bandwidth per 8 APs, and a heartbeat (30 s, five 1 s retries) that flips the AP to standalone. Split tunnelling lets even a centrally switched WLAN reach branch-local printers/servers directly. Design consequence: state the branch's survivability SLA first, then pick the per-WLAN state that actually delivers it (Controller placement, HA, and tunnel optimization).
Mesh - RAP/MAP trees and the shared backhaul
Cisco mesh forms trees, not meshes: a wired RAP roots each tree, MAPs join over a radio backhaul, and traffic always flows down to the RAP first - never laterally between branches (unlike the largely unadopted 802.11s model with multiple gateways). Every AP in a tree shares one backhaul channel (dual-5 GHz APs can split uplink and downlink), so the tree is a single contention domain: each wireless hop re-transmits on the same channel, and usable capacity shrinks with depth and fan-out. Parent selection is AWPP: an ease metric blending per-hop SNR and hop count (link load and latency in later code), with a ~20% bonus on the current path so marginal differences do not cause parent-flapping; Bridge Group Names keep co-located trees from adopting each other's APs. Design cautions: backhaul client access (serving clients on the backhaul radio) spends the shared transit airtime on individual users; a 2.4 GHz backhaul trades capacity for foliage/range penetration; Ethernet bridging behind a MAP extends VLANs to wired devices (cameras, kiosks) at the far end. Force a preferred parent only when the forced path's RF is provably adequate - forcing does not make a path good.
Comparison
Recommendation / justification
Campus with central policy/RF -> centralized controller; branches over a WAN -> FlexConnect (local switching + survivability); distributed multi-site, low ops -> cloud-managed; a few APs -> autonomous. The pivotal tradeoff is the data path: central switching simplifies policy but hairpins traffic to the WLC (see Controller placement, HA, and tunnel optimization); local switching keeps data efficient but distributes policy.
What would change this (mid-scenario twist)
- Branch must keep working if the WAN/WLC is unreachable -> FlexConnect local switching/auth.
- Many small sites, minimal on-site IT -> cloud-managed.
Validation checks
- Does the data path match the requirement (central policy vs local efficiency/survivability)?
- Is the architecture's scale and ops model appropriate for the site count?
IPv6 / dual-stack note
SSID-to-VLAN mapping carries v4 and v6; with CAPWAP central switching, the tunnel MTU affects v6 large packets (MTU, fragmentation, and PMTUD).
Related
- Controller placement, HA, and tunnel optimization
- Roaming - L2 vs L3 mobility
- Infrastructure segmentation
Spaced repetition
FlexConnect's defining advantage over central switching is [...].
FlexConnect's defining advantage over central switching is local switching + local auth, so the branch survives WAN/WLC loss and data stays local.
The pivotal WLAN-architecture tradeoff is [...].
The pivotal WLAN-architecture tradeoff is the client data path: central switching (tunnel to WLC, easy policy, hairpin) vs local switching (efficient, distributed policy).
Name three AP modes beyond "local."
FlexConnect, Monitor/Sensor (WIPS), Bridge/Mesh, Sniffer (any three).
Cisco-mode vs universal-mode WGB?
Cisco mode = proprietary infrastructure client (Aironet IE): many wired MACs/VLANs behind it but Cisco-to-Cisco only; universal mode = standards-clean, masquerades as the single wired device's MAC, associates to any vendor's AP.
A FlexConnect WLAN's WAN-loss behaviour is decided by [...].
A FlexConnect WLAN's WAN-loss behaviour is decided by its authentication x switching state - central/central dies, central-auth/local-switching keeps existing clients (open/PSK joins still work), local/local fully survives.
Why is a Cisco mesh tree's capacity sensitive to depth?
All APs in a tree share one backhaul channel and traffic always relays down to the RAP - each hop re-transmits on the same channel, so airtime divides with depth and fan-out (AWPP picks parents by SNR + hop-count "ease").
Sources
- Cisco Press, CCIE Wireless v3 Study Guide (Alcantara, Darchis, Henry, Jimenez, Ziliotto) - bridging/WGB roles, FlexConnect states, mesh/AWPP.
- Cisco Press, Cisco Wireless design guides; CAPWAP RFCs.