Aruba Wireless Interview Q&A — 39 questions a panel actually asks

This is the classic Aruba opener. A Campus AP (CAP) is controller-dependent: it builds a GRE/IPsec tunnel to a controller or gateway on the LAN and pulls all config and policy from it. A Remote AP (RAP) is the same idea over the internet — it forms an IPsec tunnel back to a controller/VPNC so a home or branch user gets the corporate SSID and policy securely across an untrusted link.

An Instant AP (IAP) is controller-less: a group of IAPs elects one as the Virtual Controller, which pushes config to the rest, so they serve Wi-Fi with no separate controller. Quick line for the panel: CAP = on-prem tunnel, RAP = CAP over the internet via IPsec, IAP = standalone with a Virtual Controller. An AP can be converted between CAP and IAP by loading the matching image and re-provisioning.

The Mobility Conductor (MC, formerly Master Controller) is the configuration and management brain in AOS-8. It holds the hierarchical config, pushes templates and licences, and runs centralised services like AirMatch and centralised WIDS correlation. It does not terminate client traffic.

The Mobility Controller is the workhorse: APs terminate their GRE tunnels on it, it does client authentication, applies the stateful firewall (PEF) and forwards user data. So one device is the conductor of config, the other is the data plane. A small site can collapse both, but in any real campus they are separate boxes (e.g. a 7200-series controller).

The big shift is the management plane moves to the cloud. In AOS-8 the Conductor + AirWave talk to devices over PAPI, AMON, SNMP and IPsec. In AOS-10 each gateway and AP talks to Aruba Central over HTTPS on TCP 443 only — far fewer firewall holes.

The controller becomes a gateway, deployed as a cluster instead of master-local pairs. Config moves from the on-prem hierarchy to Central groups. PAPI still runs, but now mostly between the gateways for cluster formation. A headline win is live-upgrade across the cluster with no client outage, which classic AOS-8 master-local could not do cleanly.

Tunnel mode: the AP wraps client traffic in GRE and sends it to the controller/gateway, where the VLAN, firewall and role live. Use it for full central policy, seamless roaming and consistent segmentation — the default for campus.

Bridge mode: the AP drops traffic straight onto the local wired VLAN, no controller in the path. Use it at tiny remote sites or where a gateway is overkill — common with Instant APs.

Mixed (split-tunnel): per-SSID or per-role you tunnel some traffic and bridge the rest — e.g. tunnel corporate to the data centre but bridge guest/Internet locally at a branch to save WAN bandwidth. Choice is driven by where you want policy enforced and how much you trust the local LAN.

A Campus AP (CAP) is controller-dependent: it boots, finds a controller/gateway, builds a tunnel and gets all its config and policy from there. No controller, no service (unless in bridge).

An Instant AP (IAP) is self-contained: a cluster of IAPs elects a Virtual Controller (VC) among themselves, so they run Wi-Fi with no separate controller. Historically these were different images, but in AOS-10 the same AP can operate controller-managed or Central-managed — the line has blurred. Interview shorthand: CAP leans on a controller, IAP is standalone with a virtual controller.

The AP boots, gets an IP via DHCP, then hunts for its controller/Central in a defined order:

1. Static — if master/ap-master is provisioned, it uses that. 2. ADP — Aruba Discovery Protocol multicast/broadcast on the local subnet. 3. DHCP Option 43 — vendor-specific option carrying the controller IP (with the right VCI string). 4. DNS — it resolves aruba-master (and for Central, the activation/Central FQDN).

Once it finds the controller it does an IPsec/PAPI handshake, downloads its image and config, and builds the GRE tunnel. So if an AP is missing, you check L3 reachability, then which discovery method should work, then whether Option 43 or DNS is actually populated. Layer-2 adjacency makes ADP enough; across subnets you almost always need Option 43 or DNS.

In a cluster, APs and clients are distributed across gateway nodes, and each client has a designated active gateway (A-AAC/A-UAC) plus a standby (S-AAC/S-UAC) pre-assigned. State — including the client's authentication and firewall session — is synced to the standby ahead of time.

