Aruba APs & ArubaOS — Campus, Remote & Instant in 11 Minutes

Before the modes — one AP, three jobs

Imagine one smart speaker that can be a home speaker, an office speaker, or a portable party speaker — depending on which app you load. An Aruba access point is like that. The hardware is identical; the mode decides its job. Today you learn the three "apps": Campus, Remote, and Instant.

Here's the one idea that unlocks everything: an Aruba AP's mode is just a question of where the "brain" lives and which link it trusts. A Campus AP trusts the office LAN. A Remote AP trusts an IPsec tunnel over the open Internet. An Instant AP trusts itself — the controller logic runs on the AP.

Architecturally, all three personalities ship in the same firmware image since ArubaOS 8, and ArubaOS 10 unifies management in Aruba Central. The mode is a provisioning decision, not a hardware SKU. What changes is the discovery path (how the AP finds its manager), the trust boundary (LAN vs IPsec vs none), and the data plane (locally bridged vs GRE-tunnelled to a gateway cluster). Get those three axes straight and every Aruba design question becomes a lookup, not a guess.

① Campus AP — the trusted-LAN workhorse

A Campus AP is like a desk phone in the office: it plugs into the company wall jack, finds the company switchboard, and just works. The "switchboard" here is the controller / gateway, and the wall jack is the trusted office LAN.

A Campus AP (CAP) lives on a private link — LAN, WLAN, WAN or MPLS — and terminates directly on a controller or, in ArubaOS 10, a gateway cluster. No IPsec is required because the path is trusted. This is the default build for office buildings, warehouses, hospitals and universities.

Design-wise, the CAP's strength is centralised policy: user roles, firewall rules and VLANs are enforced at the gateway, so a roaming client keeps the same IP and role across the campus. The trade-off is hairpinning — even local traffic may ride the tunnel to the gateway unless you choose bridge or mixed forwarding (covered in section 4).

② Remote AP — HQ in a box, over the open Internet

A Remote AP is the office Wi-Fi shrunk into a box you take home. Plug it into your home router, and it builds a secret armoured tunnel back to the office so your laptop behaves exactly like it's on the company floor.

A Remote AP (RAP) gets a DHCP address on its Eth0, then dials the master controller and forms an IPsec tunnel. After it authenticates, it receives an inner IP and an IKE security association, and the master hands it the LMS-IP (and backup LMS-IP) of the controller it should terminate on. Only then do the SSIDs come up.

The RAP's trust model flips Campus on its head: the path is hostile, so everything rides IPsec, and provisioning is gated by a RAP whitelist. Architecturally that whitelist is the soft underbelly — see the trap below. RAPs also support split-tunnel and bridge SSIDs so home-printer traffic stays local while corporate traffic tunnels home.

③ Instant AP — the controller that lives inside the AP

An Instant AP is a group project where one student volunteers to be the leader. The "leader" AP runs the brains for everybody. If the leader leaves, the group instantly picks a new leader — nobody notices.

Instant APs run the Instant OS, which virtualises controller capabilities right on the AP. The cluster elects one AP as the Virtual Controller (VC). You browse to the VC's IP, configure once, and the config replicates to every member. No appliance, no per-AP CLI. Aruba positions Instant for small and medium sites — it scales to several dozen APs.

Instant's elegance is also its ceiling: with the control plane on the AP, you lose the centralised data-plane policy and large-scale roaming domains a gateway cluster gives you. The migration path is clean, though — an Instant AP can be converted to a Campus or Remote AP, or onboarded to Aruba Central as an ArubaOS 10 AP, when the site outgrows controller-less.

④ ArubaOS 10 forwarding + ap convert + hardening

Now the modern twist. In ArubaOS 10 the cloud (Aruba Central) is the manager. You also choose how each Wi-Fi network sends traffic: keep it local at the AP (bridge), or ship it to a central gateway (tunnel). Like deciding whether to cook at home or send the order to a central kitchen.

ArubaOS 10 APs forward client traffic two ways. In bridge mode the AP places traffic on the local VLAN at its uplink and acts as the authenticator. In tunnel mode the AP encapsulates traffic in GRE and tunnels it to the primary gateway cluster, which becomes the authenticator. Mixed mode decides per-VLAN: bridge if the VLAN isn't on the cluster, tunnel if it is.

The forwarding choice is really a scale + mobility decision. Aruba validates bridge forwarding to a maximum of 500 APs and 5,000 bridged clients across shared VLANs; beyond that you deploy a gateway cluster with centralised user VLANs for higher scale and seamless roaming. When clients tunnel to the same primary cluster, they keep their VLAN, IP and default gateway as they roam — even across config groups. So tunnel mode buys mobility and central policy at the cost of gateway hardware and tunnel overhead.

Converting an AP between modes — ap convert

Need to repurpose an Instant AP as a Campus or Remote AP? You don't re-buy hardware — you convert it. On ArubaOS the controller-side command provisions APs into a new persona; on an Instant AP you point it at the controller IP and pick the target mode.

(Aruba-Controller) #ap convert active-all
(Aruba-Controller) #ap convert add-mac 20:4c:03:1a:2b:3c controller-ip 10.20.5.10
(Aruba-Controller) #show ap convert-status

Conversion Status
-----------------
MAC                 Mode-From   Mode-To   Controller-IP   State
20:4c:03:1a:2b:3c   instant     campus    10.20.5.10      converting
20:4c:03:1a:2b:3d   instant     campus    10.20.5.10      converted
Total APs converting: 1   converted: 1