Aruba Switching Associate common mistakes
Aruba Switching Associate · Understand the traps and how to avoid them.
Treating the ArubaOS-Switch factory-default VLAN 1 as an ordinary configurable data VLAN and assigning user ports to it, then wondering why untagged traffic and management behave unexpectedly.
Candidates carry over habits from platforms where any VLAN can be used freely, and they miss that VLAN 1 is the default, carries untagged traffic on all ports, and is tied to default management behavior.
What to do instead
Learn the default VLAN 1 state explicitly (all ports untagged members) and practice the standard pattern: create a dedicated data VLAN, move access ports to it with 'untagged vlan X', and keep VLAN 1 for management or remove unintended port memberships.
Configuring a port as tagged for a VLAN on one side of a trunk and untagged on the other, or tagging on the access port instead of the uplink.
The direction of tagging is easy to confuse: candidates remember 'tag the trunk' but apply it to the wrong end or forget that access ports should be untagged members of exactly one VLAN.
What to do instead
Adopt a rule: access port = untagged member of one VLAN; inter-switch link = tagged member of every VLAN that must cross it. Verify with 'show vlans' on both switches and confirm the same VLAN ID appears tagged on both ends.
Assuming a port is forwarding because it is physically up, without checking spanning tree state, and then troubleshooting IP or VLAN problems that are actually STP blocking.
Link LEDs and 'show interfaces' up/up status look healthy, so candidates skip the STP check and chase the wrong layer.
What to do instead
Make 'show spanning-tree' part of the standard verification sequence after any topology change, confirm the port role and state (root/designated, forwarding/blocking), and check that the intended root bridge is actually the root.
Building a multi-switch link aggregation without matching the LACP configuration on both peers, or mixing static trunk and LACP on the two ends.
Candidates configure only the local switch and assume the far end will negotiate, and they do not realize both ends must agree on the aggregation mode and member ports.
What to do instead
Configure LACP (active/passive) or static trunking consistently on both switches, keep member ports identical in speed, duplex, and VLAN membership, and verify with the LACP/trunk status command that the bundle is up and all members are participating.
Leaving a newly created VLAN without an IP address and then expecting the switch to route between VLANs, or assigning the same subnet to two VLANs.
Candidates conflate Layer 2 VLAN creation with Layer 3 interface configuration, and they do not check that each routed VLAN needs its own unique subnet and gateway address.
What to do instead
For each VLAN that must be routed, assign a unique IP address/subnet to the VLAN interface and enable routing if required; verify with 'show ip' and 'show ip route' that connected routes exist for every VLAN.
Mixing up the default gateway on the switch (for management traffic) with the routing configuration for attached hosts, and testing connectivity only from the switch itself.
Ping from the switch can succeed via its management path while hosts on a VLAN still cannot reach other subnets, so candidates conclude routing works when it does not.
What to do instead
Test from a host in each VLAN, confirm the host's default gateway points at the switch's VLAN interface address, and separately confirm the switch's own management default route exists for out-of-band reachability.
Assigning an access port to a VLAN but forgetting to save the configuration, so a reboot reverts the change and the candidate blames the VLAN or the cabling.
Running-config changes take effect immediately, which creates a false sense of completion; candidates skip the explicit save step on ArubaOS-Switch.
What to do instead
End every configuration task with a save (write memory) and verify by comparing running and startup configurations, or reboot a lab device to confirm persistence.
Misreading the port numbering and interface naming when applying commands, configuring the wrong port and then diagnosing a 'broken' link.
ArubaOS-Switch uses slot/port naming conventions and candidates apply commands from memory or from a different platform's syntax without confirming the interface identifier.
What to do instead
Confirm the exact interface name from the interface listing before configuring, use the range syntax deliberately, and re-display the interface configuration afterward to confirm the command landed on the intended port.
Creating a loop while adding a redundant link and assuming spanning tree will silently handle it, without verifying that STP is enabled and converged on all switches.
Candidates trust STP as automatic and never check that it is enabled, that all switches share compatible STP settings, or that the topology has actually converged before testing.
What to do instead
Verify STP is enabled on every switch in the path, confirm consistent STP mode and priority design, check the root bridge election, and confirm one end of the redundant link is blocking before declaring the topology stable.
Applying security features such as port security or DHCP snooping globally without understanding the trust direction, then locking out legitimate clients or the uplink.
Candidates enable the feature and move on, missing that trusted ports, MAC limits, and violation actions must be planned per port, and that a wrong trust setting breaks DHCP for whole VLANs.
What to do instead
Before enabling, identify trusted uplink/DHCP server ports, set explicit MAC limits and violation actions on access ports, then verify client DHCP and connectivity from an access port and confirm the intended violation behavior in a lab.