Hybrid Wireless Management Across Cloud XIQ and XIQ-SE
A K-12 school district operates 1,150 access points across 42 sites. Twenty sites are managed in ExtremeCloud IQ (cloud), and 22 sites remain on-premises in XIQ-SE with two wireless controllers. The district standardized on one student SSID and one staff SSID, but the cloud sites and on-premises sites drifted: the cloud sites use WPA2-Enterprise with a cloud RADIUS proxy, while the on-premises sites use 802.1X to two local RADIUS servers. During a six-hour WAN outage at a cloud-managed middle school, existing clients stayed connected, but new students could not authenticate and the help desk had no visibility in XIQ-SE. The CIO wants one management model, local survivability for authentication, and a single view of wireless health. The network team proposes moving all 42 sites to the cloud next quarter, including the 22 sites that use local RADIUS for compliance reasons.
1. How would you evaluate the proposal to move all sites to cloud XIQ, given the local RADIUS requirement and the outage?
Read the worked answer
Treat the proposal as an architecture decision, not a migration task.
The outage showed the real dependency: the cloud-managed site kept serving existing clients, but new 802.1X authentications depended on the cloud RADIUS proxy and failed when the WAN went down. Moving the remaining 22 sites to the cloud does not fix that; it extends the same failure mode to sites that currently authenticate locally. The compliance requirement for local RADIUS also conflicts with a pure cloud proxy design unless the cloud APs can reach a local RADIUS server or use a local survivability option.
A defensible position is:
- Keep authentication local where compliance or survivability requires it: local RADIUS primary/secondary at each site or regional hub, with the cloud used for management and monitoring, not as the sole authentication path.
- Standardize SSIDs and security settings across both management planes so clients behave consistently.
- If the district still wants one plane, require a proven local survivability design and a tested WAN-down scenario before migrating the compliance sites.
Do not accept 'cloud is simpler' as the only criterion; the six-hour outage is the requirement test.
2. What would you configure to prevent a repeat of the new-client authentication failure during a WAN outage?
Read the worked answer
Design for the WAN-down state explicitly:
- Local RADIUS at each site or regional hub. Primary and secondary servers reachable on the local LAN, with the same policies as the central system. The AP/controller must be configured to use them, not a cloud proxy, for 802.1X.
- Fallback behavior that is intentional. If the local RADIUS is also down, decide whether to fail closed, use a cached credential, or offer a limited guest/PSK SSID. Do not silently fall back to an open SSID.
- Test the failure mode. Disconnect the WAN link at a pilot site and verify that a new supplicant can authenticate, obtain DHCP, and reach local resources. Existing-client survival is not the test; new authentication is.
- Certificate and trust continuity. Ensure the RADIUS server certificate clients trust is available locally, and that the same certificate chain is used in both management planes, or clients will reject the server during the outage.
- Monitoring for the outage state. Alert on WAN loss and on RADIUS health from the site's perspective, not just from the data center.
The goal is that a WAN outage degrades management visibility, not student onboarding.
3. How can XIQ-SE provide a single wireless health view when 20 sites are managed in the cloud?
Read the worked answer
Be clear about what XIQ-SE can and cannot see. XIQ-SE is authoritative for the 22 on-premises sites and their controllers. For the cloud-managed sites, it needs an integration or data source that imports cloud AP inventory and health; without that, any 'single view' is manual.
Practical approach:
- Use the supported cloud integration/connector to bring cloud AP and site data into XIQ-SE, or use a reporting export from the cloud and correlate by site and AP name. Confirm the integration's polling interval and which metrics it carries; inventory-only integration will not give client experience data.
- Normalize site names between the two systems before building dashboards. The 42 sites should use identical site identifiers, or reports will split the same school into two rows.
- Build the health view around the metrics that matter in the outage: AP up/down, client authentication failures, RADIUS response time, and WAN reachability. XIQ-SE alarms can cover the on-premises sites; cloud-side alarms need to be forwarded or polled.
- Document the gap. If cloud data is 15 minutes stale, the NOC should know that before they troubleshoot a live incident.
A single pane of glass is a data-integration project, not a rename of two consoles.