When a node fails, clients fail over to their standby without re-authenticating, so a voice call or RDP session survives. The cluster also load-balances clients across nodes (cluster load balancing) and supports live-upgrade, draining one node at a time. The user VLAN is stretched across all cluster members so the IP doesn't change on failover. That hitless failover is the whole point versus the older active/standby controller pair.

That is a textbook AOS-10 + Aruba Central fit. AOS-10 devices reach Central over HTTPS / TCP 443 for management, so the security team opens a single outbound 443 to the Central cloud — no inbound, no IPsec/SNMP/AMON mesh like AOS-8 needed.

For a Pune bank that already has strict egress rules, this is a selling point: data forwarding stays on-prem on the gateway cluster, only telemetry and config ride 443 to Central. You'd still confirm reachability to the Central activation and device FQDNs, and that TLS inspection isn't breaking the cert pinning. One clean answer: AOS-10, port 443 outbound to Central.

AirWave is the on-prem, multi-vendor network management system that pairs with classic AOS-8. It does monitoring, reporting, historical trending, alerting and VisualRF heatmaps, but config still largely lives on the Mobility Conductor — AirWave watches and reports.

Aruba Central is the cloud-native management plane for AOS-10. It is the single pane for config, monitoring, AIOps/AI Insights and analytics across APs, gateways and CX switches, reached over HTTPS. So the mapping the panel wants: AOS-8 with AirWave (on-prem, multi-vendor monitoring); AOS-10 with Central (cloud, config + AIOps). Central On-Prem exists for customers who need cloud features without public cloud. Knowing which platform goes with which OS is a frequent screening check.

Config in Aruba is scoped through a hierarchy. A Virtual AP (VAP) profile ties one SSID to its SSID profile (encryption, band) and an AAA profile (auth/role). VAPs are bound to an AP-Group, which also carries the RF profile and regulatory domain, and every AP is assigned to exactly one AP-Group. AP-Name settings allow per-AP overrides on top.

So to add an SSID to just one building, you create the VAP for that SSID and attach it only to that building's AP-Group — the other groups never see it. At a Bengaluru campus you'd have, say, blr-tower-a and blr-tower-b AP-Groups; pushing a pilot SSID to blr-tower-a alone keeps the rollout contained. That group-scoped model is why interviewers probe it — it's how you do safe, partial changes.

Panels open or close with this. 802.11n = Wi-Fi 4 (2.4 + 5 GHz, MIMO, up to 40 MHz). 802.11ac = Wi-Fi 5 (5 GHz only, up to 80/160 MHz, downlink MU-MIMO). 802.11ax = Wi-Fi 6 (2.4 + 5 GHz) and Wi-Fi 6E = Wi-Fi 6 extended into the new 6 GHz band. 802.11be = Wi-Fi 7 (adds 320 MHz channels and Multi-Link Operation).

The headline Wi-Fi 6 feature is OFDMA: it splits a channel into resource units so the AP serves several clients in one transmission instead of one-at-a-time, which slashes latency in dense rooms. The 2.4 GHz band has only three non-overlapping channels (1/6/11); 5 GHz adds many more (some need DFS); 6 GHz gives wide, clean spectrum with no legacy clutter. Channel width is a trade: 80/160 MHz means more speed but fewer non-overlapping channels, so you don't blanket wide channels in dense areas.

ARM (Adaptive Radio Management) is the per-AP RF engine. Each AP continuously scans, then dynamically picks its best channel and transmit power to avoid co-channel interference and cover holes left by a failed neighbour. ARM also handles features like band steering, airtime fairness and spectrum load balancing.

The key word is local and reactive: ARM reacts to the RF it sees right now, AP by AP. It is the classic AOS-8 mechanism and still exists, but in modern deployments channel/power planning is handled by AirMatch instead.

ARM optimises each AP independently and reactively, which can cause channel ping-pong as neighbours keep reacting to each other. AirMatch is centralised and predictive: it collects RF data from every AP every 5 minutes over a 24-hour window, then the Conductor (or Central) computes one network-wide, dual-band channel-and-power plan and deploys it once a day at a quiet hour.

So AirMatch sees the whole estate, not one AP's view, which kills the oscillation and gives a stable, holistic plan. Rule of thumb for interviews: ARM = reactive, per-AP; AirMatch = predictive, network-wide, runs daily. AirMatch is the default channel/power planner from AOS-8.x onward.

