Cisco Expert

300-415

ENSDWI (Enterprise SD-WAN)

The Implementing Cisco SD-WAN Solutions (300-415 ENSDWI) is a concentration exam for the CCNP Enterprise certification, focusing on Cisco's Software-Defined Wide Area Network (SD-WAN) solution. This expert-level exam validates skills in designing, deploying, configuring, and managing Cisco SD-WAN solutions using the Viptela architecture.

The exam covers SD-WAN architecture and components including vManage, vSmart, vBond, and vEdge/cEdge routers, controller deployment and provisioning, WAN edge router deployment including zero-touch provisioning (ZTP), SD-WAN policies (control, data, application-aware routing), security features including service-side and transport-side VPNs, centralized and localized policies, and QoS policies. Candidates must demonstrate ability to configure, manage, and troubleshoot Cisco SD-WAN deployments.

This certification is designed for senior network engineers, SD-WAN architects, and WAN specialists who implement and manage Cisco SD-WAN solutions. It is ideal for professionals transitioning from traditional WAN technologies to software-defined networking and for those responsible for deploying modern branch and WAN connectivity solutions.

Updated Feb 2024 Networking

60

Questões

6

Simulados

83%

Nota de Aprovação

36

Visualizações

0

Total de Tentativas

0%

Nota Média

0%

Taxa de Aprovação

0

Discussões

Simulados Flash Cards Tópicos do Exame Folha de Resumo

€5.00

300-415 Practice Exam 1

Comprehensive Cisco SD-WAN ENSDWI practice exam covering architecture, controller deployment, router deployment, policies, and security and QoS across 65 professional-level questions.

65 Q 90 minutos 70%

Test Drive

€5.00

300-415 Practice Exam 2

Comprehensive Cisco SD-WAN ENSDWI practice exam covering architecture, controller deployment, router deployment, policies, and security and QoS across 65 professional-level questions.

65 Q 90 minutos 70%

Test Drive

€5.00

300-415 Practice Exam 3

Comprehensive Cisco SD-WAN ENSDWI practice exam covering architecture, controller deployment, router deployment, policies, and security and QoS across 65 professional-level questions.

65 Q 90 minutos 70%

Test Drive

€5.00

300-415 Practice Exam 4

Comprehensive Cisco SD-WAN ENSDWI practice exam covering architecture, controller deployment, router deployment, policies, and security and QoS across 65 professional-level questions.

65 Q 90 minutos 70%

Test Drive

€5.00

300-415 Practice Exam 5

Comprehensive Cisco SD-WAN ENSDWI practice exam covering architecture, controller deployment, router deployment, policies, and security and QoS across 65 professional-level questions.

65 Q 90 minutos 70%

Test Drive

€5.00

300-415 Practice Exam 6

Comprehensive Cisco SD-WAN ENSDWI practice exam covering architecture, controller deployment, router deployment, policies, and security and QoS across 65 professional-level questions.

65 Q 90 minutos 70%

Test Drive

Desbloquear Todo o Conteúdo para 300-415

6 Simulado(s) + Flash Cards — acesso por 3 meses

€39.99 €26.99 Economize 30%

ou incluído com assinatura Mensal / Pacote de Conteúdo

300-415 Cheat Sheet

Guia de referência rápida - 6 seções

Acesso Gratuito

Cisco SD-WAN Solutions (300-415 ENSDWI)

The Cisco 300-415 ENSDWI (Implementing Cisco SD-WAN Solutions) exam validates your ability to design, deploy, configure, and manage the Cisco SD-WAN solution in a large-scale live network. This concentration exam is one of the options available to earn the Cisco Certified Network Professional Enterprise (CCNP Enterprise) certification when combined with the core exam (350-401 ENCOR). The ENSDWI exam focuses on the Cisco SD-WAN (formerly Viptela) architecture, which provides a software-defined approach to managing the WAN by separating the data plane from the control and management planes. Candidates must demonstrate proficiency with the four key components of the SD-WAN fabric: vManage (centralized network management system), vBond (orchestrator that authenticates and coordinates all fabric elements), vSmart (centralized controller that distributes routing and policy information via OMP), and vEdge/cEdge routers (WAN edge devices that form the data plane). The exam covers the full lifecycle of an SD-WAN deployment, from initial architecture decisions and controller deployment through router onboarding, template-based configuration, centralized and localized policy creation, security integration, and quality of service implementation. Cisco SD-WAN leverages zero-trust security principles with certificate-based device authentication, encrypted control plane connections (DTLS/TLS), and IPsec-encrypted data plane tunnels between all WAN edge devices. Understanding the Overlay Management Protocol (OMP), TLOC (Transport Location) concept, VPN segmentation model, and the interplay between centralized policies on vSmart and localized policies on edge routers is essential for passing this exam.

Exam Details

Exam Code	300-415 ENSDWI
Full Name	Implementing Cisco SD-WAN Solutions
Duration	90 minutes
Number of Questions	55-65 questions
Passing Score	Cisco does not publish (scaled 300-1000)
Cost	$300 USD
Validity	3 years (recertify via CE credits or re-exam)
Question Types	Multiple choice, multiple select, drag-and-drop
Certification Level	CCNP Enterprise (concentration exam)

Domain Weights

Domain	Weight
Architecture	20%
Controller Deployment	15%
Router Deployment	20%
Policies	25%
Security and QoS	20%

