ExtremeCloud IQ Site Engine (XIQ-SE) cheat sheet

XIQ-SE is a single-server or distributed deployment: the main (application) server hosts the GUI, NAC, and databases, while remote servers host distributed services such as captive portal, RADIUS/802.1X authentication, and site-local engines.

Core components: the Site Engine application server, Extreme Control (NAC), Extreme Analytics, one or more ExtremeCloud IQ Controller (wireless) instances, and ExtremeCloud IQ (cloud) integration for wireless management.

The application server runs on a hardened Linux appliance image or as a virtual appliance; management is through a web GUI on HTTPS (default 8443) and CLI via console/SSH.

Licensing is feature-based and per-device/per-seat: base Site Engine, Extreme Control (device count), Extreme Analytics (flow source count), and wireless controller licenses are separate entitlements.

License entitlement is enforced by device count; exceeding the licensed device count for a feature disables onboarding of additional devices for that feature until licenses are added or devices are removed.

A distributed deployment requires network reachability between servers on the documented ports; the application server must reach remote servers for authentication, portal, and data collection traffic.

The appliance database (PostgreSQL-based) and file stores are local to each server; backup and restore must be planned per server, and distributed servers must be backed up consistently.

Capacity planning depends on managed device count, monitored ports, flow rate for Analytics, and NAC authentication rate; scale guidance is per appliance size (small/medium/large).

Initial setup is performed through the console/CLI first-time configuration: set hostname, management IP, netmask, gateway, DNS, NTP, and the admin password before accessing the web GUI.

NTP synchronization is mandatory for correct certificates, logs, NAC session timing, and distributed server trust; configure at least one reliable NTP source during initial setup.

The initial web GUI wizard covers license installation, database initialization, and administrator account creation; complete it before adding devices.

Upgrades are performed with the application upgrade image uploaded through the GUI or CLI; take a full backup and verify free disk space before starting.

Upgrade path rules apply: some releases require an intermediate version before jumping to the target; check the release notes' supported upgrade path from the currently installed version.

Distributed deployments must be upgraded in the correct order (typically remote/distributed servers before or in coordination with the application server), following the release notes.

After upgrade, verify services start, check the server health/status page, and re-validate licenses and integrations (wireless controllers, cloud connection, RADIUS).

Firmware for managed Extreme devices is stored in the Site Engine image repository; device firmware images are added separately from the Site Engine upgrade image.

Discovery methods: subnet/range scan, seed device (walks neighbors via LLDP/CDP/EDP/FDP), CSV import, and auto-discovery of devices that report in (e.g., via ExtremeCloud IQ or DHCP/registration).

SNMP credentials (v2c community or v3 user/auth/priv), CLI credentials (SSH/Telnet), and device profiles determine whether a discovered device can be onboarded and managed.

Device families have profiles that define the credential set, firmware, and configuration templates applied at onboarding; a device must match a profile to be fully managed.

Onboarding enforces licensing: a device is only added to inventory as managed if a license is available for its feature set (wired, wireless controller, NAC).

Inventory views group devices by family, firmware version, site, and management status; unmanaged/unknown devices remain visible until credentialed or deleted.

Site assignment determines which maps, policies, and role-based access apply to a device; devices can be moved between sites after onboarding.

Device configuration changes can be pushed from Site Engine (templates, firmware) or made locally; a resync/re-read updates Site Engine's view of the device.

Bulk operations (firmware upgrade, configuration deploy, delete) are scheduled as jobs and tracked in the job/task status view.

The site hierarchy is a tree: World > Region/Country > Site > Building > Floor; devices, maps, and policies are bound at the appropriate level.

Topology maps are auto-generated from neighbor discovery (LLDP/CDP/EDP/FDP) and can be manually adjusted; link status and device health are reflected in map colors.

Floorplan maps are image-based; devices are placed on the floorplan and AP placement drives wireless coverage/heat-map views.

Site-level policy inheritance flows down the hierarchy; a policy set at a parent site applies to children unless overridden.

Topology views can be filtered by site, device family, or link type to isolate segments; the physical topology differs from the logical/VLAN view.

Map status propagates device alarms to the map icon; a red icon indicates a critical alarm on that device or link.

Devices not assigned to a site appear in a default/unassigned location; assigning them to a site is required for site-scoped policy and reporting.

