Aruba Wireless Interview Questions & Answers

An SSID (Service Set Identifier) is the human-readable network name you see when joining Wi-Fi, like Aruba-Corp. A BSSID (Basic Service Set Identifier) is the radio's MAC address that actually transmits frames for that SSID on a given band.

Analogy: the SSID is a shop's brand name; the BSSID is the street address of one branch. Many branches (BSSIDs) can share one brand (SSID).

A single AP advertises one BSSID per SSID, per radio. With multiple SSIDs across the 2.4 GHz, 5 GHz, and 6 GHz radios, one AP can broadcast many BSSIDs. Each radio supports up to roughly 16 BSSIDs in practice, so a tri-radio AP can expose dozens.

👉 Interview tip: Stress that clients roam between BSSIDs while staying on the same SSID, and that too many SSIDs waste airtime because each one beacons separately on every radio.

2.4 GHz: best range and wall penetration, but only 3 non-overlapping 20 MHz channels (1, 6, 11), low throughput, and heavy interference from Bluetooth, microwaves, and legacy devices.

5 GHz: the balanced workhorse. Shorter range, much higher throughput, ~25 channels (many are DFS, shared with radar), moderate interference. Most enterprise traffic lives here.

6 GHz (Wi-Fi 6E/7): shortest range and weakest penetration, but a huge clean spectrum. In the US (full 1200 MHz) that is 59 20 MHz channels — which can be bonded into roughly fourteen 80 MHz channels, seven 160 MHz channels, or three 320 MHz channels (Wi-Fi 7). Europe currently opens only the lower 500 MHz, so it has fewer. Almost no legacy interference, since only WPA3 6E/7 devices use the band.

Analogy: 2.4 GHz is a loud crowded highway, 5 GHz a busy expressway, 6 GHz a fresh empty motorway with no old trucks.

👉 Interview tip: Say higher frequency = more bandwidth but less range, and 6 GHz needs denser AP placement.

The Wi-Fi Alliance gave numeric names to make versions friendlier:

• 802.11b — 2.4 GHz, legacy (no number)
• 802.11a — 5 GHz, legacy
• 802.11g — 2.4 GHz, legacy
• 802.11n — Wi-Fi 4, 2.4 & 5 GHz
• 802.11ac — Wi-Fi 5, 5 GHz only
• 802.11ax — Wi-Fi 6, 2.4 & 5 GHz

Wi-Fi 6E is not a new amendment — it is the same 802.11ax standard extended into the new 6 GHz band. The 'E' literally means 'Extended'. The newest generation, 802.11be, is Wi-Fi 7.

👉 Interview tip: Emphasize Wi-Fi 6 and 6E share the same PHY/MAC (OFDMA, TWT, BSS Coloring) — 6E just unlocks 6 GHz spectrum with mandatory WPA3.

Wi-Fi 5 (802.11ac) focused on raw speed: wider channels, more spatial streams, and 256-QAM, but only on 5 GHz. It performs well with one fast client but struggles when many devices compete.

Wi-Fi 6 (802.11ax) focuses on efficiency in crowded environments. Key gains:

• OFDMA — splits a channel into sub-carriers so multiple clients share one transmission
• 1024-QAM — packs ~25% more data per symbol
• BSS Coloring — better spatial reuse
• Target Wake Time (TWT) — saves IoT battery
• Works on both 2.4 and 5 GHz (and 6 GHz as 6E)

Analogy: Wi-Fi 5 made the truck faster; Wi-Fi 6 added carpool lanes so everyone moves.

👉 Interview tip: Say Wi-Fi 6's headline win is capacity and efficiency in dense deployments, not just peak speed.

OFDMA (Orthogonal Frequency-Division Multiple Access) splits a channel in the frequency domain into small units called Resource Units (RUs). Several clients are served inside a single transmission, each on its own RU.

MU-MIMO works in the spatial domain: it uses multiple antennas and beamforming to send separate streams to a few clients at the same time, but each gets the whole channel width.

Analogy: OFDMA is one delivery truck carrying many small parcels to different addresses in one trip; MU-MIMO is several trucks driving in parallel.

OFDMA shines in dense, mixed-traffic settings (IoT, voice, small packets) because tiny frames no longer monopolize the channel — they share airtime efficiently, cutting latency and overhead. They are complementary: Wi-Fi 6 APs use both.

👉 Interview tip: OFDMA = frequency-domain sharing for many small flows; MU-MIMO = spatial-domain parallelism for fewer large flows.

