Aruba SD-WAN (ACSDP) study materials
Aruba SD-WAN (ACSDP) study resources

Aruba SD-WAN (ACSDP) cheat sheet

Aruba SD-WAN (ACSDP) · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.