Extreme Data Center (VOSS/VSP) common mistakes
Extreme Data Center (VOSS/VSP) · Understand the traps and how to avoid them.
Treating Auto-Sense as if it configures the whole port automatically, expecting an access port to come up with a VLAN, I-SID, and IP interface without any manual provisioning, and then answering that Auto-Sense assigns I-SIDs or builds the Layer 3 interface.
Marketing-level descriptions of Fabric Auto-Sense blur the boundary between what the fabric automates (VLAN-to-I-SID mapping and IS-IS fabric attachment via auto-sense) and what the administrator still must define (the VLAN, the I-SID value, the UNI port, and any IP interface). Candidates who learned the feature from a summary assume end-to-end automation.
What to do instead
Memorise the division of labour: Auto-Sense automates the mapping and fabric attachment of an already-created VLAN/I-SID pair on a UNI port, not the creation of the service identifiers themselves. For each scenario question, ask 'who supplies the I-SID?' - if the answer must be the administrator, reject any option claiming Auto-Sense generates it.
Conflating SPB with STP-based or MPLS-based designs - for example stating that SPB blocks redundant links to form a loop-free tree, or that it requires a spanning-tree instance per VLAN to prevent loops.
Candidates carry over habits from classic Layer 2 or from VPLS/MPLS study. SPB (as implemented with IS-IS and the backbone VLAN) uses a link-state topology with equal-cost multipathing and does not block links; there is no per-VLAN STP. The mental model of 'blocking ports' is deeply ingrained.
What to do instead
Anchor on three facts: IS-IS builds the topology, all links forward (ECMP), and loop prevention comes from the SPB forwarding model plus the backbone VLAN separation, not from STP. When an answer option mentions blocking or per-VLAN STP inside the fabric, treat it as a distractor unless the question is explicitly about edge/UNI STP behaviour.
Mixing up the BVLAN (backbone VLAN) and the customer/service VLAN, or assuming the I-SID is carried inside the customer VLAN tag end-to-end across the fabric.
In VOSS the fabric runs over a dedicated backbone VLAN (commonly BVLAN 4001/4002 in examples), while customer traffic is mapped to an I-SID at the edge. Candidates who think in terms of 802.1Q trunking assume the service VLAN traverses the core unchanged, which leads to wrong answers on tagging, MTU, and UNI configuration.
What to do instead
Draw the packet path once from memory: customer frame arrives on UNI in a service VLAN, is mapped to an I-SID, encapsulated with the backbone MAC/VLAN across the fabric, and de-encapsulated at the far edge. Revise which VLAN exists on which link, and confirm that the I-SID - not the customer VLAN - is the end-to-end service identifier.
Answering that a new I-SID must be configured on every fabric node for the service to work, rather than only on the edge nodes where the service is attached.
Candidates extrapolate from traditional VLAN provisioning, where the VLAN must exist on every switch in the path. In SPB, transit nodes forward based on the I-SID in the SPB header and do not need the I-SID defined locally; only the edge/UNI nodes need the service instance.
What to do instead
State the rule explicitly: I-SID provisioning is edge-only; core nodes are service-agnostic. Use this as a filter on 'which nodes require configuration' questions, and be ready to explain why an I-SID unknown to a transit node still forwards correctly.
Assuming a VSP switch boots into the same CLI and configuration model as a conventional VSP or ERS device, and answering management-access questions as if the default management interface, user account, or config-save syntax were identical across platforms.
The Extreme Data Center portfolio spans VOSS-based fabric switches and other operating models; candidates study one platform's quick-start and generalise. Default credentials, the 'enable'/'configure' hierarchy, and the way configuration is saved differ, and exam questions probe those specifics.
What to do instead
Build a one-page comparison of the platforms you are responsible for: default management access method, initial user, CLI hierarchy, and the command that persists configuration. When a question names a platform, answer for that platform, not for the family in general.
Forgetting that an IS-IS fabric requires consistent system-id, area, and MTU settings, and selecting an answer that adds a node to the fabric without checking those parameters first.
Candidates focus on the service layer (VLANs, I-SIDs) and treat the fabric as 'just enable IS-IS'. Adjacency failures in practice are usually caused by mismatched area, system-id length/format, or MTU on the backbone links, so troubleshooting questions hinge on these.
What to do instead
Adopt a fixed pre-flight checklist for any 'new node joins the fabric' scenario: system-id uniqueness and format, area match, BVLAN consistency, and MTU on all backbone links. Practise reading an adjacency-failure symptom and mapping it to the specific mismatched parameter.
Confusing VRRP with RSMLT (or with SMLT) when answering first-hop redundancy questions - for example saying RSMLT requires a virtual IP shared between peers, or that VRRP provides active-active Layer 3 forwarding across an SMLT pair.
The SMLT/RSMLT/VRRP trio is conceptually adjacent and all appear in high-availability designs. VRRP is a standards-based virtual router with a master/backup model; RSMLT is an Extreme-specific mechanism where both peers forward for the same subnet using their own IPs, avoiding a virtual MAC. Candidates blur the roles.
What to do instead
Write three one-line definitions and one distinguishing question each: does it use a virtual IP? is forwarding active-active? does it depend on SMLT? Then answer HA questions by matching the design requirement (active-active L3 across an SMLT pair, fast failover, standards interoperability) to the mechanism.
Describing SMLT as a single physical link or assuming it requires STP to prevent loops between the paired switches and the access device.
SMLT is an IST-based multi-homing mechanism: the two cluster peers share an Inter-Switch Trunk and present a logical multi-homed attachment to the access device, with no STP blocking needed. Candidates who map it onto classic dual-homing with STP get the loop-prevention and failover behaviour wrong.
What to do instead
Fix the model: IST carries cluster control and must be sized/configured correctly; SMLT is the logical multi-homed link; SMLT avoids STP blocking and provides sub-second failover. Revise what happens on IST failure versus SMLT link failure, since questions test both.
Answering routing questions as if VOSS behaves like a generic router - for example assuming OSPF is enabled by default, that a VLAN automatically gets an IP interface, or that redistribution between IS-IS and other protocols happens without explicit configuration.
Candidates transfer general routing knowledge and skip the platform-specific wiring: interfaces must be created and bound to VLANs, routing protocols must be enabled globally and per-interface, and redistribution is explicit. The fabric's use of IS-IS also leads some to assume IS-IS is the only routing option.
What to do instead
Rehearse the provisioning chain in order: create VLAN, create IP interface, assign address, enable the routing protocol globally, enable it on the interface, then configure redistribution if required. For each routing question, identify which step the scenario has omitted - that is usually the answer.
Choosing 'reboot the switch' or 'disable/enable the port' as the first troubleshooting step for fabric or service problems, instead of checking logs, alarms, IS-IS adjacency state, and I-SID status in a defined order.
Under time pressure, candidates default to generic IT reflexes. Fabric faults usually announce themselves through specific signals - adjacency down, I-SID not in forwarding state, MAC not learned at the expected UNI - and questions test whether the candidate knows which signal to read first.
What to do instead
Memorise a triage ladder: physical/link and MTU, then IS-IS adjacency, then I-SID/service state, then MAC and ARP learning, then routing. For each troubleshooting question, name the layer at which the symptom sits before reading the options, and reject any option that disrupts service before diagnosis.