Aruba SD-WAN (ACSDP) cheat sheet
Aruba SD-WAN (ACSDP) · Keep the key ideas within reach.
SD-WAN Architecture and Deployment Planning
Aruba SD-WAN separates the control plane (orchestrator/controller) from the data plane (branch gateways and VPNCs), so forwarding continues if the controller is unreachable.
Roles: Orchestrator (Aruba Central) provisions and pushes configuration; Gateways terminate tunnels and enforce policy; VPN Concentrators aggregate branch tunnels in the data center.
A Branch Gateway performs underlay WAN termination, overlay tunnel termination, and policy enforcement in one device, replacing separate router and firewall functions.
Hub-and-spoke, full mesh, and partial mesh are the three overlay topologies; full mesh requires every site to hold tunnels to every other site and scales poorly past mid-size deployments.
Bandwidth sizing rule: sum per-site committed WAN bandwidth plus 20-30 percent headroom for overlay overhead and burst before selecting gateway throughput tier.
High availability options are standalone, active-standby VRRP pair, and active-active cluster; VRRP pair requires a dedicated redundancy/HA link between peers.
Deployment planning must confirm underlay IP addressing, NAT traversal requirements, and whether ISP links are static, DHCP, or PPPoE before overlay design.
A branch with local internet breakout keeps SaaS traffic on the local WAN path, while centralized breakout backhauls it to the hub - the choice drives tunnel and policy counts.
Underlay, Overlay, and Fabric Configuration
Underlay interfaces are configured with WAN type (static, DHCP, PPPoE), bandwidth values used for path scoring, and health-check targets for liveness probing.
Overlay tunnels are established between gateways using IPsec; tunnel endpoints must be mutually reachable, and NAT-T (UDP 4500) applies when either side is behind NAT.
The fabric is the logical mesh of gateways and tunnels; adding a gateway to the fabric requires it to be registered to the orchestrator and assigned a role.
Per-tunnel health checks send probes at a configured interval; failure thresholds determine how many missed probes mark a path down and trigger steering changes.
Uplink bandwidth configured on the underlay directly feeds path selection scoring - an overstated value causes oversubscription during steering.
Tunnel MTU must account for IPsec overhead (commonly ~50-70 bytes); fragmentation issues appear as large-packet failures while pings succeed.
Branch-to-branch traffic can traverse hub tunnels (spoke-to-spoke via hub) or direct tunnels; direct tunnels reduce latency but increase tunnel count.
Site-to-site overlay addressing is typically a separate tunnel subnet so routing and policy can distinguish overlay from underlay next hops.
Routing, Traffic Steering, and Path Selection
Path selection evaluates candidate WAN links per flow using policy order: business intent or application match first, then path quality, then default fallback.
Path quality metrics include latency, jitter, packet loss, and MOS; thresholds defined in the policy determine when a path is considered degraded.
Steer modes include best path (single best-quality link), load balance across links, and replication of a flow over multiple links for loss-sensitive traffic.
When the primary path violates a threshold, the flow is re-steered to the next qualifying path; sessions may be re-established depending on flow stickiness.
Routing inside the overlay uses static routes and dynamic protocols; BGP is the common choice for advertising branch and data-center prefixes across tunnels.
Route preference order: more specific prefix wins, then lower administrative distance, then lower metric - overlay routes should not accidentally lose to underlay defaults.
Application identification feeds steering; unrecognized traffic falls to the default business intent, so default policy must be explicitly defined.
Local internet breakout policies route SaaS-destined flows directly out the local WAN instead of the overlay, reducing hub load and latency.
Security, Segmentation, and Policy Enforcement
Segmentation uses VRFs or zones to isolate user groups; inter-segment traffic is denied by default and permitted only by explicit policy.
Policy is evaluated top-down with first-match semantics; a broad permit placed above a specific deny silently defeats the deny.
Stateful firewall inspection on the gateway tracks flow state; asymmetric routing across gateways breaks stateful inspection and causes drops.
Business intent overlays bundle segmentation, path selection, and security posture into one reusable policy applied per site or group.
Role-based access control on the orchestrator separates operator duties (monitoring vs. configuration) and should follow least privilege.
IPsec protects overlay traffic in transit; tunnel authentication uses pre-shared keys or certificates, and keys must be rotated per organizational policy.
Guest or IoT segments typically use local breakout with restricted policy, keeping untrusted devices off the corporate overlay entirely.
Microsegmentation policies should be tested with logging or a monitor-only action before enforcement to avoid unintended outages.
Orchestration, Automation, and Management
The orchestrator is the single source of configuration truth; devices pull intended state, so out-of-band CLI edits can be overwritten on next sync.
Configuration is organized into groups and scopes; a device inherits group policy and can receive device-level overrides, with the most specific scope winning.
Zero-touch provisioning: a factory-default gateway obtains its orchestrator address (DHCP option or cloud redirect), authenticates, and pulls its assigned configuration.
Templates and variables allow one configuration to deploy to many sites; per-site values (WAN IPs, bandwidth, subnets) are supplied as variables.
API-driven automation uses REST calls with token authentication; bulk operations should be idempotent and validated in a lab group first.
Firmware upgrades are scheduled per group with maintenance windows; a device reboots to apply, so HA pairs should upgrade one member at a time.
Configuration backup and version history enable rollback; capture a known-good snapshot before any bulk policy or routing change.
Audit logs record who changed what and when; they are the primary evidence trail for change management and incident review.
Monitoring, Troubleshooting, and Operations
Troubleshooting order: verify underlay reachability, then tunnel state, then routing, then policy, then application - each layer can mask the next.
Tunnel down with underlay up usually indicates IPsec parameter mismatch (PSK, encryption, NAT-T) or blocked UDP 500/4500 on the path.
High latency with low loss points to path selection choosing a poor link; check configured bandwidth accuracy and health-check thresholds.
Flapping tunnels are diagnosed by comparing health-check interval and failure threshold against actual link stability; thresholds too tight cause churn.
Asymmetric routing symptoms (one-way traffic, stateful drops) are confirmed by comparing forward and return path selection on both gateways.
Interface counters and per-tunnel statistics distinguish physical link errors from overlay problems; CRC errors indicate cabling or ISP issues.
Path-quality dashboards show latency, jitter, loss, and MOS per link; a MOS drop below threshold should trigger a steering review.
Packet captures taken on both tunnel endpoints are the definitive test for whether traffic is dropped before or after encryption.