Cisco SD-WAN Course in Pune — Viptela SD-WAN Training & ENSDWI Certification

The four-component Cisco SD-WAN architecture is where every understanding of SD-WAN must begin — because knowing what each component does, how they communicate with each other, and what happens when one of them is unavailable is the foundation for every configuration and troubleshooting decision that follows. This is not background reading: this is the conceptual framework that determines whether engineers understand what they are configuring or just following click-by-click instructions.

vManage is the management plane — the web GUI from which all SD-WAN configuration is done, all templates are created, all policies are written, and all monitoring is performed. Everything you do in the SD-WAN deployment originates in vManage. vSmart is the control plane controller — it receives OMP route advertisements from all vEdge and cEdge routers in the fabric, applies centralised routing policy, and distributes updated routing information back. No direct data-plane communication passes through vSmart; it only handles routing decisions. vBond is the orchestration plane — when a new vEdge router boots and needs to find vManage and vSmart, it contacts vBond first. vBond provides the addresses of vManage and vSmart and facilitates the DTLS/TLS control connections. vBond also handles NAT traversal, allowing vEdge routers behind NAT to establish connectivity with the rest of the fabric. vEdge (Viptela hardware) and cEdge (Cisco IOS-XE SD-WAN routers like ISR 4000 and ASR 1000 series) are the data plane devices — the branch routers that forward user traffic, establish IPSec tunnels to each other based on vSmart routing information, and enforce data plane policies.