Study Tips

Policies (25%) is the heaviest domain; master the difference between centralized policies (applied on vSmart, influence routing and data forwarding across the fabric) and localized policies (applied on edge routers, handle QoS, ACLs, and route filtering locally)
Understand the complete SD-WAN control plane flow: vBond orchestration, DTLS/TLS tunnel establishment, OMP peering between vSmart and edge routers, TLOC resolution, and how routes are advertised and redistributed
Hands-on lab practice with vManage device and feature templates is essential; know how to create templates with variables, bind them to devices, and push configurations to edge routers
Master the VPN segmentation model: VPN 0 (transport), VPN 512 (management), service-side VPNs (1-511), and how VPN membership controls traffic isolation across the overlay
Security topics including Enterprise Firewall, IPS/IDS, URL Filtering, and DNS/Web Layer Security on cEdge routers are heavily tested; understand the Unified Threat Defense (UTD) engine and Cisco Umbrella integration
Know the differences between vEdge (Viptela OS) and cEdge (IOS-XE) routers, including CLI syntax differences, supported features, and migration considerations
Study the zero-touch provisioning (ZTP) and plug-and-play (PnP) onboarding processes, including certificate authentication, serial number whitelisting, and the role of each controller in the bootstrap process

SD-WAN Fabric Components

Component	Description
vManage	Centralized Network Management System (NMS) that provides a single pane of glass GUI and REST API for configuration, monitoring, troubleshooting, and software management of the entire SD-WAN fabric; runs as a virtual machine or on dedicated hardware; stores all device configurations, templates, and policies; provides real-time and historical dashboards for tunnel health, application performance, and device status; supports multi-tenancy for managed service providers; connects to vSmart and vBond via DTLS/TLS control connections; can be deployed as a cluster (3 or 6 nodes) for high availability and horizontal scaling; the vManage database uses Elasticsearch for statistics and Neo4j for configuration data
vBond	Orchestrator that serves as the first point of contact for all SD-WAN fabric devices; authenticates devices using signed certificates and serial number whitelisting in the authorized serial number file; facilitates NAT traversal by relaying connection information between devices behind NAT; distributes a list of vSmart controllers and vManage instances to each connecting device; must have a public IP address or static 1:1 NAT so all fabric devices can reach it; lightweight component that handles initial authentication and then hands off to vSmart and vManage; supports redundant deployment (multiple vBond orchestrators) with DNS-based load balancing
vSmart	Centralized controller that maintains the control plane for the SD-WAN overlay; establishes OMP (Overlay Management Protocol) sessions with all WAN edge routers to exchange routing information, TLOC mappings, service chains, encryption keys, and policy directives; implements centralized data policies and app-route policies that manipulate how traffic is forwarded across the fabric without touching the edge routers' local configuration; propagates crypto keys for IPsec between edge routers so they can build direct data plane tunnels; supports route reflector-like functionality distributing the best paths to all edges; deployed redundantly (at least 2) with affinity groups for scale; each vSmart can manage up to approximately 5,400 OMP peerings
vEdge / cEdge	WAN edge routers that form the data plane of the SD-WAN fabric; vEdge runs Viptela OS (proprietary, CLI-based, limited feature set), while cEdge runs IOS-XE (Cisco standard, broader feature set including UTD security, EIGRP, IS-IS); both establish DTLS/TLS tunnels to controllers and IPsec tunnels to other edge routers for encrypted data plane forwarding; support multiple WAN transport connections (MPLS, internet, LTE/5G) with transport-independent overlay; perform application-aware routing using BFD probes to measure loss, latency, and jitter per tunnel; enforce localized policies for QoS, ACLs, and NAT; cEdge is the strategic platform going forward and supports features like Cisco Umbrella integration, ThousandEyes, and UTD (Unified Threat Defense)

Exam Tip: The control plane uses DTLS (UDP 12346) or TLS (TCP 12346) between controllers and edge routers. The data plane uses IPsec (ESP/UDP encapsulation) between WAN edge routers. vBond must always be reachable on a public IP because it is the initial contact point for all devices. In a greenfield deployment, bring up vBond first, then vManage, then vSmart, and finally edge routers.

Overlay Management Protocol (OMP)

OMP Route Type	Description
OMP Routes (vRoutes)	Prefix-based routes learned from the service side (LAN) of WAN edge routers; similar to BGP prefixes; each route carries attributes including originator-id, site-id, VPN label, TLOC, preference, origin (connected, static, OSPF, BGP, OMP), and origin-metric; redistributed into OMP from service-side routing protocols; vSmart selects the best route per prefix and advertises it to all edge routers in the same VPN; by default vSmart sends only the best path (configurable up to 16 with send-path-limit)
TLOC Routes	Transport Location routes representing the physical WAN transport interfaces on edge routers; a TLOC is uniquely identified by the combination of system-ip, color, and encapsulation type (IPsec/GRE); carries attributes including public-ip, private-ip, preference, weight, site-id, and restrict flag; TLOCs resolve vRoutes to actual transport paths; when an edge router receives a vRoute with a TLOC next-hop, it looks up the TLOC in its TLOC table to determine the tunnel endpoint; a router can have multiple TLOCs (one per WAN interface with a unique color)
Service Routes	Advertise the availability of network services (firewall, IPS, load balancer) at specific sites for service chaining; a service route maps a service type (FW, IDS, IDP, netsvc) to a TLOC, telling vSmart that a particular service is available at that location; used by centralized policies to redirect traffic through service nodes before reaching the destination; enables traffic insertion into services without modifying the edge router data path

