Blog

Aruba AP Tunnels and MultiZone

1) Aruba AP Tunnels — Architecture & Forwarding

A. Big picture

In Aruba’s controller–based architecture (Campus AP / RAP), each AP:

  • Discovers one or more controllers (L2 ADP, DHCP option 43, DNS, static)
  • Authenticates & secures its control channel (CPSec with certs)
  • Builds data tunnels to the controller(s)
  • Applies a forwarding mode per SSID (tunnel / bridge / split-tunnel / decrypt-tunnel)

These tunnels let you centralize policy (firewall roles, AAA, CP), QoS, and logging at the controller — or break traffic out locally if you prefer.

B. Control vs. data planes

  • Control plane: Secure AP↔controller session used for config/RRM/keepalives (CPSec certificate trust recommended).
  • Data plane: GRE-style tunnels carrying client 802.3 frames tagged to the VLAN associated with each SSID/policy. Multiple SSIDs/VLANs can share the same AP→controller tunnel(s).

C. Forwarding modes (per SSID)

  • Tunnel (centralized):
    AP decrypts 802.11, encapsulates 802.3 into the AP tunnel, and sends all user traffic to the controller.
    Use when you want central firewalling, captive portal, NAT, or inter-VLAN routing at the controller.
  • Bridge (local breakout):
    AP decrypts and bridges traffic directly onto the AP’s wired VLAN (no central data tunnel).
    Use for simple local L2/L3 where the wired edge handles policy/DHCP/routing.
  • Split-tunnel (RAP/branch):
    AP sends corporate subnets down the tunnel to the controller, but breaks “Internet” traffic out locally (defined by policy).
    Use for remote sites to save WAN bandwidth while keeping corp traffic centralized.
  • Decrypt-tunnel (special cases):
    AP decrypts on the radio, then tunnels selected traffic types (useful for certain compliance/inspection workflows).

Roaming note: Tunnel mode enables fast, controller-assisted L2/L3 roaming with consistent policy. Bridged SSIDs rely on the wired network’s L2/L3 design for roaming continuity.

D. Redundancy & failover

  • LMS / Backup-LMS: APs try primary (“LMS”) controller first, failover to backup if down.
  • Controller HA: Hitless failover/stateful options minimize client impact.
  • AP behavior: AP keeps control/data tunnels alive; if controller fails, it retargets per LMS/backup settings.
  • Multi-controller scale: Large deployments use a Conductor + Mobility Controllers with cluster/HA.

E. Why tunnel centralized?

  • Consistent security (roles, ACLs, DPI/AppRF), uniform captive portal, central DHCP/NAT, audit/logging, guest isolation — all enforced at the controller.
  • Trade-off is backhaul consumption and controller throughput sizing; pick bridge/split-tunnel where that matters more than centralized control.

2) Aruba MultiZone — One AP, Multiple Secure Tenants

A. What MultiZone is

MultiZone lets a single physical Aruba AP connect to multiple, logically separate controller “zones” at the same time.
You get hard separation of:

  • Management plane/config per zone
  • Data plane (each SSID’s traffic is tunneled only to its zone’s controller)
  • Administrative control (tenants don’t see each other)

Think: one AP, many virtual APs (VAPs), each owned by a different controller “zone”.

B. Roles: Primary (Owner) Zone vs. Data Zones

  • Primary / Owner Zone
    • Adopts/provisions the AP (serial, image/firmware), sets RF/RRM (channels, power, 20/40/80/160 widths, DFS behavior), country code/regulatory, radio features.
    • Controls hardware resources (LEDs, radio enablement, antenna, Ethernet uplinks/PoE draw, USB, etc.).
    • Whitelists which Data Zones are allowed to ride this AP and how many radios/SSIDs they can consume.
  • Data Zone(s)
    • Each tenant/controller defines its own SSIDs, AAA, roles, VLANs, CP, policy, WIPS/WIDS thresholds, etc. for the VAPs it owns.
    • Sees and manages only its own WLAN services on the AP.
    • Cannot change RF/channel/power or firmware — that’s the Owner’s job.

Typical scale is Owner + several Data Zones (commonly up to 5 total; check your AOS & AP model release notes).

C. Tunnels & isolation

  • The AP establishes separate secure control channels to each zone and separate data tunnels for that zone’s SSIDs.
  • A client on Zone-B SSID is tunneled only to Zone-B controller — it never touches the Owner or other tenants’ data plane.
  • Management isolation: Zone-B admins cannot read/alter Owner or Zone-C config, and vice-versa.

D. Use cases

  • Multi-tenant buildings/campuses: Landlord owns APs (Owner Zone). Tenants bring their own controllers (Data Zones) and broadcast their corporate SSIDs on the same APs — no shared data plane.
  • Stadiums/venues/hospitals/airports: Venue Wi-Fi team owns RF; retail/operator/partner SSIDs run as separate Data Zones.
  • MSPs: Provider manages RF/firmware (Owner), customers get independent policy and tunnels (Data).

