ExtremeCloud IQ Certification cheat sheet

ExtremeCloud IQ is a cloud-delivered management platform for Extreme switches, access points, and branch routers; it is offered as a public cloud SaaS service and in private/on-premises deployment options, with the cloud instance hosting configuration, policy, and telemetry data.

The platform organizes objects in a hierarchy: an account (customer tenant) contains one or more sites, and devices are assigned to a site; network policies are attached to sites, so a device inherits the policy of the site it belongs to.

Cloud management uses a data plane versus management plane split: managed devices maintain a persistent outbound management tunnel (CAPWAP-based for access points) to the cloud, so no inbound firewall ports need to be opened to the device.

ExtremeCloud IQ uses a subscription/licensing model tied to device entitlements; a device that is not covered by an active license will not be managed and will fall back to standalone operation.

The platform provides a single pane of glass for wired and wireless: dashboards, client 360 views, alarm/event monitoring, and reporting are shared across device types rather than split into separate wired and wireless consoles.

Configuration is policy-driven and template-based: network policies define SSIDs, VLANs, and device settings, while device templates and CLI supplements handle device-specific overrides.

ExtremeCloud IQ is part of the ExtremeCloud IQ / Extreme Platform ONE family; the cloud-native management model emphasizes zero-touch onboarding, centralized policy, and API access for automation.

Role-based access control (RBAC) governs what each administrator can see and change; roles such as Super User, Operator, and Monitor scope permissions by account or site.

The platform exposes a REST API and supports integrations (for example, with identity providers via RADIUS/LDAP and with external monitoring), enabling automation and single sign-on.

Zero-touch onboarding: a device with cloud connectivity enabled (DHCP option 43 or DNS resolution of the cloud redirector hostname) contacts the cloud and appears as a 'new' device awaiting approval in the onboarding queue.

Onboarding workflow: claim/approve the device, assign it to a site, and attach the appropriate network policy; the device then downloads its configuration and reboots into managed mode.

Devices can be onboarded individually or in bulk by serial number or MAC address; pre-provisioning lets you assign a site and policy to a device before it ever powers on.

Device templates apply a common baseline configuration to many devices; CLI supplements and device-level overrides layer site- or device-specific settings on top of the template.

Firmware management is centralized: you can schedule firmware upgrades, set a target firmware version per device or group, and stage upgrades to avoid simultaneous reboots.

Configuration audit and delta views show the running configuration versus the intended cloud configuration, helping detect drift or failed pushes.

Devices can be monitored for reachability and health; a device that loses its cloud tunnel shows as disconnected but continues to forward traffic using its last-known configuration.

Device replacement uses the same serial-based claim process; the new device inherits the site and policy assignment so configuration is restored automatically.

Bulk operations (reboot, firmware upgrade, policy change, site move) can be applied to selected devices, and the platform reports per-device success or failure for each operation.

A network policy is the container that binds SSIDs, VLANs, and device settings together; it is applied to a site or device, and a device can only have one active network policy at a time.

An SSID is configured inside a network policy and references a VLAN; the SSID broadcast, security mode, and authentication method are all defined at the SSID level.

Security modes include Open, WPA2-PSK, WPA3-PSK/SAE, WPA2/WPA3 Enterprise (802.1X with RADIUS), and captive portal; WPA3 provides stronger handshake protection than WPA2-PSK.

