Aruba Central Greenfield Deployment -- Solutions Document
This document explains the design logic behind each architectural decision, how the conditional CLI template system works, and identifies potential functions and improvements that would enhance the current solution.
Solution Overview
This deployment uses Aruba Central in AOS10 architecture with a single template group (Greenfield-Global) managing all APs and CX switches across 3 sites. The design prioritizes consistency, zero-touch automation, and scalability through a unified conditional CLI template that adapts to 5 switch roles and variable stack sizes using just 2 conditional axes: %SWITCH_ROLE% and %MEMBER_COUNT%.
Design Decision: Single Group
Architecture Layers
Aruba Central Cloud
Collectors (x2)
Sites (x3)
Aggregation
Access Layer (4 roles)
Floor Infrastructure (x5)
The solution covers the complete lifecycle: pre-provisioning serial numbers in Central, generating bulk CSV uploads with all per-device variables, zero-touch firmware upgrade and config push on first boot, and ongoing template compliance monitoring. No on-site IT interaction is required for initial deployment.
Design Layers & Definitions
Aruba Central organizes network infrastructure in a layered hierarchy. Each layer has a specific role in how configuration, monitoring, and policy are applied. Understanding these layers is critical to interpreting this design.
| Layer | Definition | Role in This Design |
|---|---|---|
| Group | A logical container in Central that groups devices together for shared policy, firmware, and template assignment. Devices in the same group receive the same firmware compliance level, WLAN profiles, and CLI templates. | One group (Greenfield-Global) for all 3 sites. All CX switches and APs share a single firmware target, one unified CLI template, and the same WLAN profiles. This ensures zero config drift. |
| Site | A named physical location in Central with an address, timezone, and country code. Devices are assigned to sites for geographic organization, topology mapping, and location-aware reporting. | Three sites: 2Cal (under SCG collector), Branch-Central and Branch-West (under SDGE collector). Each site contains its own buildings and floors. The %SITE_NAME% CSV variable is keyed to the site, enabling per-site SNMP location, syslog routing, and naming conventions. |
| Site Collector | A lightweight VM or appliance deployed on-prem that proxies management traffic between Central cloud and local devices. Collectors sit above sites in the hierarchy -- each collector can serve one or more sites. They enable local survivability and cache operations during WAN outages. | Two collectors: SCG (serves 2Cal) and SDGE (serves Branch-Central + Branch-West). Collectors are the layer between the group and sites. Each handles config push, firmware downloads, and telemetry collection for its assigned sites. |
| Building | A structural subdivision of a site. Buildings are used for physical topology mapping in Central's visual floor plan tools and for organizing floors. | One building per site in this deployment. The building contains all floors and is the container for floor-plan RF heat mapping and AP placement visualization. |
| Floor | A subdivision of a building. Floors host APs and switches. Central uses floor assignments for RF proximity analysis, channel planning, and AP neighbor detection. | Five floors per building. Each floor has its own set of data-role and AP-role switch stacks, plus 10-14 APs. The %FLOOR% CSV variable drives per-device naming and SNMP location tagging. |
| Label / Attribute | Key-value metadata tags that can be assigned to any device in Central. Labels enable dynamic grouping, filtering, and policy targeting without changing the device's group or site. | Used to tag devices by switch role (agg, data, AP_switch, MDT, garage), stack membership, and floor assignment. Labels enable Central dashboards to filter by role across sites (e.g., show all agg switches globally) without changing group or template assignment. |
| Template (CLI) | A Jinja-like CLI configuration file with %VARIABLE% placeholders and %if/%endif conditional blocks. Central resolves variables from the device's CSV record, then pushes the rendered config. | One unified template (CX-Greenfield-Unified.tmpl) with two conditional axes: %SWITCH_ROLE% selects port-config blocks, %MEMBER_COUNT% includes/skips VSF sections. The template resolves into 9 effective configs (5 roles x stack/standalone minus agg-standalone). |
| CSV / Device Variables | A per-device record uploaded to Central containing values for every %VARIABLE% in the template. Each row maps a serial number to its hostname, role, site, IP addresses, port assignments, and service parameters. | The CSV is the single source of truth for all per-device differentiation. It contains 50+ columns covering identity, stack membership, port groups, universal services (DNS/NTP/SNMP/TACACS), management IPs, and L3 SVI addresses (agg only). |
| Conditional CLI (%if/%endif) | Control-flow directives inside the CLI template that include or exclude config blocks based on variable values. Supports equality (%if VAR == value%), inequality, and numeric comparison. | Used for two axes: (1) %if SWITCH_ROLE == X% gates port-config, STP priority, loop-protect, and uplink definitions per role. (2) %if MEMBER_COUNT >= N% gates VSF member blocks, inter-member links, and serial validation. Nested conditionals combine both axes. |
| Switch Role | A logical tag (stored in the CSV %SWITCH_ROLE% column) that identifies a switch's function in the network topology. Not a Central-native concept -- it is enforced entirely through the conditional CLI template. | Five roles defined: agg (aggregation/distribution -- L3 SVIs, OSPF, VRRP, STP root), data (user-facing access ports -- loop protect, 802.1X), AP_switch (PoE AP trunks -- LLDP-MED, PoE priority), MDT (BMS/BAS trunks -- building systems), garage (hardened access -- extended PoE, weatherized). |
| VSF Stack | Virtual Switching Framework -- HPE/Aruba's chassis virtualization technology that bonds 2-8 physical CX switches into a single logical switch with distributed forwarding and a single management IP. | Used for data-role (3-4 members), AP_switch-role (2-3 members), and agg-role (2 members, HA pair). The %MEMBER_COUNT% variable controls stack depth, and %MEMBERn_SERIAL% / %MEMBERn_PRIORITY% variables define the per-member identity. Standalone (count=1) is used for MDT and garage roles. |
Layer Interaction Summary
%SWITCH_ROLE% and %MEMBER_COUNT% from the CSV to resolve the correct config blocks. Labels are used for dashboarding and filtering, not for config selection.Single Group Architecture
The Greenfield-Global group contains both APs and CX switches with template mode enabled. This means switch configurations are driven entirely by CLI templates with%VARIABLE% placeholders, while AP configurations (SSIDs, RF profiles) are managed centrally through the group's wireless settings.
- Architecture: AOS10 -- all devices are cloud-managed. No local controllers or mobility masters.
- Device Types: APs + CX Switches in the same group for unified firmware compliance.
- Template Mode: CX switches receive CLI configs from templates. AP SSIDs/RF are managed via the group's wireless profile.
- Collectors: SCG (2Cal) and SDGE (Branch-Central, Branch-West) -- each site with 5 floors.
- Firmware Compliance: Central enforces a single firmware version across all devices in the group. Devices auto-upgrade on ZTP.
Risk: Single Group Blast Radius
Role-Based Template Strategy
The core innovation is a single conditional CLI template that handles all 5 switch roles (agg, data, MDT, AP_switch, garage_switch) and both deployment modes (stack vs. standalone). The template uses two conditional axes:
Axis 1: %SWITCH_ROLE%
Determines which port-config blocks execute. Agg gets trunks + OSPF + VRRP + STP root. Data gets access ports + loop protect. AP_switch gets PoE AP trunk profiles + LLDP-MED. MDT gets BMS/BAS trunk ports. Garage gets hardened access + extended PoE.
Axis 2: %MEMBER_COUNT%
Determines whether VSF sections are included. When > 1, the template generates vsf member blocks with serial-number validation, priority assignments, and link definitions for 2-4 members. When = 1, all VSF sections are skipped.
Template Conditional Logic Flow
%SWITCH_ROLE%selects port-config blocks%MEMBER_COUNT%includes/excludes VSF blocks= 1 (standalone)
Skip all VSF sections
>= 2 (stack)
VSF members + links + serials
Resolved Config
Only the blocks matching role + count are included. All %VARIABLE% placeholders resolved from CSV.
This two-axis model means adding a new role requires only one new %if SWITCH_ROLE == new_role% block -- zero impact on existing roles. Adding a 5th stack member requires extending the%if MEMBER_COUNT >= 5% conditionals -- no change to standalone logic.
Design Decision: Agg Role -- No AAA/NAC
Template Assignment Logic
VSF Serial Validation
Every vsf member N block in the CLI template includes aserial-number %MEMBERn_SERIAL% line. This creates a two-stage serial validation chain:
Two-Stage Serial Validation Chain
Stage 1: ZTP Call-Home
Commander (member 1) boots, gets DHCP, contacts Aruba Activate. Central matches physical serial against CSV MEMBER1_SERIAL to find device record and push config.
Stage 2: VSF Join
Member 2/3/4 boots and attempts to join the stack. Commander checks physical serial against %MEMBERn_SERIAL% in the pushed config.
Mismatch Rejected
If serials do not match, the member is rejected -- STACK_SERIAL_MISMATCH alert fires in Central. Member stays standalone until CSV is corrected.
- Stage 1 -- ZTP Call-Home: The commander switch (member 1) boots, gets DHCP, contacts Aruba Activate, and is redirected to Central. Central matches the commander's physical serial against the CSV's
MEMBER1_SERIALto find the correct device record and push the config. - Stage 2 -- VSF Join: When member 2/3/4 boot and attempt to join the stack, the commander checks the physical serial of the joining switch against
%MEMBER2_SERIAL%(or 3/4) in the pushed config. If there is a mismatch, the member is rejected -- it will not join the VSF ring. - Mismatch Handling: A serial mismatch generates a STACK_SERIAL_MISMATCH log event on the commander and a device health alert in Central. The rejected member powers on but remains standalone, requiring manual intervention (correct the CSV serial or physically swap the switch).
Risk: Wrong Serial in CSV
CSV Bulk Provisioning Workflow
The CSV template provides a complete row schema for all 5 switch roles. Each row represents one device (or stack commander). The CSV columns map 1:1 to%VARIABLE% placeholders in the CLI template. The schema is organized into 5 column groups:
- Device Identity (required): Serial, Group, Site, HOSTNAME, SWITCH_ROLE, MEMBER_COUNT, SITE_NAME, FLOOR. These are mandatory for every device and drive template selection.
- Stack / VSF Members (stack only): MEMBERn_SERIAL, MEMBERn_PRIORITY, VSF_LINK_n_m. Set to -- for standalone devices. Serials must match physical hardware for VSF join validation.
- Port Groups: UPLINK_PORTS, LAG_UPLINK_ID/PORTS, ACCESS_PORTS, AP_PORTS, TRUNK_PORTS. Use -- for port types that do not apply to the role (e.g., ACCESS_PORTS = -- for agg).
- Universal Services: DNS, NTP, SNMP, syslog, TACACS. These are typically site-level and can be set once per site in Central's variable store rather than repeating in every CSV row.
- Per-Device Services: STP_PRIORITY, LOOP_PROTECT_PORTS, MGMT_VLAN_IP/MASK. These vary by individual switch position in the topology.
The CSV includes SWITCH_ROLE and MEMBER_COUNT columns so that bulk processing tools can validate rows before upload -- for example, ensuring agg rows always have MEMBER_COUNT = 2, or that standalone rows have -- for all stack-only columns.
Zero-Touch Provisioning Flow
The ZTP workflow is a 7-step process from pre-provisioning to operational status:
ZTP Workflow Sequence
AP Role Segmentation
APs are segmented into 4 purpose-built roles, each with its own AP group in Central. This allows radio profiles, SSID assignments, and operational parameters to be tuned for the specific use case without compromising other roles:
General office coverage. Balanced channel widths (20/40/80 MHz across bands), moderate power, standard client density.
High-density optimized. Narrow channels (20 MHz on 5 GHz), low power to contain RF, aggressive band steering, max-client caps.
360-degree outdoor coverage for courtyards and plazas. Omni antenna, higher power, DFS disabled, 200ms beacon.
Bi-directional outdoor coverage for corridors, walkways, and loading docks. Sector antenna, focused RF in two opposing lobes.
Dedicated WIDS/WIPS scanning. No client service. Scans all channels (including DFS) for rogue detection.
Radio Design Decisions
Radio configuration decisions are driven by one primary factor: client density. Every parameter -- channel width, transmit power, band steering aggressiveness, DTIM interval, max-client caps -- is tuned based on how many clients share the airtime in that AP role.
- Channel Width: 2.4 GHz is always 20 MHz (only 3 non-overlapping channels). 5 GHz varies: 40 MHz for office (balances throughput vs. channel reuse), 20 MHz for conference (maximum spatial reuse in density). 6 GHz uses 80 MHz for office (14 non-overlapping channels) and 40 MHz for conference (29 channels).
- Transmit Power: ARM adaptive mode with min/max floor/ceiling. Conference rooms use significantly lower power (3-12 dBm) to contain RF within the room. Outdoor uses higher power (15-21 dBm) to compensate for free-space path loss.
- DFS Channels: Enabled indoors (doubles available 5 GHz spectrum), disabled outdoors (radar detection causes frequent channel switches near airports/weather stations).
- OFDMA + BSS Coloring: Enabled everywhere for Wi-Fi 6/6E/7 efficiency. BSS Coloring is critical in conference rooms to distinguish adjacent BSSes on the same channel.
- DTIM Interval: DTIM 1 for office (responsive multicast for Bonjour/AirPlay), DTIM 3 for conference (reduces multicast overhead with 50+ clients), DTIM 3 + 200ms beacon for outdoor (battery savings).
VLAN Architecture
The VLAN design uses 7 VLANs with consistent IDs across all sites. The subnet structure uses 10.x.VLAN_ID.0/24 where x is the site octet (1=HQ, 2=Branch-Central, 3=Branch-West). This makes IP addressing predictable and simplifies troubleshooting.
| VLAN | Name | Purpose | Subnet Pattern |
|---|---|---|---|
| 10 | Management | Network device management | 10.x.10.0/24 |
| 20 | Employee-Data | Wired employee endpoints | 10.x.20.0/24 |
| 30 | Employee-Voice | VoIP traffic | 10.x.30.0/24 |
| 40 | Wireless-Corp | Corporate SSID clients | 10.x.40.0/24 |
| 50 | Wireless-Guest | Guest SSID clients | 10.x.50.0/24 |
| 60 | IoT | IoT devices and sensors | 10.x.60.0/24 |
| 99 | Native-VLAN | Native/default VLAN | N/A |
Potential Improvements
The following improvements would enhance the current solution. They are prioritized by impact and effort, with implementation notes for each.
CSV Validation Engine
highBuild a JavaScript function that validates CSV rows against the template schema -- checking serial format (alphanumeric, 10-14 chars), IP address format, port-range syntax (M/S/P-M/S/P), and role-specific constraints (agg MEMBER_COUNT must be 2, standalone rows must have -- for stack columns).
Prevents deployment failures from CSV typos before upload
Add client-side validation function to parse CSV and check constraints
Create a validateCsvRow(row, schema) function that returns an array of validation errors. Integrate with a CSV upload UI that shows per-row validation results before Central upload. Export as a standalone utility for CI/CD pipeline integration.
Template Diff Preview
highBuild a resolveTemplate(template, variables) function that takes the conditional CLI template and a device's variable map, evaluates all %if% conditionals, substitutes all %VARIABLE% placeholders, and returns the final resolved config text.
Shows the resolved config for any device before pushing to production
Template resolution engine that substitutes %VARIABLE% with CSV values
Implement a simple parser for %if CONDITION%, %endif% blocks. Support ==, !=, >, >=, <, <= operators. Render the resolved output in a syntax-highlighted code viewer. Allow comparison between two devices to see exactly what differs (e.g., agg vs. data).
Serial Number Barcode Scanner Integration
mediumAdd a barcode scanner component that reads serial numbers from switch box labels using the device camera. Scanned serials auto-populate the CSV MEMBER_SERIAL fields and cross-reference against Aruba Activate inventory.
Eliminates manual serial entry -- the #1 source of deployment errors
Camera API integration for barcode/QR scanning on mobile devices
Use a browser-based barcode scanning library (e.g., zxing-js). Build a scan flow: select role/site, scan commander serial, scan member 2/3/4 serials. Auto-generate the CSV row with all serials validated against Activate API.
IPAM Integration
mediumInstead of manually entering MGMT_VLAN_IP, DATA_VLAN_IP, etc., query the IPAM system for the next available IP in each VLAN's subnet for the target site. Auto-populate all IP and mask columns.
Auto-generates all IP-related CSV columns from IPAM allocations
REST API integration with IPAM tools (InfoBlox, NetBox, phpIPAM)
Build an IPAM adapter interface with implementations for popular IPAM tools. Add a 'Auto-fill from IPAM' button to the CSV generation UI that queries each VLAN subnet and allocates IPs. Handle subnet exhaustion gracefully.
Config Compliance Dashboard
mediumAfter deployment, continuously compare each device's running-config (pulled from Central API) against the expected resolved template. Highlight drift: added lines, removed lines, modified values.
Real-time visibility into which devices match their expected template config
Central API integration to pull device running-config and compare against template
Use Central's device config API to fetch running-config periodically. Diff against the resolved template (from the Template Diff function above). Display drift in a dashboard with per-device compliance status and a 'remediate' button that re-pushes the template.
Staged Rollout Orchestration
mediumWhen a template change is made, instead of pushing to all devices immediately, orchestrate a staged rollout: push to 1 canary device, wait for health check, push to 1 site, wait, then push to remaining sites.
Reduces blast radius of template changes across all sites
Workflow engine for phased template pushes with health-gate validation
Build a rollout workflow: define stages (canary -> site-1 -> site-2 -> site-3), health gates (device responds to SNMP, no config errors in 5 minutes), and rollback triggers (health gate failure auto-reverts to previous template version).
Port Map Auto-Generation
lowGiven a switch model (CX 6300-M 48-port) and member count (4), auto-generate ACCESS_PORTS (1/1/1-1/1/48,2/1/1-2/1/48,...), VSF_LINK ports, and UPLINK_PORTS based on the hardware datasheet port layout.
Eliminates manual port-range calculation for multi-member stacks
Function to compute port ranges from switch model + member count
Create a generatePortMap(model, memberCount, role) function with a hardware database mapping model names to port counts, SFP+ slot positions, and stacking port ranges. Output a complete port-group variable set for the CSV row.
Central API Direct Upload
lowInstead of generating a CSV file for manual upload, push device records directly to Central's pre-provisioning API. Each device gets its variables set via API call, eliminating the CSV intermediary.
Eliminates CSV file handling -- push variables directly to Central API
OAuth2 integration with Aruba Central REST API
Implement Central API client with OAuth2 token management. Build a push workflow: validate all devices locally, then batch-upload via POST /configuration/v1/devices. Handle rate limiting, partial failures, and rollback.
Architecture Note: Function Modularity