Aruba ACSP common mistakes
Aruba ACSP · Understand the traps and how to avoid them.
Choosing a VSF or VSX topology from a diagram and deploying it without first checking that every member runs the same AOS-CX firmware branch and that the model supports the intended conductor or primary role.
Candidates focus on port counts and cabling, then assume stacking and multi-chassis features are version-independent. Mixed firmware or unsupported member roles cause failed formations and partial forwarding that look like cabling faults.
What to do instead
Before deployment, read the release notes for supported VSF/VSX topologies and mixed-member rules, standardize firmware across all members, and verify formation with show vsf and show vsx status before attaching access devices.
Leaving the trunk native VLAN at its default and assuming it matches the untagged VLAN used by the connected access switch or server, then troubleshooting an intermittent management or DHCP failure.
Trunk ports carry one untagged VLAN as the native/PVID. A mismatch silently places untagged frames in the wrong VLAN, so the link appears up but hosts receive no address or lose management reachability.
What to do instead
Explicitly set vlan trunk native and vlan trunk allowed on both ends, verify the PVID and allowed list with show vlan port, and avoid using a production data VLAN as native.
Configuring MSTP region name, revision, and instance-to-VLAN mappings only on the core switches, while edge switches keep defaults, and expecting one loop-free region.
MSTP builds regions only when the name, revision, and VLAN mapping match exactly. A mismatch creates separate regions, so the intended root and blocking topology never form.
What to do instead
Deploy a region template to all switches, verify with show spanning-tree mst-config and show spanning-tree summary, and confirm the same root bridge and per-instance state on every switch.
Bringing up a multi-chassis LAG with LACP active on one side and a static trunk on the peer, or adding member links without matching trunk allowed VLANs on every member.
Candidates concentrate on the logical bundle and ignore per-member and per-peer consistency. LACP mode mismatch prevents the bundle, and VLAN mismatches cause silent drops on some member links.
What to do instead
Configure matching LACP modes and rates on both peers, apply identical trunk settings to every member, and verify with show lacp interfaces, show lag, and per-member VLAN checks before carrying traffic.
Forming an OSPF adjacency over an interface with an MTU mismatch or wrong network type, then assuming the area is misconfigured when neighbors remain stuck in EXSTART or EXCHANGE.
OSPF hello timers are often memorized, but MTU and network-type mismatches prevent database exchange. The neighbor state can look like an area or authentication problem when it is an interface parameter problem.
What to do instead
Check show ip ospf neighbors, interface MTU, network type, area, and authentication. Match MTU on both sides or correct the network type, then confirm FULL adjacency before changing area design.
Running the VSX interswitch link and keepalive over the same physical path or VLAN, and bringing up the peer before confirming the ISL LAG is fully operational.
VSX depends on a reliable ISL for data and a separate keepalive path for split-brain detection. Candidates often treat both as one link, so a single failure causes both data-plane and consistency failures.
What to do instead
Use a dedicated ISL LAG and an independent keepalive path or subnet. Verify with show vsx status, show vsx config-consistency, and show lag before enabling dual-active forwarding.
Applying an ACL to the wrong interface direction or VRF, then concluding the ACL is broken because hit counters remain at zero while unwanted traffic still passes.
ACLs are direction- and VRF-specific. Candidates write correct match rules but attach them outbound or to the wrong context, so transit traffic never hits the intended policy.
What to do instead
Apply the ACL inbound on the ingress interface or VLAN, confirm the attachment and VRF with show running-config interface, and validate with show access-list hitcounts and controlled test traffic.
Testing 802.1X after configuring only the RADIUS server IP, without matching the shared secret, NAS-ID, or port-access role, and without checking fail-through behavior.
Candidates concentrate on switch-side dot1x commands and overlook RADIUS identity and authorization. A secret mismatch or missing role makes clients fail authentication even though the port is configured.
What to do instead
Verify show radius and AAA reachability, match the shared secret on both sides, configure port-access roles and fail-through deliberately, and inspect results with show port-access clients.
Sending REST API requests with a username and password on every call, or using the wrong Content-Type, and treating the resulting 401 or 415 response as a platform outage.
AOS-CX REST requires a login session and CSRF handling. Candidates test with a raw GET and omit the session cookie or required headers, then misdiagnose normal authentication rejection.
What to do instead
POST to the versioned login endpoint, retain the session cookie and CSRF token, include the correct Content-Type and Accept headers, and confirm the API version path before automating changes.
Troubleshooting by changing configuration and rebooting first, without capturing show tech, event logs, interface counters, and a baseline before the change.
Reboots erase evidence and configuration edits remove the failing state. Candidates then cannot distinguish a real hardware or protocol fault from the effect of their own change.
What to do instead
Capture show tech, show events, show interface, and relevant protocol state before any change. Compare against a known-good baseline, isolate one variable at a time, and document each test.