The Firmware Window and the DFS Stores
A 300-AP retail chain runs a controller HA pair. 802.11r is enabled globally on every SSID, including guest and IoT. Forty stores still have 802.11n access points. Some stores use DFS channels 52-64 because 36-48 is congested; radar events there cause channel changes and roughly 60-second outages at the point-of-sale. A firmware upgrade is scheduled in two weeks, and the customer wants new 802.11ax features enabled at the same time to save a maintenance window.
1. Build the upgrade plan. What do you verify before, during, and after, and where do the legacy APs fit?
Read the worked answer
Before. Read the target release notes for supported AP models and for the upgrade path - the 802.11n units may be unsupported in the new image, in which case they either stay on the current code at those 40 sites or are replaced; do not discover this mid-window. Confirm whether an intermediate release is required. Export and archive per-site configuration, and diff against the running config. Check the HA pair upgrade order and confirm both controllers will land on the same image. Choose a pilot store that includes a legacy AP and a POS terminal.
During. Standby controller first, then fail over, then the active. Predownload AP images so APs do not pull code over the WAN at boot. Watch AP join counts and auth failures live.
After. Verify configuration parity, SSID broadcast, 802.1X and PSK authentication, roaming, and POS connectivity at the pilot before touching the other 299 sites. Keep the previous image on the alternate partition and the previous config exported, so rollback is a defined step rather than an improvisation.
On the ax features. Do not bundle feature enablement into the same change as the image. Upgrade, stabilize for a week, then turn on the new features - otherwise a failure has two candidate causes and no clean rollback.
2. Is global 802.11r appropriate? Explain the risk and recommend a scope.
Read the worked answer
No. Fast BSS transition requires client support and correct implementation. Devices with old drivers or broken implementations can fail to associate entirely, and the symptom looks like a security or profile problem, so it wastes hours. Guest phones and IoT sensors gain nothing from it because they do not roam between APs mid-session. It also interacts with key handling and protected management frames, which complicates the client matrix.
Scope. Enable it only on the SSID used by handsets and scanners, after testing each device model on the floor. Leave guest and IoT on plain 802.11k and 802.11v, which are low risk and help clients discover and steer to better APs. Where the platform supports it, test 11r in mixed mode first so non-capable clients can still associate, then move to strict mode once the fleet is known.
Verification. Roam time measurements per device model, association failure counts before and after, and a spot check that clients with 11r disabled still connect. Roll it out to a subset of stores before the chain.
3. How would you handle the radar-driven POS outages?
Read the worked answer
Understand the mechanism. When an AP detects radar it must vacate the channel, and it cannot transmit on a new DFS channel until the channel availability check completes, plus a non-occupancy period for the channel it left. Clients also have to notice the move and rejoin, which adds their own scan and re-auth time on top. That is where the minute of outage comes from.
Options, in order of preference. Reserve 36-48 for the POS-critical APs and put non-critical or overlay APs on DFS - the congested band is a capacity problem you can solve with 20 MHz channels and more cells rather than with DFS. Reducing channel width frees non-DFS channels and is often enough. If DFS must be used, minimize the blast radius by keeping POS APs off it and making rejoin fast: 802.11r on the POS SSID, fast DHCP, and a client that supports directed roaming.
What not to do. Do not disable DFS - it is a regulatory requirement in most jurisdictions and the AP will be operating illegally. Do not assume the AP's channel change is transparent to clients; many scan from scratch.
Longer term, 6 GHz access points add clean, non-DFS spectrum for the POS SSID, but they require WPA3 and 802.11ax clients, so verify the terminal fleet before making that part of the plan.