Aruba ACSA common mistakes
Aruba ACSA · Understand the traps and how to avoid them.
Applying ArubaOS-Switch (ProVision/Comware-style) syntax such as 'vlan 10 untagged 1-24' or 'trunk 1-4 trk1 lacp' when the question stem specifies an ArubaOS-CX switch, and vice versa.
Candidates study one CLI family and pattern-match on keywords, missing the platform cue in the stem; the two operating systems differ in VLAN membership, trunking, and LAG commands.
What to do instead
Before answering, underline the platform named in the stem. Drill the CX equivalents: 'vlan 10 / interface 1/1/1 / no routing / vlan access 10' and 'interface lag 1 / lacp mode active'. Build a two-column cheat sheet mapping each concept to both CLIs and self-quiz on it.
Treating a VLAN as automatically permitted on an uplink because it exists in the VLAN database, or assuming a trunk carries all VLANs by default on ArubaOS-CX.
Mental models carried over from other vendors where a trunk is 'all VLANs unless pruned'; on CX, a VLAN must be explicitly allowed on the trunk member and the native VLAN must be configured for untagged traffic.
What to do instead
Memorize the rule: allowed VLAN list is explicit per interface; native/untagged VLAN is a separate setting. When a stem shows a missing VLAN end-to-end, check the allowed list on every hop before looking at STP or routing.
Confusing an access port, a trunk port, and an SVI when troubleshooting 'host cannot reach its gateway' scenarios, and assigning an IP to a physical port instead of a VLAN interface.
Layer 2 and Layer 3 configuration are visually similar; candidates forget that on CX the gateway lives on 'interface vlan X' and the physical port stays a Layer 2 member.
What to do instead
Practice the full chain in order: port is member of VLAN (access or allowed), VLAN interface exists, VLAN interface has IP and is up, host default gateway matches. Verify with 'show vlan', 'show interface vlan', 'show ip interface brief'.
Assuming RSTP/MSTP behaves identically to classic STP for convergence and port roles, or misidentifying the root bridge and root port from a topology description.
Candidates memorize 'STP blocks loops' without internalizing port states, roles, and the election criteria (lowest bridge ID, then lowest path cost, then lowest port priority/ID).
What to do instead
Rehearse root election step by step using priority and MAC, then trace the lowest-cost path to the root for each switch. Learn RSTP's discarding/learning/forwarding states and that edge/portfast ports skip listening.
Mismatching LACP modes (active vs passive) or static vs dynamic aggregation, and expecting a LAG to come up when one side is passive and the other is also passive.
The mode names are symmetric-looking; candidates forget that at least one side must be active, and that static trunks bypass LACP negotiation entirely.
What to do instead
Memorize the matrix: active+active and active+passive form a LAG; passive+passive does not; static+static forms without LACP. Also verify member ports share the same speed, duplex, and VLAN configuration before blaming LACP.
Misreading a routing table entry and choosing the wrong next hop, especially when a more specific prefix, a static route, or a connected route competes with a default route.
Candidates default to 'the default route wins' or pick the lowest metric without applying longest-prefix-match first, and confuse administrative distance with metric.
What to do instead
Apply the order every time: longest prefix match first, then lowest administrative distance among equal prefixes, then lowest metric. Practice with tables that mix /24, /16, static, connected, and default entries until the sequence is automatic.
Forgetting that inter-VLAN routing requires either an SVI per VLAN on a Layer 3 switch or a router-on-a-stick subinterface, and then blaming firewall or ACL for the failure.
The Layer 2 configuration looks correct, so candidates assume routing 'just works'; they skip verifying that each VLAN has a Layer 3 interface and that hosts point to the correct gateway.
What to do instead
For any inter-VLAN scenario, explicitly list: SVI for each VLAN, IP addressing, host gateways, and whether 'ip routing' is enabled. Confirm with 'show ip route' that both subnets appear as connected.
Treating DHCP relay as automatic: assuming a DHCP server on another subnet will answer clients without an 'ip helper-address' on the client VLAN interface.
DHCP broadcast does not cross routers by default; candidates focus on the server scope and miss the relay configuration on the gateway.
What to do instead
When a stem shows clients in one VLAN and a server in another, check the SVI for 'ip helper-address '. Remember the relay forwards to the server and the reply is unicast back to the relay agent.
Assuming a port-security or 802.1X configuration will block traffic as soon as it is applied, without accounting for the authentication state, guest VLAN, or the difference between monitor and enforce modes.
Candidates learn the commands but not the operational states (unauthorized, authorized, guest) and forget that misconfigured RADIUS or a missing client certificate leaves the port in an unexpected state.
What to do instead
Trace the port state machine: unauthenticated -> guest VLAN or blocked -> authenticated -> authorized VLAN. Verify RADIUS reachability and shared secret, and confirm whether the port is in monitor (log only) or enforce mode before predicting the outcome.
Ignoring management-plane and configuration-management details: assuming a configuration change is saved automatically, or that a firmware/configuration file transfer uses the wrong protocol or direction.
Candidates focus on the feature being configured and forget operational housekeeping such as 'write memory'/'copy running-config startup-config', checkpoint/rollback, and which transfer method (TFTP/SFTP/USB) the stem specifies.
What to do instead
For any management question, ask three things: is the change saved, is there a rollback/checkpoint path, and what is the transfer source versus destination. Memorize the save command for each platform and the difference between running and startup configuration.