Exam Tip: OMP is often compared to BGP but operates over DTLS/TLS between edge routers and vSmart (not directly between edge routers). OMP uses TCP-like reliable transport within DTLS/TLS, carries multiple address families (vRoutes, TLOCs, service routes, crypto keys), and by default advertises only the best route. OMP graceful restart keeps routes for 12 hours if the vSmart connection is lost. The best path selection order is: Origin type, OMP preference (higher wins), TLOC preference (higher wins), Origin metric (lower wins), System-IP (lower wins as tiebreaker).

SD-WAN Transport and Overlay Concepts

Concept	Description
Colors	Labels assigned to WAN transport interfaces to identify the transport type; public colors (biz-internet, public-internet, lte, 3g) indicate the transport is behind NAT and can initiate tunnels to any other color; private colors (mpls, metro-ethernet, private1-6) indicate the transport can only form tunnels with the same color by default (restrict flag); custom colors allow flexibility; colors drive automatic tunnel formation: public-to-public and public-to-private tunnels form by default, private-to-private of the same color form by default; use the restrict flag to control tunnel topology
VPN Segmentation	SD-WAN uses VPNs (virtual routing and forwarding instances, equivalent to VRFs) to segment traffic; VPN 0 is the transport VPN carrying WAN underlay interfaces and control plane tunnels; VPN 512 is the out-of-band management VPN; VPNs 1 through 511 are service-side VPNs for user traffic (e.g., VPN 10 for corporate, VPN 20 for guest); each VPN has its own routing table, and traffic between VPNs requires explicit policy or route leaking; OMP carries routes per VPN so a route in VPN 10 is only distributed to other VPN 10 members
IPsec Data Plane	All data plane traffic between WAN edge routers is encrypted using IPsec by default; vSmart distributes IPsec keying material (AES-256-GCM keys) via OMP so edge routers can build direct tunnels without IKE negotiation; keys are rotated every 24 hours (configurable); full-mesh IPsec tunnels form automatically between all edge routers by default; BFD (Bidirectional Forwarding Detection) probes run inside each IPsec tunnel to measure loss, latency, and jitter for application-aware routing decisions; tunnel MTU is auto-detected and packets are fragmented as needed
NAT Traversal	vBond acts as a STUN-like server to assist edge routers behind NAT in discovering their public IP and port; when two edge routers are both behind NAT, vBond relays their public IP information so they can form direct IPsec tunnels; supports symmetric NAT traversal using UDP encapsulation of IPsec; if direct tunnel formation fails, traffic can be relayed through a device with a public IP; DTLS/TLS control connections to vManage and vSmart also support NAT traversal

SD-WAN Planes Summary

Management Plane: vManage provides centralized configuration, monitoring, and lifecycle management via GUI (port 8443) and REST API (port 8443/dataservice); uses NETCONF internally to push configurations to devices; stores templates, policies, device inventory, and statistics; supports role-based access control (RBAC) with customizable user groups and resource groups for multi-tenant deployments
Control Plane: vSmart controllers distribute routing (OMP), policy, and encryption key information to all WAN edge routers; DTLS/TLS tunnels on port 12346; OMP is the single routing protocol for the overlay; vBond orchestrates initial device authentication and controller discovery; control plane is always encrypted and authenticated via certificates
Data Plane: WAN edge routers (vEdge/cEdge) forward user traffic across IPsec-encrypted tunnels over any available WAN transport; application-aware routing steers traffic based on real-time SLA measurements; QoS policies shape and prioritize traffic per application; direct internet access (DIA) can be configured to break out specific traffic locally without backhauling to a hub
Orchestration Plane: vBond serves as the initial trust broker; validates device identity against the authorized serial number list and organization name; provides the IP addresses of vManage and vSmart controllers so the device can establish permanent connections; essential for zero-touch provisioning (ZTP) where edge routers auto-discover and join the fabric without manual intervention

Certificate Management and Authentication

Concept	Description
Root Certificate Authority	All SD-WAN devices must trust the same root CA for mutual TLS authentication; Cisco provides Symantec/DigiCert root CA for cloud-hosted controllers; for on-premises deployments, an enterprise CA or Cisco PKI can be used; the root CA certificate is installed on all controllers and edge routers during initial setup; every device presents a signed certificate during DTLS/TLS handshake for bidirectional authentication
Device Certificate Signing	Each device generates a CSR (Certificate Signing Request) containing its chassis-id (serial number) and organization name; the CSR is signed by the root CA to produce a device certificate; for Cisco cloud-managed deployments, certificates are automatically provisioned via Cisco PnP (Plug and Play) portal; for enterprise CA, CSRs are manually signed and uploaded via vManage or CLI; certificates bind a device identity to a cryptographic key pair
Authorized Serial Number File	A whitelist file on vBond and vManage containing the chassis-id (serial number), serial-number-entry, and board-id of all authorized devices; only devices listed in this file can join the SD-WAN fabric; vManage maintains this list and synchronizes it to vBond; in Cisco cloud deployments, the serial number file is automatically populated from the PnP portal when devices are added to the smart account/virtual account
Organization Name	A unique identifier string configured on all controllers and edge routers that must match exactly across the fabric; acts as a domain boundary ensuring devices from different organizations cannot join each other's fabric even if they share the same root CA; configured during initial controller setup and embedded in device certificates; case-sensitive and must be identical on vManage, vBond, vSmart, and all edge devices

