Extreme Fabric (Fabric Connect) study materials
Extreme Fabric (Fabric Connect) study resources

Extreme Fabric (Fabric Connect): Fabric automation and management

Extreme Fabric (Fabric Connect) · Work through your exam, one topic at a time.

All guide sections

Fabric automation and management

Domain 5 tests how fabrics are run at scale: zero-touch onboarding, modelling the fabric in a manager (XIQ-SE with Fabric Manager, or XCO/ExtremeCloud Orchestration), pushing changes through REST or CLI scripting, and monitoring with SNMPv3, syslog and sFlow. The thread running through it is that automation consumes the same IS-IS and I-SID model you troubleshoot by hand - if the registry is wrong, the automation distributes the error quickly.

Tooling layers

  • XIQ-SE (formerly XMC) with Fabric Manager discovers nodes and I-SID topology from the fabric itself, then provides configuration backup, comparison and audit, script and policy push, and alarms.
  • XCO / Fabric Orchestrator works from intent: you declare sites, roles and services, and it generates per-node configuration and onboards devices.
  • Native interfaces on the switches: REST API over HTTPS with JSON payloads, SNMPv3, syslog, sFlow, configuration upload/download over SCP or TFTP, and CLI script files for repeatable changes.

Zero touch and Fabric Attach

  • ZTP: DHCP option 66/67 (or the vendor's ZTP service) points a factory-fresh switch at a configuration file or URL. That configuration must already contain nickname, B-VIDs, IS-IS and management addressing.
  • Fabric Attach removes per-port work: the server assigns an I-SID from a pool when a client attaches, so new access switches need no fabric-specific port configuration.
  • The nickname and I-SID registry is the real source of truth. Validate against it before a push, because duplicates do not fail the push - they fail the fabric.

Worked example

Twenty access switches are onboarded by ZTP into an existing fabric. Nineteen come up clean; one shows a flapping adjacency and MACs that keep moving between two nodes. The cause is a stale registry record: the new switch was issued a nickname already held by a core node. The manager's alarm pointed at the symptom, but the registry was the root cause. Fix: correct the record, re-push the configuration, then confirm show isis spbm reports a single unique nickname per system-id.

Traps that cost marks

Treating manager topology as real time (it is polled); automating I-SID or nickname allocation without a collision check; running SNMPv2c or unencrypted HTTP against production; assuming ZTP delivers licences or feature enablement; making out-of-band CLI changes that the orchestrator later overwrites; expecting Fabric Attach to work without a designed server and pool.