Enterprise authentication uses a RADIUS server (or ExtremeCloud IQ's built-in RADIUS/identity integration) to validate 802.1X credentials; the SSID references the RADIUS profile.

VLAN assignment for wireless clients can be static (one VLAN per SSID) or dynamic (RADIUS-assigned VLAN per user/group), enabling role-based segmentation.

Radio profiles control channel width, transmit power, and band steering; channel selection can be automatic (ACS/DFS) or manual, and 5 GHz/6 GHz bands are managed per radio profile.

Guest and captive portal SSIDs use a portal page plus a walled garden to restrict pre-authentication traffic; the portal can be hosted by ExtremeCloud IQ or an external server.

SSID-to-VLAN mapping should align with the wired switching configuration; a mismatch causes clients to associate but fail to obtain an IP address (DHCP failure).

Policy changes are pushed to devices as a configuration delta; devices may reboot or briefly drop clients depending on whether the change requires a restart.

Dashboards surface device health, client counts, throughput, and alarm summaries; the Client 360 view aggregates a single client's association history, signal, and traffic.

Alarms are categorized by severity (critical, major, minor, warning) and can be filtered by site, device, or category; alarm rules can trigger notifications.

For wireless issues, check RSSI/SNR, retry rate, channel utilization, and roaming events; low SNR and high retries point to RF or coverage problems rather than authentication.

For connectivity issues, verify the client obtained an IP address; DHCP failure after association usually indicates a VLAN or upstream switching problem, not a wireless problem.

Cloud tunnel status distinguishes 'device offline' from 'device online but client failing'; a disconnected device cannot receive new configuration but keeps forwarding traffic.

Diagnostic tools include ping, traceroute, and remote packet capture (where supported) initiated from the cloud, plus live device CLI access for managed devices.

Event and syslog streams, plus the audit log, record configuration changes and device events; correlate a client complaint with the timestamp of a policy push.

Firmware and configuration drift reports help explain behavior changes after an upgrade; compare the device's running config to the intended policy.

Reporting exports (client counts, usage, alarm history) support trend analysis; sustained high channel utilization suggests co-channel interference and a need for channel/power tuning.

RBAC roles scope access: Super User has full account control, Operator can manage devices and policies, and Monitor is read-only; permissions can be limited to specific sites.

Administrator accounts should use strong authentication; single sign-on via an identity provider and multi-factor authentication reduce credential risk.

The audit log records administrative actions (logins, configuration changes, device onboarding) and is the primary evidence source for change tracking and compliance.

API access uses tokens/credentials tied to an administrator or integration account; API tokens should be scoped and rotated, never embedded in client-side code.

Device onboarding should be gated by approval so an unknown device cannot join the managed fleet; serial/MAC allowlists and pre-provisioning tighten this control.

Firmware and configuration changes should follow a staged rollout: pilot site, verify, then expand; the platform's scheduling and per-device result reporting support this.

Backups of configuration are maintained in the cloud; export policies and templates periodically so they can be restored or migrated.

Alarm notification rules route critical alarms to email or integrations; define thresholds so operations staff are alerted before clients are impacted.

Segmentation (separate SSIDs/VLANs for corporate, guest, and IoT) limits lateral movement; apply the principle of least privilege to both users and devices.

The exam emphasizes the cloud management model: tenant/account hierarchy, site assignment, and how policies flow from account to site to device.

Expect questions on the onboarding sequence: device contacts cloud, appears as new, is approved/claimed, assigned to a site, and receives its network policy.

Know the difference between a network policy, an SSID, and a VLAN: the policy is the container, the SSID is the wireless service, and the VLAN is the Layer 2 segment.

Troubleshooting questions typically start from the symptom (no IP, no association, high retries) and require mapping it to the correct layer (DHCP/VLAN, RF, or authentication).

Administration questions cover RBAC roles, audit logging, and API/token security; know which role can change configuration versus only view it.

Licensing and subscription questions test that managed devices require active entitlement and that unlicensed devices fall back to standalone operation.

Firmware and configuration management questions test staged upgrades, templates, and drift detection as operational controls.

The cloud management tunnel is outbound from the device; firewall rules must allow the device to reach the cloud redirector and management endpoints, but no inbound ports are required.

DHCP option 43 or DNS can direct a device to the cloud redirector; without either, the device may not discover the cloud and will not appear for onboarding.

RADIUS/LDAP integration supports 802.1X and captive portal authentication; the SSID references the authentication profile, and the RADIUS server returns accept/reject plus optional VLAN attributes.

Captive portal flows require a walled garden for pre-authentication DNS and portal traffic; missing walled garden entries cause the portal page to fail to load.

API-based automation uses the REST API with token authentication; automation can create sites, assign policies, and query client/device telemetry.

Site design matters: group devices by physical location or policy need, because policy assignment and RBAC scoping operate at the site level.

High availability for cloud management is provided by the cloud service itself; the on-premises option requires its own redundancy planning.

Monitoring integrations (syslog, SNMP, or API polling) complement cloud dashboards; export alarms to an external system for long-term retention.

Channel planning: use 20/40/80 MHz widths deliberately; wider channels increase throughput but reduce the number of non-overlapping channels and raise co-channel interference.

5 GHz and 6 GHz offer more non-overlapping channels than 2.4 GHz; band steering moves capable clients to 5/6 GHz to relieve 2.4 GHz congestion.

Transmit power should be tuned so cells overlap enough for roaming but not so much that co-channel interference dominates; automatic channel/power (ACS) can assist but should be validated.

Roaming depends on client behavior and AP overlap; minimum RSSI and roaming thresholds influence when a client transitions, but the client ultimately decides.

High retry rates and low SNR indicate RF problems; high channel utilization with low client count suggests interference or a misbehaving device.

WPA3/SAE improves security but older clients may not support it; mixed WPA2/WPA3 modes provide compatibility at some security cost.

Guest SSIDs should be isolated from corporate VLANs and rate-limited; client isolation prevents guest-to-guest traffic on the same SSID.

Validate coverage with a site survey and post-deployment monitoring; compare design intent (AP placement, power) to observed SNR and utilization.

Lifecycle stages: plan (site/policy design), onboard (claim and assign), configure (template/policy push), monitor (dashboards/alarms), and maintain (firmware, drift, replacement).

Change control: record the policy/template version, schedule the push, and verify per-device results; roll back by restoring the prior policy or template version.

Firmware lifecycle: track end-of-support versions, schedule upgrades in maintenance windows, and verify post-upgrade health before expanding to the fleet.

Device replacement: claim the new serial, assign the same site and policy, and confirm the device reaches managed state before decommissioning the old unit.

Capacity planning uses client counts, throughput, and channel utilization trends; sustained utilization near the ceiling signals a need for more APs or spectrum.

Alarm hygiene: tune thresholds and notification rules so critical alarms reach on-call staff and noisy low-value alarms are suppressed.

Documentation of site-to-policy mapping and VLAN/SSID design is essential for troubleshooting and for onboarding new administrators.

Periodic access review of administrator accounts and API tokens reduces standing privilege and stale integrations.

Least privilege applies to both administrators (RBAC roles scoped to sites) and network access (SSID/VLAN segmentation by user or device role).

802.1X with RADIUS provides per-user authentication; dynamic VLAN assignment enforces role-based segmentation without separate SSIDs.

Guest networks should be isolated, rate-limited, and use captive portal with a minimal walled garden; never bridge guest traffic into corporate VLANs.

Administrative access should use SSO/MFA where available; shared accounts undermine auditability because the audit log cannot attribute actions.

API tokens are credentials: scope them to the minimum needed integration, rotate them, and store them in a secrets manager rather than in code or config files.

Data in the cloud includes configuration and telemetry; review retention settings and export requirements to meet organizational policy.

Firmware currency is a security control; unpatched devices may have known vulnerabilities, so track versions and upgrade on a defined cadence.

Monitor for rogue or unauthorized devices: onboarding approval, allowlists, and alarm rules detect unexpected devices joining the managed fleet.

Client associates but gets no IP: check SSID-to-VLAN mapping, DHCP reachability on that VLAN, and upstream switch trunk configuration before touching RF.

Client cannot associate: check security mode compatibility (WPA3 vs legacy client), PSK/credential correctness, and whether the SSID is broadcast and enabled on the serving AP.

Client associates and authenticates but is slow: check SNR, retry rate, channel utilization, and band; low SNR or high retries point to RF/coverage, not authentication.

Device shows offline in the cloud: verify outbound connectivity to the cloud redirector and management endpoints; the device keeps forwarding traffic with its last configuration.

Configuration push failed: inspect the per-device result, check for template/CLI supplement conflicts, and verify the device is online and licensed.

Captive portal does not load: verify walled garden entries for DNS and portal hostnames and that the portal profile is attached to the SSID.

Roaming failures: check AP overlap, minimum RSSI/roaming thresholds, and whether the client supports the configured security and band.

Unexpected behavior after an upgrade: compare running config to intended policy, check drift, and review release notes for changed defaults.

The REST API supports programmatic management of sites, devices, policies, and clients; authentication uses tokens obtained via the API login endpoint.

Typical automation: bulk-claim devices, assign sites and policies, query client/device inventory, and pull alarm/event data into external systems.

API responses are JSON; pagination and filtering parameters control large result sets, and rate limits should be respected in polling loops.

Reporting exports support operational review: client counts, usage trends, alarm history, and device inventory; schedule exports for recurring compliance needs.

Webhooks/notifications can push alarm events to external systems, reducing the need for constant polling.

Automation should be idempotent: check whether a site/policy exists before creating it, so reruns do not create duplicates.

Store API credentials securely and use a dedicated integration account so audit logs distinguish automated changes from human ones.

Validate automation in a non-production site first; policy pushes affect live clients and may cause brief disconnections.

A site represents a physical or logical location; devices are assigned to exactly one site, and the site determines which network policy the device receives.

Network policy design should start from segmentation requirements: corporate, guest, IoT, and management traffic each get their own SSID/VLAN mapping.

Reuse policies across sites with identical requirements to reduce configuration drift; use templates for device-level baselines and overrides only where needed.

Naming conventions for sites, policies, SSIDs, and VLANs make troubleshooting and RBAC scoping manageable at scale.

VLAN IDs must be consistent between the wireless policy and the wired infrastructure; document the mapping per site.

Guest and IoT SSIDs should be isolated at Layer 2/3 with firewall rules controlling what they can reach.

Plan for growth: reserve VLAN ranges and SSID slots, and size AP density from capacity (clients/throughput) as well as coverage.

Policy changes should be reviewed against the site's device inventory to ensure all devices support the required features (bands, security modes).

Client 360 aggregates association history, authentication events, signal quality, and traffic for a single client, making it the first stop for client complaints.

Device health metrics include CPU/memory, uptime, tunnel status, and client counts; sustained high CPU can degrade forwarding and management responsiveness.

Wireless telemetry includes RSSI, SNR, retry rate, and channel utilization per radio; these distinguish RF problems from authentication or DHCP problems.

Alarm and event streams capture threshold breaches and state changes; correlate timestamps with configuration pushes to explain behavior changes.

Historical trends (client counts, usage, alarms) support capacity planning and post-incident review.

Syslog and SNMP export complement cloud dashboards for organizations with existing monitoring tools.

Baseline normal behavior (typical client counts, utilization, retry rates) so anomalies are detectable.

Telemetry retention depends on the subscription and platform settings; export data you need to keep long-term.

Distinguish cloud management plane from data plane: configuration and telemetry go through the cloud, but client traffic is forwarded by the device locally.

Distinguish policy container (network policy) from service (SSID) from segment (VLAN); many questions hinge on which layer a setting belongs to.

Distinguish onboarding states: new/unapproved, approved but unassigned, assigned to site with policy, and fully managed.

Distinguish device offline (no cloud tunnel, still forwarding) from device online but client failing (RF, DHCP, or authentication).

Distinguish RBAC roles by capability: Super User (full), Operator (manage), Monitor (read-only); scope can be limited by site.

Distinguish licensing: managed devices require active entitlement; unlicensed devices fall back to standalone operation.

Distinguish firmware upgrade from configuration push: both are scheduled, both report per-device results, and both can cause brief disruption.

When a question describes a symptom, identify the layer first (association, authentication, DHCP/VLAN, RF) before choosing a remedy.

Define an onboarding approval process and an allowlist so unknown devices cannot silently join the managed fleet.

Maintain a change log tied to the audit trail: who changed which policy/template, when, and which devices were affected.

Review administrator accounts and API tokens on a schedule; remove stale integrations and departed staff promptly.

Set alarm notification rules with clear severity routing so critical events reach on-call staff and low-value alarms are suppressed.

Stage firmware and policy rollouts: pilot, verify health and client impact, then expand to the full fleet.

Document site-to-policy mapping, SSID/VLAN design, and firmware baselines; this is the reference for troubleshooting and audits.

Test restore/migration of policies and templates periodically so configuration can be recovered if needed.

Track license entitlement and renewal dates so devices do not lose management coverage unexpectedly.

WPA3-SAE provides forward secrecy and protects against offline dictionary attacks; WPA2-PSK does not, so prefer WPA3 where clients support it.

WPA2/WPA3 mixed mode maximizes compatibility but the network is only as strong as the weaker mode for clients that negotiate WPA2.

802.1X Enterprise uses RADIUS for per-user credentials; configure the RADIUS profile, shared secret, and server reachability before enabling the SSID.

Dynamic VLAN assignment from RADIUS enables role-based segmentation without multiplying SSIDs.

Captive portal should use HTTPS and a minimal walled garden; pre-authentication traffic must be restricted to portal and DNS endpoints.

Guest SSIDs should enable client isolation and rate limiting, and should terminate in an isolated VLAN with firewall policy to corporate networks.

Disable legacy protocols and weak ciphers where possible; audit SSIDs periodically for open or misconfigured security modes.

PMF (protected management frames) improves resistance to deauthentication attacks; check client compatibility before enforcing it.

Public cloud SaaS is the default deployment: Extreme operates the management infrastructure and devices connect outbound to it.

Private/on-premises deployment places the management platform in the customer's environment; it requires the customer to plan compute, storage, and redundancy.

Device-to-cloud connectivity requires outbound access to the cloud redirector and management endpoints; DNS or DHCP option 43 can supply the redirector address.

No inbound firewall ports are required for the device management tunnel because the device initiates the connection.

Proxy environments must allow the device's management traffic through the proxy; otherwise onboarding fails.

Bandwidth planning should account for telemetry and firmware downloads, which can be large during staged upgrades.

Time synchronization (NTP) on devices supports accurate event timestamps for troubleshooting and audit correlation.

Document the redirector/endpoint allowlist and share it with the network/security team to prevent future blocking.

Track the firmware version of every device; end-of-support versions are a security and stability risk.

Schedule upgrades in maintenance windows and stagger them so the fleet is not rebooted simultaneously.

Verify post-upgrade health (tunnel status, client counts, alarms) before expanding the rollout.

Use templates for baseline configuration and CLI supplements/overrides only where device-specific settings are required.

Detect configuration drift by comparing running configuration to the intended cloud configuration; investigate unexplained differences.

Roll back by restoring the prior policy/template version or firmware image if an upgrade causes regressions.

Device replacement: claim the new serial, assign the same site and policy, and confirm managed state before removing the old device.

Keep a record of firmware baselines per site/model to speed future troubleshooting.

Alarm severity levels (critical, major, minor, warning) determine routing and urgency; map severities to notification channels.

Alarm rules can be tuned to suppress noise and escalate conditions that affect clients.

Correlate alarms with configuration pushes and firmware upgrades by timestamp to identify cause.

Event and syslog streams provide detailed records beyond summarized alarms; export them for long-term retention.

Notification integrations (email, webhooks) push alarms to on-call systems and ticketing tools.

Review recurring alarms periodically; a repeating alarm often indicates a design issue rather than a transient fault.

Acknowledge and document alarm resolution so post-incident review has a record.

Test notification paths so critical alarms actually reach staff during an incident.

Size AP density from both coverage and capacity: client count and throughput requirements often drive density more than signal strength.

Channel width trade-off: wider channels raise peak throughput but reduce non-overlapping channels and increase interference.

Band steering and 6 GHz use relieve 2.4 GHz congestion and improve overall capacity.

Monitor channel utilization and retry rates as leading indicators of capacity exhaustion.

Client counts and usage trends inform when to add APs or spectrum.

High CPU or memory on devices can degrade forwarding; track device health alongside RF metrics.

Validate design assumptions with post-deployment surveys and monitoring rather than relying on the plan alone.

Document capacity thresholds and review them as client populations grow.

Create sites first, then policies, then onboard devices and assign them to sites; this order avoids rework.

Use templates for common baselines and reserve per-device overrides for exceptions.

Review the audit log after significant changes to confirm only intended devices were affected.

Use bulk operations for firmware and policy changes, and check per-device results rather than assuming success.

Scope administrator roles by site to limit blast radius of mistakes.

Keep a change log with timestamps that match the audit trail for incident review.

Export policies/templates periodically as a backup and for migration between environments.

Test changes in a pilot site before broad rollout.

Open: no authentication; suitable only for isolated guest or onboarding networks.

PSK/SAE: a shared key authenticates all clients; rotation requires updating every client.

802.1X: per-user credentials validated by RADIUS; supports dynamic VLAN and role assignment.

Captive portal: browser-based authentication, often combined with a guest management system.

Authentication failures and DHCP failures are distinct: an authenticated client that gets no IP has a VLAN/DHCP problem, not a credential problem.

RADIUS reachability and shared-secret mismatches cause authentication failures across all clients on the SSID.

Client compatibility with WPA3/PMF should be verified before enforcing stricter modes.

Log authentication events and correlate with client complaints to distinguish credential from RF issues.

API tokens should be scoped to the minimum required operations and rotated on a schedule.

Use a dedicated integration account so audit logs distinguish automated from human changes.

Store tokens in a secrets manager, never in source code, config files, or client-side scripts.

Respect rate limits and use pagination for large queries to avoid throttling.

Webhooks push events to external systems, reducing polling load and latency.

Validate automation in a non-production site before applying to production.

Make automation idempotent so reruns do not create duplicate sites or policies.

Review integration access periodically and revoke tokens for retired integrations.

Guest traffic should be isolated in its own VLAN with firewall rules blocking access to corporate networks.

Captive portal with a minimal walled garden restricts pre-authentication traffic to portal and DNS endpoints.

Client isolation prevents guest-to-guest traffic on the same SSID.

Rate limiting protects guest and corporate bandwidth from abuse.

Use HTTPS for portal pages and avoid collecting unnecessary personal data.

Monitor guest usage and authentication failures as indicators of portal or walled garden misconfiguration.

Separate guest SSIDs per venue or building simplify policy and troubleshooting.

Review guest firewall rules periodically to ensure isolation still holds after changes.

Device not appearing for onboarding: check outbound connectivity to the cloud redirector, DNS/option 43 configuration, and proxy settings.

Device appears but cannot be approved: verify serial/MAC matches the claim and that the administrator has permission for the target site.

Device approved but not managed: confirm it is assigned to a site with a network policy and has active license entitlement.

Configuration not applied: check per-device push results, template/override conflicts, and whether the device is online.

Device repeatedly disconnects: investigate network path stability and proxy/firewall timeouts on the management tunnel.

Firmware mismatch during onboarding may require an upgrade before the policy can be applied.

Check the audit log for approval and assignment actions to confirm the intended workflow occurred.

Document the redirector/endpoint allowlist to prevent future onboarding failures.

Scheduled exports of client counts, usage, alarms, and device inventory support recurring compliance reporting.

The audit log is the primary evidence for administrative change tracking.

Retention settings determine how long telemetry is available in the cloud; export what must be kept longer.

Alarm history supports post-incident review and trend analysis.

API polling or webhooks can feed external SIEM or monitoring systems.

Document report definitions and schedules so compliance evidence is reproducible.

Review reports periodically for anomalies (unexpected device counts, recurring alarms).

Align reporting with organizational policy for data retention and access.

Public cloud management resilience is provided by the service; the customer's responsibility is device connectivity and local forwarding.

Devices continue forwarding traffic with their last-known configuration if the cloud tunnel drops.

On-premises deployment requires the customer to plan redundancy for the management platform itself.

Redundant WAN paths for device management traffic reduce the risk of prolonged disconnection.

Monitor tunnel status and alert on disconnections so remediation starts quickly.

Firmware and configuration backups enable recovery if management data is lost.

Document recovery procedures and test them periodically.

Time synchronization supports accurate event correlation during outages.

Record the policy/template version before a change so rollback is possible.

Schedule pushes in maintenance windows and verify per-device results afterward.

Use pilot sites to validate changes before broad rollout.

Check device inventory compatibility (bands, security modes, firmware) before enabling new features.

Correlate client complaints with change timestamps to identify regressions.

Roll back by restoring the prior policy/template version if issues appear.

Update documentation (site-to-policy mapping, SSID/VLAN design) after approved changes.

Review the audit log to confirm only intended devices received the change.

Track tunnel status, uptime, CPU, memory, and client counts per device.

Sustained high CPU or memory can degrade forwarding and management responsiveness.

A disconnected device still forwards traffic but cannot receive new configuration.

Compare running configuration to intended policy to detect drift.

Correlate device health with alarms and events for root-cause analysis.

Set thresholds and notifications for device health metrics that matter operationally.

Review device health trends before and after firmware upgrades.

Document baselines so anomalies are detectable.

Roaming is client-driven; AP overlap and minimum RSSI thresholds influence when clients transition.

Insufficient AP overlap causes sticky clients and poor throughput; excessive overlap causes co-channel interference.

Band steering moves capable clients to 5/6 GHz, improving capacity and experience.

Check SNR, retry rate, and roaming events in Client 360 when diagnosing roaming complaints.

Security mode and PMF compatibility can cause roaming or association failures on some clients.

Validate roaming behavior with real client tests and monitoring after design changes.

Document roaming thresholds and AP placement decisions for future troubleshooting.

Correlate roaming complaints with channel/power changes and firmware upgrades.

Design sites and policies from segmentation and capacity requirements, not ad hoc per-device configuration.

Use templates for baselines and overrides sparingly to reduce drift.

Stage firmware and policy changes; verify per-device results and post-change health.

Maintain least privilege for administrators and API tokens; review access periodically.

Monitor alarms, device health, and RF metrics continuously; tune thresholds to reduce noise.

Document site-to-policy mapping, SSID/VLAN design, and firmware baselines.

Export configuration and reports for backup and compliance.

Correlate changes with incidents using audit logs and timestamps.

Account/tenant: the top-level customer container holding sites, devices, and administrators.

Site: a location or logical grouping that determines which network policy devices receive.

Network policy: the container binding SSIDs, VLANs, and device settings, applied to a site or device.

SSID: the wireless service broadcast by APs, defined within a network policy and mapped to a VLAN.

Template: a reusable baseline configuration applied to many devices.

Client 360: a per-client view aggregating association, authentication, signal, and traffic data.

Audit log: the record of administrative actions used for change tracking and compliance.

RBAC: role-based access control scoping administrator permissions by role and site.

Symptom-to-layer questions: identify whether the failure is association, authentication, DHCP/VLAN, or RF before choosing a remedy.

Hierarchy questions: account → site → device → policy; know where each object lives.

Workflow questions: onboarding order (claim, approve, assign site, apply policy).

Distinction questions: cloud management plane vs local data plane; offline device vs failing client.

Role questions: which RBAC role can change configuration versus only view it.

Security questions: WPA3 vs WPA2, 802.1X vs PSK, guest isolation and captive portal walled garden.

Operations questions: staged firmware rollout, drift detection, audit logging, API token hygiene.

Licensing questions: managed devices require entitlement; unlicensed devices fall back to standalone.

Client traffic is forwarded by the device locally; it does not traverse the cloud management plane.

The management tunnel carries configuration, telemetry, and control traffic, not client data.

A cloud tunnel outage does not stop local forwarding; devices use their last-known configuration.

VLAN and DHCP design on the wired side determines whether wireless clients obtain addresses.

Local survivability depends on the device retaining its configuration during disconnection.

Firewall rules must permit device management traffic outbound but need not permit inbound management.

Traffic segmentation (corporate/guest/IoT) is enforced at the device and upstream firewall, not in the cloud.

Monitor both tunnel status and local forwarding health to distinguish management from data-plane issues.

A device inherits the network policy of the site it is assigned to; one active policy per device.

Templates provide a baseline that can be supplemented with CLI or device-level overrides.

Overrides should be limited to genuine exceptions to avoid configuration drift.

Conflicts between template and override settings can cause push failures; check per-device results.

Moving a device between sites changes its inherited policy; verify compatibility before the move.

Document overrides and their justification so future administrators understand exceptions.

Audit drift regularly by comparing running configuration to intended policy.

Roll back by restoring the prior policy/template version if an override causes issues.

Low SNR and high retry rate indicate RF or coverage problems, not authentication failures.

High channel utilization with few clients suggests interference or a misbehaving device.

Wider channels increase throughput but reduce non-overlapping channels and raise interference risk.

Band steering and 6 GHz use relieve 2.4 GHz congestion.

Validate AP placement and power with surveys and post-deployment monitoring.

Check for rogue or unauthorized devices causing interference.

Correlate RF complaints with channel/power changes and firmware upgrades.

Use Client 360 signal and roaming data to pinpoint coverage gaps.

Managed devices require active license entitlement tied to the subscription.

Unlicensed devices fall back to standalone operation and are not managed by the cloud.

Track renewal dates so devices do not lose management coverage unexpectedly.

License coverage should be reviewed when adding devices or sites.

Subscription features may vary; confirm which capabilities are included before designing around them.

Document entitlement per site/device for audit and planning.

Coordinate license changes with firmware and policy rollouts to avoid disruption.

Review usage against entitlement periodically to plan growth.

Public cloud SaaS is operated by Extreme; devices connect outbound to the cloud.

Private/on-premises deployment places management infrastructure in the customer environment.

On-premises requires planning for compute, storage, redundancy, and upgrades.

Cloud deployment shifts management infrastructure resilience to the provider.

Device connectivity requirements (redirector, proxy, DNS/option 43) apply in both models.

Data retention and export requirements may influence deployment choice.

Document the chosen model and its operational responsibilities.

Test failover and recovery procedures appropriate to the model.

Confirm the target device list and site assignment before pushing a change.

Check device online status and license entitlement.

Verify compatibility of the change with device model, firmware, and client population.

Schedule the push in a maintenance window and stagger reboots.

Review per-device push results and resolve failures.

Monitor alarms, client counts, and RF metrics after the change.

Correlate complaints with the change timestamp using the audit log.

Roll back to the prior policy/template version if regressions appear.

Guest onboarding often uses captive portal with a walled garden and optional sponsor approval.

Pre-authentication traffic should be limited to portal and DNS endpoints.

Client isolation and rate limiting protect guest and corporate networks.

HTTPS portal pages and minimal data collection reduce privacy risk.

Monitor portal load failures and authentication errors as configuration indicators.

Separate guest SSIDs per venue simplify policy and troubleshooting.

Review guest firewall rules periodically to confirm isolation.

Document guest flows for support staff.

The audit log records logins, configuration changes, onboarding, and other administrative actions.

Use dedicated accounts and integration identities so actions are attributable.

Review audit logs after significant changes and periodically for anomalies.

Retain and export audit data per organizational policy.

Correlate audit timestamps with alarms and client complaints during incident review.

Restrict audit log access to appropriate roles.

Document change approvals alongside audit records.

Test that audit logging is enabled and complete.

Network policy binds SSIDs, VLANs, radio profiles, and device settings into one deployable unit.

SSIDs define broadcast name, security mode, and authentication method.

VLAN mapping determines client Layer 2 segment and must match wired configuration.

Radio profiles control channel width, power, and band behavior.

Authentication profiles reference RADIUS or portal configuration.

Device templates and overrides handle device-specific settings outside the shared policy.

One active policy per device; moving sites changes inherited policy.

Document policy contents and versions for change control.

SSID-to-VLAN mismatch causes association but no IP address.

Missing walled garden entries cause captive portal pages to fail to load.

RADIUS shared-secret mismatch causes authentication failures across the SSID.

Unlicensed devices are not managed and appear to ignore configuration.

Template/override conflicts cause configuration push failures.

Insufficient AP overlap causes sticky clients and poor roaming.

Excessive transmit power causes co-channel interference.

Stale API tokens or integration accounts cause automation failures.

Tunnel status and uptime per device.

Client counts per SSID, band, and site.

RSSI, SNR, retry rate, and channel utilization per radio.

CPU and memory per device.

Alarm counts by severity and category.

Firmware version distribution across the fleet.

Configuration drift reports.

License entitlement versus device count.

Track current versions and identify end-of-support firmware.

Read release notes for changed defaults and known issues.

Schedule upgrades in maintenance windows and stagger reboots.

Pilot on a small site and verify health before expanding.

Confirm devices have connectivity and bandwidth for downloads.

Verify post-upgrade tunnel status, client counts, and alarms.

Roll back to the prior image if regressions appear.

Record firmware baselines per site and model.

Group devices by physical location or shared policy requirements.

Site assignment determines inherited network policy and RBAC scoping.

Reuse policies across similar sites to reduce drift.

Document site-to-policy mapping for troubleshooting and audits.

Plan VLAN and SSID naming conventions at scale.

Consider growth when reserving VLAN ranges and SSID slots.

Verify device model and firmware compatibility with site policy.

Review site design periodically as requirements change.

Monitor for rogue or unauthorized devices joining the managed fleet.

Use onboarding approval and allowlists to gate device admission.

Track authentication failures as potential credential or configuration issues.

Review administrator and API access periodically for stale privilege.

Keep firmware current to address known vulnerabilities.

Segment guest, IoT, and corporate traffic to limit lateral movement.

Alert on critical security-relevant alarms.

Document security monitoring procedures and responsibilities.

Gather device serial, site, policy, firmware version, and timestamps before escalating.

Capture relevant alarms, events, and audit log entries.

Use diagnostic tools (ping, traceroute, packet capture where supported) to gather evidence.

Reproduce the issue in a controlled site if possible.

Document steps taken and results for the support case.

Correlate with recent changes (policy, firmware, configuration).

Follow up with root cause and remediation documentation.

Update internal knowledge base with the resolution.

Cloud management plane configures and monitors; the device data plane forwards client traffic locally.

Hierarchy: account → site → device, with network policy inherited from the site.

Onboarding: device contacts cloud, is claimed/approved, assigned to a site, and receives policy.

Security: RBAC for administrators, WPA3/802.1X for clients, segmentation for traffic.

Operations: staged firmware and policy rollouts, drift detection, audit logging, alarm management.

Troubleshooting: identify the layer (association, authentication, DHCP/VLAN, RF) before remedying.

Licensing: managed devices require entitlement.

Documentation and periodic review sustain operational readiness.