Exam Tip: Three elements must match for a device to join the SD-WAN fabric: (1) the root CA certificate must be trusted, (2) the organization name must match, and (3) the device serial number must be in the authorized serial number file. If any one of these fails, the device will not be authenticated and will not form control connections.

Controller Deployment Options

Deployment Model	Description
Cloud-Hosted	Cisco hosts vManage, vBond, and vSmart controllers in Cisco cloud infrastructure; fastest time to deployment; Cisco manages controller software updates, patching, and availability; customer manages only edge routers and policies; certificates are automatically provisioned from Cisco PKI; suitable for organizations that prefer operational simplicity and do not have strict data sovereignty requirements
On-Premises	Controllers deployed as virtual machines in the customer's data center on ESXi, KVM, or cloud platforms (AWS, Azure, GCP); gives full control over controller infrastructure, software versions, and data residency; requires the customer to manage HA, backups, software upgrades, and certificate infrastructure; vBond still needs a public-facing IP or NAT; typical deployment uses dedicated VMs with specific CPU, memory, and storage requirements based on fabric size
Hybrid	Mix of cloud-hosted and on-premises controllers; for example, vBond and vSmart in the cloud with vManage on-premises for data sovereignty; or additional vSmart controllers on-premises for latency-sensitive control plane operations; requires careful planning of control plane connectivity and certificate trust between cloud and on-premises components

Controller High Availability and Scalability

Component	HA and Scale Details
vManage Cluster	Deploy 3 or 6 node clusters for high availability and horizontal scaling; cluster uses an internal messaging bus for data synchronization; services distributed across nodes: configuration database, statistics database, application server; minimum 3 nodes required for quorum-based consistency; nodes should be deployed across separate failure domains; cluster VIP (Virtual IP) provides a single management endpoint; supports up to 6,000+ edge devices in a 6-node cluster
vSmart Redundancy	Deploy at least 2 vSmart controllers for redundancy; all vSmart controllers are active-active and share the OMP routing state; each edge router connects to all configured vSmart controllers simultaneously; if one vSmart fails, the remaining controllers continue serving all edge routers without route loss; affinity groups can partition which vSmart controllers serve which edge routers for scale; OMP graceful restart timer (default 12 hours) preserves routes if all vSmart connections are lost temporarily
vBond Redundancy	Deploy multiple vBond instances and use DNS round-robin to distribute initial connections; since vBond is only needed for initial device onboarding and periodic re-authentication, it is the lightest component; each vBond must have a reachable public IP; all vBond instances serve the same organization and share the same authorized serial number file; if one vBond fails, new devices connect to the next DNS-resolved IP

Controller Bring-Up Sequence and Troubleshooting

Step 1 - vBond: Configure system-ip, site-id, organization-name, vbond address (pointing to itself), and install root CA certificate; vBond must be the first controller brought online because all other devices depend on it for initial discovery; verify with show orchestrator connections
Step 2 - vManage: Configure system-ip, site-id, organization-name, vbond address, and install root CA certificate; vManage connects to vBond for authentication and then establishes DTLS/TLS connections; upload the authorized serial number file (WAN edge list); verify with show control connections
Step 3 - vSmart: Configure system-ip, site-id, organization-name, vbond address, and install root CA certificate; vSmart authenticates through vBond and then forms control connections to vManage; OMP sessions are established once edge routers come online; verify with show control connections and show omp peers
Troubleshooting: Use show control local-properties to verify local device identity (system-ip, organization-name, certificate status); show control connections to verify DTLS/TLS tunnel status to all controllers; show certificate installed to verify the device certificate; check NTP synchronization (certificates have validity periods); verify DNS resolution for vBond hostname; check firewall rules for ports 12346 (DTLS/TLS) and 8443 (vManage GUI)

Exam Tip: Common controller connectivity failures include mismatched organization names, expired or untrusted certificates, NTP clock skew causing certificate validation failures, serial numbers not in the authorized list, and firewall blocking DTLS (UDP 12346) or TLS (TCP 12346). Always verify show control local-properties first to confirm the local device is correctly configured before troubleshooting remote connectivity.

WAN Edge Onboarding Methods

Method	Description
Zero-Touch Provisioning (ZTP)	Automated onboarding for vEdge routers; the router boots with factory defaults, obtains an IP via DHCP, resolves ztp.viptela.com via DNS to discover vBond, authenticates using its factory-installed certificate and serial number, downloads its configuration from vManage, and joins the SD-WAN fabric without any manual CLI configuration; requires DHCP to provide IP address, default gateway, and DNS server on the WAN interface; the serial number must be pre-registered in vManage's authorized device list
Plug-and-Play (PnP)	Automated onboarding for cEdge (IOS-XE) routers; similar to ZTP but uses Cisco PnP infrastructure; the router contacts devicehelper.cisco.com on boot, is redirected to vBond based on its serial number registered in the Cisco PnP Connect portal (linked to the smart account/virtual account); the PnP Connect profile maps the serial number to the vBond IP and organization; the router then authenticates with vBond, connects to vManage, and receives its configuration; requires the device serial number to be claimed in the Cisco PnP portal
Manual Bootstrap	CLI-based onboarding when ZTP/PnP is not feasible; manually configure the system-ip, site-id, organization-name, vbond address, and WAN interface IP on the edge router via console; install the root CA certificate; the router then contacts vBond, authenticates, and joins the fabric; useful for lab environments, troubleshooting, or scenarios where DHCP and DNS are not available on the WAN transport; also used when the WAN interface requires PPPoE or static IP configuration that ZTP cannot provide
Bootstrap Configuration File	A minimal configuration file loaded onto a USB drive or TFTP server containing the system-ip, site-id, organization-name, vbond address, and WAN interface settings; the router reads this file on boot and uses the information to connect to vBond; provides an alternative to full manual CLI entry; vManage can generate bootstrap configuration files for each device that include all required parameters; this method bridges the gap between fully automated ZTP/PnP and fully manual CLI configuration

