Cisco ENSDWI 300-415 common mistakes
Cisco ENSDWI 300-415 · Understand the traps and how to avoid them.
Treating the control plane and data plane as one thing when describing the architecture, so the candidate says traffic between branches flows through the vSmart controller or that vManage is in the data path.
The three-plane split (management, control, data) is the conceptual core of the exam, but many candidates learned SD-WAN from diagrams where the controller icons sit in the middle of the drawing and infer that traffic passes through them. They also confuse the role of vSmart (distributes routes and policies via OMP) with the role of vBond (orchestrates NAT traversal and authentication).
What to do instead
Memorize the plane-by-plane function: vManage is management plane (configuration, monitoring, templates); vSmart is control plane (OMP route and policy distribution, no data forwarding); vBond is orchestration (initial authentication, vSmart/vManage list distribution, NAT traversal); WAN Edge routers carry the actual data plane in IPsec tunnels. Practice explaining a full bring-up sequence out loud: WAN Edge to vBond, then to vManage for config, then OMP peering to vSmart, then data tunnels directly between WAN Edges.
Confusing controller placement and redundancy options, for example stating that vSmart controllers must be in the same data center as vManage or that a single vBond can provide full high availability.
Deployment topology questions are usually presented as scenarios with partial information, and candidates fall back on generic 'redundancy means two of everything' reasoning instead of the actual roles. vBond has a special role in initial discovery that makes its reachability and DNS/anycast design different from vSmart and vManage.
What to do instead
Learn the distinct HA models: vManage clustering (N+1 or N+M with a load balancer and shared database), vSmart horizontal scaling with multiple controllers peering to all WAN Edges, and vBond redundancy via multiple vBonds or DNS round-robin/anycast so a device can always reach at least one orchestrator. Remember controllers can be geographically distributed and that WAN Edges need reachability to at least one vBond at boot.
Mixing up device templates and feature templates, or attaching a device template without first understanding which features are mandatory, then answering that a feature template alone configures a WAN Edge.
The template hierarchy (feature templates bound into device templates, then device templates attached to devices) is straightforward in a lab but easy to blur under exam pressure. Candidates also forget that some settings (system, VPN/interface, OMP, and at least one transport) are effectively required for a device to come up and form control connections.
What to do instead
Draw the hierarchy: feature templates are reusable per-feature config fragments; a device template references them and adds device-specific variables; attachment pushes config. For each device template, list the mandatory feature templates (system, transport/VPN 0 interface, OMP, and service VPN interfaces). Practice reading a template variable list and predicting which values must be supplied.
Forgetting that variables must be filled in per device and that a template cannot be attached until all variables resolve, then blaming the controller when a device shows as 'in progress' or fails to attach.
Candidates focus on the template content and skip the operational step of variable binding. Variables can be defined at template level and per-device, and a missing or malformed value (for example an interface IP or a system IP) silently blocks attachment.
What to do instead
Before attaching, open the device template variables view and confirm every variable has a value; use device-specific values where the template expects them. Verify that system IP, site ID, and organization name match the intended overlay, because a wrong system IP breaks OMP peering even though the template attaches successfully.
Choosing the wrong policy type for the requirement, for example using a centralized control policy to enforce a data-plane traffic preference, or a localized data policy when the requirement is to influence OMP route selection across the fabric.
Cisco SD-WAN has several policy families (centralized control, centralized data, localized control, localized data, application-aware routing, cflowd, and security policies) and the names are similar. Candidates pick based on the word 'policy' rather than on which plane and which device the policy must act on.
What to do instead
Map requirement to policy type: to change which routes are preferred or advertised, use centralized control policy (topology, route manipulation) applied at vSmart; to steer traffic at the edge based on application/SLA, use centralized data policy or application-aware routing; to act only on one device, use a localized policy. Confirm where the policy is applied (vSmart vs WAN Edge) and whether it affects control plane or data plane before selecting.
Misunderstanding application-aware routing, such as claiming it can steer traffic without SLA probes or that it overrides a centralized data policy, or forgetting that it requires an application-aware routing policy attached to the correct site list.
AAR depends on bidirectional forwarding detection or IP SLA-style probes per tunnel plus an AAR policy that references SLA classes. Candidates remember the concept ('pick the best path') but not the prerequisites, so they choose AAR for scenarios where it cannot act.
What to do instead
Remember the chain: define SLA classes (latency, loss, jitter) and best-path criteria, ensure probes are enabled on the tunnels, then attach an AAR policy to the relevant sites and VPNs. Know that AAR selects among viable paths and that a centralized data policy can still drop or redirect traffic, so the order of evaluation matters.
Treating service insertion and service chaining as a single checkbox, for example assuming a firewall service node is automatically in the path once it is added to the overlay without configuring service chaining or the service VPN.
Service insertion involves several moving parts: the service node is onboarded as a WAN Edge (or hosted), placed in a service VPN, and traffic is steered to it with a centralized data policy using service chaining actions. Candidates who only remember 'add the firewall' miss the steering configuration.
What to do instead
Learn the full sequence: onboard the service node, assign it the service VPN and system IP, verify OMP peering, then create a centralized data policy that redirects matching traffic through the service chain (and back). Test with a policy that matches a specific prefix or application so you can predict the forwarding path.
Confusing the security features built into the WAN Edge with separate service-node functions, for example saying enterprise firewall or URL filtering requires an external firewall appliance when it can be enabled as a WAN Edge security feature, or vice versa for advanced IPS/AMP.
Cisco SD-WAN security spans on-box features (enterprise firewall, zone-based firewall, URL filtering, IPS/IDS, advanced malware protection, DNS security, TLS/SSL decryption) and service insertion. The exam tests which capability lives where, and candidates overgeneralize from one product family.
What to do instead
Build a table of security features with two columns: on-box WAN Edge vs service node/cloud-delivered. Note that zone-based firewall and URL filtering can be enabled per VPN on the WAN Edge, while some advanced inspection may require a service node or a cloud security service. Study the security policy and security feature template options so you can name where each is configured.
Reading monitoring output without knowing the tool: quoting vManage alarms when the question asks about OMP peer state, or using 'show sdwan control connections' to diagnose a data-plane issue that requires tunnel or BFD output.
Troubleshooting questions reward knowing which command or dashboard answers which question. Candidates memorize command names but not their scope, so they pick a plausible-sounding command that shows the wrong layer.
What to do instead
Map symptom to tool: control connection and OMP peering issues use control connection and OMP neighbor output; tunnel/data issues use BFD/tunnel and interface statistics; policy issues use policy hit counters and cflowd; template/onboarding issues use device status and audit logs in vManage. Practice a short decision tree: is the device onboarded, are control connections up, is OMP exchanging routes, are tunnels up, is policy matching?
Overlooking certificate and clock prerequisites during onboarding troubleshooting, such as assuming a WAN Edge will authenticate to vBond without valid certificates or a correct system clock, or ignoring the enterprise root CA chain in a controller deployment.
Onboarding failures often trace to PKI and time, not routing. Candidates focus on reachability and NAT and skip the certificate chain, the controller certificate installation, and the NTP requirement that makes certificate validation succeed.
What to do instead
In troubleshooting order, verify: DNS/reachability to vBond, correct system time via NTP, valid signed certificates installed on controllers and WAN Edges, and matching organization name. For controller deployment, confirm the root CA and controller certificates are generated and installed before bringing up vBond, and check that the WAN Edge's bootstrap configuration points to a reachable vBond address.