Extreme Certified Professional - Extreme Switching common mistakes
Extreme Certified Professional - Extreme Switching · Understand the traps and how to avoid them.
Treating EXOS as if it were a Cisco-style IOS with a single flat running configuration, so candidates answer questions about where a setting is stored or how it persists with the wrong mental model.
Most candidates learned switching on IOS or similar platforms where everything lives in one running-config and 'write memory' saves it. EXOS uses a primary/secondary configuration pair, a separate 'config' vs. 'i' (current) view, and explicit save commands, so habits carried over produce wrong answers on save/rollback and on which config is active after reboot.
What to do instead
Learn the EXOS configuration model as a first-class topic: the distinction between the running (current) configuration and the saved primary/secondary configuration, the commands that save and select each, and what happens on reboot if you never saved. Practice on a switch or emulator by changing a VLAN, rebooting without saving, and observing which config is restored.
Assuming a newly cabled switch will pass traffic as soon as it boots, without accounting for default VLAN membership and the default untagged VLAN on access ports.
Candidates focus on physical link lights and forget that EXOS assigns ports to a default VLAN untagged, and that a port's VLAN membership determines whether frames are tagged, untagged, or dropped. Questions about why two hosts on the same switch cannot communicate often hinge on this default, not on cabling.
What to do instead
Memorize the default VLAN behavior on EXOS (default VLAN ID and which ports are members untagged out of the box) and be able to read a 'show vlan' style output to determine per-port tagging. When troubleshooting, always verify port VLAN membership and tagging before assuming a hardware fault.
Configuring an 802.1Q trunk by adding a VLAN to a port but forgetting to make it tagged, so the port sends that VLAN untagged and the neighbor drops or misclassifies the frame.
The mental model of 'add VLAN to port' feels complete, and EXOS commands distinguish tagged versus untagged membership explicitly. Candidates who skip the tagging keyword get a port that is a member but not trunking as intended, and the symptom (one VLAN works, others do not) is easy to misread.
What to do instead
Drill the exact syntax for tagged versus untagged VLAN membership on a port and for removing a VLAN from a port. Build a two-switch lab with two VLANs across a trunk and verify with VLAN show output and a ping in each VLAN before moving on.
Mixing up STP port roles and states, or assuming RSTP behaves like classic STP during topology changes, leading to wrong answers about convergence and which port forwards.
Candidates memorize 'root, designated, blocked' but not the RSTP edge/alternate/backup roles, the difference between discarding/learning/forwarding, or the effect of edge ports and BPDU guard. Exam scenarios about a port that stays in a non-forwarding state usually test these distinctions.
What to do instead
Build a table of STP versus RSTP roles and states and the conditions that produce each. Then reason through small topologies by hand: identify the root bridge by priority then MAC, walk the cost to each switch, and predict each port's role before checking with show commands in a lab.
Configuring a LAG by adding ports on only one side or with mismatched member sets and expecting it to come up, then blaming the switch when the link stays down.
LAG negotiation (LACP) requires both peers to agree on members and parameters. Candidates often configure the local switch, assume the far end auto-negotiates, and do not check whether LACP is active/passive or static, or whether member ports have identical speed, duplex, and VLAN configuration.
What to do instead
Always configure and verify both ends. Know the difference between static (on) and LACP (active/passive) LAG modes, confirm member ports share identical characteristics, and use LAG show commands to confirm the aggregator is up and which ports are members before testing throughput.
Expecting traffic to load-share evenly across LAG members for a single flow, then concluding the LAG is broken when one link carries most of the traffic.
Hashing is per-flow, not per-packet, so a single conversation uses one member link. Candidates who have not internalized hash-based load sharing misdiagnose normal behavior as a fault and pick wrong answers about distribution and hashing inputs.
What to do instead
Learn that LAG load sharing hashes on header fields (such as source/destination MAC, IP, and port depending on configuration) and that a single flow maps to one member. Test with many parallel flows to see distribution and be ready to explain why one flow stays on one link.
Configuring an IP interface on a VLAN but forgetting that the VLAN must exist and have member ports, or assigning overlapping subnets, then wondering why routing fails.
Layer 3 forwarding on a switch depends on Layer 2 constructs: the VLAN interface is only useful if the VLAN exists and is carried on ports. Candidates jump straight to routing commands and skip verifying VLAN existence, port membership, and subnet uniqueness.
What to do instead
Adopt a fixed order: create the VLAN, assign member ports with correct tagging, assign the IP address to the VLAN interface, verify the interface is up, then add a default route or routing protocol. Check the routing table and ARP entries after each step.
Assuming that enabling a routing protocol automatically redistributes connected networks, or forgetting to advertise the VLAN subnets, so remote networks are unreachable.
Candidates configure the protocol process and neighbor relationships but do not verify which prefixes are actually being advertised. Connected interfaces may or may not be included depending on configuration, and a missing network statement or redistribution leaves the routing table incomplete.
What to do instead
After configuring routing, always inspect both the local routing table and the advertised/received routes. Explicitly confirm that each VLAN subnet is present and being advertised, and verify reachability end to end with traceroute rather than assuming neighbor adjacency means full reachability.
Locking yourself out by changing management access (VLAN, IP, or authentication) without a working out-of-band path or a verified fallback, and being unable to answer recovery questions.
Candidates treat management access as a checkbox and change the management VLAN or enable authentication without testing in a second session. Exam scenarios about lost access test whether you understand which changes are disruptive and how to recover.
What to do instead
Before changing management settings, open a second session and confirm the new path works before closing the old one. Know how to recover access (console access, saved alternate config, and the platform's recovery mechanisms) and understand the effect of enabling authentication on existing sessions.
Treating authentication and access control as a single setting, so RADIUS/TACACS+ versus local fallback, and port-based access control versus management login, get conflated in answers.
These are separate planes: device management login versus network access control on edge ports. Candidates who blur them choose answers that apply the right technology to the wrong plane, especially in questions about fallback behavior when the authentication server is unreachable.
What to do instead
Separate the two planes explicitly in notes: management authentication (local users, RADIUS/TACACS+, fallback order) and port access control (802.1X, MAC-based, and what happens to the port when the server is down). For each, state the default behavior and how to verify it with show commands.
Reading a show command output without knowing which counters or fields indicate a real problem, so troubleshooting answers cite the wrong evidence.
Candidates memorize command names but not the meaning of fields such as CRC errors, runts, giants, discards, or STP topology change counters. Without interpreting the evidence, they pick plausible-sounding but incorrect root causes.
What to do instead
For each major show command, learn two or three key fields and what fault they indicate (for example, CRC and alignment errors pointing to cabling or duplex, discards pointing to congestion or policy). Practice describing a symptom, choosing the command, and justifying the conclusion from the output.