Exam Tip: ZTP is for vEdge routers (resolves ztp.viptela.com), while PnP is for cEdge routers (resolves devicehelper.cisco.com). Both require the device serial number to be pre-registered. The key difference is the discovery mechanism: ZTP uses DNS resolution of the Viptela ZTP server, while PnP uses the Cisco PnP Connect cloud portal. Both ultimately connect the router to vBond for authentication and then to vManage for configuration download.

Device and Feature Templates

Template Type	Description
Feature Templates	Modular building blocks that define a specific configuration component: System (hostname, system-ip, site-id, timezone, GPS, NTP), VPN (VPN ID, routes, DNS, interfaces), Interface (IP addressing, DHCP, tunnel, bandwidth, color, TLOC extension, NAT), BGP/OSPF/EIGRP (routing protocol parameters per VPN), AAA, Logging, SNMP, Banner, and more; each feature template can use variables (device-specific values like hostname, IP addresses), global values (same across all devices), or default values; variables are denoted by double curly braces {{variable_name}} and are populated when the template is attached to a specific device
Device Templates	Aggregate multiple feature templates into a complete device configuration; a device template references one feature template for each configuration component (e.g., one System template, one VPN 0 template, one VPN 10 template with its interfaces, one BGP template); device templates are device-model specific (ISR4331, ISR1100, vEdge1000, etc.); when you attach a device template to a device in vManage, you fill in the variable values (hostname, IPs, etc.) and vManage generates and pushes the complete device configuration; device templates enforce configuration consistency across sites
CLI Templates	Allow direct CLI configuration when feature templates do not support a specific feature; entered as free-form CLI text in vManage with optional variables; can be used as an add-on to device templates (CLI add-on template) for features not covered by feature templates; provide maximum flexibility but sacrifice the validation and structured approach of feature templates; useful during migration from legacy CLI-managed routers or for niche configurations
Template Variables	Parameterize templates for reuse across multiple devices; variable types: device-specific (entered per device, e.g., {{hostname}}, {{interface_ip}}), global (same value for all devices, e.g., DNS server), and default (pre-set value that can be overridden); when attaching a template to devices in bulk, vManage presents a CSV-like spreadsheet to fill in all variable values for each device simultaneously; this enables rapid deployment of hundreds of edge routers with consistent configurations and unique per-site parameters

WAN Edge Configuration Essentials

Configuration Element	Description
System Parameters	system-ip: unique loopback-like identifier for each device (does not need to be routable); site-id: numeric identifier for the physical site (all routers at the same site share the same site-id); organization-name: must match across all fabric devices; hostname: descriptive name for device identification; system-ip and site-id together uniquely identify a device in the fabric; site-id is used for policy matching and to prevent routing loops (OMP will not advertise a route back to its originating site by default)
VPN 0 (Transport)	Contains all WAN-facing interfaces that carry SD-WAN tunnels; each WAN interface is configured with an IP address, tunnel encapsulation (IPsec), color (biz-internet, mpls, lte, etc.), and optional bandwidth settings; the default route (0.0.0.0/0) for WAN connectivity is configured in VPN 0; tunnel interfaces are bound to physical/logical WAN interfaces; TLOC extension allows a remote router to share a WAN transport with an adjacent router via a LAN connection between them
Service-Side VPNs	VPNs 1-511 carry LAN/service-side traffic; each service VPN has its own routing table (similar to a VRF); interfaces facing the LAN (e.g., GigabitEthernet0/0/1) are placed in the appropriate service VPN; service-side routing protocols (OSPF, BGP, EIGRP, static routes) are configured per VPN to exchange routes with the LAN; routes learned from the service side are redistributed into OMP and advertised to vSmart for distribution to other sites within the same VPN
VPN 512 (Management)	Out-of-band management VPN for direct device management access; typically connects to a dedicated management network; used for SSH access, SNMP polling, syslog, and other management traffic that should not traverse the SD-WAN overlay; optional but recommended for large deployments to keep management traffic separate from production and control plane traffic

Routing, Multicast, and Special Configurations

