Cisco ENSDWI 300-415 cheat sheet

Control plane and data plane are separated: vSmart distributes OMP routes and policies, vBond performs authentication and NAT traversal, vManage provides management and acts as the controller CA; vEdge/cEdge routers forward traffic directly to each other.

vManage is the single pane of glass and also runs the certificate authority by default; controllers use self-signed or enterprise-signed certificates, and the vBond must be reachable by every device to bootstrap trust.

vBond requires a public IP or 1:1 NAT and must be reachable on UDP 12346; devices behind NAT discover their public address through vBond and use it for IPsec tunnel establishment.

OMP runs over DTLS (UDP 12346) between routers and vSmart; TLOC routes carry system IP, color, and encapsulation, while OMP routes carry prefixes, TLOC, and service/VPN context.

Controller placement rule: vBond and vSmart in a DMZ or public cloud for reachability; vManage may be private if all devices can reach it; each controller role should be redundant (at least two vSmarts, two vBonds, and a vManage cluster for scale).

VPN 0 is the transport/underlay VPN carrying TLOCs and control connections; VPN 512 is reserved for out-of-band management; service VPNs (1-511, 513-65527) carry user traffic.

Colors (biz-internet, mpls, lte, public-internet, etc.) identify WAN transport types and drive TLOC selection; each TLOC is unique by system-IP + color + encapsulation.

Deployment models: controller-hosted on-premises, Cisco-hosted cloud, and managed cloud; the routers can be hardware vEdge, cEdge (IOS-XE), or virtual cloud routers (vEdge Cloud, CSR/Cat8k).

Onboarding sequence: device gets certificate/OTP, contacts vBond, is authenticated, receives vManage/vSmart lists, forms DTLS control connections, then exchanges OMP routes.

Feature templates define device-specific settings (VPN interfaces, routing, security, AAA); device templates bind feature templates to a device model and are attached to devices via device groups or directly.

CLI templates are free-form device configuration; they cannot be mixed with feature templates on the same device - a device uses one template type at a time.

Variables in feature templates (e.g., {{system_ip}}, {{vpn0_ip}}) are filled per device in the device template or device variables; undefined variables block template attachment.

Minimum device configuration before onboarding: system IP, site ID, organization name, vBond address, and certificates - often pushed via bootstrap or PnP/ZTP.

System IP must be unique per device and is the OMP router ID; site ID groups devices at a location and is used for topology and policy matching.

Interface configuration requires an IP address, color (for WAN transport), and encapsulation (IPsec or GRE) to form a TLOC; a TLOC without a color is not used for SD-WAN tunnels.

Default route on VPN 0 typically points to the WAN next hop; service VPNs use VRF with a default route toward the transport or a routing protocol (BGP/OSPF) in the service VPN.

Template change workflow: edit feature template, update device template, then push via device template; config diff and rollback are available, and devices show a 'sync' or 'out-of-sync' state.

Device groups and configuration groups (newer vManage) allow hierarchical, reusable configuration; configuration groups support variables and are the recommended model for scale.

Policy types: centralized policy (vSmart) vs localized policy (device); centralized control policy affects OMP routing, centralized data policy affects data forwarding (e.g., AAR, traffic engineering).

Centralized control policy can change topology (hub-and-spoke, full mesh, partial mesh), set route preference, and filter OMP routes by site, VPN, prefix, or TLOC.

Centralized data policy matches on VPN, source/destination prefix, DSCP, application, and protocol, then applies actions: accept, drop, or set (e.g., set TLOC, set DSCP, NAT).

Application-Aware Routing (AAR) uses SLA classes (latency, loss, jitter) and per-application probes; a traffic class picks the best TLOC that meets SLA and falls back to the next-best path.

AAR requires an application-aware routing policy with SLA class definitions and a data policy that maps traffic to a traffic class; BFD/ probe intervals and the number of probes affect failover speed.

Direct Internet Access (DIA) sends traffic out the local internet TLOC; it can be combined with application-based routing to keep SaaS traffic local while backhauling other traffic.

Topology example: hub-and-spoke with a hub site; control policy sets hub as next-hop for spoke routes, while data policy can allow direct spoke-to-spoke for selected applications.

Traffic engineering: prefer a TLOC for voice via control policy or set a higher preference; ensure both ends have consistent policy to avoid asymmetric routing.

Policy order matters: policies are evaluated top-down and the first match wins; explicit default (accept/drop) at the end is required to define unmatched traffic behavior.

IPsec is the default tunnel encapsulation; IKE uses UDP 500/4500, and IPsec ESP carries data; GRE is an option but lacks encryption, so use IPsec for untrusted transports.

Enterprise firewall features on cEdge include zone-based firewall, URL filtering, IPS/IDS (Snort), AMP, and Advanced Malware Protection; these are enabled through security feature templates.

Security policy (centralized data policy) can redirect traffic to a service VPN hosting a firewall or IPS device (service insertion) using a service chain or PBR.

Service insertion: place a service node in a service VPN, then use a centralized data policy with a service action to steer traffic through the node; return traffic must be routed back consistently.

SGT/TrustSec and segmentation: VPNs provide segmentation; SGT propagation can carry group tags across the SD-WAN fabric for policy enforcement.

DIA security: route internet-bound traffic through a local security stack or SIG/cloud security provider when direct internet access is enabled; do not send DIA traffic unencrypted.

Certificate management: controllers and devices use certificates for authentication; enterprise CA or Cisco PKI can be used, and expired certificates break control connections.

Control plane security: DTLS protects OMP; data plane uses IPsec; replay protection and anti-replay windows are configurable, and TLOC colors determine which transport is encrypted.

vManage dashboards show device health, control connections, TLOC status, and alarms; use Monitor > Devices for per-device control connection state and OMP peer status.

Common control connection states: 'up' means DTLS established; 'connect' or 'challenge' indicates certificate or reachability issues; check vBond reachability, certificates, and UDP 12346.

OMP troubleshooting: verify system IP, site ID, and TLOC; use 'show omp routes', 'show omp tlocs', and 'show sdwan omp peers' (cEdge) or 'show omp peers' (vEdge).

BFD is used for TLOC liveness and path quality; 'show sdwan bfd sessions' shows color, state, and remote system IP; BFD down indicates tunnel or path failure.

Tunnel troubleshooting: check IPsec/IKE SAs, NAT traversal, and ACLs on the underlay; asymmetric NAT or firewall blocking UDP 500/4500 prevents tunnel establishment.

Logs and events: vManage alarms, syslog, and 'show logging' on devices; use packet capture and 'show sdwan policy' to verify policy application.

Upgrades: controllers first (vBond, vSmart, vManage), then routers; use vManage image repository and validate compatibility; maintain controller redundancy during upgrade.

Backups: vManage configuration backup, device template backups, and CA backup; losing the CA can invalidate certificates across the fabric.

Performance monitoring: AAR probes and SLA metrics appear in vManage; verify probe configuration and that both ends support the same SLA class definitions.