Arista ACE Specialist - WAN Routing common mistakes
Arista ACE Specialist - WAN Routing · Understand the traps and how to avoid them.
Treating an Arista SD-WAN overlay path as a simple IPsec tunnel and expecting the underlay to forward traffic without checking whether the path is actually 'up' in the path-selection table, then blaming routing when traffic blackholes.
Candidates carry over generic IPsec/MPLS VPN mental models and assume tunnel establishment equals usable forwarding, missing that SD-WAN overlays gate forwarding on path health, SLA state, and policy eligibility rather than tunnel existence alone.
What to do instead
For any overlay-forwarding scenario, explicitly separate tunnel state (IKE/IPsec up), path health (probes/SLA met), and policy eligibility (path allowed for that traffic class). Verify each layer independently before concluding where the failure is.
Assuming a single best path is chosen globally, when SD-WAN path selection is per-application/per-flow based on policy and measured SLA, so different flows legitimately take different paths.
Candidates map traditional routing (one best route per prefix) onto SD-WAN, where multiple paths per prefix coexist and selection is policy- and SLA-driven, so they misdiagnose 'asymmetric' or 'inconsistent' forwarding as a fault.
What to do instead
Map the actual traffic class/application to its policy, then check which paths satisfy that policy's SLA and which path each flow selected. Expect per-flow differences and validate against the policy rather than a single route table entry.
Conflating control-plane adjacency state (BGP/OSPF neighbor up) with data-plane reachability, and concluding the WAN is healthy because neighbors are established.
Routing protocols report control-plane liveness, but SD-WAN forwarding and SLA depend on data-plane probes and overlay path state; candidates stop at 'neighbor up' and miss data-plane failures.
What to do instead
Always verify data-plane health separately: overlay path status, probe results, and actual flow forwarding. Treat control-plane adjacency as necessary but not sufficient evidence.
Ignoring that SD-WAN path selection depends on measured SLA (latency/jitter/loss) thresholds, and expecting a path to be used just because it exists and is reachable.
Candidates focus on reachability and forget that a path can be administratively up yet excluded because it fails the policy's SLA thresholds, so they cannot explain why a preferred link is unused.
What to do instead
Check the policy's SLA criteria against current measured values on each path. If a path is excluded, confirm whether it fails SLA, and verify probe configuration (targets, intervals) is actually producing valid measurements.
Misconfiguring or misreading the directionality of policy (match vs. action, inbound vs. outbound, site-to-site vs. site-to-Internet) and then expecting steering to apply where it was never scoped.
SD-WAN policy has multiple scopes and directions; candidates apply a policy in one context and assume it governs all traffic, then cannot explain unsteered flows.
What to do instead
For each policy, state explicitly: what it matches (application, prefix, zone), where it is applied (which sites/direction), and what action it takes. Trace a specific flow through that chain before troubleshooting elsewhere.
Assuming policy order does not matter, or that a more specific intent will override an earlier broad rule, when evaluation is ordered and the first match wins.
Candidates treat policy like a declarative set where specificity wins, but ordered rule evaluation means a broad earlier match shadows later specific rules, producing unexpected steering.
What to do instead
Read policies top-down as an ordered list. Identify the first rule that matches the flow, and reorder or narrow broad rules that shadow intended specific rules.
Failing to distinguish underlay routing problems from overlay/policy problems, so they change SD-WAN policy when the actual fault is an underlay reachability or next-hop issue (or vice versa).
The stack is layered (underlay transport, overlay tunnels, policy steering), and symptoms look similar; candidates jump to the layer they know best instead of isolating which layer is failing.
What to do instead
Use a layered isolation method: confirm underlay reachability to the peer transport address, then overlay tunnel/path state, then policy eligibility, then application. Fix the lowest broken layer first.
Overlooking that asymmetric forwarding across different WAN paths can break stateful inspection or return-path assumptions, and diagnosing it as a routing loop.
Per-flow path selection plus multiple available paths naturally produces asymmetry; candidates see return traffic on a different link and mislabel it a loop or misconfiguration.
What to do instead
Confirm whether asymmetry is policy-intended (different paths per direction/flow). If it breaks a stateful device, adjust policy to pin the flow's both directions to a consistent path rather than chasing a nonexistent loop.
Reading aggregate/interface counters or a single probe result as proof of end-to-end application health, without correlating flow-level telemetry, path selection, and application performance data.
Observability data is layered and candidates fixate on one signal (e.g., interface up, one successful probe) instead of triangulating across telemetry sources, leading to premature 'it's fine' conclusions.
What to do instead
Correlate at least three signals for a suspect flow: path health/SLA measurements, the selected path per policy, and flow/application performance telemetry. Reconcile discrepancies rather than trusting any single source.
Assuming a configuration change takes effect immediately and uniformly across all sites/edges, without verifying propagation and per-edge state after the change.
SD-WAN configuration is distributed to multiple edges; candidates validate on one device or assume instant convergence, missing partial application, stale state, or edges that did not receive the update.
What to do instead
After a change, verify propagation to each relevant edge and confirm per-edge state (policy applied, path re-evaluated, flows re-selected) rather than validating a single node or assuming instant global convergence.