Extreme Fabric (Fabric Connect) common mistakes
Extreme Fabric (Fabric Connect) · Understand the traps and how to avoid them.
Designing a fabric by copying a flat Layer 2 spanning-tree topology across every site, then assuming the control plane will converge automatically once IS-IS is enabled.
Candidates study the protocol configuration commands in isolation and never practise the underlay/overlay design decision: whether to use a Layer 2 or Layer 3 underlay, how far the I-SID/VLAN extension should reach, and where the anycast gateway sits. They treat Fabric Connect as a set of CLI steps rather than an architecture, so they cannot answer scenario questions about which fabric node should be the BCB versus BEB.
What to do instead
Before touching configuration, draw the topology for each scenario: mark core Backbone Core Bridges, edge Backbone Edge Bridges, and the access layer. For each design question, state which node terminates the I-SID, where the anycast gateway is hosted, and whether the underlay is L2 or L3. Practise translating a stated requirement (for example, extend a subnet across two data centres without stretching spanning tree) into a specific node role assignment and interface type (NNI versus UNI).
Configuring the fabric interfaces but leaving the IS-IS system ID, nickname, or manual area inconsistent, then being surprised when adjacencies never form or the SPBM topology is incomplete.
System IDs and nicknames are easy to treat as boilerplate to paste in, so candidates do not learn the constraints: system IDs must be unique and consistent in format, nicknames must be unique and large enough for the node's role, and the manual area must match across the fabric. Mismatches produce silent adjacency failures rather than obvious errors, so the candidate never learns to check these first.
What to do instead
Build a habit of verifying the fabric identity layer before anything else: confirm unique system IDs, unique nicknames with adequate nickname space for the expected node count, and a consistent manual area across all fabric nodes. On the exam, when a scenario says adjacencies are down, check identity and area mismatches before routing or I-SID issues. Practise on a small lab fabric by deliberately breaking one parameter and observing the failure signature.
Assuming that creating an I-SID and attaching it to a UNI is sufficient to make an end-to-end service work, without verifying the VSN creation, the backbone VLAN binding, or that the I-SID is provisioned on every node along the path.
In a working lab, services often come up because a previous engineer already created the VSN and bound the I-SID. Candidates who only add the UNI-side VLAN see the service work and conclude that is the whole task. In exam scenarios where a service fails at one site, they cannot distinguish a missing VSN from a missing I-SID mapping from a UNI misconfiguration.
What to do instead
Learn the full service-creation chain as an ordered checklist: create the VSN, map the I-SID to the VSN, bind the customer VLAN to the I-SID at the UNI, and confirm the I-SID is advertised across the fabric. When troubleshooting, walk the chain in order from the UNI inward rather than guessing. Practise with a two-site service and remove one element at a time to learn each failure signature.
Treating every fabric link as an NNI by default, or plugging a server-facing port into a fabric port, and then debugging the resulting adjacency or traffic problem as if it were a routing fault.
The distinction between Network-to-Network Interfaces and User-to-Network Interfaces is a design concept, but candidates often learn it as a label rather than as a configuration mode that changes what the port does. Misassigning an interface produces symptoms (no adjacency, no service, unexpected flooding) that look like other faults, so the candidate chases the wrong cause.
What to do instead
For every interface in a scenario, decide explicitly whether it faces another fabric node (NNI) or an endpoint (UNI), and configure accordingly. When a port misbehaves, verify its role first: an NNI should form an IS-IS adjacency and an SPBM adjacency, while a UNI should not. Build a lab where one port is deliberately set to the wrong role and record the symptoms so you recognise them on the exam.
Troubleshooting an end-to-end service by starting at the far end or by checking application symptoms first, instead of verifying the underlay IS-IS adjacencies and SPBM topology before looking at the service layer.
Candidates who learned services first naturally reach for I-SID and VLAN checks, but most fabric faults are underlay faults that manifest as service faults. Without a layered troubleshooting order, they waste time on the overlay while the real problem is a down adjacency or an incomplete topology.
What to do instead
Adopt a strict bottom-up order for every troubleshooting question: physical link and interface status, then IS-IS adjacency and topology completeness, then SPBM path and I-SID propagation, then UNI and customer VLAN binding, then endpoint. State the layer you are testing and what evidence would confirm or eliminate it. Practise this order in a lab by injecting faults at each layer and timing how quickly you localise them.
Assuming the redundant fabric path will take over automatically without confirming that the primary path's failure actually triggers reconvergence, and without knowing the expected convergence behaviour.
Fabric Connect is marketed on resilience, so candidates assume redundancy is automatic and skip the verification step. They do not learn how the fabric reconverges after a link or node failure, what the expected traffic impact is, and how to prove the backup path is carrying traffic. Scenario questions about failover then expose the gap.
What to do instead
Study and lab the failover sequence: what happens to adjacencies, how the SPBM topology changes, and how quickly service resumes. Practise proving the backup path is active by checking the forwarding path and service state after shutting a link. On the exam, when a scenario describes a failover, describe the specific evidence you would collect rather than asserting that redundancy handles it.
Ignoring control-plane and management-plane hardening: leaving default credentials, unauthenticated management access, or unrestricted access to the fabric nodes from user-facing segments.
Candidates focus on getting services working and treat security as a separate topic to memorise later. Because the fabric is presented as a connectivity technology, they do not connect management access, authentication, and segmentation to the security domain, so security questions feel unrelated to the configuration they practised.
What to do instead
Treat the fabric nodes as critical infrastructure: enforce strong authentication for management access, restrict management reachability to a dedicated management network, and use the fabric's own segmentation to keep user traffic away from control and management planes. For each security scenario, identify the asset, the threat, and the specific control that mitigates it. Review the management-access configuration of your lab fabric as a checklist exercise.
Designing segmentation by creating many I-SIDs without a naming, numbering, and documentation scheme, so the fabric becomes unmanageable and service conflicts appear later.
I-SIDs are just numbers, so candidates assign them ad hoc while practising and never experience the consequences of collisions or undocumented services. Exam scenarios about scaling or auditing segmentation expose the absence of a plan, and candidates cannot reason about how to organise services across sites.
What to do instead
Adopt a documented I-SID allocation scheme from the first lab service: reserve ranges by site, service type, or tenant, and record each I-SID with its VSN, UNI bindings, and owner. When a scenario involves many services, propose the allocation plan before the configuration. This also makes troubleshooting faster because an unexpected I-SID is immediately visible as out of plan.
Configuring fabric nodes one at a time through the CLI and never practising scripted or template-driven provisioning, then failing scenario questions that ask how to roll out a change consistently across many nodes.
Candidates learn the CLI because it is the fastest way to make a single lab node work, and automation feels like an optional extra. As a result they cannot describe how to apply a consistent configuration across a fabric, how to verify it, or how to roll it back, which is exactly what management and automation questions probe.
What to do instead
Practise provisioning at least a small fabric from a repeatable source: a configuration template or script that sets identity, interfaces, and services consistently, plus a verification step that checks adjacencies and service state across all nodes. Learn to describe the workflow in terms of intent, deployment, verification, and rollback. Even a simple scripted lab gives you the vocabulary and judgement the exam expects.
Skipping configuration backup and change verification, so a failed change cannot be rolled back and the candidate cannot describe how to confirm a change succeeded.
Lab work is treated as disposable, so candidates never build the habit of capturing a baseline, applying a change, verifying it, and knowing how to revert. Exam scenarios about operational change then reveal that the candidate has no defined process, only ad hoc commands.
What to do instead
For every lab change, capture the pre-change state, apply the change, verify the intended effect with specific show commands, and record how you would revert. Build a short personal runbook covering identity, adjacencies, service state, and management access. In scenario questions, describe the verification evidence explicitly rather than saying you would check that it works.