BSS Coloring tags each Basic Service Set (one AP's cell) with a small numeric 'color' (a 6-bit field) carried in the PHY header. Radios use this color to instantly tell whether a frame they overhear belongs to their own BSS or a neighboring one.

It solves the co-channel interference / overlapping BSS (OBSS) problem. Normally a device hearing any signal above the CCA threshold backs off and waits, even if that signal is a distant neighbor. With BSS Coloring, if the overheard frame has a different color, the radio applies a more aggressive (adjusted) energy threshold and may transmit anyway — this is spatial reuse.

Analogy: same-color cars share a lane carefully; a different-color car far away doesn't force you to stop.

👉 Interview tip: Say BSS Coloring boosts airtime efficiency in high-density designs by reducing unnecessary deferrals between overlapping cells.

Target Wake Time (TWT) is a Wi-Fi 6 power-saving feature where the AP and client negotiate a schedule agreeing exactly when the client must wake to send or receive data. Outside those agreed windows the client's radio sleeps deeply.

Analogy: instead of constantly checking the mailbox, you and the postman agree the mail arrives at 9 AM daily — you sleep until then.

This matters for IoT battery life because sensors, smart locks, and meters send tiny amounts of data infrequently. Keeping the radio awake to listen for every beacon drains the battery fast. TWT lets such devices stay asleep for seconds, minutes, or longer, dramatically extending battery life (potentially years on a coin cell).

TWT also reduces channel contention, since devices aren't all waking and competing at once.

👉 Interview tip: Mention individual vs broadcast TWT and that it benefits both battery and airtime.

Spatial streams (NSS) are independent data flows sent simultaneously over different antennas using MIMO. More streams = more parallel pipes (e.g. 2x2 = 2 streams).

MCS (Modulation and Coding Scheme) is an index defining the modulation (BPSK up to 1024-QAM in Wi-Fi 6) and coding rate. A higher MCS packs more bits per symbol but needs a stronger, cleaner signal (high SNR).

Channel width sets how many sub-carriers are available — double the width roughly doubles the rate. Wi-Fi 6/6E supports 20/40/80/160 MHz; Wi-Fi 7 adds 320 MHz on 6 GHz.

The PHY rate is the product: spatial streams × bits-per-symbol (MCS) × channel width × guard-interval factor. So a 2x2 client at MCS 11 on 80 MHz reaches far higher rates than a 1x1 client at MCS 7 on 20 MHz.

👉 Interview tip: Note clients often limit the rate — a 1x1 phone won't hit the AP's 4x4 maximum, and weak SNR forces a lower MCS.

The 6 GHz band is a fresh start, so the standard mandates WPA3 (and OWE/Enhanced Open for open networks) — no WPA2, no legacy PSK. This guarantees modern encryption (SAE, no downgrade attacks) and forces a clean security baseline across all 6E devices.

Preferred Scanning Channels (PSC): with up to 59 channels, scanning all of them is slow. PSCs are a defined subset (every 4th 20 MHz channel) that APs should beacon on and clients scan first, making discovery and roaming fast and efficient.

Power classes shape coverage:

• LPI (Low Power Indoor) — lower EIRP, no external antennas, indoor-only; the default for enterprise APs.
• SP (Standard Power) — higher EIRP for larger or outdoor coverage, but requires AFC (Automated Frequency Coordination) to avoid incumbents.
• VLP (Very Low Power) — the lowest EIRP, allowed indoor and outdoor with no AFC; used for short-range, portable, and wearable devices.

👉 Interview tip: Say design APs/SSIDs on PSC channels, plan for LPI's reduced range (denser APs), and use SP+AFC only where coverage demands it.

Wi-Fi 7 (802.11be) builds on 6E with three headline features:

• MLO (Multi-Link Operation) — a client connects across multiple bands/links (e.g. 5 GHz + 6 GHz) at once, aggregating throughput or using one link for reliability/low latency.
• 320 MHz channels — double Wi-Fi 6E's 160 MHz width, only feasible in the wide 6 GHz band, for very high throughput.
• 4096-QAM (4K-QAM) — ~20% more bits per symbol than 1024-QAM under strong signal.

These shift the design conversation: you plan for even denser, high-SNR cells (4K-QAM and 320 MHz need clean RF), reserve enough contiguous 6 GHz spectrum for 320 MHz, and treat MLO as a reason to keep multiple bands healthy rather than steering everything to 6 GHz.

👉 Interview tip: Frame Wi-Fi 7 as evolution, not rip-and-replace — a 6E design is forward-compatible and 6E APs coexist with Wi-Fi 7 clients.

In AOS-8, the Mobility Conductor (renamed from Mobility Master) is the central management and configuration brain. It holds the master configuration, pushes it down to controllers, and handles licensing, WLAN/RF config, and centralized monitoring. It does not usually terminate AP tunnels or forward client traffic.

A Mobility Controller (MD = Managed Device) is the workhorse: APs build tunnels to it, clients authenticate through it, and user data is forwarded by it.

Analogy: the Conductor is the orchestra conductor writing the score; the MD is a musician actually playing the notes for the audience (clients).

• Conductor = control/config plane
• MD = data plane + AP termination

👉 Interview tip: Say clearly that the Conductor manages, the MD forwards — separating control plane from data plane is the whole point.

Aruba Central is HPE's cloud platform that manages APs, gateways, and switches over the internet. AOS-10 is the operating system built for that cloud model.

In AOS-8, configuration and management live on-prem on a Mobility Conductor/controller you own and patch. In AOS-10, the management plane moves to the cloud (Central); APs and gateways connect out to it over an outbound, TLS-encrypted connection on TCP 443 (a persistent WebSocket-style channel).

• AOS-8: you run the controllers; the master config is on-prem.
• AOS-10: Central runs the management; gateways become pure forwarders.

Analogy: AOS-8 is owning your own server room; AOS-10 is renting a managed cloud dashboard.

👉 Interview tip: Stress that in AOS-10 the gateway is no longer the manager — it just forwards traffic; Central is the manager.

• Campus AP (CAP): controller-based. Sits on the trusted LAN, builds a GRE tunnel to a controller/gateway. No local brain.
• Remote AP (RAP): controller-based but lives at home/branch over the internet; builds an IPsec tunnel back to the controller, with survivability if the link drops.
• Instant AP (IAP): controller-less (in the AOS-8 world). The APs elect a Virtual Controller (VC) among themselves — good for small sites with no controller.
• Mesh: a topology, not an AP type. A mesh portal is wired; mesh points relay wirelessly where you cannot cable.

Analogy: CAP/RAP are employees reporting to a manager; IAP is a self-managing small team.

👉 Interview tip: Only IAP is truly controller-less. Note that AOS-10 retires the IAP Virtual Controller model — Instant APs there are managed directly by Aruba Central instead of electing a VC.

This is the classic control-plane vs data-plane separation question. The Conductor is the control/management plane; the MDs are the data plane.

Keeps working if the Conductor dies: APs stay tunneled to their MDs, existing clients stay connected, new clients can still associate and authenticate, and traffic keeps forwarding — because MDs already hold their running config and talk to RADIUS directly.

Stops working: centralized config changes/pushes, centralized dashboards and historical monitoring, licensing operations, and onboarding brand-new MDs.

Analogy: if the architect (Conductor) leaves the site, the already-built machines (MDs) keep running, but you cannot get new blueprints approved.

👉 Interview tip: The headline answer is "clients are unaffected; only management/config is impacted" — that proves you understand the split.

A factory AP boots, gets an IP via DHCP, then tries to find its controller. The common discovery methods are:

1. Static master: if someone manually provisioned the controller IP on the AP, it uses that.
2. ADP (Aruba Discovery Protocol): the AP sends a Layer-2 multicast and a Layer-3 broadcast to find a local controller.
3. DHCP option 43/60: the AP sends vendor class option 60 (the string ArubaAP); the DHCP server returns the controller IP in option 43.
4. DNS: the AP resolves the hostname aruba-master in its DHCP-supplied domain to a controller IP.

Once it reaches the master/Conductor it is provisioned to an MD. The LMS-IP (in the AP system profile) tells the AP which controller to terminate on; backup-LMS-IP is the failover controller.

👉 Interview tip: Know the methods — static, ADP, DHCP option 43/60, DNS aruba-master — and that LMS-IP is what actually anchors the AP after provisioning.

AOS-8 uses a tree-based configuration hierarchy on the Conductor. Common nodes are /mm (Conductor settings), /md (the root for all managed devices), and below it region/site/group folders, down to individual MDs.

Configuration inherits downward: settings at /md apply to every device beneath it; a region or group node refines it; an individual device node holds device-specific bits.

Per-MD overrides: at a lower node you can override an inherited value (for example a different VLAN or LMS-IP) without breaking the shared config above. Override at the lowest node that needs it.

Analogy: company policy at HQ, refined per region, then per office — each level can tweak without rewriting the policy above.

👉 Interview tip: Say "configure shared settings high, override low" — that is the AOS-8 best practice.

In AOS-8, an AP anchors to a specific controller defined by LMS-IP, and that controller both manages and forwards.

In AOS-10, the management plane is in Central and gateways become forwarding-only. APs no longer pin to one box — they anchor to a gateway cluster. Central's Tunnel Orchestrator automatically assigns each AP an active and standby gateway, balancing load and providing redundancy.

• GRE carries the user tunnel between AP and gateway.
• IPsec optionally encrypts that tunnel (mandatory across untrusted/branch links).

Analogy: instead of every AP reporting to one fixed manager, they report to a team (cluster), and a dispatcher (orchestrator) assigns coverage.

👉 Interview tip: Emphasize "cluster + orchestrated tunnels = no manual LMS-IP and automatic failover."

In AOS-8, the MD-to-Conductor relationship runs over an IPsec tunnel, with AMON carrying real-time monitoring/telemetry and SNMP available for management polling — all on-prem, requiring reachability between your own boxes.

In AOS-10, that on-prem control channel is replaced by a single outbound, TLS-encrypted connection to Aruba Central over TCP 443 (a persistent WebSocket-style channel). Devices stream telemetry and pull config through that one cloud connection.

Why the change: outbound 443 traverses firewalls/NAT with no inbound rules, scales to huge fleets without on-prem management hardware, centralizes analytics and updates, and removes the per-site IPsec/AMON/SNMP plumbing.

Analogy: swapping many private leased lines for one secure cloud login.

👉 Interview tip: The keyword is "outbound TLS on 443 to Central" — firewall-friendly and cloud-scalable.

I follow Aruba's Campus Migrate VSG (Validated Solution Guide) path:

1. Audit and onboard: inventory APs/gateways, confirm they support AOS-10, license them into Central, and verify outbound TCP 443 reachability.
2. Decide forwarding per WLAN: map each SSID to Bridge (AP forwards locally to a VLAN), Tunnel (AP GREs to the gateway cluster, like AOS-8 centralized), or Mixed (per-VLAN choice).
3. Build the gateway cluster and let the Tunnel Orchestrator anchor APs.
4. Migrate in waves per site/group, validating roaming, RADIUS, and roles before the next wave.

IAP note: AOS-10 retires the IAP Virtual Controller model — Instant APs move to Central-managed mode (no more VC election), which unlocks the larger AOS-10 cluster scale.

👉 Interview tip: Lead with "per-WLAN forwarding choice (Bridge vs Tunnel) is the key design decision" and migrate in phased waves, not big-bang.

I size a cluster off four numbers: AP count, client count, aggregate throughput, and tunnel count, then pick gateway models whose datasheet limits comfortably exceed peak with N+1 headroom so one node can fail and the rest absorb the load.

AOS-10 scale gains over AOS-8: because gateways are now forwarding-only (Central does management), each gateway can dedicate its resources to devices and tunnels, raising per-cluster capacity. On the Instant side specifically, AOS-10's Central-managed clustering lifts the old IAP swarm ceiling roughly 4x — from the legacy ~128-AP Virtual-Controller recommendation toward several hundred APs per cluster (verify exact numbers against the current Aruba datasheet/VSG for your gateway and AP models).

• Always size for N+1 so failover never oversubscribes survivors.
• Spread load with the Tunnel Orchestrator's active/standby assignment.

👉 Interview tip: Quote "AOS-10 raises cluster scale (about 4x on the Instant side) because gateways stopped doing management" and always design N+1.

An SSID profile defines the radio and Layer-2 behaviour of a wireless network — essentially the rules for how a Wi-Fi name is advertised and secured. Think of it as the signboard plus the door lock on a shop: it controls what name people see and how they get in.

• SSID name + broadcast vs hidden: broadcast for easy user joining; hidden suppresses the name in beacons (weak security, mainly for clutter reduction).
• Band / radio: 2.4GHz for range/IoT, 5GHz for capacity, 6GHz for Wi-Fi 6E/7 clean spectrum.
• Security / opmode: WPA3-Personal (SAE) or WPA2-Personal (PSK) for pre-shared keys; WPA3-Enterprise or WPA2-Enterprise with 802.1X for identity; Enhanced-Open (OWE) for encrypted open networks. Note 6GHz mandates WPA3/OWE — legacy WPA2/open are not allowed on that band.
• Data rates: disable low rates (1/2/5.5) to improve airtime efficiency and trim cell size.

Interview tip: Stress that hiding an SSID is not security — WPA3 + 802.1X is.

A user role is the identity-driven container that decides what a connected client is actually allowed to do. After a client authenticates, Aruba assigns it a role, and that role becomes its set of network privileges — like an office ID badge that opens only certain doors.

• Firewall policies (ACLs) — the stateful permit/deny rules (this is the core of the role).
• VLAN assignment — which subnet/segment the user lands on.
• QoS / traffic priority — DSCP/802.1p marking.
• Bandwidth contracts — per-user or per-role rate limits.
• Captive portal / re-auth settings and time-based or VPN options.

Aruba's firewall is role-based, not just IP-based, which is why roles are central to the platform.

Interview tip: Say "the firewall policy is the heart of the role" — that's the answer interviewers want.

The difference is what you optimise for: reaching everywhere vs serving many devices fast.

• Coverage-oriented: maximise signal reach with fewer APs at higher power. Goal is "no dead spots." Fine for warehouses, hallways, or low-density areas. Risk: each AP serves a large area, so co-channel interference and contention rise under load.
• Capacity-oriented: more APs at lower power with tight cells, prioritising 5GHz/6GHz and channel reuse. Goal is high per-client throughput in dense spaces — auditoriums, classrooms, stadiums.

Analogy: coverage is one loud teacher for a whole field; capacity is many quiet teachers, one per small group, so everyone is heard.

Modern high-density designs (Wi-Fi 6/6E/7) almost always lean capacity-first, using band steering and smaller cell sizes.

Interview tip: Mention that capacity design lowers TX power on purpose — counterintuitive but key.

In AOS-8 these three profiles are nested, and the Virtual AP (VAP) profile is the parent that ties everything together. A VAP is one broadcast WLAN instance on a radio.

• SSID profile (child of VAP): the RF/L2 layer — SSID name, broadcast/hidden, band, WPA3/WPA2 encryption opmode, allowed data rates.
• AAA profile (child of VAP): the identity layer — 802.1X auth server group, MAC-auth, initial role, RADIUS accounting, and server-derived role rules.
• VAP profile (parent): binds the SSID + AAA together, plus forwarding mode (tunnel/bridge/split-tunnel/decrypt-tunnel), VLAN(s), and is attached to an AP group.

Analogy: the VAP is a car; the SSID profile is the bodywork and locks; the AAA profile is the driver's licence check.

Interview tip: Remember the hierarchy: AP group → VAP → (SSID profile + AAA profile).

Forwarding mode decides where client traffic is decrypted and where it exits.

• Tunnel: the AP encapsulates client 802.11 frames (still encrypted) in GRE up to the Mobility Controller, which terminates encryption and applies the firewall/role. Centralised control; default for campus.
• Bridge: AP decrypts locally and dumps traffic straight onto the local LAN/VLAN — no controller in the data path. Lowest latency, but role/firewall enforcement is limited.
• Decrypt-Tunnel: AP decrypts locally, then tunnels the cleartext to the controller for full firewall/role processing — gives central policy without re-encrypting over GRE.
• Split-Tunnel: AP intelligently splits — corporate traffic is tunnelled to the controller at HQ, while internet/local traffic breaks out locally (a session ACL decides which is which).

For a branch RAP with local internet breakout, choose Split-Tunnel: corporate apps stay secured to HQ while web traffic exits locally, saving WAN bandwidth and improving SaaS latency.

Interview tip: Tie Split-Tunnel to "WAN cost + SaaS performance."

In AOS-8, forwarding mode is set on the VAP profile and the architecture assumes a Mobility Controller in the path for tunnelled traffic. In AOS-10, the model is cloud-managed via Aruba Central, and forwarding mode is configured per-WLAN with the Gateway (rather than a Mobility Controller) as the tunnel termination point.

• Bridge: AP decrypts and forwards locally to the wired VLAN — no gateway needed. Ideal for microbranch/IAP-style or small sites.
• Tunnel: AP tunnels all WLAN traffic to a Gateway cluster for centralised role/firewall and Dynamic Segmentation.
• Mixed: per-WLAN choice on the same AP — e.g. employee SSID tunnelled to a gateway while guest/IoT SSID is bridged locally.

Analogy: AOS-10 lets each WLAN pick its own "exit door" on the same building.

Interview tip: Key shift — AOS-10 terminates tunnels on Gateways, not Mobility Controllers, and mode is per-WLAN.

Role derivation answers "which role does this client finally get?" Aruba evaluates several sources in a fixed precedence order, and the role applied later in that order overrides earlier ones:

1. Initial / default role: from the AAA profile, assigned before/during auth (e.g. logon for captive portal). It's the fallback floor.
2. User-derived rules (UDR): match client attributes the AP can see — MAC OUI, DHCP fingerprint, hostname. Useful for IoT that can't do 802.1X.
3. Server-derived rules (SDR): a role the controller derives by matching RADIUS reply attributes (e.g. an AD group returned in Filter-Id or Class) against rules you define.
4. RADIUS-pushed role (VSA): an explicit Aruba-User-Role vendor-specific attribute sent by the auth server. This is the most authoritative.

Precedence in plain terms: an explicit Aruba-User-Role VSA beats a server-derived rule, which beats a user-derived rule, which beats the initial/default role. The authenticated result wins because the RADIUS server is the trusted identity source.

Interview tip: One-liner — "VSA role beats server-derived beats user-derived beats default."

You enable both MAC-auth and 802.1X in the same AAA profile, configuring MAC-auth-first (often called MAC-then-dot1x). The flow runs in stages and the role upgrades as the client proves more identity.

• MAC-auth first: the AP/controller checks the device MAC against RADIUS. If it matches a known device, it gets a limited device role (e.g. IoT/printer access).
• 802.1X next: if the device/user then completes EAP, the RADIUS server returns a higher-privilege user role that overrides the MAC-derived role.
• Fallback: a known device that can't do 802.1X simply stays in its MAC role; an unknown device may drop to a captive-portal/guest role.

Analogy: MAC-auth is showing your office badge at the gate; 802.1X is the fingerprint scan that unlocks the inner floor.

Interview tip: Stress that 802.1X wins over MAC-auth — the final role reflects the strongest credential.

Define one role per trust tier, each enforced by least-privilege firewall policy rather than relying on VLAN/IP boundaries:

• Employee: 802.1X (WPA3-Enterprise), AD-group server-derived role, full corp access, high QoS, generous bandwidth contract.
• Contractor: 802.1X but restricted ACL (internet + specific app subnets only), time-bound, medium bandwidth cap.
• IoT: MAC-auth + DHCP-fingerprint UDR, micro-segmented ACL (allow only its controller/cloud), no peer-to-peer, low QoS.
• Guest: captive portal, internet-only ACL, strict per-user bandwidth contract, client isolation.

Keeping it scalable: use RADIUS/ClearPass to push roles dynamically (one SSID, role decided by identity) instead of one SSID per group; build reusable named ACL aliases (netdestinations) so policy changes propagate everywhere; and lean on Dynamic Segmentation so the role — not the VLAN sprawl — is the policy boundary.

Interview tip: Say "few SSIDs, many roles, identity-driven" — that's the scalable pattern.

Dynamic Segmentation extends identity-based policy from wireless to the wired world: a device's traffic is steered to a policy enforcement point and given a role, regardless of which physical port it plugs into.

• User-Based Tunneling (UBT): an Aruba CX switch tunnels a wired client's traffic (via GRE) to an Aruba Gateway, which applies the same role-based firewall used for Wi-Fi. The switch authenticates the client (802.1X/MAC), gets a role from ClearPass, then tunnels matching traffic.
• Colorless ports: no port is pre-assigned a VLAN/role. The identity (not the cable) decides access — a printer, laptop, or camera can use any port and still land in the right segment.
• Global vs micro-segmentation: global keeps broad trust tiers apart; micro-segmentation restricts even same-tier devices from talking laterally (east-west).

This is core to Zero Trust: never trust the port, always verify identity, and enforce least-privilege everywhere — limiting lateral movement.

Interview tip: Say "colorless ports = identity decides access, not the cable."

ARM (Adaptive Radio Management) is Aruba's per-AP, real-time RF tuning engine. Each AP runs ARM locally and continuously adjusts its own radios:

• Channel — moves to a cleaner channel when it detects interference or noise.
• Transmit power — raises or lowers TX power to size its coverage cell so neighbouring APs don't overlap too much.
• Coordination features — ARM also drives band steering, spectrum load balancing, and airtime fairness, and feeds rogue/interference scanning data into the system.

Think of it like a person in a noisy room who lowers their voice and shifts to a quieter corner so they don't drown out others. ARM reacts in seconds to local conditions, but it only sees what one AP hears.

👉 Interview tip: Stress that ARM is per-AP and reactive — that's the contrast examiners want versus network-wide AirMatch.

Co-channel interference (CCI) happens when two or more APs (or clients) use the same channel within radio range of each other. Wi-Fi is half-duplex and shares the medium using CSMA/CA, so devices on the same channel must take turns. When APs on the same channel hear each other, they wait for one another instead of transmitting — airtime is wasted and throughput drops, even though signal strength looks fine.

Analogy: two people on the same walkie-talkie frequency can't both talk — they queue. Put them on different frequencies and both speak at once.

Channel reuse planning spaces same-channel APs far apart so they don't hear each other, while neighbours use non-overlapping channels (in 2.4 GHz: 1, 6, 11). This maximises usable airtime and capacity.

👉 Interview tip: Say CCI hurts airtime/capacity, not coverage — a strong signal can still be slow.

Wi-Fi 6/6E supports channel widths of 20, 40, 80, and 160 MHz. Wider channels bond more spectrum together, so a single link gets higher peak throughput (roughly double the speed each time you double the width).

The trade-off: spectrum is finite, so wider channels mean fewer non-overlapping channels available. In 5 GHz you might get many 20 MHz channels but only a couple of clean 160 MHz channels. Fewer channels → more APs forced onto the same channel → more co-channel interference in dense deployments.

Analogy: one wide highway lane carries fast traffic, but you can fit fewer lanes — and they jam when crowded.

• Wide (80/160): homes, low-density, speed-test wins.
• Narrow (20/40): high-density (offices, stadiums) — more reusable channels = more capacity.

6 GHz (Wi-Fi 6E) helps by adding lots of fresh spectrum, making wider channels more practical.

👉 Interview tip: Wider = faster per client but worse channel reuse — pick narrow in high density.

These are Aruba's three RF optimisation technologies, each working at a different scope:

• ARM — per-AP, real-time. Each AP independently adjusts its own channel and TX power in seconds based on what it locally hears. Reactive; no global view.
• AirMatch — network-wide, scheduled. Runs on the Mobility Conductor (AOS-8), collects RF data from all APs, and computes one coordinated channel/width/power plan for the whole deployment, deployed typically once every 24 hours. Proactive and holistic.
• ClientMatch — client-focused, continuous. Steers individual clients to the best AP/band/channel, fixing sticky clients and balancing load.

Analogy: ARM = each driver adjusting their own car; AirMatch = a city traffic planner optimising all signals overnight; ClientMatch = a valet guiding each car to the best parking spot.

👉 Interview tip: Map them as per-AP (ARM) → network-wide (AirMatch) → per-client (ClientMatch) — that one-liner nails the question.

ClientMatch solves the problem that clients make poor roaming and band decisions on their own. The controller/AP has a network-wide view of every client's signal and the surrounding APs, so it nudges clients to a better radio.

• Sticky clients: a device stays glued to a distant AP it first joined even after walking near a stronger one, because clients are slow to roam. ClientMatch detects the weak link and steers it to the closer AP, restoring speed.
• Band steering: dual-band clients often default to crowded 2.4 GHz. ClientMatch pushes capable clients up to 5 GHz/6 GHz, which has more channels and less congestion.
• Load balancing: when one AP is overloaded and a neighbour is idle, ClientMatch distributes clients across APs for better airtime.

It uses 802.11v BSS Transition Management hints where supported (alongside 802.11k neighbour reports), falling back to controlled deauth for clients that ignore the hint.

👉 Interview tip: Name all three (sticky, band steering, load balancing) and mention 802.11v/k for bonus marks.

In AOS-8, every AP continuously scans and reports RF telemetry — neighbour APs heard, interference, noise, channel utilisation — up to the Mobility Conductor. AirMatch aggregates this fleet-wide data and runs a centralised optimisation algorithm that solves the whole RF puzzle at once: it assigns channels, channel widths, and EIRP/power across all APs to minimise co-channel interference and maximise capacity using a coordinated, global view.

• Schedule: AirMatch computes and deploys a new plan once per solver cycle, by default every 24 hours (configurable, often deployed in early-morning low-traffic windows to avoid disruptive channel changes).
• Incremental updates: it can react to a radar hit (DFS event) or AP failure sooner, but the full plan is periodic, not instantaneous.

By contrast, ARM is real-time and per-AP — each AP self-adjusts in seconds with only a local view. AirMatch is the proactive planner; ARM is the reactive fallback.

👉 Interview tip: Say AirMatch = centralised + ~24h cycle + global view; ARM = local + seconds.

Wi-Fi packet tools only show 802.11 traffic, but non-Wi-Fi interferers — microwave ovens, Bluetooth, cordless phones, wireless cameras, jammers — also eat airtime. To find them you need spectrum analysis, which scans raw RF energy rather than packets. On Aruba this is done in two ways:

• Dedicated Spectrum Monitor (SM): the radio is taken out of client service and acts as a full-time spectrum sensor.
• Hybrid AP: a serving AP runs spectrum analysis part-time on its current channel while still passing client traffic.

The radio scans raw RF energy and classifies interferers by their signature, showing a spectrum waterfall / FFT view, duty cycle, and affected channels. (Note: an Air Monitor (AM) is the related security/WIDS-WIPS sensor mode — it also serves no clients, but its job is wireless intrusion detection, not raw spectrum analysis.)

Findings drive action: relocate or remove the interferer (e.g. move the microwave), change channels away from the polluted band, switch heavy users to 5 GHz/6 GHz if 2.4 GHz is saturated, or feed the data into ARM/AirMatch so the RF plan avoids the noisy channel.

👉 Interview tip: Stress that spectrum analysis sees non-802.11 energy a normal Wi-Fi scan can't — and that Spectrum Monitor is the dedicated mode, distinct from the security-focused Air Monitor.

High-density design flips the usual goal: you want many small, clean cells (capacity), not a few big cells (coverage).

• Channel width: go narrow — 20 MHz (maybe 40 in 6 GHz). Narrow channels give the most non-overlapping channels for reuse; wide channels would force co-channel interference.
• Channel plan: exploit all 5 GHz channels (and 6 GHz/Wi-Fi 6E if available); minimise or disable 2.4 GHz radios since they offer only 3 non-overlapping channels and cause heavy CCI.
• AP placement: in stadiums use under-seat or field-side directional APs with antennas aimed at small seating sectors, so each AP covers a tight zone and clients hear one strong AP only.
• TX power: keep power low and uniform to shrink cells, reduce overlap, and force frequent roaming to the nearest AP. Keep AP and client power balanced so the link isn't lopsided (a client should be able to talk back as far as it can hear).

Add band steering/ClientMatch and airtime fairness. Analogy: many small classrooms beat one giant hall for everyone talking at once.

👉 Interview tip: Lead with 20 MHz + low power + directional antennas + small cells = capacity.

Aruba Central AIOps / AI Insights shifts RF work from manual, reactive tuning to data-driven, proactive automation. Central pools telemetry from millions of devices across many customers, then uses machine learning to baseline normal behaviour and flag anomalies — sticky clients, coverage holes, excessive interference, roaming failures, capacity hotspots — often before users complain. It surfaces ranked insights, root-cause hints, and recommended (sometimes auto-applied) fixes, so engineers stop staring at raw spectrum graphs.

Where engineer judgment still matters:

• Physical-world causes AIOps can't fix: bad AP placement, building materials, antenna choice, cabling/power.
• Business context — prioritising a CEO's video call vs. guest Wi-Fi, or planning for a one-off event.
• Validating recommendations — AI suggests; the engineer confirms a channel change won't break a critical area.
• Design decisions — capacity planning, AP count, and high-density layout are still human-led.

Analogy: AIOps is an expert co-pilot; the engineer is still the pilot who owns the outcome.

👉 Interview tip: Say AIOps augments, not replaces — humans own design, physical causes, and business priorities.

WPA2-Personal (PSK) uses one shared pre-shared key (a passphrase) for everyone on the network. It's simple to set up — common in homes and small offices — but everyone knows the same password, so revoking one user means changing it for all, and there's no per-user identity.

WPA2-Enterprise (802.1X) authenticates each user individually against a backend RADIUS server (like Aruba ClearPass), using credentials or certificates. Each session gets unique encryption keys, and you can apply per-user roles, audit who connected, and revoke one person without touching others.

Analogy: PSK is one house key everyone copies; Enterprise is a badge system where each person has their own card the front desk can deactivate.

👉 Interview tip: Say Enterprise gives per-user identity, accounting, and central revocation — essential for any real corporate or campus network.

A captive portal is the web page that automatically pops up when you connect to a Wi-Fi network and try to browse — it 'captures' your session and forces you to authenticate or accept terms before granting internet access.

How it works: before authentication the client is placed in a limited pre-auth role. Any web request is redirected to the portal page. Only after you log in, accept terms, register, or get sponsor approval are you moved to a fuller role with internet access.

It's used mainly for guest access — hotels, airports, cafes, retail, hospitals, and corporate visitor Wi-Fi. It can also collect marketing details or display an acceptable-use policy.

Analogy: it's the reception desk you must sign in at before being let into the building.

👉 Interview tip: Mention captive portals can be internal (hosted on the Aruba controller/gateway) or external (hosted on ClearPass or a cloud service).

802.1X uses three roles:

• Supplicant — the client device (laptop, phone) software that presents credentials or a certificate. It wants to get on the network.
• Authenticator — the network device that controls the port/connection: an Aruba AP, controller/gateway, or switch. It blocks all traffic except EAPOL until the user is authenticated, then relays messages between the supplicant and server.
• Authentication Server — the RADIUS server (e.g. Aruba ClearPass) that actually validates the identity and tells the authenticator allow or deny, plus what role/VLAN to apply.

Analogy: the supplicant is a visitor showing ID, the authenticator is the security guard at the door, and the authentication server is the back-office that verifies the ID and says 'let them in.'

👉 Interview tip: Note the authenticator talks EAPOL to the supplicant and RADIUS to the server — it never sees the password itself.

WPA3 hardens WPA2's weaknesses:

• SAE (Simultaneous Authentication of Equals) replaces the WPA2-PSK 4-way handshake. It's a Dragonfly handshake giving forward secrecy and resistance to offline dictionary attacks — even a weak passphrase can't be cracked from a captured handshake (and it closes KRACK-style key-reinstallation issues).
• WPA3-Enterprise 192-bit mode uses a CNSA suite (GCMP-256, SHA-384, EAP with strong ciphers) for high-security/government environments.
• OWE / Enhanced Open gives encryption without a password on open networks (guest/public Wi-Fi) via opportunistic key exchange — no more cleartext open Wi-Fi.

Transition mode runs WPA2 and WPA3 on the same SSID so legacy and modern clients coexist during migration. Use it temporarily while old devices remain, but disable it once everything supports WPA3, since transition mode keeps WPA2's downgrade exposure.

👉 Interview tip: 6 GHz forbids transition mode — it requires pure WPA3.

MPSK (Multi Pre-Shared Key) lets a single SSID accept many different passphrases instead of one shared key. Each device or group gets its own unique PSK, and ClearPass returns a per-key role/VLAN based on which key authenticated.

MPSK-Local is the controller/AP-resident version (no ClearPass needed) — multiple keys configured locally on Aruba gateways/Instant, ideal for smaller sites.

Why it beats a single PSK:

• IoT: each camera, printer, or sensor gets its own key, so you can revoke or re-key one device without disrupting the rest
• Multi-tenant: each tenant/family gets a private key on a shared SSID, isolated by role/VLAN
• Per-key role assignment: the same SSID can place a camera in an IoT role and a guest in a guest role, all from the key used

Analogy: instead of one shared house key, every resident gets a personal key the lock recognizes individually.

👉 Interview tip: Stress per-device revocation and per-key role/VLAN as the security wins.

All three are EAP methods used inside 802.1X:

• EAP-TLS — mutual certificate authentication. Both client and server present X.509 certificates; no passwords cross the air. Strongest, but needs a PKI to issue/manage client certs.
• PEAP-MSCHAPv2 — server presents a cert to build a TLS tunnel, then the client authenticates with username/password inside it. Easy to deploy (uses AD credentials) but vulnerable if the server cert isn't validated, and password-based.
• EAP-TTLS — similar tunneled approach, more flexible on inner methods (e.g. PAP), often used with non-AD identity stores.

Choose EAP-TLS when you need the highest security, phishing-resistant auth (no passwords to steal or reuse), strong device identity, and you can support a PKI — typically corporate-managed laptops, BYOD via Aruba Onboard, or high-security/government networks. Use PEAP when a quick password-based rollout on existing AD is the priority.

👉 Interview tip: Say EAP-TLS = no shared secret over the air, so it's immune to credential phishing.

In ClearPass Policy Manager these two work together:

• An enforcement profile is the action/result — the actual set of attributes ClearPass sends back to the authenticator, e.g. a RADIUS Aruba-User-Role VSA, a VLAN, or a CoA. It defines what access to grant.
• An enforcement policy is the decision logic — a set of rules (conditions on identity, role, posture, time, device type) that selects which enforcement profile to apply. It defines when/which profile is chosen.

Analogy: the policy is the if/then rulebook; the profile is the stamped pass it hands out.

The returned Aruba-User-Role must exactly case-match a role defined on the Aruba controller/gateway because the controller does a literal string lookup. Employee and employee are different strings — a mismatch means no role is found, so the user falls back to a default/deny role and access breaks.

👉 Interview tip: Always copy-paste the role name to avoid silent case/whitespace mismatches.

A guest connects to an open/OWE SSID and lands in a pre-auth (logon) role that blocks general internet but permits DNS, DHCP, and a walled garden — a whitelist of allowed destinations (the portal server, payment/SMS verification, terms pages) reachable before login.

Internal portal: the page is hosted on the Aruba controller/gateway/Instant itself. Simple, self-contained, good for basic terms-acceptance or static guest credentials.

External portal: the page is hosted on ClearPass Guest (or cloud). The AP redirects the guest to ClearPass, which handles richer flows, branding, and logging, then sends a RADIUS/CoA result back to apply the post-auth guest role.

Onboarding options:

• Self-registration — guest enters details, gets credentials via SMS/email, then logs in
• Sponsor approval — guest request is emailed to an employee sponsor who approves before access is granted

After auth, a CoA bounces the session and the guest moves to the full guest role.

👉 Interview tip: Always whitelist the portal and verification hosts in the walled garden or login breaks.

A campus ClearPass design layers these pieces:

• Services — separate Policy Manager services matched by SSID/connection type: 802.1X wired/wireless (EAP-TLS/PEAP), MAC-Auth for IoT/printers, and a Guest service for the captive portal.
• Authentication sources — Active Directory/LDAP for employees, ClearPass local DB or Endpoints for IoT, and Guest/Onboard DBs; chained so AD is primary.
• Role mapping & enforcement — map AD groups/device attributes to roles, then enforcement policies pick profiles returning the Aruba-User-Role and VLAN (Employee, Contractor, IoT, Guest).
• OnGuard posture — agent/agentless checks (AV, patch, disk encryption); a Healthy posture gets the full role, an Unhealthy one gets a CoA into a quarantine VLAN with remediation-only walled-garden access.
• Onboard/BYOD — personal devices run the Onboard workflow to provision a unique device certificate, then authenticate via EAP-TLS instead of passwords.
• Clustering — one Publisher plus Subscribers for HA and scale, with subscribers serving local RADIUS at each site for resilience.

👉 Interview tip: Mention CoA, posture-driven VLAN change, and a Publisher/Subscriber cluster for HA.

Cloud Auth, part of HPE Aruba Networking Central / NetConductor, is a cloud-native NAC service that delivers identity-based access without on-prem RADIUS appliances. It's aimed at simpler, fast-to-deploy access policy.

Identity integration: it federates directly with cloud directories — Azure AD/Entra ID and Google Workspace — via OAuth/SAML, so user and group membership drives role assignment with no AD connector or local user DB to maintain.

Native MPSK: Cloud Auth issues and manages per-device/per-user MPSK keys from the cloud, mapping each key to a client role/VLAN — ideal for headless IoT and BYOD without certificates or 802.1X supplicants.

Where it falls short of full ClearPass:

• No deep OnGuard-style posture/health remediation
• Limited guest workflows (sponsor, self-reg, branding) vs ClearPass Guest
• Fewer custom authentication sources, complex policy chains, and TACACS+ device admin
• Less granular profiling and third-party integration depth

👉 Interview tip: Position Cloud Auth as 'right-sized cloud NAC' for cloud-first orgs, and ClearPass for complex, posture-heavy, multi-source enterprises.

I start read-only, working from the AP outward, before touching anything:

1. Confirm it's really down: on the controller run show ap database and look at the AP's flags/status (e.g. D = down).
2. Online history: in Central/dashboard check last-seen time — did it just blip or has it been down a while?
3. Uplink and PoE: on the access switch check the port — is it up, is PoE being drawn, any errors? No PoE/link usually means a switch-port or cabling issue, not the AP.
4. Neighbors: are other APs on the same switch/closet also down (shared cause)?

Analogy: before blaming the bulb, check the switch and the wiring.

👉 Interview tip: Always say "read-only first, confirm power/uplink before escalating" — never reboot blindly.

I scope the problem with simple questions first: one user or many? which SSID? which device? since when? which location?

Then basic checks:

• Is the SSID visible on the device, or hidden/typo'd?
• Correct band — an old 2.4 GHz-only device cannot see a 5 GHz/6 GHz-only SSID.
• Association vs authentication: does it connect then drop (authentication/RADIUS or password issue), or never even attach (RF, band, or SSID problem)? This single distinction points you in the right direction.
• Right credentials/certificate for 802.1X SSIDs.

Analogy: association is knocking on the door; authentication is showing valid ID to get inside.

👉 Interview tip: Saying "first I separate association from authentication" instantly shows you troubleshoot Wi-Fi methodically.

On an AOS-8 controller the key command is show user-table (or show user mac aa:bb:cc:dd:ee:ff for one client). It shows the client's IP, MAC, current AP/BSSID, assigned role, VLAN, auth method, and state.

Useful companions:

• show ap association — which clients are on which BSSID/AP.
• show user-table verbose — fuller per-client detail.
• show datapath session — to see the client's live traffic flows.

On AOS-10/Central, the client detail page (or the gateway CLI show user-table) gives the same AP, role, and VLAN view.

Analogy: show user-table is the guest register — who's in, where they're sitting, and what access badge (role/VLAN) they hold.

👉 Interview tip: Lead with show user-table — it's the single most-used Aruba client troubleshooting command.

I walk the connection in order:

1. Association: show ap association / show user-table — confirm the client is on a BSSID and note its role and VLAN.
2. 802.1X auth: check it actually passed RADIUS. Use show auth-tracebuf on the controller and ClearPass Access Tracker for an Accept vs Reject and which enforcement/role was returned.
3. Role/VLAN sanity: if the client landed in the wrong VLAN (or a deny/captive role), DHCP will never reach the right scope.
4. DHCP: verify DHCP relay/helper on that VLAN's SVI, scope not exhausted, and the path with show datapath session for DHCP traffic.

Common root cause: correct VLAN but no DHCP helper, or a post-auth role putting the client on the wrong VLAN.

👉 Interview tip: Always confirm auth and the returned role/VLAN before blaming DHCP — that's where most "no IP" cases actually break.

"Drops while walking" is a roaming problem: clients either roam too late or take too long to re-authenticate to the next AP. I'd confirm with show ap association history and client roam logs, and check for coverage gaps between buildings.

The fast-roaming standards each fix a different piece:

• 802.11r (Fast BSS Transition): pre-negotiates and caches keys so the client skips a full 802.1X/EAP handshake on roam — huge for voice/video.
• 802.11k (Radio Resource Management): gives the client a neighbor report so it knows which APs to roam to (no blind scanning).
• 802.11v (BSS Transition Management): lets the network steer/nudge a client toward a better AP.
• OKC (Opportunistic Key Caching): a pre-802.11r way to reuse the PMK across APs for fast WPA2-Enterprise reauth (note: client support varies, unlike standardized 11r).

👉 Interview tip: Summarize: 11k = where to roam, 11v = when/steering, 11r/OKC = roam fast without a full reauth.

I work from both ends — the controller (RADIUS client) and ClearPass (RADIUS server).

1. Controller side: show auth-tracebuf shows the live 802.1X/RADIUS exchange — are requests even reaching ClearPass, and is the reply Accept or Reject? No reply at all points to RADIUS reachability/shared-secret.
2. ClearPass Access Tracker: open the failed request and read the Alerts/Summary. It pinpoints the stage: certificate (expired/untrusted CA/EKU), wrong service/role-mapping/enforcement, or AD/identity-store lookup failure.

Pattern: cert errors = TLS/EAP stage; "no enforcement profile matched" = role-matching; no request seen = RADIUS transport/secret.

Analogy: auth-tracebuf is the doorman's log; Access Tracker is the security office explaining exactly why the badge was rejected.

👉 Interview tip: Say you correlate the same timestamp in both tools — that's how pros isolate transport vs policy vs cert.

Full bars but slow = almost always capacity/airtime, not coverage. Coverage problems show as weak RSSI and low data rates; capacity problems show good RSSI but high contention.

What I check:

• Channel utilization / airtime: high channel busy % means the air is congested (too many clients, overlapping/neighbor APs, or non-Wi-Fi interference).
• Client count per radio and retries — many clients or high retry/error rates kill throughput.
• SNR and noise floor — high noise (interference) drops the effective rate even with a strong signal.
• show ap arm rf-summary / the RF dashboard for utilization, and show datapath session for a single client's flows.

Analogy: signal is how loud you can hear; airtime is whether everyone is talking at once.

👉 Interview tip: "Full bars + slow = airtime/contention. I look at channel utilization and retries, not RSSI."

Sticky client = a device clings to a far AP at a low rate instead of roaming to a closer one (clients, not the network, ultimately decide to roam).

Confirm it: in show user-table / client detail, look for clients on an AP with low RSSI and low data rate while a stronger AP is nearby; ClientMatch logs show steering attempts.

Fix it:

• ClientMatch (Aruba's band/AP steering): ensure it's enabled so the controller actively steers sticky clients toward better APs and balances band.
• Raise minimum/basic data rates: disable the slowest legacy rates (for example the low 2.4 GHz DSSS rates 1/2/5.5/11 Mbps, and the lowest OFDM rate 6 Mbps) so distant low-rate clients are nudged to disconnect and reassociate to a nearer AP.
• Check coverage/cell sizing so a better AP genuinely exists.

Analogy: raising min rates is like turning off the faint far speaker so people walk to the nearer one.

👉 Interview tip: Pair ClientMatch with minimum-rate tuning — neither alone fully fixes sticky clients.

Clients dropping on a controller failure means redundancy was misconfigured. Expected behavior by model:

• AOS-8 VRRP: controllers share a virtual IP; on failure the backup takes the VIP and APs/clients re-anchor — done right, failover is near-seamless.
• LMS-IP / backup-LMS-IP: the AP system profile must define a backup-LMS-IP; without it the AP has nowhere to fail over to and reboots/drops.
• AOS-10 gateway cluster (AAC/SAC): each client is assigned an Active Anchor Controller (AAC) and a Standby Anchor Controller (SAC); the standby already holds synced client state, so on failure it takes over without a full re-auth.

To validate: confirm backup-LMS-IP is set, verify cluster AAC/SAC pairing and that client state is synced, then actively test by failing a node and watching client continuity.

👉 Interview tip: Root cause for "dropped instead of failed over" is usually a missing backup-LMS-IP or no standby anchor — and you must test failover, not assume it.

The clue is huge: only tunneled traffic loses packets, bridged is fine. Bridged traffic exits the AP locally, while tunneled traffic rides a GRE (optionally IPsec) tunnel to the gateway — so the fault is in that tunnel path, not the RF.

My approach:

• MTU first: GRE/IPsec adds encapsulation overhead; if the underlay path doesn't allow the larger frame, big packets drop while small ones pass (classic intermittent loss). Test with sized/DF-bit pings, and verify jumbo support end-to-end or lower the TCP MSS.
• Datapath: on the gateway use show datapath session plus tunnel and heartbeat counters to see drops and tunnel flaps.
• Gateway health: CPU/datapath utilization, cluster failover events.
• Upstream switching: packet-capture both ends; confirm the trunk allows the tunnel/user VLANs and that LACP isn't hashing flows onto a flapping or misconfigured member link.

👉 Interview tip: "Tunnel-only loss almost always means MTU/fragmentation or an upstream trunk/LACP issue on the tunnel path" — and I capture at both the AP and gateway to prove it.