I85PREP
⌘ K
ExtremeCloud IQ Site Engine (XIQ-SE) study materials
ExtremeCloud IQ Site Engine (XIQ-SE) study resources

ExtremeCloud IQ Site Engine (XIQ-SE): Device Discovery, Onboarding, and Inventory Management

ExtremeCloud IQ Site Engine (XIQ-SE) · Work through your exam, one topic at a time.

All guide sections

Device Discovery, Onboarding, and Inventory Management

Domain 3 tests how devices enter XIQ-SE, stay current, and stay organised: discovery profiles, credential handling, automated onboarding, and the inventory views that answer "what do we have and what firmware is on it?".

Discovery profiles

  • Under Discover > Devices, a profile holds a name, target ranges (start–end, CIDR, subnets, seed devices), SNMP profiles, CLI credentials, device-family filters, site assignment and a schedule (one-time or recurring).
  • Credentials in the list are tried in order, so put the most widely working set first. SNMP yields identity, inventory and interface data; CLI yields configuration, scripts and firmware operations.
  • Keep an ignore list for printers, cameras and ranges you never want managed, otherwise recurring discoveries keep re-adding decommissioned gear.

Onboarding automation

  • ZTP+/fabric onboarding: VSP/Fabric Engine devices receive an address from DHCP, learn the XIQ-SE call-home target, enrol and pull staged configuration. The ZTP server settings and a ZTP credential must exist first.
  • Fabric Attach auto-sense lets EXOS access switches attach themselves and their I-SIDs when FA and LLDP are enabled on the uplink.
  • Manual Add Device and CSV import remain valid for isolated or pre-staged sites.

Inventory and lifecycle

  • The Devices table is the inventory of record: family, model, serial, firmware, IP, site, poll state and last-successful-poll timestamp.
  • Use firmware summaries and inventory reports to plan upgrades, and poll status to separate "reachable but not managed" (SNMP/credential fault) from "unreachable" (routing/ACL fault).

Worked example

Forty new EXOS switches appear in discovery results with only an IP and a ping response. That means SNMP failed - usually a wrong community or SNMPv3 user, or a switch ACL blocking the server - while SSH management still works. Correct the SNMP profile, re-run it against the same range, and leave the existing records in place so you do not create duplicates.

Traps that cost marks

  • Re-running discovery with a different site and duplicating logical placement.
  • SNMPv3 auth/priv mismatch leaving devices "ping only".
  • Discovering across NAT and storing the translated address.
  • Expecting CLI-only devices to produce full topology.
  • Leaving stale devices managed, inflating alarms and licence counts.