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

Extreme Fabric (Fabric Connect) cheat sheet

Extreme Fabric (Fabric Connect) · Keep the key ideas within reach.

Quick reference

Fabric Design and Deployment

  • Fabric Connect builds a shortest-path bridging (SPB) fabric: every node runs SPB, and customer VLANs are mapped to I-SIDs at the edge, so the core forwards only by backbone MAC and I-SID.

  • Scale rule: each node is identified by a unique nickname (20-bit space, ~1,048,575 values); plan nickname allocation per node before deployment because duplicates break IS-IS adjacency and SPB forwarding.

  • Node roles: Backbone Edge Bridge (BEB) attaches customer access ports and does I-SID/VLAN mapping; Backbone Core Bridge (BCB) only forwards; a node can be both.

  • Underlay control plane is IS-IS (SPB uses IS-IS with SPB extensions); design the fabric as a single IS-IS Level 1 area or a defined L1/L2 hierarchy, since all nodes must share consistent topology information.

  • MTU rule: SPB encapsulation adds a 22-byte outer header (MAC-in-MAC plus I-TAG), so fabric links and access ports must be sized to carry the largest customer frame plus 22 bytes.

  • Redundancy design: SMLT/RSMLT (or vLACP/IST) on dual-homed access switches avoids STP blocking; the IST (inter-switch trunk) between cluster peers carries control traffic and must be sized and protected.

  • Addressing rule: each fabric node needs a unique system ID (sys-id) derived from a loopback or chassis MAC; the loopback address must be reachable for management and for IP shortcuts.

  • Deployment sequence: configure IS-IS and SPB on core nodes first, verify adjacencies and LSDB convergence, then add BEB edge nodes and map I-SIDs to VLANs.

Quick reference

Fabric Implementation and Configuration

  • Enable SPB globally, then per-interface: IS-IS must be enabled on the interface and SPB enabled on the interface before it participates in the fabric; a missing per-interface SPB enable leaves the port silent.

  • Nickname config: set the node nickname explicitly (or allow auto-assignment) and verify with the SPB/IS-IS neighbor and nickname show commands; the nickname must be unique per node.

  • I-SID mapping: on a BEB, bind a customer VLAN to an I-SID (VLAN-to-I-SID mapping) on the access port; the same I-SID on a remote BEB maps back to that site's VLAN, enabling L2 extension.

  • B-VLAN rule: SPB uses B-VLANs (backbone VLANs) to carry I-SIDs; I-SIDs are distributed across B-VLANs, so plan at least two B-VLANs for load sharing and verify B-VLAN membership on core links.

  • SMLT configuration: define the IST (peer IP, VLAN, and peer ports), then add SMLT client ports; both cluster peers must have matching IST and SMLT IDs for the bundle to come up.

  • RSMLT provides routed redundancy for SMLT-attached subnets by having both cluster peers hold the same IP and forward for each other; enable RSMLT on the VLAN interface on both peers.

  • Verification order: IS-IS adjacency up, SPB nickname learned, I-SID present in the SPB database, MAC learned at the correct edge, then end-to-end ping/traffic test.

Quick reference

Fabric Operations and Troubleshooting

  • First check: IS-IS adjacency state on every fabric link; a down or stuck adjacency (Init/ExStart equivalent) stops SPB topology and I-SID propagation for that path.

  • Symptom-to-cause rule: I-SID missing at a remote BEB usually means the VLAN-to-I-SID mapping is absent on the local BEB or the I-SID was not advertised through IS-IS.

  • Symptom-to-cause rule: traffic blackholes on a dual-homed access switch typically indicate SMLT/IST mismatch, one peer missing the SMLT ID, or the IST link down.

  • MAC learning check: verify the customer MAC appears in the SPB MAC table with the correct BEB nickname; a MAC learned on the wrong edge indicates a loop or mis-mapped I-SID.

  • MTU troubleshooting: large frames failing while small pings succeed points to the 22-byte SPB overhead exceeding link MTU; check jumbo configuration end to end.

  • Loop prevention: SPB is loop-free by design (IS-IS shortest path); if you see broadcast storms, suspect misconfigured access ports or an unintended L2 path outside the fabric.

  • Log and counter checks: monitor IS-IS adjacency flaps, SPB TLV errors, and interface drops; repeated adjacency flaps usually trace to physical errors, MTU mismatch, or duplicate nicknames.

Quick reference

Fabric Security and Resilience

  • Control-plane protection: apply IS-IS authentication (MD5 or HMAC) on fabric links so unauthorized nodes cannot inject topology or nickname information.

  • Nickname spoofing rule: a rogue node advertising a duplicate nickname causes traffic misdirection; enforce unique nickname allocation and monitor nickname conflict alarms.

  • Edge security: apply ACLs and DHCP snooping on BEB access ports; the fabric core should carry only I-SID traffic, not unfiltered customer broadcasts across sites.

  • SMLT/IST resilience: dual-homed access plus SMLT gives sub-second failover without STP; test by failing one peer and confirming traffic continues via the other.

  • Failure-domain rule: keep IST traffic on a dedicated, redundant link or LAG; an IST failure splits the cluster and can create an L2 loop if access switches are still dual-homed.

  • RSMLT failover: with RSMLT, a peer failure keeps the gateway IP reachable because the surviving peer forwards for the failed peer's subnet; verify hold-up timers so forwarding does not drop early.

  • Management-plane hardening: restrict management access to the fabric loopback addresses, use out-of-band or protected in-band management, and disable unused services on fabric nodes.

Quick reference

Fabric Automation and Management

  • Configuration consistency rule: fabric nodes share IS-IS and SPB settings, so template the common parameters (area, MTU, B-VLANs, authentication) and vary only node-specific values (sys-id, nickname, loopback).

  • Automation workflow: inventory nodes and roles, render per-node config from a template, push via CLI/SSH or NETCONF/REST, then verify IS-IS adjacency and SPB nickname per node before proceeding.

  • Idempotency: scripts should check current state (nickname, I-SID mapping, SMLT membership) before applying changes so re-runs do not create duplicate or conflicting entries.

  • Monitoring rule: poll IS-IS neighbor state, SPB nickname table, I-SID database, and SMLT/IST status on a schedule; alert on adjacency loss, nickname conflict, and IST down.

  • Change control: nickname and I-SID allocation should live in a central registry (spreadsheet or IPAM/DCIM) to prevent collisions as the fabric grows.

  • Backup rule: export running configuration and topology data (IS-IS LSDB summary, I-SID map) after every change so a failed node can be rebuilt to match the fabric.

  • Validation gate: after automation runs, require an end-to-end test (ping across I-SIDs, MAC learning at the remote BEB) before marking the change successful.