E. Onboarding workflow (high-level)

  1. Owner Zone
    • Adopt AP (serial), set country/RF, firmware.
    • Enable MultiZone and permit specific Data Zones (controller addresses + trust).
    • Optionally constrain resource usage (SSID limits per zone, radios usable, bandwidth caps).
  2. Data Zone(s)
    • Define the AP(s) as eligible for this zone (trust/whitelist).
    • Create SSIDs/policies/VLAN mappings as usual.
    • The AP builds additional tunnels to each Data Zone and starts advertising those SSIDs.
  3. Validate
    • Confirm each SSID is in the intended zone, client traffic tunnels to the right controller, and policy/VLANs apply as expected.

F. RF & feature boundaries

  • Only the Owner controls RF (channel, power, width, DFS, AirMatch/ARM). All zones share those radios.
  • WLAN features (AAA, roles, CP, per-SSID ACLs, L2/L3 policies) belong to the zone that owns that SSID.
  • 6 GHz note: PSC/RNR beacons and 6 GHz RF choices are Owner-controlled; Data Zones can define 6 GHz SSIDs, but RF remains centralized.

G. Failover & resilience

  • Each zone can specify primary/backup controllers.
  • If a Data Zone goes down, only its SSIDs drop; other zones continue.
  • If the Owner goes down, AP RF control/firmware authority is gone — AP behavior depends on your HA design (pair/clusters strongly recommended).

H. Licensing & compatibility (conceptual)

  • Requires controller-based ArubaOS and AP models that support MultiZone.
  • Licensing is per normal AP usage; MultiZone may add requirements depending on AOS version/edition.
  • Always check your exact AOS release + AP series for limits (zones max, SSIDs per radio, features per zone).

3) Traffic flows (mental models)

Campus AP, Tunnel mode (single zone)

arduino复制编辑Client → AP (decrypt) → AP tunnel → Controller VLAN/policy → (route/NAT/CP) → Upstream

RAP, Split-tunnel (branch)

pgsql复制编辑Client → AP
  ├─(Corp subnets)→ tunnel → Controller (corp policy)
  └─(Internet)→ local breakout/NAT at branch

MultiZone (Owner + Tenant zone B)

pgsql复制编辑Client on SSID of Zone B → AP (decrypt)
  → Zone-B data tunnel → Zone-B controller (AAA/policy/VLAN)
  (Owner never touches Zone-B user traffic; Owner controls RF/firmware only)

4) Design tips

  • Pick forwarding per SSID on purpose
    • Tunnel for central security/guest/campus.
    • Split-tunnel for WAN-sensitive branches.
    • Bridge for simple local L2 with strong wired policy.
  • Size the controller for tunneled throughput & features (DPI, CP, logging).
  • Use CPSec (cert-based trust) for APs — especially with MultiZone.
  • Plan RF centrally (Owner zone) with sane widths (20/40/80) and DFS policy that fits the venue; Data Zones inherit RF reality.
  • Reserve capacity (SSID count/radios) per Data Zone in MultiZone to prevent one tenant from exhausting AP resources.
  • HA everywhere: Owner zone cluster + Data zone backups. Test failover (AP tunnels, SSID continuity, client roam) under maintenance windows.

5) Operational & troubleshooting pointers

Useful show commands (controller-based):

  • AP status & tunnels: show ap active, show ap database, show ap details ap-name <AP>
  • WLAN/clients: show ap bss-table, show user-table, show station-table
  • Datapath/tunnels: show datapath tunnel, show datapath session table, show datapath statistics
  • CPSec / trust: show cpsec statistics, show whitelist-db cpsec
  • RF/ARM/AirMatch: show ap arm rf-summary, show ap arm history
  • MultiZone (varies by AOS): show ap multizone, show ap debug multizone (or equivalent), plus per-zone SSID inventory

Packet capture angles:

  • Confirm zone ownership via management IEs (beacons) and controller IPs the AP talks to.
  • For tunneled SSIDs, capture on the controller’s datapath to see VLAN mapping, roles, CP.
  • For DFS moves (Owner RF control), watch CSA beacons before channel change.

Common gotchas:

  • AP adopted by the wrong controller (LMS/whitelist mismatch).
  • Data Zone defined but not authorized by Owner → SSIDs never appear.
  • Oversized channels (80/160) in dense spaces causing CCI; downshift widths in Owner zone.
  • Split-tunnel policy not matching routes → unintended local breakout or black-hole.
  • Missing CPSec trust → AP can’t form tunnels (check cert/whitelist).

TL;DR

  • AP tunnels give you flexible, per-SSID forwarding: centralize policy (tunnel), keep it local (bridge), or mix (split-tunnel).
  • MultiZone lets one AP serve multiple independent controller domains at once: Owner controls RF/firmware; each Data Zone owns its SSIDs and gets private tunnels.
  • They’re complementary: use tunnels to shape traffic, use MultiZone to partition ownership and data planes safely on the same hardware.

Leave a Reply