OMP — the Overlay Management Protocol — is the routing protocol that makes Cisco SD-WAN work. Understanding OMP is the key to understanding why routes appear or do not appear at branch sites, how traffic steering policies work, and how to troubleshoot connectivity issues in an SD-WAN fabric. OMP runs between each vEdge/cEdge router and the vSmart controller — not directly between branch routers — and it carries three types of routes: OMP routes (prefixes learned from the WAN, redistributed from the site's LAN), TLOC routes (Transport Locator routes advertising the tunnel endpoints with their colour and encapsulation), and service routes (indicating which services like firewall or internet gateway are available at which site).

TLOC (Transport Locator) is the construct that ties a branch router's data plane tunnel endpoints to its control plane OMP routes. A TLOC has three components: the system IP (identifying the device), the colour (categorising the transport type — mpls, internet, biz-internet, lte), and the encapsulation (IPSec or GRE). When vSmart distributes routing information, it includes the TLOC of the advertiser — so when a branch router receives an OMP route for a remote site's LAN prefix, it also receives the TLOC attributes needed to establish a direct IPSec tunnel to that remote site's router. The full-mesh IPSec tunnel establishment between branches — so that branch-to-branch traffic does not hair-pin through the hub — is covered with BFD (Bidirectional Forwarding Detection) monitoring of each tunnel's loss, latency, and jitter in real time.

Cisco SD-WAN's template system is what allows a 500-site deployment to be managed from a single vManage. Rather than configuring each router individually via CLI, vManage uses device templates — combinations of feature templates that define every aspect of a router's configuration — that are attached to devices. When a template is updated, the change propagates to every device using that template simultaneously. Zero-Touch Provisioning allows new branch routers to be shipped directly to a branch office, plugged into an internet connection, and automatically configured without any IT staff on-site.

Feature templates cover every configurable aspect of a vEdge or cEdge router: the System feature template (system IP, site ID, organisation name, vBond address), the VPN 0 feature template (transport VPN — the WAN-facing interfaces that carry SD-WAN control and data plane traffic), the VPN 512 template (management VPN — out-of-band management access), and service VPN templates (VPN 1, 2, etc. — the LAN-facing VPNs carrying user traffic to different network segments). Variables in templates allow site-specific values (LAN IP addresses, tunnel source addresses) to be specified per device while sharing a common template. Zero-Touch Provisioning workflow — the vEdge contacts vBond using its pre-configured bootstrap configuration (often loaded via USB or via DHCP option 43), authenticates with its serial number/chassis ID registered in vManage, downloads its full configuration, and becomes operational — is configured end-to-end in a lab scenario.

Application-Aware Routing is the feature that customers most often cite as the reason they deployed Cisco SD-WAN — the ability to automatically steer each application over the transport path that best meets its performance requirements, and to automatically move applications to an alternative path when the current path's quality degrades below acceptable thresholds. This is what allows an enterprise to use both MPLS and internet broadband connections, route real-time applications (voice, video conferencing) over the low-latency MPLS path by default, and automatically switch to broadband if MPLS experiences packet loss or jitter spikes above a configured threshold — all without any manual intervention.

BFD (Bidirectional Forwarding Detection) runs between each pair of vEdge/cEdge routers across every transport path, measuring loss, latency, and jitter in real time. SLA Classes define the acceptable performance thresholds for each application category — for example, a Voice SLA class might specify maximum 150ms latency, 1% packet loss, and 30ms jitter. App-Route Policies match traffic to applications using NBAR application IDs or DSCP markings, specify which SLA class applies, define the preferred transport (MPLS first) and the fallback transport order (internet broadband second, LTE third), and specify whether to fail over automatically when the primary transport violates the SLA. The result is path selection that is continuously evaluated against real measured performance — not a static route that someone configured months ago and forgot to review.

Cisco SD-WAN has two categories of policy that serve different purposes and operate at different points in the architecture. Understanding the distinction between them — and knowing which type of policy to use for a given requirement — is one of the things that separates engineers who truly understand SD-WAN from those who can follow documentation. Centralised policies are configured in vManage and distributed by vSmart to all relevant vEdge/cEdge devices. Localised policies are configured in vManage, pushed to individual devices, and enforced locally without vSmart involvement.

Centralised data policies control how traffic is handled in the data plane across the entire SD-WAN fabric: traffic engineering policies that force specific traffic to use specific TLOCs (sending all MPLS-colored traffic over the MPLS transport), quality of service policies applied fabric-wide, and hub-and-spoke topologies that restrict which branches can communicate directly. Centralised control policies manipulate OMP route distribution at the vSmart level: restricting which routes specific sites receive, creating topologies where certain sites only receive routes through a hub, or filtering routes by prefix to control which networks are reachable from which sites. Localised data policies (ACLs applied to interfaces on specific devices) and localised control policies (route policies applied to OMP routes received or sent by a specific device) provide per-device policy enforcement for cases where fabric-wide centralised policy is too blunt. The QoS policy framework — traffic classification, marking, queuing (class-based weighted fair queuing, low-latency queuing for voice), and shaping at WAN interface egress — is configured as localised policy.

SD-WAN did not just replace MPLS — it changed the entire architecture of how enterprises connect their users to their applications. Cloud OnRamp for SaaS, Cloud OnRamp for IaaS, and the integration of cloud-based security into the SD-WAN traffic path are the capabilities that make SD-WAN genuinely transformative rather than just a less expensive MPLS replacement. This module covers the advanced SD-WAN features that appear on the ENSDWI exam and that differentiate senior SD-WAN engineers from basic practitioners.

Cloud OnRamp for SaaS automatically measures the performance of key SaaS applications (Office 365, Salesforce, Webex) from each branch through each available internet path, and dynamically routes SaaS traffic through the best-performing gateway. A branch with both broadband internet and MPLS connections might find that Office 365 performs better going directly to the internet from the branch than back-hauling through headquarters — Cloud OnRamp detects this and steers accordingly. Cloud OnRamp for IaaS extends the SD-WAN fabric into AWS and Azure, deploying vEdge instances in cloud regions that serve as SD-WAN connection points for workloads running in those clouds. Cisco Umbrella integration with SD-WAN allows all internet-bound traffic to be tunnelled to Umbrella's cloud security platform for DNS-layer and full proxy inspection — without deploying an on-premises firewall at every branch. Multi-Region Fabric addresses the large-scale SD-WAN deployments (thousands of sites, multiple geographic regions) where a single vSmart controller cluster becomes a bottleneck, introducing regional controllers and border routers to distribute the control plane.

SD-WAN troubleshooting is different from traditional WAN troubleshooting because the data plane, control plane, and management plane are all separated — and an issue in any one of them can cause connectivity or performance problems that look similar from the user's perspective. The engineer who can quickly determine whether a problem is a control plane OMP issue, a data plane tunnel problem, or a policy misconfiguration resolves incidents far faster than the engineer who starts with pings and works up from there without a systematic approach.

vManage monitoring tools are covered comprehensively: the real-time topology view showing all devices, tunnels, and their current status; the application-aware routing monitor showing which paths traffic is using and the measured performance metrics on each; the per-device configuration audit view showing whether a device's running configuration matches its vManage template; and the event log for tracking configuration pushes, alarm events, and device state changes. CLI troubleshooting on vEdge and cEdge routers covers the show sdwan commands: show sdwan omp routes (showing OMP-learned routes and their TLOC attributes), show sdwan bfd sessions (showing BFD state and measured performance for each tunnel), show sdwan policy from-vsmart (showing the policies received from vSmart), and show sdwan control connections (showing the state of DTLS/TLS connections to vManage and vSmart). The final two sessions are dedicated ENSDWI 300-415 exam preparation with practice questions, domain analysis, and timed mock exam sessions.