SD-WAN Architecture and Deployment Planning
Core model
Aruba SD-WAN (the EdgeConnect lineage) separates the underlay (physical transports and WAN links) from the overlay (logical tunnels between appliances). The control plane is handled by Orchestrator, which pushes configuration and manages appliance identity and licensing; the data plane is the EdgeConnect appliance itself, which makes per-packet forwarding and path decisions locally. A Controller role can be hosted on an appliance or in the cloud for topology and tunnel management. Understand which component does what: Orchestrator does not forward traffic, and the appliance keeps forwarding if Orchestrator is unreachable (a classic trap).
Planning concepts
Know the difference between site types (hub, spoke/branch, data-center) and how high availability is planned: dual appliances at a site versus dual WAN links on a single appliance. Bandwidth planning must account for per-tunnel overhead because overlay encapsulation consumes payload capacity. Deployment modes include physical appliance, virtual appliance, and cloud-hosted gateways; questions often test which mode supports a given HA or throughput requirement.
Traps
- Confusing management-plane outage with data-plane outage; local forwarding survives Orchestrator loss.
- Assuming overlay tunnels are always full-mesh; hub-and-spoke and partial-mesh are valid designs.
- Forgetting that licensing and business-intent policy are configured centrally but enforced at the edge.
Rule of thumb
Design overlay topology from traffic flows, not from org chart: if most traffic goes to a data center, a hub-and-spoke overlay with local internet breakout for SaaS is usually correct. Worked example: a branch with two ISPs and one appliance needs two underlay interfaces, two tunnels to the hub, and a business-intent policy preferring the lower-latency link for voice.