ARM and AirMatch optimise the AP radios; neither moves a client. ClientMatch works at the client level. It monitors each client's RSSI, SNR and data rate, and when a device is stuck on a distant AP — a sticky client — ClientMatch steers it to a closer AP or a better band.

It uses 802.11v BSS Transition where the client supports it, and de-auth-based steering as a fallback. Classic example: a laptop walks from one wing to another at a Bangalore ITES but clings to the old AP at -78 dBm; ClientMatch nudges it onto the nearer 5 GHz radio so throughput recovers. So the trio is: AirMatch plans radios, ARM tunes locally, ClientMatch moves clients.

Band steering nudges dual-band capable clients off the crowded, slower 2.4 GHz band onto 5 GHz (or 6 GHz on Wi-Fi 6E). The AP does this by delaying or withholding probe responses on 2.4 GHz so the client prefers 5 GHz.

You use it because 2.4 GHz has only three non-overlapping channels and heavy interference (microwaves, BLE, legacy gear), while 5/6 GHz has far more spectrum and width. Net effect: better throughput and less airtime contention. The caution: aggressive steering can hurt clients that genuinely have poor 5 GHz coverage, so it pairs with good ARM/AirMatch power planning.

Wi-Fi is half-duplex shared airtime. A legacy client transmitting at, say, 6 Mbps holds the channel far longer to move the same data than a fast client at 600 Mbps. Without fairness, that slow device steals airtime and drags every other client on the AP down — the classic one old phone kills the room problem.

Airtime fairness allocates equal time rather than equal packets, so each client gets a fair slice of the channel and one slow device can't monopolise it. Aruba offers modes like default-access, fair-access and preferred-access. It's a favourite L2 question because it shows you understand that Wi-Fi capacity is about time, not raw rate.

They split the roaming job. 802.11k (neighbour reports) tells the client which APs are nearby so it doesn't waste time scanning every channel. 802.11v (BSS Transition Management) lets the network suggest a better AP to the client — the steering hint ClientMatch uses. Neither shortcuts authentication.

802.11r (Fast BSS Transition / FT) is the one that actually speeds the roam: it pre-distributes key material so the client skips the full 802.1X EAP exchange and four-way handshake at the new AP, cutting roam time from hundreds of ms to ~50 ms or less. So for latency-sensitive apps (voice, scanners) you want 11r; 11k/11v just help the client pick the target faster.

Without 802.11r, each roam would normally redo full EAP — too slow for scanners. Your fallback is OKC (Opportunistic Key Caching) / PMK caching: the controller caches the client's PMK, so on the next roam the client and AP reuse the cached key and skip the full 802.1X exchange — much like 11r but without needing client FT support, since OKC works on many legacy supplicants.

Concretely: enable OKC/opportunistic key caching on the SSID, make sure all target APs share the same mobility domain/controller so the PMK is reachable, and verify scanner firmware supports it. If even OKC isn't viable, consider MPSK or PSK for that scanner SSID to remove EAP from the roam entirely. Order of preference: 11r → OKC/PMK caching → PSK/MPSK.

A VLAN is just an L2 broadcast domain — where the client's IP lives. A user role is the policy identity: it bundles the stateful firewall ACLs, bandwidth contracts, captive-portal settings and re-auth timers that apply to that client.

Two clients can sit in the same VLAN but have very different roles (e.g. employee vs contractor), so role is the real security boundary, not the VLAN. Aruba's model is role-first: the firewall rules follow the role wherever the client roams. Saying VLAN = address, role = permissions shows you get the Aruba way of thinking.

802.1X (EAP): per-user credentials/certs against RADIUS — corporate SSID for laptops at an Infosys campus. Strongest, but every device needs a supplicant.

MPSK (Multi Pre-Shared Key): many unique passphrases on one SSID, each mapped to a role/VLAN, validated via RADIUS/ClearPass. Built for headless IoT — printers, cameras, BMS — that can't do 802.1X.

Captive Portal: redirect to a web login/click-through — guest Wi-Fi at a Chennai ITES lobby. Identifies the person, not the device security.