Extreme Control NAC evaluation order: authentication (802.1X/MAC/WebAuth) → authorization (rules/roles) → enforcement (VLAN, ACL, reauthentication, posture).

Rules are evaluated top-down within a rule set; the first matching rule's role/action applies, so order and specificity matter.

Roles define network access: VLAN assignment, ACL/filter, bandwidth, and reauthentication period; roles are mapped to devices/ports via device configuration.

Policy domains separate wired, wireless, and VPN policy; each domain has its own rule sets and role mappings.

Fabric (Extreme Fabric Connect / SPBM) integration uses I-SIDs and VSNs to place authenticated users into a service; NAC role maps to a fabric service/VLAN.

Guest and BYOD flows use captive portal + registration; device registration state and MAC caching determine subsequent authentication without portal.

Policy simulation/test tools let you validate which rule and role a given set of attributes (user, MAC, device, location) will match before deploying.

ExtremeCloud IQ Site Engine can manage ExtremeCloud IQ Controller (formerly WiNG/ExtremeWireless controllers) on-premises and integrate with ExtremeCloud IQ (cloud) for cloud-managed APs.

On-premises wireless controllers are onboarded with SNMP/CLI credentials and a controller profile; APs are then adopted through the controller and appear in Site Engine inventory.

Cloud integration uses an ExtremeCloud IQ connection (API credentials/token) so cloud APs, sites, and clients appear alongside on-premises wireless in Site Engine.

Wireless views include AP status, client associations, SSID/VLAN mapping, and RF health (channel, power, interference, retries).

AP firmware and configuration templates are pushed through the controller or cloud; Site Engine orchestrates but the controller applies the config.

Client troubleshooting uses the client detail view: association history, authentication events, roaming, and the serving AP/controller.

SSID-to-VLAN-to-role mapping ties wireless policy to NAC: the SSID determines the policy domain and the resulting role/VLAN for the client.

Alarm severity levels (critical/major/minor/warning/info) drive map colors, notification, and dashboard counts; alarms are cleared or acknowledged by operators.

Events are raw log/trap records; alarms are derived from events by alarm rules/correlation. Both are searchable in the events/alarms views.

SNMP traps, syslog, and syslog-based flow data feed monitoring; ensure devices are configured to send traps/syslog to the Site Engine server address.

Dashboards and reports cover device health, port utilization, wireless clients, NAC authentications, and alarm trends; reports can be scheduled and exported.

Thresholds (interface utilization, device reachability, wireless health) generate alarms when crossed; thresholds are configurable per device/port.

Alarm notification can be delivered by email and SNMP trap forwarding; notification targets are configured in the administration settings.

Report data retention depends on the database and purge settings; long-term trending requires adjusting retention or exporting reports.

Local user accounts have assigned authorization groups (roles) that control GUI/CLI access and which device/site scopes they can manage.

External authentication (RADIUS, LDAP/AD, TACACS+) can be used for administrator login; group mapping maps external groups to Site Engine authorization groups.

Backup captures the database and configuration; schedule regular backups and store them off-box. Restore requires a matching or compatible software version.

High availability options include distributed/remote servers for service redundancy and database replication/failover configurations per deployment guide; HA must be designed before deployment.

Audit logs record administrative actions (logins, config changes, policy edits); review them for change tracking and compliance.

Certificate management: replace the default self-signed web certificate with a CA-signed certificate for trusted HTTPS access.

Server maintenance tasks (database purge, log rotation, disk cleanup) are scheduled; monitor disk usage to avoid service degradation.

Diagnostic tools include ping/traceroute from the server, SNMP walk/test, CLI credential test, and device reachability checks from the device detail view.

NAC troubleshooting follows the authentication chain: supplicant → switch/AP → RADIUS → Site Engine policy → role/VLAN enforcement; check each hop's logs.

Common onboarding failures: wrong SNMP/CLI credentials, unreachable management IP, unsupported firmware, missing license, or no matching device profile.

Logs to inspect: server logs (application, NAC, database), device syslog, and RADIUS authentication logs; increase log verbosity temporarily when diagnosing.

Automation uses the REST API and/or CLI scripting to create devices, sites, policies, and reports; API access requires an account with appropriate authorization.

Scheduled jobs (firmware, config deploy, reports, backups) show status and error detail in the job/task view; failed jobs can be retried.

Health checks: verify services are running, NTP is synced, disk space is sufficient, and licenses are valid before escalating a support case.