Municipal employee WLAN depends on 802.1X. How should RADIUS/AAA be designed for resilience?
Select an answer to reveal the explanation.
Short Explanation
If 802.1X is the front door, RADIUS is the locksmith on call. Two (or more) AAA boxes beat one lonely VM that naps during patching. Public demo servers and fake forever-success caches are how cities lock themselves out—or let everyone in.
Full Explanation
Municipal employee WLAN that depends on 802.1X fails hard when AAA is a single point of failure. Deploying redundant RADIUS/AAA servers with failover or load distribution keeps authentication available through patching, hardware faults, and site issues so staff are not locked out of the air. Civic operations that treat RADIUS as optional plumbing discover the dependency only during an outage.
Running a single RADIUS VM with no backup accepts total WLAN auth failure during routine maintenance. Pointing every AP at a public Internet RADIUS demo server exports credentials and availability to an uncontrolled third party. Caching one shared success for all users and stopping AAA contact after the first join abandons per-session authorization and accounting.
Exam caveat: redundancy includes reachability and certificate/key sync—not only a second VM on the same fragile host. Operational check: simulate failure of the primary RADIUS node during a maintenance window, confirm clients still authenticate via the secondary path, and verify monitoring alerts on AAA health before declaring the design resilient. In municipal WLAN programs, write the control into standards and verify it during change review so the next project inherits the same bar rather than rediscovering the failure mode under outage pressure.