Aruba SD-WAN (ACSDP) common mistakes
Aruba SD-WAN (ACSDP) · Understand the traps and how to avoid them.
Treating the underlay as an afterthought and assuming the SD-WAN overlay will fix bad ISP circuits, instead of validating underlay link characteristics (latency, loss, jitter, MTU, bandwidth) before designing path selection.
Candidates focus study time on overlay tunnels and routing because those are the 'SD-WAN' features, and skip the underlay prerequisites that path selection depends on.
What to do instead
For each scenario, first enumerate underlay transports (MPLS, broadband, LTE/5G), their measured SLA characteristics, and MTU/encapsulation overhead; then map which traffic-steering policies those links can actually satisfy.
Choosing a deployment topology (single-site hub-and-spoke vs. full mesh vs. regional hubs vs. dynamic mesh) by default rather than deriving it from the stated traffic flows, site count, and latency requirements.
Candidates memorize one topology as 'the answer' and apply it to every scenario without doing the requirement-to-design mapping the question is testing.
What to do instead
Practice a written decision sequence: count sites, identify dominant traffic pairs (site-to-DC, site-to-site, SaaS/Internet), apply latency and backhaul constraints, then justify the topology that minimizes hairpinning.
Confusing which functions run in the orchestrator/controller plane versus the branch device data plane, and therefore misassigning where a policy, template, or forwarding decision is actually enforced.
Vendor architectures split orchestration, control, and data planes, and candidates blur them because the UI presents them as one workflow.
What to do instead
Draw the three planes for each architecture and place every feature (template push, tunnel key distribution, DPI, QoS marking, encryption) on the correct plane; answer questions by asking 'where is this action executed?'
Mixing up policy types - security policy, segmentation/segmentation-zone policy, and traffic-steering/QoS policy - and applying the wrong construct to satisfy a requirement such as isolating a guest segment or forcing voice over MPLS.
All three are expressed as 'rules' with match/action semantics, so candidates treat them as interchangeable.
What to do instead
Build a comparison table: what each policy matches on, where it is evaluated, and what it controls (permit/deny+inspection vs. segment membership vs. path/SLA selection); classify each practice requirement into exactly one row.
Designing segmentation with overlapping or ambiguous segment identifiers and forgetting that segmentation must be enforced consistently at the overlay (VRF/segment per VPN) and at the underlay/edge handoff.
Candidates learn the concept of segments but not the end-to-end plumbing, so they miss where a segment must be mapped (LAN VLAN, tunnel, VRF, firewall zone).
What to do instead
For any segmentation scenario, trace one packet from access port through the overlay to the destination segment and list every point where the segment ID must be carried or translated; verify no shared identifiers across segments.
Assuming path selection is purely static or purely dynamic, and failing to explain how SLA probes, thresholds, and failback interact (e.g., expecting instant failover or ignoring hysteresis/backup behavior).
Questions often describe a link degrading slightly rather than failing outright; candidates reason in binary up/down terms.
What to do instead
Study the probe mechanism: what is measured, probe interval, threshold breach duration, action on breach, and failback conditions; walk through a 'loss rises from 1% to 3% then recovers' timeline and predict each state change.
Treating routing as a single protocol question instead of reasoning about route redistribution and preference between overlay routing (e.g., BGP/OSPF over tunnels) and underlay routing, causing loops or suboptimal paths in the design.
Candidates answer 'which routing protocol' but are not tested on the interaction between control-plane routing and data-plane path selection.
What to do instead
For each design, state the underlay routing, the overlay routing, the redistribution points, and the administrative distance/preference order; check that overlay-learned routes do not leak back into the underlay and create loops.
Ignoring the operational consequences of template/configuration management - not accounting for device groups, variables, staged rollout, or rollback when a change is pushed to many sites.
Candidates focus on getting a single device configured correctly and overlook fleet-scale change management, which is the point of orchestration.
What to do instead
Practice describing a change workflow end to end: variable definition, template assignment, device group scoping, staged/preview push, validation, and rollback path; identify blast radius for each change.
Jumping to configuration changes when troubleshooting, instead of following a layered isolation path (underlay reachability → tunnel establishment → routing adjacency → policy/path selection → application performance).
Candidates memorize symptoms rather than a diagnostic order, so they pick a plausible-sounding fix that addresses the wrong layer.
What to do instead
Adopt a fixed triage ladder and, for every troubleshooting scenario, state the first verification command/check at each layer and what result would exonerate that layer before moving up.
Reading monitoring data at face value - treating tunnel status 'up' as proof of healthy application delivery, or ignoring that SLA metrics, flow statistics, and DPI classifications come from different sources with different sampling behavior.
Candidates conflate control-plane tunnel state with data-plane quality and assume all dashboards measure the same thing.
What to do instead
For each monitoring question, identify the data source (tunnel state, synthetic probe, flow telemetry, DPI) and what it can and cannot prove; correlate at least two sources before concluding an application is healthy or degraded.