Client Connectivity, Roaming, and RF Optimization
Roaming mechanics
Roaming is a client decision. Layer 2 roaming stays in the same subnet/VLAN; Layer 3 roaming crosses subnets and requires mobility support so the client keeps its IP. Aruba controllers can form mobility domains/clusters that synchronize client state and tunnel or route traffic to the anchor, while Instant clusters keep clients on the same VC domain. 802.11k provides neighbor reports, 802.11v sends BSS transition requests, and 802.11r enables fast BSS transition with key hierarchies. Not every client supports all three, so design for the weakest common client.
RF optimization
Aruba ARM (and AirMatch in AOS 8) adjusts channel and power; ClientMatch steers clients to better APs and bands and balances load. Band steering moves capable clients to 5 GHz. Airtime fairness protects slower clients from consuming all airtime. Avoid 80 MHz in dense areas; use 20 MHz and more APs. Set minimum data rates to discourage distant, low-rate associations, but do not raise them so high that coverage holes appear.
Traps
802.11k does not initiate the roam by itself; it informs the client. 802.11r reduces reauthentication time but does not fix poor coverage. "Roaming" is not "load balancing"-ClientMatch does both steering and load decisions. A Layer 3 roam without mobility anchoring will break the client's IP.
Rule of thumb
For voice, target about -65 dBm or better and SNR at least 25 dB at the cell edge; overlap cells by roughly 15–20% and keep 5 GHz channels non-adjacent. If clients stick to a far AP, check ClientMatch and minimum basic rates before increasing power.
Monitoring, Management, and Basic Troubleshooting
Monitoring surfaces
ArubaOS CLI exposes the operational state: show ap database (AP inventory and up/down state), show ap active (APs with active radios), show user-table or station-table (clients), show datapath session (flows), show ap arm rf-summary (channel/power), show ap debug radio-stats (RF counters), and show log system. Aruba Central provides dashboards, alerts, Live Events, Client 360, and AP 360 for cloud-managed networks. Spectrum analysis, where the AP supports it, separates non-Wi-Fi interference from Wi-Fi congestion.
Troubleshooting flow
Work outward: physical/link (AP up? PoE? uplink?), RF (channel, power, SNR, retries), configuration (VAP bound to AP group, VLAN present), authentication (RADIUS reachable, correct shared secret, role derivation), and policy (role firewall permits DHCP/DNS). Confirm whether the client associates (802.11), authenticates (802.1X/PSK), gets DHCP, and passes traffic-each failure points to a different layer.
Traps
show ap database does not list clients. A client with an IP can still be blocked by a role policy. High retry counters may indicate interference, not a bad AP. In Central, Client 360 is the client-centric view; do not expect controller CLI output to match cloud dashboards exactly.
Worked example
Users report intermittent drops in one wing. Check show ap arm rf-summary for a channel change or high power; check retries and noise on the serving AP; then check ClientMatch history and the role policy. If retries are high but SNR is good, look for a non-Wi-Fi interferer before replacing the AP.