PSK: one shared passphrase for everyone — fine for a tiny office, weak at scale because the secret leaks. So the ladder runs PSK (simple) → MPSK (IoT scale) → Captive Portal (guest) → 802.1X (corporate).

First the client may sit in a pre-authentication / logon role with almost no access (only DHCP, DNS, RADIUS allowed). It then runs 802.1X to RADIUS/ClearPass. On success, the role is decided by, in order: a RADIUS attribute from the server — typically Aruba-User-Role (VSA) or a Filter-Id — which directly names the role.

If RADIUS sends a VLAN instead, the controller derives the role from a VLAN-to-role or server-derivation rule. Failing all that, the SSID's default role applies. So the cleanest design is: ClearPass evaluates the device/user and returns Aruba-User-Role = employee, and the controller applies that role's firewall on the spot. Always confirm the VSA dictionary is loaded on the RADIUS side.

With one shared PSK, every IoT device uses the same passphrase, so a leaked key compromises the whole SSID and you can't tell devices apart. MPSK issues a unique passphrase per device (or per device type) on a single SSID; the key is validated by ClearPass/RADIUS, which returns a role and VLAN per key.

So a camera and a printer share an SSID but land in different roles with different firewall rules, and revoking one device just removes its key — no estate-wide re-key. MPSK Local even lets the AP/cluster validate keys without RADIUS for smaller sites. For a Hyderabad campus with hundreds of headless devices that can't run 802.1X, MPSK is the pragmatic middle ground.

Both are 802.1X EAP methods, but the trust model differs. EAP-TLS uses mutual certificate authentication — the server presents a cert and so does the client, so there are no passwords on the wire at all. It is the most secure option and is phishing-resistant, but it needs a PKI to issue and manage client certificates.

PEAP (and EAP-TTLS) build a TLS tunnel using only a server certificate, then carry an inner username/password (PEAP-MSCHAPv2). It's far easier to roll out — no client certs — but credentials can be phished or stolen, and it relies on the client validating the server cert properly. So the panel answer: EAP-TLS for the strongest security where you have PKI; PEAP for quick deployment with passwords. ClearPass commonly runs both, steering managed devices to EAP-TLS and BYOD to PEAP.

Dynamic segmentation extends the same role-based policy from Wi-Fi onto the wired edge, so a device gets the same treatment whether it plugs in or associates. ClearPass authenticates the endpoint and returns a role; an Aruba CX switch can then either enforce that role locally or tunnel the traffic to a gateway (PAPI/GRE) where the centralised firewall and VLAN live — the same gateway your APs use.

The win is a single policy model and consistent micro-segmentation across wired and wireless — an IP camera on a switch port lands in the exact iot-cam role and ACLs you'd give it on Wi-Fi, with no manual port VLANs. It's the Aruba ESP answer to segment everything from one identity, and it's a strong L3 talking point.

UBT is the wired mechanism behind dynamic segmentation. A device plugs into an Aruba CX switch and authenticates via 802.1X or MAC-auth to ClearPass, which returns a user role. Instead of the switch dropping that device onto a local VLAN, UBT builds a GRE tunnel from the switch port to a gateway and tunnels the client's traffic there, so the gateway's PEF firewall applies the exact same role policy a Wi-Fi client would get.

Why it matters in AOS-10: the gateway becomes one enforcement point for both wired and wireless, so an IoT camera on a switch port and a laptop on Wi-Fi land in identical roles with identical micro-segmentation — no hand-built port VLANs or ACLs per closet. UBT supports a primary and secondary gateway for resilience. It's a fast-rising JD skill because it's the practical answer to segment everything from one identity.

Trace it end to end. On the controller/gateway run show user-table and show auth-tracebuf to see what role the client actually got and whether RADIUS returned Accept. Then look at the returned attributes — is Aruba-User-Role populated, and does that role name exist spelled identically on the controller? A missing or mistyped role silently falls back to the default.

On the ClearPass side, use Access Tracker to see which service and enforcement policy matched and what role-mapping/enforcement profile fired. Common root causes: wrong service ordering, an attribute the controller's VSA dictionary doesn't know, or a derivation rule overriding the VSA. Fix is usually aligning the enforcement profile's role name with the controller and confirming attribute order. So: controller user-table → auth-tracebuf → ClearPass Access Tracker → enforcement profile.

