Aruba Switching Professional common mistakes
Aruba Switching Professional · Understand the traps and how to avoid them.
Treating a trunk port as automatically forwarding all VLANs and assuming untagged frames are carried, then misdiagnosing a connectivity failure as a routing problem.
Candidates conflate 'trunk' with 'all VLANs allowed' and forget that native/untagged VLAN behavior and the allowed-VLAN list are separate configuration decisions; they also skip verifying which VLAN a frame is actually tagged with.
What to do instead
Before troubleshooting Layer 3, verify per-port VLAN membership and tagging: confirm the allowed VLAN list, the native VLAN, and whether the attached device expects tagged or untagged frames. Practice reading a VLAN/port table and predicting frame treatment.
Selecting the spanning-tree root by lowest bridge ID without checking priority configuration, and failing to predict which ports become root/designated/alternate after a topology change.
Candidates memorize 'lowest bridge ID wins' but do not apply the tie-break sequence (priority, then MAC) or the port role/state rules under load; they also forget that changing priority on a non-root bridge does not move the root unless it becomes lowest.
What to do instead
Work through port-role determination step by step for small topologies: root election, root port selection (lowest path cost, then neighbor bridge ID, then port ID), then designated/alternate. Drill the difference between RSTP and classic STP state names and convergence behavior.
Assuming a link-aggregation group will come up simply because both sides are configured, without checking that member ports share the same speed, duplex, VLAN membership, and that the hashing/negotiation mode matches on both ends.
Candidates focus on the aggregate interface configuration and overlook per-member physical and logical consistency requirements, plus LACP vs static mode mismatches.
What to do instead
Build a pre-check list for any LAG: member port speed/duplex, allowed VLANs, native VLAN, LACP active/passive vs static, and MTU. Verify with show commands that members are actually bundled rather than individually forwarding.
Confusing 2.4 GHz and 5 GHz channel plans and recommending overlapping or non-standard channels, or assuming higher transmit power always improves client experience.
Candidates memorize channel numbers without mapping them to actual frequency overlap, and they equate more power with better coverage while ignoring co-channel interference and client transmit-power asymmetry.
What to do instead
Memorize the non-overlapping 2.4 GHz set and the 5 GHz channel/UNII structure, and reason about cell sizing: match power to coverage goals, account for the client's lower transmit power, and prefer channel reuse planning over maximum power.
Diagnosing a wireless client association problem as an RF coverage issue when the actual cause is an authentication or encryption mismatch (PSK vs 802.1X, or mismatched security profile).
Candidates jump to RF causes because 'wireless problem' triggers a coverage reflex; they skip the association/authentication phase distinction in the client state machine.
What to do instead
Triage in order: is the client seeing the SSID, associating, authenticating, then getting an IP? Use client state and authentication logs to localize the failure before touching RF parameters.
Treating a port-security violation or a DHCP snooping/ARP inspection drop as a physical or routing fault, then changing unrelated configuration.
Candidates do not connect security feature enforcement to the symptoms it produces (port disabled, frames dropped, client without an IP), so they misattribute the outage.
What to do instead
Learn the observable symptom of each security feature: port-security violation actions, DHCP snooping trusted vs untrusted ports, dynamic ARP inspection trust. When a client has no address or traffic is silently dropped, check these features first.
Assuming 802.1X is configured correctly end-to-end without verifying the supplicant, authenticator port control, and RADIUS reachability as separate links in the chain.
Candidates see 802.1X configured on the switch and stop there, forgetting the supplicant credentials, the port-control mode (auto/force-authorized/force-unauthorized), and the RADIUS server path each can independently break access.
What to do instead
Trace the 802.1X chain explicitly: supplicant identity and method, switch port-control setting, RADIUS reachability and shared secret, and authorization result. Practice identifying which link fails from authentication logs.
Troubleshooting a management-access failure by checking data-plane connectivity first, without confirming the management VLAN, default gateway, and access method (in-band vs out-of-band) are reachable.
Candidates conflate 'the network works' with 'I can manage the device', and they overlook that management traffic may ride a dedicated VLAN or interface with its own addressing and gateway requirements.
What to do instead
Separate the management plane from the data plane in every scenario: confirm management interface/VLAN addressing, gateway, and allowed management protocols before assuming a device fault. Verify from the correct source subnet.
Ignoring the effect of a routing adjacency or first-hop redundancy state when diagnosing an intermittent connectivity complaint, and only checking interface up/down status.
Candidates equate 'link up' with 'path working' and skip verifying neighbor adjacencies, route presence, and which gateway is active in a redundant pair.
What to do instead
For intermittent issues, verify control-plane state: routing neighbor status, route table entries for the destination, and first-hop redundancy active/standby roles. Confirm the client's gateway matches the currently active device.
Reading a monitoring dashboard or log without correlating timestamps and severity, and treating a single alert as root cause rather than evidence.
Candidates answer based on the loudest symptom in a log excerpt, ignoring event ordering, severity levels, and whether the alert is a cause or a downstream effect.
What to do instead
Practice timeline reconstruction: order events by timestamp, classify severity, and separate initiating events from consequences. Ask what changed immediately before the first anomaly before proposing a fix.