HPE Aruba multi-site Wi-Fi with standard configurations and branch recovery

This reference design is a starting point for project discovery, not a completed customer case. Final quantities and settings require site measurements, endpoint compatibility checks and a release-specific implementation design.

1. Requirements analysis

Workload and capacity example

Illustrative store: 12 POS units, 8 stock handhelds, 6 office clients and up to 60 associated guests. Measure payment transactions, stock synchronization and guest peaks separately. Establish policies and paths before sizing WAN and APs. A shared template does not establish identical AP quantities across store layouts.

Deliverables at this stage: a measured floor plan, client/application inventory, current topology and dependencies, agreed test objectives and constraints. Keep associated-client counts, active-client counts and concurrent application demand as separate inputs.

2. Solution design

Branch clients → Aruba APs → local PoE switching → local Internet or controlled application backhaul. Central standardizes management. Branch gateways are evaluated where tunneling or WAN policy is required.

Define repeatable branch classes

Group sites by layout, client load and business devices. Maintain an installation and power checklist, addressing plan and approved configuration for each class. Track exceptions so a remote change can be traced and reversed.

Draw the application paths

Decide which services break out locally and which require headquarters access. Verify AP, gateway, management version, subscription and ISP requirements. Assign ownership for DNS, routing, NAT, authentication and security policy. Management reachability alone does not establish application availability.

Validate four outage cases

Test loss of cloud management, Internet, headquarters services and a WAN transport separately. Observe existing sessions, new authentication and local applications for the selected architecture. A second WAN does not remove access-switch or identity-system dependencies. Pilot representative sites before a phased rollout with assets, installation evidence and rollback instructions.

3. Network topology and forwarding

A basic store can bridge AP traffic over PoE switching to an existing firewall and SaaS. Headquarters private access and WAN orchestration require a separately designed branch gateway, hub VPNC, routing and transport. Quote and accept these scopes separately; cloud management alone is not SD-WAN. The diagram shows the bridge baseline.

Dashed paths denote logical management or authentication dependencies, not physical direct cables. Central is the management service, not the client data-plane transit point. If tunneling is chosen, redraw and validate the AP-to-gateway path and the authenticator location for that mode.

SSID, segment and access-policy example

Names and VLAN IDs above are illustrative and must be mapped to the customer address plan. A VLAN is not a complete security boundary: enforce the approved ACL/firewall/role policy at the selected forwarding points and verify both allow and deny behavior. Publish only the minimum necessary SSIDs and verify legacy-client exceptions separately.

4. Implementation plan

1. Site classification：Group stores by layout, workflows, circuits and headquarters dependency; choose a representative pilot.
2. Address and architecture plan：Choose bridge baseline or SD-Branch, assign nonconflicting site addressing and agree hub responsibilities.
3. Templates and staging：Stage names, sites, templates and variables; verify ownership, licenses, software and management access.
4. Workflow pilot：Test POS, stock and guest access; for hub connectivity verify routing, tunnels, MTU and return paths.
5. Failure exercise：Interrupt an agreed circuit/device in an approved window; record transaction recovery, sessions and alerts.
6. Fleet rollout：Validate site variables before each batch; retain configurations, contacts and rollback and audit template drift.

Change control and rollback gate

Before each batch, name the change owner, business approver and recovery operator. Preserve the approved pre-change configuration and verify that the hardware/software supports the intended recovery. Stop or roll back if critical transactions fail, identity rules are wrong or agreed recovery limits are exceeded. Capture timestamps and logs before altering the next variable.

5. Configuration and procurement checklist

6. Acceptance and operational handover

1. Run the standard commissioning checklist in two representative branch classes.
2. Test management, Internet, headquarters and primary-WAN failures independently.
3. Verify employee, guest and business-device isolation and remote rollback.
4. Confirm account ownership, subscription renewal, ISP and on-site service contacts.

Agree numeric coverage, SNR, packet-loss, latency and recovery thresholds with the application owner before the pilot. Record locations, representative clients, load and software so results can be reproduced.

7. Prepare a project request

Send scaled plans, device and application schedules, current software and topology, power and cabling records, destination and rollout constraints. We use these inputs to discuss a project-specific configuration and quotation.

Prepare the network BOM

8. Regional and architecture checks

Product families above are candidates for evaluation. Confirm exact destination SKUs, certifications, permitted channels and software support before ordering. For mainland China, global 6 GHz capability does not establish local permission to enable it. AOS 8, AOS 10 and Central features require version-specific verification.