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

ExtremeCloud IQ Site Engine (XIQ-SE): Troubleshooting, Diagnostics, and Automation

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

All guide sections

Troubleshooting, Diagnostics, and Automation

Domain 9 asks you to diagnose why a device is not polled or an endpoint fails authentication, and then automate the fix: the diagnostics toolbox, log locations and the workflow engine.

Diagnostics toolbox

  • Per-device tools include ping, traceroute, SNMP walk and an SSH/Telnet session launched from the server using stored CLI credentials - the fastest proof of whether routing, credentials or an ACL is at fault.
  • Poll status and last-successful-poll separate unreachable devices from reachable-but-unmanaged ones. A credential test validates a username and secret before you apply it broadly.
  • Endpoint/MAC search maps a MAC address to switch and port. Control diagnostics show which authentication and authorisation rule matched, and test-authentication replays a MAC through the rules.
  • Server side, Administration > Diagnostics > Server Logs offers adjustable log levels, and a support-information bundle collects logs and state for Extreme support.

Automation

  • Workflows link a trigger - alarm, event, schedule, endpoint authentication, discovery - to activities such as send email, run a CLI script, deploy configuration, apply a role, add to a site, or disable a switch port.
  • Scripts run with device credentials from the credential list, not the admin's login, and use per-family command syntax. Failed activities stop the branch unless error handling is configured.
  • Use scheduled tasks for recurring reports, backups and compliance checks, and the REST API for inventory and Control data when integrating with ticketing or a CMDB.

Worked example

A port must shut down when a rogue-device alarm fires. First build the alarm definition matching the rogue-detection trap, then a workflow with an alarm trigger filtered to that exact alarm name and an action that runs a script on the reporting device: enter interface context, issue shutdown, save. Test with a lab alarm - if the workflow never starts, the trigger filter name usually does not match the alarm exactly.

Traps that cost marks

  • Testing credentials with the admin account instead of the configured device credential.
  • Alarm-name mismatch between definition and workflow filter.
  • Scripts assuming one device family's syntax for another family.
  • Expecting alarms for data the device never sends.
  • Capturing a support bundle after the log window has rolled over.