A county campus has constrained WAN links between buildings. How should WLAN data-forwarding architecture be chosen?
Select an answer to reveal the explanation.
Short Explanation
If every YouTube stream has to ride downtown through a skinny WAN just to bounce back, you’ve picked the wrong forwarding mode. Keep local traffic local when the WAN is the bottleneck. Stretching one giant VLAN or turning off crypto doesn’t fix architecture.
Full Explanation
WAN-constrained campuses should avoid hairpinning user data through a distant controller when local forwarding can keep traffic on-site. For a county campus with constrained WAN links between buildings, WLAN data-forwarding architecture should match traffic patterns by preferring distributed/local forwarding when centralizing client data would exhaust WAN capacity. Control and management planes may still centralize while user data exits locally toward building servers and Internet edge resources. That split preserves policy without saturating the WAN.
Always centralizing all user data through the HQ controller regardless of WAN size fails by concept: hairpinning saturates constrained links and adds latency for building-local applications. Bridging every SSID as a single campus-wide VLAN across the WAN fails by concept: oversized L2 domains across WAN amplify broadcast risk and bandwidth waste. Disabling encryption so packets compress better fails by concept: security must not be sacrificed for dubious WAN savings.
Exam caveat: CWNE forwarding-mode questions tie architecture to WAN reality and traffic locality, not dogma that everything must centralize.
Operational check: Measure inter-building WAN utilization during peak WLAN use, identify SSIDs with local server affinity, enable local/distributed forwarding for those SSIDs, and validate policy enforcement and roaming still meet campus needs.