Service-Side Routing: OSPF, BGP, EIGRP (cEdge only), and static routes can be configured per service VPN; routes are redistributed into OMP with proper origin and metric attributes; on the remote site, OMP routes are redistributed back into the service-side protocol; use route policies to filter which routes are redistributed to prevent suboptimal routing and route loops
TLOC Extension: Allows a WAN edge router without a direct WAN connection to share the WAN transport of an adjacent router; the extending router sends traffic over a LAN link to the extending peer which forwards it to the overlay; both routers must be at the same site (same site-id); configured by referencing the TLOC extension interface on the WAN edge that provides the shared transport
Multicast over SD-WAN: Supports PIM (Protocol Independent Multicast) replication over the overlay; head-end replication on the edge router or auto-RP/BSR for rendezvous point discovery; multicast traffic is replicated per WAN edge to each interested site; OMP distributes multicast source information; configurable per VPN
Direct Internet Access (DIA): Break out internet traffic directly from the branch edge router instead of backhauling to a central site; configured with a NAT on the VPN 0 transport interface and a route in the service VPN pointing internet traffic to the NAT interface; can be combined with Cisco Umbrella or UTD for security; centralized data policy can selectively route specific applications via DIA

Exam Tip: When configuring DIA, you must enable NAT on the transport interface in VPN 0 and add a default route or specific routes in the service VPN pointing to the VPN 0 NAT interface. Centralized data policy can be used to selectively break out only specific applications (e.g., Office 365, Webex) via DIA while backhauling all other traffic to the hub for security inspection.

Centralized Policies (vSmart)

Policy Type	Description
Centralized Control Policy	Manipulates the OMP routing information on vSmart before it is distributed to edge routers; can filter, modify, or redirect routes based on match criteria including site-id, VPN, prefix, TLOC color, origin, community, and preference; actions include accept, reject, set TLOC, set preference, set community, and set service; applied inbound (from edge to vSmart) or outbound (from vSmart to edge); topology control uses control policies to create hub-and-spoke, mesh, or custom topologies by selectively advertising routes between sites; use cases include route filtering between regions, traffic engineering by setting TLOC preference, and creating isolated VPN segments
Centralized Data Policy	Controls how data plane traffic is forwarded at the WAN edge router, but is configured and pushed from vSmart; matches on packet attributes including source/destination IP prefix, source/destination port, protocol, DSCP, and application; actions include set TLOC (steer traffic to specific transport), set next-hop, set VPN (route leaking between VPNs), set local TLOC preference, drop, count, log, NAT VPN, DIA, redirect DNS, cflowd, and service chain insertion; applied per VPN and per site-list; data policies are pushed from vSmart to the matched edge routers where they are installed in the data plane for per-packet enforcement
Application-Aware Routing (AAR) Policy	Steers application traffic to the best available WAN path based on real-time SLA metrics measured by BFD probes; match criteria include application name or application-family from the SD-WAN application-aware DPI engine; SLA classes define thresholds for loss, latency, and jitter (e.g., voice SLA: loss <1%, latency <150ms, jitter <30ms); actions include set preferred-color (try this transport first), set backup SLA with fallback behavior, and set TLOC list; fallback actions when no path meets SLA: use the best available path, drop the traffic, or use a backup SLA class; works in conjunction with BFD probes that measure tunnel performance every second
cflowd Policy	Exports flow data (NetFlow/IPFIX) from WAN edge routers for traffic visibility; configured as a centralized data policy action that collects flow records for matched traffic; flow records include source/destination IP, ports, protocol, byte counts, and application identification; exported to an external collector or consumed by vManage for the real-time application visibility dashboards; essential for understanding traffic patterns and validating policy effectiveness

Exam Tip: Centralized control policies manipulate OMP routes on vSmart (control plane), while centralized data policies are pushed from vSmart to edge routers and enforce per-packet forwarding decisions (data plane). Control policies affect routing table entries; data policies match actual traffic flows. Application-aware routing policies are a special type of data policy focused on SLA-based path selection. Know which match/action combinations are valid for each policy type.

Policy Building Blocks

Building Block	Description
Site Lists	Define groups of sites by site-id for policy application; e.g., branch-sites (100, 200, 300), hub-sites (1, 2), dc-sites (10, 20); policies reference site lists to specify where they apply; a single site-id can appear in multiple site lists; essential for scoping policies to specific locations in the network
VPN Lists	Define groups of VPNs for policy application; e.g., corporate-vpns (10, 20), guest-vpn (30); data policies and control policies are applied per VPN list; enables different routing and forwarding behavior for different network segments (corporate vs. guest traffic)
Prefix Lists	Define IP prefix match criteria for control and data policies; used to match source or destination prefixes in route filtering or traffic classification; support exact match and ge/le prefix length modifiers similar to BGP prefix lists
TLOC Lists	Define specific TLOCs (system-ip, color, encap) for traffic steering; used in data policy actions to direct traffic to a specific transport path; e.g., steer voice traffic to the MPLS TLOC of the hub router; also used in control policies to set the preferred TLOC for specific routes
SLA Classes	Define performance thresholds for application-aware routing; specify maximum acceptable loss (%), latency (ms), and jitter (ms); referenced in app-route policies to determine which WAN paths meet application requirements; BFD probes continuously measure each tunnel against the SLA class thresholds; multiple SLA classes can be defined for different application types (voice, video, data, best-effort)
Application Lists	Group applications by name for policy matching; leverage the SD-WAN Deep Packet Inspection (DPI) engine that classifies over 3,000 applications; examples: voice-apps (cisco-phone, ms-teams-audio), business-apps (salesforce, sap), streaming-apps (youtube, netflix); used in app-route policies and data policies to match traffic by application identity rather than IP/port

Localized Policies (Edge Router)

