Aruba Switching Expert (Written) common mistakes
Aruba Switching Expert (Written) · Understand the traps and how to avoid them.
Treating VSX and VSF as interchangeable clustering technologies, describing both as 'stacking' and attributing a single control plane and unified configuration to VSX.
Both are presented as switch virtualization, and candidates study them in the same block without separating the architectural premise: VSF merges physical switches into one logical entity with one control plane, while VSX keeps two independent control planes synchronized over an ISL with separate management.
What to do instead
Build a two-column comparison table covering control plane count, management IP model, ISL/peer-link role, split-brain handling (VSF auto-split vs VSX keepalive and ISL-up delay), and supported topologies; recite the table until the distinction is automatic.
Applying STP root bridge and port-cost tuning on the assumption that all ports use the legacy 16-bit cost, and failing to recompute costs after changing the spanning tree mode or link speed.
Candidates memorize a single cost table from early study material and do not account for the long/short method distinction and how the configured mode (MSTP/RPVST/PVST) changes default costs, so they predict the wrong root port and blocked port.
What to do instead
For every topology question, first state the spanning tree mode, then state the cost method, then list per-link costs explicitly before electing root and root ports; practice with mixed 1G/10G topologies where the cost method changes the outcome.
Configuring an aggregation group as static when the question calls for dynamic negotiation, or assuming LACP will bundle links whose speed, duplex, or VLAN membership differ.
Candidates focus on the 'add ports to a group' command syntax and overlook the prerequisite matching criteria and the operational difference between static and LACP groups, so they misjudge which links actually come up.
What to do instead
Memorize the member-port compatibility checklist (speed, duplex, MTU, allowed VLANs, native VLAN, flow control) and the LACP operational-key behavior; for each scenario predict which members are eligible before selecting static vs dynamic.
Describing a trunk port as carrying tagged traffic only and forgetting native/untagged VLAN behavior, then misdiagnosing a native VLAN mismatch as a physical or STP fault.
Lab habits often use a single tagged VLAN on trunks, so the untagged frame path and its interaction with PVID on access ports is never exercised, and the mismatch symptom (CDP/LLDP warnings, VLAN hopping, STP inconsistency) is unfamiliar.
What to do instead
Draw the frame path for untagged and tagged frames across access-to-trunk-to-access hops, and explicitly state the PVID and allowed VLAN list at each hop; practice diagnosing native VLAN mismatch from log and show-command output.
Assuming inter-VLAN routing happens automatically once SVIs exist, without verifying that the SVI is up (VLAN active, at least one member port up) and that the downstream host has the correct default gateway.
Candidates conflate 'configured' with 'operational' and skip the state checks that determine whether an SVI can forward, so they choose a routing fix for what is a Layer 2 or host-configuration problem.
What to do instead
Adopt a fixed verification order for every routing scenario: VLAN exists and is active, SVI state and IP, member port up in correct VLAN, ARP entry present, host gateway correct, then routing table and next hop.
Mixing tagged and untagged membership on the same port when the design requires one or the other, and failing to predict the resulting forwarding behavior for each VLAN on that port.
The configuration accepts both permitted modes on a single interface, so candidates assume any combination is valid and do not trace how each frame type is handled on egress.
What to do instead
For each port in a scenario, write the intended role (access, trunk, hybrid) first, then derive the permitted VLAN list and tagging per VLAN from that role; reject configurations that contradict the stated role.
Confusing port-based security features with authentication features, for example expecting port-security to authenticate users or 802.1X to limit MAC counts, and misreading which feature produces a given violation or log message.
The features are taught as a list of 'security things' rather than by mechanism (MAC learning limits vs supplicant authentication vs dynamic VLAN assignment), so the symptom-to-feature mapping is never built.
What to do instead
Map each feature to its trigger, its enforcement point, and its failure action in a table (port security: MAC count/violation action; 802.1X: supplicant/EAP exchange and dynamic authorization; ACL/RADIUS: filtering and authorization), then answer symptom questions from that table.
Treating QoS as a single marking step and ignoring the per-hop behavior chain of classification, marking, queuing, and scheduling when predicting which traffic is dropped or delayed.
Candidates learn DSCP values and trust settings in isolation and do not model how a trust boundary, queue mapping, and scheduler weights combine to determine treatment under congestion.
What to do instead
For every QoS scenario, write the chain explicitly (ingress classification/trust, marking, egress queue assignment, scheduler behavior under congestion) and identify the trust boundary before predicting outcomes.
Assuming IGMP snooping alone delivers multicast to the right ports without verifying querier election, and misdiagnosing multicast flooding as a hardware fault.
Snooping is often enabled by default, so candidates assume group membership is always tracked, overlooking that without an active querier the snooping state ages out and traffic reverts to flooding.
What to do instead
Check querier presence and election first in any multicast scenario, then verify group membership state and the mrouter port; state explicitly what happens when no querier exists before proposing a fix.
Jumping to configuration changes from a single show command instead of following a layered isolation sequence from physical/link state upward through Layer 2, then Layer 3, then services.
Exam questions supply a symptom and a tempting configuration answer, and candidates pattern-match to a familiar command rather than establishing which layer is actually failing.
What to do instead
Practice a fixed triage script (interface state and counters, VLAN and trunk membership, MAC/ARP learning, STP state, routing adjacency and table, then service-specific checks) and require the evidence for each layer before selecting an answer.