Create a dedicated guest SSID with Captive Portal auth, ideally backed by ClearPass Guest for sponsor-approval and self-registration. New clients land in a guest-logon role that only permits DHCP, DNS and the captive-portal redirect. After login they move to a guest role.

The guest role's firewall denies all RFC1918 corporate subnets (10.x, 172.16/12, 192.168.x) and permits only Internet, with a bandwidth contract to stop abuse. Put guests on an isolated VLAN, ideally with a local Internet break-out (split-tunnel) so guest traffic never touches the corporate core. Add client isolation so guests can't see each other. That gives sponsor control + hard segmentation in one role.

WIDS (Wireless Intrusion Detection System) only detects and alerts — it classifies APs as valid, rogue, interfering or neighbour, and flags attacks like deauth floods, spoofed SSIDs or honeypots. It watches; it doesn't act.

WIPS (Wireless Intrusion Prevention System) adds the prevention: once something is classified rogue, WIPS can contain it — tarpit clients or send spoofed deauths so devices can't associate to the rogue. Aruba runs both, with APs scanning off-channel or dedicated Air Monitors doing full-time scanning. Interview line: WIDS sees, WIPS stops.

The system first asks: is this unknown AP plugged into MY wired network? Aruba correlates the wireless BSSID with wired-side MACs (it sees the rogue's traffic on the LAN). If the unknown AP is on your wire, it's a true rogue — a real bridge into your network — versus a mere interfering/neighbour AP (the café next door), which you leave alone.

Containment then disrupts the rogue: the AP/Air Monitor sends spoofed deauthentication/disassociation frames (and can tarpit clients) so no one can use it, buying time to physically find and unplug it. Caution: only contain APs you've positively confirmed are yours — deauthing a neighbour's AP is illegal interference. So classification first, containment only on wired-confirmed rogues.

PEF (Policy Enforcement Firewall) is Aruba's licensed, identity-aware stateful firewall built into the controller/gateway. Every client is in a role, and the role carries an ordered ACL of permit/deny rules matched on source/dest, service/port and even application.

Because it's stateful, return traffic for an allowed session is automatically permitted, and because policy follows the role not the IP, the rules travel with the user as they roam. So instead of giant subnet ACLs on a core switch, you write contractors can reach the print server and Internet, nothing else once, and it applies everywhere. PEF is what makes Aruba's role model actually enforceable in the data path.

AppRF is Aruba's deep packet inspection (DPI) engine. It identifies traffic by application and category — Zoom, YouTube, Office 365, BitTorrent — not just port, and feeds visibility dashboards in Central/AirWave.

In a role you use it to write application-aware firewall rules and QoS: prioritise Teams/Zoom for a corporate role, throttle or block streaming on a guest role, or deny peer-to-peer entirely. Example: a Chennai ITES caps Netflix on guest while giving Microsoft 365 priority marking on employee. So AppRF turns the role firewall from port-based into app-based, which is what auditors and capacity planners actually ask for.

WPA3-Personal replaces the PSK handshake with SAE (Simultaneous Authentication of Equals), which kills offline dictionary attacks and gives forward secrecy — so a captured handshake can't be brute-forced like WPA2-PSK. Use it for home/small-office PSK SSIDs.

WPA3-Enterprise is 802.1X with stronger crypto, plus an optional 192-bit mode (CNSA suite) for government/defence-grade requirements. Use it for corporate.

OWE (Opportunistic Wireless Encryption / Enhanced Open) encrypts open networks — no password, but each client gets an individual encrypted session, so guest Wi-Fi is no longer plaintext. Use OWE for guest/public SSIDs. Real estates often run a transition mode so WPA2-only clients still connect. Summary: SAE for personal, 802.1X for enterprise, OWE to encrypt open guest.

mDNS/Bonjour and DLNA are link-local — discovery packets don't cross a VLAN boundary by design. So if phones are on the employee VLAN and the Apple TV is on an AV VLAN, AirPlay just doesn't appear. AirGroup is Aruba's mDNS/DLNA gateway: the controller/gateway snoops the service advertisements, caches them, and proxies them across VLANs on demand.

You then scope visibility with policies — by role, user, location or AP group — so only people in that meeting room see that Apple TV, not the whole campus (which would be chaos and a security leak). So AirGroup answers two needs at once: cross-VLAN discovery and controlled scoping. Without it, you'd be stretching one flat VLAN everywhere, which you don't want.

Work bottom-up. 1. Power/link: does the AP get PoE and a DHCP IP? Check the switch port and show ap database on the controller. 2. L3 reachability: can the AP subnet reach the controller IP — ping/traceroute, any ACL or firewall in the path blocking PAPI/IPsec (UDP 4500)? 3. Discovery: across a routed link ADP won't work, so confirm DHCP Option 43 or the DNS aruba-master record actually points to the controller.

4. On the controller: show ap database long to see if it appears as down or in the wrong group, and check it's not failing the image download or licence. Console the AP and watch the boot log for where discovery stalls. Nine times out of ten on a routed link it's Option 43/DNS missing or a blocked port.

Find the layer that fails. On the controller run show user-table / show user mac <mac> — did the client authenticate, get a role, and a DHCP IP? No IP → DHCP scope exhausted or VLAN not trunked to the AP/gateway. Wrong/limited role → it's stuck in a logon/captive role and the firewall is dropping traffic — check show datapath session for denies.

If it has an IP and the right role, test L3: can it reach the gateway, then DNS, then the Internet? A common one is the role's ACL missing DNS (UDP 53) so name resolution fails while ping-by-IP works. So the chain is: associated → authenticated → role → IP → gateway → DNS → Internet, and you stop at the first broken link.

Separate not enough signal from too much noise. Pull the client's RSSI and SNR (Central client view or show ap client). Low RSSI (e.g. -78 dBm) with low noise = a coverage hole — fix with AP placement/power (let AirMatch raise power, or add an AP). Decent RSSI but low SNR / high retries = an interference problem.

Then use the spectrum analyser on a dedicated radio to identify the source — a microwave, Bluetooth, a rogue on the channel, or co-channel from your own over-dense APs. Check show ap arm history for channel churn and the channel utilisation. So one is solved by adding/boosting RF, the other by removing the interferer or re-planning channels. Stating that RSSI-vs-SNR split is what marks the L3 answer.

This is a roaming-handoff issue, not coverage. First confirm fast roaming is on and working: is 802.11r (or OKC) enabled on that voice SSID, and does the handset actually support it? If not, every roam redoes full 802.1X and the gap drops the call. Check show ap client roam-history / Central's roam timeline for how long the handoff takes.

Next, look for a sticky-client pattern — the phone clings to AP-1 until -80 dBm before roaming, so by the time it moves the call is already broken; tune ClientMatch and the roam thresholds. Also check the two APs are in the same mobility domain/cluster so keys and L3 mobility hold the IP. Finally a quick packet capture at the roam point shows whether it's deauth, missing FT, or DHCP re-request. Root cause is usually no 11r/OKC or sticky thresholds.

AIOps uses crowd-sourced baselines across the install base plus your own history to flag anomalies before tickets land. Central's AI Insights surface things like APs with abnormal reboots, clients with chronic auth failures, a site with rising channel utilisation, or sub-optimal AP placement — each with a recommended fix.

It also gives connectivity scoring and time-series for association, DHCP and RADIUS so you can prove where in the journey clients fail. Practically: instead of waiting for a Hyderabad SOC to complain, Insights might flag that 12% of clients on one SSID fail RADIUS at 9 am — pointing you straight at a ClearPass capacity issue. So AIOps turns reactive firefighting into proactive, evidence-led fixes.

show ap database — which APs are up/down and in what group. show ap active — APs serving clients with their channels. show user-table / show user mac <mac> — a client's role, VLAN, IP and auth state, the single most useful command. show auth-tracebuf — live 802.1X/RADIUS exchange to see why auth fails.

show datapath session — firewall sessions and whether traffic is being denied by a role ACL. show ap arm history / show ap arm rf-summary — channel and power changes and RF health. show ap client — per-client RSSI/SNR and rates. Knowing which command answers which question — auth vs RF vs firewall — is exactly what the panel is checking.