Policy Type	Description
Access Control Lists (ACLs)	Applied directly on edge router interfaces to permit or deny traffic; match on source/destination IP, port, protocol, DSCP, and packet length; implicit deny at the end; applied inbound or outbound on interfaces; support both IPv4 and IPv6; can include logging and counter actions; configured via localized policy in vManage and pushed as part of the device template; used for basic traffic filtering at the branch level
Route Policies	Filter and manipulate routes at the edge router level; applied to service-side routing protocols (OSPF, BGP, EIGRP) or to OMP route redistribution; match on prefix, community, origin, metric, and other route attributes; actions include accept, reject, set metric, set community, set preference; used to control which LAN routes are advertised into OMP and which OMP routes are redistributed to the LAN; prevents route leaking and ensures optimal routing
QoS Policies	Localized QoS maps applied to WAN interfaces for traffic classification, marking, queuing, and scheduling; define forwarding classes (queues) with bandwidth allocation percentages, scheduling type (LLQ for priority, WRR/WRED for non-priority), and drop behavior; traffic is classified into queues based on DSCP values or ACL matches; applied per interface as part of the localized policy; detailed QoS configuration is covered in the Security and QoS domain

Topology and Traffic Engineering

Full Mesh (Default): By default, all SD-WAN edge routers form IPsec tunnels to all other edge routers and OMP advertises all routes to all sites; this creates a full-mesh topology where every site can communicate directly with every other site; suitable for small to medium deployments but can create excessive tunnel count in large networks (N*(N-1)/2 tunnels)
Hub-and-Spoke: Use centralized control policy to restrict route advertisement so branch sites only receive routes via the hub; branch-to-branch traffic must traverse the hub; implement by setting the TLOC on branch-destined routes to the hub's TLOC; reduces tunnel count and centralizes traffic inspection; most common enterprise deployment topology
Regional Mesh: Create regional hub-and-spoke topologies with full mesh between regional hubs; branches in each region only tunnel to their regional hub; regional hubs mesh with each other and with data centers; implemented using control policy with site lists grouping branches by region; balances scalability with performance
Service Chaining: Use centralized data policy to redirect traffic through a network service (firewall, IPS, proxy) before forwarding to the destination; the service chain is defined by a service route advertised via OMP indicating the service type and location; traffic is steered to the service node via policy action set service; supports single-hop and multi-hop service chains for defense-in-depth architectures
Traffic Engineering with TLOC: Use control policy to set TLOC preference and weight for specific routes to influence which WAN transport is used; preference is used for primary/backup path selection (higher preference preferred); weight is used for load balancing across equal-preference TLOCs; combine with data policy for application-level granularity

Exam Tip: The policies domain (25%) is the most heavily weighted section. Focus on understanding the difference between centralized control policy (route manipulation on vSmart), centralized data policy (per-packet actions pushed to edge), and localized policy (configured directly on edge router). Know the policy building blocks (site lists, VPN lists, prefix lists, TLOC lists, SLA classes) and how they are assembled into a complete policy framework. Practice creating hub-and-spoke topologies with control policies and application-aware routing with app-route policies in vManage.

SD-WAN Security Architecture

Security Feature	Description
Enterprise Firewall	Zone-based stateful firewall integrated into cEdge routers via UTD (Unified Threat Defense) container; define security zones (inside, outside, DMZ) and assign VPN interfaces to zones; create zone-pair policies (inside-to-outside, outside-to-inside) with inspect, drop, pass, and log actions; supports application-level inspection (ALG) for protocols like FTP, SIP, H.323; configured via vManage security policy templates; provides branch-level traffic inspection without requiring a separate firewall appliance; supports both IPv4 and IPv6 traffic inspection
Intrusion Prevention System (IPS/IDS)	Snort-based intrusion detection and prevention engine running in the UTD container on cEdge routers; uses Cisco Talos threat intelligence signatures updated automatically; IDS mode monitors and alerts on malicious traffic; IPS mode actively blocks threats inline; signature categories include exploit, malware, policy-violation, and command-and-control; configure detection sensitivity levels (connectivity, balanced, security); custom signature rules can be added for organization-specific threats; logs alert events to vManage and external syslog servers
URL Filtering	Web content filtering on cEdge routers using Cisco URL categorization database with 80+ categories (gambling, adult, malware, social-media, streaming, etc.); define URL filtering policies with allow, block, and alert actions per category; supports custom allow-list and block-list entries for specific URLs/domains; cloud-based URL lookup ensures up-to-date categorization; provides compliance enforcement and acceptable use policy at the branch without backhauling web traffic to a central proxy; works for both HTTP and HTTPS traffic (HTTPS requires SSL/TLS decryption or SNI inspection)
Advanced Malware Protection (AMP)	File analysis and malware detection integrated into the UTD container; inspects file transfers (HTTP, SMTP, IMAP, POP3, FTP) for known malware using cloud-based file reputation lookups via SHA-256 hash; files with unknown reputation can be submitted to Cisco Threat Grid sandbox for dynamic analysis; supports file type filtering to block specific file extensions; retrospective alerts notify when a previously clean file is later identified as malicious; combined with IPS and URL filtering provides defense-in-depth at the branch
DNS/Web Layer Security (Umbrella)	Integration with Cisco Umbrella for cloud-delivered DNS-layer security; cEdge router redirects DNS queries to Umbrella resolvers (208.67.222.222/208.67.220.220) for inspection; Umbrella blocks requests to malicious or unwanted domains before the connection is established; provides protection against phishing, malware callbacks, and C2 communications at the DNS layer; supports per-VPN Umbrella policy with different security levels for corporate vs. guest networks; requires an Umbrella subscription and API token configured in vManage; lightweight security layer that complements on-box UTD features

