Aruba ACMP common mistakes
Aruba ACMP · Understand the traps and how to avoid them.
Sizing the WLAN purely on a client-count-per-AP rule of thumb and selecting 80 MHz channels in a dense area, then discovering throughput collapse after go-live.
Vendor datasheets and simple CWNA-style formulas encourage 'clients per AP' thinking; channel width and airtime consumption from video/cloud apps are ignored, so the design passes on paper but fails under real application load.
What to do instead
Model per-SSID throughput and airtime, not just client counts. In high-density areas plan 20/40 MHz on 5 GHz, cap SSIDs per band, define an application mix, and document the capacity assumption for each coverage zone so it can be validated in a post-deployment survey.
Leaving ARM/AirMatch on default settings and assuming the network is 'self-optimizing', never defining a minimum TX power floor or re-surveying after the RF domain settles.
ARM is treated as a set-and-forget feature; candidates forget that power changes alter cell edges, that voice clients need a minimum RSSI/SINR floor, and that a design is only valid once verified against the deployed RF.
What to do instead
Create an RF profile per area with explicit min/max EIRP, scanning and channel settings, bind it to the correct AP group, then verify with 'show ap arm rf-summary' and 'show ap arm history' and compare against the predicted design. Repeat after any AP addition.
Deploying APs that never appear in the controller ('show ap database' empty or flag mismatch) and then debugging RF instead of onboarding.
The AP sits on a VLAN with no DHCP option 43/DNS entry or no route to the controller, or a stale controller IP is hard-coded in the AP, so discovery never completes and the symptom looks like an RF problem.
What to do instead
Verify L2/L3 reachability and required ports first, provide DHCP option 43 or a DNS record for the controller, and confirm with the AP console. Once the AP registers, check 'show ap database long' for flags, IP and assigned AP group before touching RF settings.
Configuring SSIDs, AAA profiles and VAPs at the wrong node in the Mobility Master hierarchy, then assuming the change is live because it was typed without error.
The /mm/node/group/device hierarchy and inheritance rules are unfamiliar; candidates also skip the commit step or edit a device-level override that masks the group-level intent.
What to do instead
Always state which node you are configuring and why, use 'show configuration effective' to prove inheritance, and commit before testing. Prefer group-level configuration so the setting applies consistently to every device in that group.
Building a user role but never actually mapping clients into it, so everyone lands in the default logon/authenticated role and firewall rules appear 'broken'.
The role is defined but no initial role or server-derivation rule references it in the AAA profile; candidates test the role in isolation instead of tracing the assignment path.
What to do instead
Trace the full chain: VAP -> AAA profile -> authentication/derivation rules -> role -> rights. Confirm on a live client with 'show user' and 'show rights ', then test the policy with a known client before declaring the design correct.
Enabling captive portal or 802.1X and blocking the pre-authentication traffic the client needs (DHCP, DNS, portal HTTP/HTTPS, RADIUS), then blaming the client supplicant.
Candidates focus on the post-authentication role and forget the initial role must permit bootstrap traffic; missing server certificates or wrong RADIUS shared secrets produce the same 'nothing works' symptom.
What to do instead
Use the built-in captiveportal role as the initial role, permit DHCP/DNS/portal destinations, verify the server certificate and RADIUS reachability, and follow the exchange with 'show auth-tracebuf' rather than guessing.
Assuming a client roaming between APs on different subnets keeps its address without any L3 mobility configuration, then treating the resulting session drops as a client or roaming bug.
L2 roaming across a single VLAN works by default, so candidates generalize it; they omit the mobility domain, GRE/mobility traffic permission in the VAP, or the correct controller peering.
What to do instead
Decide explicitly between L2-only and L3 roaming, place controllers in the same mobility domain, enable mobility traffic on the VAP, and verify tunnels with 'show datapath tunnel' and client state with 'show datapath user' after a real roam test.
Designing a VRRP/master-redundancy or cluster solution on paper and never performing a controlled failover, database sync check, or license check on the standby.
Redundancy is validated by configuration review, not by behaviour; candidates miss DB synchronization, licensing on the backup, preemption settings, or cluster AP-to-controller assignment.
What to do instead
Confirm synchronization with the relevant database-sync and VRRP status commands, replicate licenses, then run a scheduled failover in a maintenance window and measure AP and client recovery against the documented RTO.
Changing a role, firewall rule or VLAN assignment and expecting connected clients to pick it up, then troubleshooting on stale client state.
Existing sessions keep their assigned role until re-authentication; candidates compare a fresh test client against an unchanged production client and reach contradictory conclusions.
What to do instead
Recall that policy takes effect at authentication. Use CoA/deauth or 'aaa user delete' to force re-authentication, then confirm the new state with 'show user' and the datapath session table before drawing conclusions.
Troubleshooting by randomly toggling settings instead of walking the layers: association, 802.11 auth/assoc, 802.1X, DHCP, role/firewall, then datapath forwarding.
The control plane and datapath are reported by different commands; candidates misread AP database flags, or check a client-table entry that reflects RF state while the actual drop is in the session table or firewall.
What to do instead
Use a fixed ladder: 'show ap database', 'show ap debug client-table', 'show station-table', 'show auth-tracebuf', 'show user', 'show datapath session table'. At each rung confirm the client actually progressed past that stage before moving to the next, and record the evidence.