Exam Tip: The UTD container on cEdge runs Enterprise Firewall, IPS/IDS, URL Filtering, and AMP as a unified security stack. UTD requires a security virtual image (utd.vip) to be installed on the cEdge. vEdge routers do NOT support UTD; they only support basic zone-based firewall. For the exam, know how to configure security policies in vManage, assign them to device templates, and understand the traffic flow through each security function in the UTD service chain.

Encryption and Data Plane Security

Feature	Description
IPsec Encryption	All data plane tunnels between WAN edge routers are encrypted with IPsec using AES-256-GCM by default; provides confidentiality, integrity, and anti-replay protection; keys are generated by each edge router and distributed via vSmart using OMP, eliminating the need for IKE negotiation; supports ESP with UDP encapsulation for NAT traversal; encryption is always on by default and cannot be disabled for the overlay tunnels; pairwise keys ensure that each tunnel pair has unique encryption keys
Key Rotation	IPsec keys are automatically rotated every 24 hours (default, configurable from 10 minutes to 30 days); key rotation happens seamlessly with no traffic interruption using a make-before-break approach; the new key is distributed via OMP before the old key expires; ensures forward secrecy by periodically refreshing encryption material; shorter rotation intervals increase security but add minor OMP overhead
Control Plane Security	All control plane connections between controllers (vManage, vBond, vSmart) and edge routers use DTLS (UDP) or TLS (TCP) encryption with mutual certificate authentication; prevents eavesdropping and man-in-the-middle attacks on control traffic; certificates are validated against the root CA; the organization name in the certificate must match; connection port is 12346 for both DTLS and TLS

Quality of Service (QoS)

QoS Component	Description
Classification and Marking	Traffic is classified on ingress using match criteria: DSCP values, source/destination IP, protocol, port, or application identity from DPI; marking sets or re-marks the DSCP value of classified packets to ensure consistent treatment across the SD-WAN fabric and service provider networks; classification is configured via localized QoS policy or access lists; trust DSCP from LAN or re-mark at the WAN edge based on organizational policy; inner DSCP (original packet) is preserved in the IPsec tunnel and optionally copied to the outer header for WAN provider QoS honoring
Forwarding Classes and Queues	Define up to 8 forwarding classes (queues) per interface; each class is mapped to a queue with a configured bandwidth percentage, buffer allocation, and scheduling discipline; queue 0 is typically LLQ (Low Latency Queuing) for real-time traffic (voice, video) with strict priority and a policer to prevent starvation; remaining queues use WFQ (Weighted Fair Queuing) or WRR (Weighted Round Robin) for bandwidth-proportional scheduling; WRED (Weighted Random Early Detection) can be enabled per queue for congestion avoidance based on DSCP markings; total bandwidth allocation across all queues must equal 100%
QoS Map and Scheduling	QoS map associates DSCP values with forwarding classes; for example, DSCP EF (46) maps to the voice queue, DSCP AF41 (34) maps to the video queue, DSCP AF21 (18) maps to the business-critical queue, and DSCP 0 (best effort) maps to the default queue; the QoS map is applied to WAN interfaces in the egress direction; shaping rate can be set per interface to match the WAN circuit bandwidth; per-tunnel QoS allows different bandwidth allocations for different TLOC tunnels on the same physical interface
Per-Tunnel QoS	When a single physical WAN interface carries multiple IPsec tunnels to different remote sites, per-tunnel QoS allocates bandwidth individually to each tunnel; prevents a single high-bandwidth tunnel from starving others; configured by setting tunnel bandwidth and enabling per-tunnel shaping; particularly important for hub sites where hundreds of spoke tunnels share a single WAN interface; each tunnel gets its own set of queues with the configured forwarding class percentages applied to the tunnel's allocated bandwidth

SD-WAN Quick Reference

Scenario	SD-WAN Solution
Steer voice traffic to low-latency path	App-route policy with SLA class (loss <1%, latency <150ms) + preferred-color mpls
Force branch traffic through hub firewall	Centralized control policy: set TLOC to hub + service chain (FW) via data policy
Break out SaaS traffic locally at branch	Centralized data policy with DIA + NAT on VPN 0 transport + Umbrella for DNS security
Block malware and intrusions at branch	UTD container on cEdge: Enterprise FW + IPS (Snort) + URL Filtering + AMP
Prioritize real-time traffic over data	Localized QoS policy: LLQ for voice (DSCP EF), WFQ queues for video/data/best-effort
Isolate guest from corporate traffic	Separate VPNs (VPN 10 corporate, VPN 30 guest) with no route leaking between them
Deploy routers without manual config	ZTP (vEdge) or PnP (cEdge) with pre-staged device templates and serial number whitelist
Ensure failover when MPLS link degrades	App-route policy with SLA class + backup preferred-color biz-internet + BFD monitoring
Create hub-and-spoke topology	Centralized control policy: accept routes from branches only at hub, set TLOC to hub for branch-to-branch
Monitor application performance	cflowd data policy + vManage dashboards + BFD tunnel metrics for loss/latency/jitter