Lesson Overview
Cisco Catalyst SD-WAN is a software-defined wide area networking solution designed to simplify the deployment, management, security, and optimization of enterprise WAN connectivity.
Traditional WAN architectures often rely on device-by-device configuration and routing policies to connect branch offices, data centers, cloud environments, and remote locations. Cisco Catalyst SD-WAN introduces a centralized, policy-driven architecture that enables organizations to manage WAN infrastructure more efficiently.
This lesson introduces the fundamental concepts, architecture, components, and operational principles of Cisco Catalyst SD-WAN. Learners will understand how SD-WAN separates the control plane from the data plane, uses centralized controllers to distribute routing and policy information, and establishes secure overlay tunnels across different WAN transports, including MPLS, broadband internet, and LTE/5G.
The lesson also explores the roles of Cisco SD-WAN Manager (formerly vManage), SD-WAN Controller (formerly vSmart), SD-WAN Validator (formerly vBond), and WAN Edge devices, along with centralized policies, application-aware routing, secure connectivity, and network segmentation.
By completing this lesson, learners will gain a foundational understanding of how Cisco Catalyst SD-WAN improves enterprise WAN scalability, operational flexibility, application performance, and centralized network management.
Course overview topology: Cisco Catalyst SD-WAN control components and edge routers.
Learning Objectives
- Explain why SD-WAN separates management, control, and data-plane functions.
- Identify the roles of Cisco Catalyst SD-WAN Manager, Cisco SD-WAN Controller, Cisco SD-WAN Validator, and SD-WAN edge routers.
- Explain system IP, site ID, VPN/VRF, transport color, TLOC, OMP, IPsec, and BFD.
- Describe the edge onboarding and overlay bring-up process.
- Compare traditional WAN operation with an SD-WAN overlay.
- Configure a representative dual-transport edge and validate control, OMP, BFD, and route state.
- Troubleshoot common control-plane, routing, tunnel, and policy failures.
1. What Is Cisco Catalyst SD-WAN?
Cisco Catalyst SD-WAN is an enterprise WAN architecture that creates a centrally controlled overlay across one or more IP transport networks. Instead of treating every branch router and circuit as an isolated configuration target, the solution separates network intent and control information from packet forwarding. Edge routers still forward packets locally, but policy, reachability, and operational visibility are coordinated through centralized SD-WAN control components.
The underlay can be Internet, MPLS, Metro Ethernet, LTE/5G, or another IP network. The SD-WAN overlay is logically independent of those transports. This means an enterprise can use multiple providers and circuit types while presenting applications with a consistent routing, segmentation, security, and policy model.
1.1 Why Enterprises Use SD-WAN
- Use multiple WAN transports concurrently rather than keeping a second circuit only as a passive backup.
- Build secure site-to-site connectivity without manually creating a traditional tunnel for every pair of sites.
- Centralize policy and configuration intent while preserving distributed packet forwarding at the edge.
- Measure real path characteristics such as loss, latency, and jitter and steer applications according to SLA requirements.
- Create end-to-end segmentation using service VPNs/VRFs across shared transport infrastructure.
- Improve operational visibility with centralized inventory, alarms, telemetry, software lifecycle, and API-driven automation.
Figure 1.1: Traditional WAN and Catalyst SD-WAN use different operating models even when they share the same physical circuits.
1.2 SD-WAN Does Not Replace the Underlay
A common misunderstanding is that SD-WAN eliminates routing in the provider or Internet network. It does not. The underlay must still provide IP reachability from each edge transport interface to the SD-WAN control components and to remote edge transport addresses. The overlay then uses that reachability to build secure logical connectivity.
|
NOTE |
Think of the underlay as the roads and the SD-WAN overlay as a secure, policy-controlled transportation system running on top of those roads. |
2. Cisco Catalyst SD-WAN Architecture
The fabric has centralized control components and distributed edge routers. Cisco currently describes three major SD-WAN control components: Manager for centralized management, Controller for the overlay control plane, and Validator for secure onboarding/orchestration. Edge routers create the data plane and forward enterprise traffic.
Figure 2: High-level Catalyst SD-WAN architecture showing control components, WAN underlay, and distributed edge routers.
2.1 Cisco Catalyst SD-WAN Core Components
Cisco Catalyst SD-WAN consists of four primary components that work together to provide centralized network management, secure control-plane communication, automated device onboarding, and distributed traffic forwarding.
1. Cisco SD-WAN Manager (formerly vManage)
Primary Role: Centralized Management and Operations
Cisco SD-WAN Manager provides a centralized platform for managing, monitoring, configuring, and troubleshooting the SD-WAN fabric.
Key Functions
Centralized configuration and template management.
WAN Edge device onboarding and lifecycle management.
Network monitoring, alarms, and performance analytics.
Software image management and upgrades.
Centralized policy configuration and deployment.
Operational dashboards and troubleshooting tools.
What It Does Not Normally Do
SD-WAN Manager is not part of the normal branch-to-branch application traffic forwarding path. User traffic is forwarded by WAN Edge devices.
2. Cisco SD-WAN Controller (formerly vSmart)
Primary Role: Overlay Control Plane
Cisco SD-WAN Controller manages the SD-WAN overlay control plane using the Overlay Management Protocol (OMP).
Key Functions
Establishes secure control-plane connections with WAN Edge devices.
Receives and distributes OMP routing information.
Advertises transport-location (TLOC) information.
Distributes service-route information.
Applies centralized control policies.
Distributes information required for secure overlay operation.
What It Does Not Normally Do
The Controller does not forward normal branch-to-branch application traffic. WAN Edge routers forward traffic directly across the overlay according to their installed routing and forwarding information.
3. Cisco SD-WAN Validator (formerly vBond)
Primary Role: Initial Authentication and Orchestration
Cisco SD-WAN Validator facilitates the discovery, authentication, and initial orchestration of SD-WAN devices.
Key Functions
Assists WAN Edge devices during initial connection to the SD-WAN fabric.
Supports initial authentication and device validation.
Provides controller connection information.
Facilitates NAT traversal and public/private address discovery.
Helps WAN Edge devices establish connectivity with appropriate controllers.
What It Does Not Normally Do
SD-WAN Validator does not normally distribute OMP routing information or make centralized routing-policy decisions. These functions are handled by the SD-WAN Controller.
4. Cisco SD-WAN Edge (Legacy vEdge / Cisco IOS XE cEdge)
Primary Role: Distributed Data Plane
WAN Edge devices are deployed at branch offices, campuses, data centers, and other WAN locations to provide secure network connectivity.
Key Functions
Establishes secure IPsec tunnels with other WAN Edge devices.
Forwards application and user traffic across WAN transports.
Connects local LAN networks to the SD-WAN overlay.
Exchanges routing information with SD-WAN Controllers using OMP.
Supports application-aware routing and traffic steering.
Implements QoS, segmentation, and supported security policies.
Provides connectivity through MPLS, broadband internet, and cellular WAN transports.
What It Does Not Normally Do
WAN Edge devices do not send every individual traffic-forwarding decision to a centralized controller. Instead, they use locally installed forwarding information and policies to forward traffic.
|
MEMORY |
vManage manages. vSmart learns, decides, and distributes. vBond introduces/authenticates. vEdge/cEdge forwards user traffic. |
2.2 Identification Values Used by the Fabric
|
Value |
Purpose |
Example |
|
Organization name |
Common trust/administrative identity for the fabric |
NGA-LAB |
|
System IP |
Stable overlay node identifier; similar in concept to a router ID |
10.255.1.1 |
|
Site ID |
Identifies the logical site; devices at one site use the same site ID |
101 |
|
VPN/VRF ID |
Separates transport or service routing contexts |
0 for transport; 10 for CORP |
|
Color |
Logical name for a transport/TLOC |
mpls, biz-internet |
|
TLOC |
Transport location identifying a WAN attachment |
{system IP, color, encapsulation} |
3. Management, Control, Orchestration, and Data Planes
Figure 3: The same physical device may participate in multiple functions, but the architectural roles remain distinct.
3.1 Management Plane — Cisco Catalyst SD-WAN Manager (vManage)
The Management Plane is responsible for the centralized configuration, administration, monitoring, and lifecycle management of the Cisco Catalyst SD-WAN fabric.
In traditional enterprise WAN environments, network engineers frequently configure routers individually using the Command-Line Interface (CLI), which can increase operational complexity and create configuration inconsistencies.
Cisco Catalyst SD-WAN introduces Cisco SD-WAN Manager (formerly vManage), a centralized network management platform that allows administrators to manage WAN Edge routers and SD-WAN infrastructure from a common interface.
SD-WAN Manager provides visibility into device health, transport connectivity, configuration deployment, network performance, policy management, and troubleshooting.
Important: SD-WAN Manager does not normally participate in forwarding user application traffic between branches. Traffic forwarding occurs on WAN Edge devices.
Figure 3.1: Management plan Architecture
3.2 Control Plane — Cisco SD-WAN Controller (vSmart)
The Cisco Catalyst SD-WAN Controller (formerly vSmart) is responsible for managing the SD-WAN overlay control plane.
In traditional enterprise WAN networks, routers exchange routing information directly using protocols such as OSPF, EIGRP, or BGP. Each router independently builds its routing table based on information received from its neighbors.
In Cisco Catalyst SD-WAN, WAN Edge routers exchange overlay routing information with centralized SD-WAN Controllers through the Overlay Management Protocol (OMP).
The Controllers learn routing and transport information from WAN Edge routers, apply centralized control policies, and distribute permitted routing information across the SD-WAN fabric.
This enables centrally managed connectivity between branch offices, data centers, campuses, and cloud environments.
Important: The Controller manages overlay routing information and policy distribution. It does not forward normal branch-to-branch user traffic.
Figure 3.2: Control Plane Architecture
A typical SD-WAN control-plane architecture contains:
SD-WAN Controller: Maintains OMP peering with WAN Edge devices and distributes routing information.
WAN Edge Routers: Advertise local routes and transport information to Controllers.
Secure Control Connections: Protect communication between Controllers and WAN Edge devices.
OMP: Exchanges overlay routing, TLOC, and service-route information.
Centralized Control Policy: Determines how eligible routes and transport information are distributed.
The Cisco SD-WAN Validator (formerly vBond) is responsible for supporting the initial authentication, discovery, and orchestration of devices joining the Cisco Catalyst SD-WAN fabric.
When a new WAN Edge router is installed at a branch, it must locate the appropriate SD-WAN Controllers and Manager before becoming operational.
The Validator helps the device establish these initial relationships.
It also assists with NAT traversal, allowing WAN Edge routers behind NAT devices to discover the public and private transport addressing information required for SD-WAN communication.
Important: The Validator does not normally forward application traffic and does not act as the OMP routing controller.
Figure 3.3: Orchestration Architecture
Primary responsibilities
Initial controller discovery.
Secure device authentication assistance.
Authorized device validation.
NAT information discovery and assistance.
Distribution of controller connection information.
Initial orchestration of control connections.
The WAN Edge-to-Validator connection as normally temporary during onboarding, while the Validator maintains persistent relationships with other control components. Certain control-connection recovery conditions can also result in a WAN Edge maintaining a Validator connection.
3.3.1 How WAN Edge Onboarding Works
When a WAN Edge router boots for the first time, it must establish trusted control-plane connectivity with the SD-WAN infrastructure.
Step 1 — WAN Edge Initialization
The WAN Edge starts its software and loads its initial configuration or bootstrap information.
Typical required parameters include:
System IP
Site ID
Organization name
Validator address or hostname
Transport interface configuration
Device identity and certificates
Step 2 — Validator Discovery
The WAN Edge attempts to reach the configured Validator.
The Validator must be reachable through the WAN transport.
For an internet-based deployment, public reachability, DNS, and NAT or firewall policy must be configured correctly.
Step 3 — Secure Authentication
The WAN Edge establishes a secure DTLS connection with the Validator.
The SD-WAN infrastructure uses certificates and authorized device identity information to establish trust.
The device must be recognized as an authorized participant in the organization's SD-WAN overlay.
Step 4 — Controller Information Exchange
After successful validation, the Validator provides information that allows the WAN Edge to discover and reach the appropriate SD-WAN Manager and Controllers.
The Validator can also assist with public/private transport address discovery.
Step 5 — Permanent Control Connections
The WAN Edge establishes its required secure control connections with:
Cisco SD-WAN Manager
Cisco SD-WAN Controllers
These connections normally use DTLS or TLS, depending on the configured protocol and supported software.
Step 6 — OMP Establishment
After secure Controller connectivity is established, the WAN Edge forms OMP peer relationships with the appropriate Controllers.
It can then exchange routing and transport information.
Step 7 — Secure Overlay Formation
Once permitted OMP routes and TLOCs are learned, the WAN Edge can establish eligible IPsec overlay tunnels with other WAN Edge devices.
BFD sessions are used to monitor the resulting data-plane paths.
3.3.4 NAT Traversal and Public/Private Transport Addresses
NAT traversal is an important orchestration function.
WAN Edge devices may be located behind provider or enterprise NAT infrastructure.
Consider this example:
The Validator can help WAN Edge devices learn relevant public and private transport information.
This supports communication across NAT boundaries, subject to compatible NAT behavior and permitted transport flows.
Important distinction: Validator-assisted NAT discovery does not guarantee that every pair of NAT types or firewall policies will permit direct overlay connectivity.
3.4 Data Plane — Cisco SD-WAN Edge Routers (vEdge / cEdge)
The Cisco Catalyst SD-WAN Edge Router is responsible for forwarding actual user and application traffic across the SD-WAN network.
While the SD-WAN Manager provides centralized management and the SD-WAN Controller distributes routing and policy information, WAN Edge routers perform packet forwarding and enforce relevant data-plane policies.
WAN Edge routers are typically deployed at:
Branch offices
Data centers
Enterprise campuses
Regional hubs
Cloud connectivity locations
WAN Edge devices establish secure overlay connectivity across available WAN transports such as MPLS, broadband internet, and cellular links.
3.4.1 Types of WAN Edge Routers
1. Cisco vEdge
vEdge routers represent the original Viptela-based SD-WAN router platforms.
They use the Viptela operating environment and CLI syntax.
Their primary functions include establishing control connections, exchanging OMP information, forwarding user traffic, and supporting secure overlay connectivity.
2. Cisco IOS XE Catalyst SD-WAN Edge (cEdge)
cEdge routers run Cisco IOS XE in SD-WAN mode.
These devices integrate enterprise routing capabilities with SD-WAN functions.
Common deployment families include supported Cisco Catalyst 8000 Edge Platforms and other compatible IOS XE SD-WAN devices.
Important: vEdge and cEdge perform similar architectural roles but use different operating environments and CLI command structures. Feature support varies by hardware and software release.
3.4.2 WAN Edge Data Plane Architecture
4. Underlay, Overlay, TLOCs, and Transport Colors
Cisco Catalyst SD-WAN uses a software-defined networking architecture that separates the physical WAN transport infrastructure from the logical network used to connect enterprise branches, data centers, campuses, and cloud environments.
Figure 4: Dual-transport design: the same site can build overlay tunnels over MPLS and Internet simultaneously.
4.1 Underlay
The underlay is the provider or enterprise IP network that gives transport interfaces basic reachability. Traditional routing still matters here. DNS, default routes, firewall rules, NAT behavior, MTU, and upstream reachability can all determine whether SD-WAN control connections and data tunnels form successfully.
4.2 Overlay
The overlay is the logical SD-WAN network formed between authenticated edge routers. Remote service prefixes are learned through OMP, and forwarding uses secure tunnels between eligible TLOC pairs. The overlay can therefore maintain consistent enterprise routing and segmentation even when sites use different physical WAN services.
4.3 Transport Location - TLOC
A TLOC represents an edge attachment to a WAN transport. A useful mental model is the three-part identity: system IP + color + encapsulation. A dual-homed branch can therefore advertise multiple TLOCs for the same edge system IP.
Figure 4.3: OMP carries service reachability and TLOC information so edges can resolve overlay routes to usable WAN paths.
4.4 Transport Colors
A color is a logical name applied to a transport. Examples include mpls, biz-internet, public-internet, lte, metro-ethernet, and other predefined values. Policy can prefer, restrict, or steer traffic using colors. Colors are not VLAN IDs and they are not merely cosmetic labels; they participate in TLOC identity and policy decisions.
5. Overlay Management Protocol - OMP
OMP is the control protocol responsible for building and maintaining the SD-WAN overlay control plane. It runs between edge routers and SD-WAN Controllers over secure control connections. OMP exchanges information that conventional routing protocols do not carry as a single integrated system.
5.1 What OMP Advertises
|
Information |
Meaning |
Why it matters |
|
OMP/vRoutes |
Service-side prefixes learned locally |
Provides remote reachability across the overlay. |
|
TLOC routes |
Transport locations and associated attributes |
Tells edges where remote tunnel endpoints are reachable. |
|
Service routes |
Locations of advertised network services |
Supports service insertion/chaining designs. |
|
Policy/security information |
Attributes and control-plane directives |
Lets the fabric implement central intent consistently. |
5.2 OMP Routing Flow Example
Figure 5.2: OMP routing flow step by step
1. Branch Edge A learns 10.1.10.0/24 on its service side.
2. The edge advertises the prefix through OMP together with transport reachability attributes.
3. The Controller receives the route and evaluates centralized control policy.
4. The Controller advertises permitted reachability to Branch Edge B and other relevant edges.
5. Branch Edge B resolves the received route to one or more remote TLOCs and installs usable forwarding state.
6. Actual application packets travel edge-to-edge through the data plane; they do not traverse the Controller.
5.3 OMP and Conventional Routing
An edge often runs OSPF, BGP, connected, or static routing on the service side. Selected local routes are advertised into OMP. Remote OMP routes can then be installed in the appropriate service VPN/VRF and, if required, redistributed into a local routing protocol. Engineers must therefore troubleshoot both domains: local site routing and overlay OMP state.
6. Secure Control Plane and Overlay Bring-Up
Cisco Catalyst SD-WAN uses a secure, software-defined architecture to establish connectivity between enterprise branch offices, data centers, campuses, and cloud environments.
Before WAN Edge routers can exchange application traffic across the SD-WAN overlay, they must establish underlay connectivity, authenticate with the SD-WAN infrastructure, form secure control-plane connections, exchange routing and transport information, and establish functional data-plane tunnels.
This process is known as SD-WAN overlay bring-up.
Unlike traditional WAN networks, where routing adjacencies and tunnels may be configured individually between routers, Cisco Catalyst SD-WAN automates many of these operations through centralized control components.
Figure 6: Simplified edge onboarding and overlay bring-up sequence.
6.1 Prerequisites on an Edge
- Valid device identity/certificate and correct system clock.
- System IP, site ID, organization name, and Validator address configured correctly.
- Transport interface with an IP address and SD-WAN tunnel-interface attributes.
- Underlay route to required controllers/Validator.
- DNS resolution if hostnames are used.
- Firewalls/NAT permitting required control-plane communication.
6.2 Control Connections
Control connections are secured with DTLS or TLS depending on component, platform, and configuration. The edge establishes persistent control relationships to SD-WAN Controllers. OMP runs over these secure control connections. Because the control plane is separated from the data plane, a controller failure and a WAN path failure are different troubleshooting events.
6.3 Why Certificates Matter
The fabric uses certificates and cryptographic identity to ensure that only authorized devices join the overlay. This prevents an arbitrary router on the Internet from becoming a trusted edge simply by knowing the Controller address. Certificate validity, time synchronization, organization name consistency, and device authorization are therefore common control-connection troubleshooting checks.
7. Data Plane: IPsec Tunnels and BFD
After control-plane exchange provides the required TLOC and security information, edge routers can form direct secure data-plane connectivity. User traffic is carried across IPsec tunnels between edges. BFD sessions operate across the data tunnels to determine whether each path is alive and to measure characteristics used by application-aware routing.
7.1 What BFD Gives the Fabric
- Fast detection of tunnel/path failure.
- Loss, latency, and jitter information for path quality assessment.
- Automatic removal of unusable forwarding paths when a data tunnel fails.
- Input to application-aware routing so path decisions can reflect real transport performance rather than only route preference.
7.2 Control Plane Up vs Data Plane Up
In Cisco Catalyst SD-WAN, the Control Plane and Data Plane perform different functions and must be verified independently.
A WAN Edge router may have healthy control connections and OMP routing relationships while application traffic fails because of an IPsec tunnel, BFD, routing, or policy problem.
Key concept: Control Plane Up does not automatically mean Data Plane Up.
1. Control Plane Up — What Does It Mean?
The Control Plane is responsible for exchanging routing and transport reachability information between WAN Edge routers and Cisco SD-WAN Controllers (vSmart).
When the Control Plane is Up:
WAN Edge has established secure connections with the expected Controllers.
OMP peer relationships are operational.
Eligible service routes and TLOC information can be exchanged.
Centralized control policies can influence route distribution.
The WAN Edge can learn remote overlay reachability information.
2. Data Plane Up — What Does It Mean?
The Data Plane is responsible for forwarding actual application traffic between WAN Edge routers through the secure SD-WAN overlay.
When the Data Plane is Up:
The required IPsec overlay paths are operational.
Expected BFD sessions are Up.
Remote TLOCs are reachable through the underlay.
The WAN Edge has usable forwarding entries.
Packets can traverse the intended overlay paths.
|
NOTE |
An edge can have healthy control connections but still have failed BFD sessions to a remote edge. That means the control plane knows the topology, but the actual edge-to-edge data path is not usable. Troubleshoot the planes independently. |
8. Segmentation with Service VPNs / VRFs
Figure 8: Example end-to-end segmentation carried over the same physical WAN transports.
Catalyst SD-WAN separates transport connectivity from service-side enterprise routing. Transport connectivity is commonly associated with VPN 0, while enterprise segments are placed into service VPNs/VRFs. This allows CORP, VOICE, GUEST, PCI, OT, or other logical networks to share the same edges and circuits while keeping routing tables and policies separated.
8.1 Why Segmentation Matters
- Reduces route and policy leakage between business domains.
- Supports different security and application-routing policies for different traffic classes.
- Allows a common WAN fabric to transport multiple logical networks.
- Maps naturally to enterprise VRF-based segmentation in campus and data-center networks.
9. Centralized Policy and Application-Aware Routing
A major advantage of SD-WAN is the ability to express routing and forwarding intent centrally. Control policy can influence route/TLOC advertisement and topology. Data policy can influence packet forwarding. Application-aware routing (AAR) combines traffic classification with BFD-derived path measurements and SLA classes.
Figure 9: Application-aware routing can move selected traffic between eligible tunnels when path quality changes.
9.1 AAR Decision Logic
1. Identify the traffic of interest, such as voice, business applications, or specific prefixes/ports.
2. Define an SLA class using acceptable loss, latency, and/or jitter thresholds.
3. Map matching traffic to the SLA class and optionally prefer one or more transport colors.
4. BFD continuously supplies path measurements for local-to-remote TLOC pairs.
5. The edge selects a qualifying tunnel according to the active policy and current measurements.
6. When path quality degrades beyond policy thresholds, eligible traffic can move to another path; when the path recovers, policy behavior determines whether traffic returns.
9.2 Why This Is Different from Simple Failover
Traditional routing may keep using a path as long as the next hop is reachable, even when the circuit is experiencing heavy packet loss or excessive jitter. AAR can detect these “brownout” conditions and steer selected applications before the link becomes completely unreachable.
10. Traditional WAN vs Catalyst SD-WAN
|
Area |
Traditional WAN |
Cisco Catalyst SD-WAN |
|
Operating model |
Distributed device-by-device operation; routing and policy are configured mainly on individual routers. |
Centralized management and policy with distributed forwarding at WAN edges. |
|
Management |
CLI/SNMP/NMS tools may be separate; consistency depends heavily on operational process. |
vManage / SD-WAN Manager provides centralized GUI, APIs, inventory, configuration, monitoring, alarms, certificates, and software lifecycle. |
|
Control plane |
BGP, OSPF, EIGRP, static routing, DMVPN/NHRP, provider routing, and local policy independently influence reachability. |
vSmart / SD-WAN Controller runs the centralized overlay control plane using OMP and distributes policy-adjusted reachability/TLOC information. |
|
Initial onboarding |
Router is normally preconfigured or staged through separate provisioning systems. |
vBond / SD-WAN Validator provides secure orchestration/rendezvous and helps new edges discover the fabric. |
|
WAN edge |
Branch router performs forwarding and usually has locally configured WAN/routing policy. |
vEdge (legacy) or IOS XE cEdge/WAN edge forwards user traffic and enforces centrally defined/local policy. |
|
Tunnel model |
DMVPN/IPsec/GRE or other VPN design may require hub/spoke or peer-specific configuration and separate key/tunnel planning. |
Secure overlay tunnels are formed between eligible WAN-edge TLOCs according to fabric reachability and policy. |
|
Transport use |
Often MPLS-primary with Internet backup, or circuit roles are statically defined. |
MPLS, Internet, broadband, Metro-E, LTE/5G and other IP transports can be active simultaneously. |
|
Path selection |
Primarily routing metrics, next-hop reachability, PBR, tracking, or separate performance-routing features. |
Policy can combine routing intent with TLOCs and measured path quality; AAR can steer applications using loss, latency, and jitter thresholds. |
|
Failure behavior |
Often reacts when route/next hop becomes unreachable; brownout detection may require extra mechanisms. |
BFD continuously measures overlay paths and policy can react to hard failures or SLA degradation. |
|
Segmentation |
VRFs/MPLS VPNs/ACLs are coordinated device by device and possibly with provider services. |
Service VPN/VRF segmentation can be carried consistently across the SD-WAN overlay. |
|
Security |
IPsec, firewall, PKI, and routing security may be separate design layers and configurations. |
Authenticated fabric plus encrypted edge-to-edge overlay is integral to the architecture; security policy can be centrally orchestrated. |
|
Application awareness |
Often limited unless dedicated DPI/performance-routing or SD-WAN-like tooling is added. |
Application-aware routing can classify traffic and select paths based on policy and SLA measurements. |
|
Cloud/SaaS access |
Backhaul through data center is common in older designs; direct Internet access requires separate design. |
Supports direct Internet/cloud/SaaS connectivity and centralized policy for path selection and security integration. |
|
Visibility |
Troubleshooting frequently requires logging into multiple routers and correlating separate monitoring systems. |
Centralized health/telemetry/topology visibility in Manager plus device CLI and APIs for deeper verification. |
|
Scale of change |
A routing/policy change may require repeated CLI changes on many routers. |
Reusable configuration/policy can be applied across site groups, reducing repetitive device configuration but increasing the blast radius of a bad centralized policy. |
|
Provider dependency |
Private WAN features and topology may be closely coupled to carrier design. |
Transport-agnostic overlay can use multiple providers; MPLS can remain one underlay rather than being replaced. |
|
Data path |
Packets follow router-to-router/provider paths based on the configured WAN design. |
Application packets are forwarded directly by WAN edges; vManage/vSmart/vBond are not normal transit devices for user traffic. |
|
Provisioning / branch turn-up |
New sites are commonly staged with site-specific CLI, routing, VPN, QoS, ACL, NAT, and monitoring settings, unless a separate automation platform is used. |
Zero-touch or automated onboarding can bring an authenticated WAN edge into the fabric and then apply reusable configuration and centralized policy. |
|
Configuration consistency |
Standards depend on templates, scripts, change procedures, and engineer discipline; configuration drift can develop between sites. |
Central configuration groups/templates and policy reduce repetitive configuration and make consistency easier to enforce across site groups. |
|
Circuit utilization |
Many older designs use an expensive private circuit as primary and keep Internet or cellular mostly as backup. |
Multiple transports can be active at the same time, allowing different applications or prefixes to use different eligible paths. |
|
Brownout handling |
A circuit may remain routed as UP even when loss, latency, or jitter makes an application unusable; additional probes/PfR/IP SLA logic may be required. |
BFD path measurements and application-aware routing can react to SLA degradation even when the physical interface is still UP. |
|
QoS and application policy |
QoS is usually configured per device/interface and path selection is normally separate from application classification. |
QoS, application identification, centralized policy, and SLA-based path selection can be coordinated as part of the SD-WAN design. |
|
Change deployment |
The same change may need to be repeated across many routers or executed through external automation. |
A central policy or configuration change can be deployed to groups of devices; this is efficient, but an incorrect policy can create a larger blast radius. |
|
Troubleshooting model |
Focuses mainly on interfaces, routing adjacencies, routing tables, VPN/tunnel state, ACLs, NAT, QoS, and provider circuits. |
Requires layered troubleshooting: underlay IP reachability, identity/certificates, control connections, OMP, TLOC/BFD, service routes, policy, and application path. |
|
Controller dependency |
No SD-WAN controller fabric is required; routers can continue exchanging routes directly according to the WAN design. |
Management and control systems are fundamental to operations. Existing data-plane tunnels can continue forwarding in many failure cases, but management/policy/control changes depend on healthy controller services. |
|
Operational skill set |
Strong knowledge of routing, MPLS, DMVPN/GRE/IPsec, QoS, NAT, ACLs, and provider troubleshooting is central. |
The same routing fundamentals remain necessary, plus OMP, TLOCs, BFD, certificates, templates, centralized policy, APIs, and controller troubleshooting. |
|
Migration impact |
Existing designs can often be extended incrementally without introducing a new controller architecture. |
Migration requires planning for edge conversion/replacement, controller reachability, certificates, segmentation, policy translation, coexistence, and rollback. |
|
Cost model |
May rely heavily on premium carrier circuits and operational effort; simple small networks can be inexpensive to operate. |
Can improve utilization of lower-cost Internet transports and reduce repetitive operations, but adds platform subscriptions/licensing, controller services, and migration/training costs. |
|
Vendor / platform coupling |
Core routing standards are broadly interoperable, although provider services and feature sets still vary. |
Overlay policy, controllers, orchestration, analytics, and workflows are platform-specific, so design should consider feature portability and vendor dependence. |
10.1 Branch-to-Data-Center Example: Traditional WAN vs SD-WAN
Both traditional WAN and Cisco Catalyst SD-WAN can use the same physical connectivity. The main differences are how routers are configured, how routing information is exchanged, how secure tunnels are established, and how applications are directed across available WAN paths.
The following six phases explain the operational differences.
Phase 1 — Branch Provisioning and Configuration
Traditional WAN
What Happens
The network engineer configures the branch router with WAN interfaces, routing protocols, QoS policies, VPN tunnels, tracking mechanisms, and security settings.
Depending on the network design, configurations may be maintained separately across individual routers.
Example
A branch router uses:
MPLS as the primary WAN connection.
Internet as a secondary connection.
BGP or static routing for MPLS connectivity.
IPsec or DMVPN for secure Internet-based connectivity.
IP SLA and tracking for failure detection.
Cisco Catalyst SD-WAN
What Happens
Cisco SD-WAN Manager (vManage) provides centralized configuration management.
Administrators can use supported Configuration Groups, Feature Profiles, or traditional templates to deploy standardized configurations to WAN Edge devices.
Operational Advantage
Common network configurations and policies can be managed centrally while device-specific addressing and identification remain unique.
Phase 2 — Establishing Network Reachability
Traditional WAN
What Happens
The branch establishes network reachability using its configured routing protocols or static routes.
For MPLS, the branch may exchange routes with the provider using BGP.
Internet-based connectivity may use IPsec or DMVPN tunnels, with routing configured according to the VPN architecture.
Cisco Catalyst SD-WAN
What Happens
The WAN Edge establishes underlay reachability and uses the SD-WAN Validator (vBond) during onboarding.
It then establishes secure control connections with SD-WAN Controllers (vSmart).
Using OMP, WAN Edge devices exchange eligible service routes and TLOC information through the Controllers.
Operational Advantage
Overlay routing information and transport reachability can be distributed through a centralized control-plane architecture.
Phase 3 — Establishing Secure WAN Connectivity
Traditional WAN
What Happens
Secure tunnels are configured according to the VPN design.
Technologies may include:
Site-to-site IPsec
DMVPN
GRE over IPsec
Other supported encrypted tunnel architectures
Engineers must ensure the required tunnel endpoints, routing, encryption parameters, and reachability are configured correctly.
Cisco Catalyst SD-WAN
What Happens
WAN Edge routers use learned TLOC information and applicable policies to establish eligible secure IPsec overlay tunnels across WAN transports.
BFD monitors the operational health of the resulting overlay paths.
Operational Advantage
Eligible overlay connectivity is established using centrally distributed transport information, reducing the need to configure individual peer-to-peer tunnel relationships.
Phase 4 — Application Path Selection
Traditional WAN
What Happens
Traffic path selection commonly depends on:
Routing protocol metrics and attributes.
Static route administrative distance.
Policy-Based Routing (PBR).
IP SLA and object tracking.
Provider routing policies.
Example
A branch uses MPLS as its preferred route to a Data Center.
When MPLS fails, routing or tracking mechanisms can cause traffic to use an Internet VPN backup path.
Cisco Catalyst SD-WAN
What Happens
WAN Edge devices can select eligible paths using centralized or localized policies and application-aware routing.
BFD provides path-performance measurements, including latency, jitter, and packet loss.
For example:
Voice traffic can prefer MPLS.
Selected business applications can prefer Internet.
Traffic can move between eligible paths according to SLA and policy conditions.
Operational Advantage
Different applications can use different WAN paths based on their requirements rather than relying exclusively on destination-based routing.
Phase 5 — Handling WAN Performance Degradation
A brownout occurs when a WAN connection remains operational but experiences degraded performance, such as high latency, jitter, or packet loss.
Traditional WAN
What Happens
A routing protocol may continue considering the MPLS path available because the interface and routing adjacency are Up.
Without separately configured performance-aware mechanisms, application traffic may continue using the degraded path.
Even though the link is operational, voice and real-time applications may experience poor performance.
Traditional WAN can address this using suitable IP SLA, tracking, PBR, or other performance-routing mechanisms.
Cisco Catalyst SD-WAN
What Happens
Application-Aware Routing (AAR) can evaluate BFD-based path measurements against configured SLA requirements.
If the selected path violates an application SLA, the WAN Edge can select another eligible path according to the configured policy.
Example
Measurement | MPLS | Internet |
|---|---|---|
Latency | 220 ms | 45 ms |
Jitter | 55 ms | 8 ms |
Packet loss | 8% | 0.2% |
Interface status | Up | Up |
If the Internet path meets the applicable SLA and is eligible, SD-WAN can steer the affected application traffic to it.
Operational Advantage
SD-WAN can respond to path-quality degradation even when the physical connection remains Up.
Phase 6 — Network Troubleshooting
Traditional WAN
What Happens
Network engineers typically investigate routing, interfaces, VPN tunnels, QoS, tracking, and security settings across the relevant devices.
Useful Commands
show ip interface brief
show ip route
show ip bgp summary
show crypto ikev2 sa
show crypto ipsec sa
show track
show interfaces
Commands depend on the deployed routing and VPN technologies.
Cisco Catalyst SD-WAN
What Happens
Troubleshooting can begin with centralized visibility in SD-WAN Manager, followed by detailed verification on the affected WAN Edge devices.
Useful Commands
show control connections
show omp peers
show omp routes
show omp tlocs
show bfd sessions
show app-route stats
show ip route vrf 10
10.2 Important Nuance
SD-WAN does not make routing fundamentals obsolete. Engineers still need IP addressing, NAT, BGP/OSPF, MTU, QoS, security, DNS, certificates, and troubleshooting skills. SD-WAN adds an overlay and centralized policy system on top of those fundamentals.
10.3 Traditional WAN Is an Operating Model, Not a Single Protocol
Traditional WAN describes the conventional way of building wide-area connectivity using routers, service-provider circuits, routing protocols, and individually engineered VPN or security functions. A traditional WAN may use MPLS Layer 3 VPN, leased lines, Metro Ethernet, broadband Internet, IPsec site-to-site VPNs, GRE/DMVPN, or a combination of these technologies. The important distinction is that routing and policy decisions are generally distributed across routers rather than coordinated by an SD-WAN control system.
Common routing technologies: BGP, OSPF, EIGRP, static routes, route maps, PBR, IP SLA, HSRP/VRRP, and provider-managed MPLS routing.
Common overlay/VPN technologies: GRE, IPsec, DMVPN/NHRP, and carrier MPLS VPN services.
Common operational model: device-by-device configuration or separate automation/NMS platforms, with each router retaining its own control-plane logic.
10.4 Architecture: Distributed WAN vs Controller-Based SD-WAN
|
Layer |
Traditional WAN |
Cisco Catalyst SD-WAN |
|
Management |
Routers are managed individually or by general-purpose NMS/automation tools. |
vManage / Cisco Catalyst SD-WAN Manager centralizes configuration, inventory, monitoring, certificates, software lifecycle, APIs, and policy workflows. |
|
Orchestration |
No direct equivalent is required. Device discovery and VPN establishment depend on the chosen routing/VPN design. |
vBond / SD-WAN Validator provides secure rendezvous/orchestration and helps authenticated edges discover control components. |
|
Control plane |
Each router independently exchanges and calculates routes using BGP, OSPF, EIGRP, static routing, DMVPN/NHRP, and local policy. |
vSmart / SD-WAN Controller exchanges OMP information with edges and distributes routing, TLOC, and policy information. |
|
Data plane |
Routers forward traffic using their local FIB/routing and VPN state. |
vEdge/cEdge/WAN Edge routers forward user traffic directly across secure overlay tunnels. Controllers do not normally sit in the application data path. |
10.5 Control Plane and Route Distribution
In a traditional WAN, the routing control plane is distributed. Every router forms routing adjacencies or peers according to the design and makes its own best-path calculation. At scale, engineers must coordinate routing policy, summarization, redistribution, filtering, and failover behavior across many nodes.
In Catalyst SD-WAN, WAN edges still maintain local routing tables and can run conventional routing protocols on the service side, but overlay reachability is exchanged through OMP with vSmart/SD-WAN Controllers. This allows control policy to influence which routes and TLOCs are advertised without placing vSmart in the user-data path.
|
CCNP KEY POINT |
vSmart controls the overlay; it does not normally forward user application traffic. vEdge/cEdge/WAN Edge devices perform the actual data-plane forwarding. |
10.6 Data Plane, Tunnels, and Encryption
Traditional WAN encryption depends on the chosen design. MPLS provides traffic separation inside the provider network but is not inherently the same as customer-controlled end-to-end encryption. Internet-based traditional WANs usually require an independently designed IPsec/DMVPN/GRE solution when encryption is needed.
Catalyst SD-WAN builds a secure overlay between eligible WAN-edge transport locations (TLOCs). The underlay only needs IP reachability between transport endpoints and the SD-WAN control components. User packets are then forwarded directly edge-to-edge across secure overlay tunnels according to routing and policy.
10.7 Underlay and Overlay Comparison
|
Concept |
Traditional WAN |
Catalyst SD-WAN |
|
Underlay |
The physical/provider WAN itself is often the primary routed service: MPLS, leased line, Metro-E, Internet, or cellular. |
MPLS, Internet, broadband, LTE/5G, Metro-E, and other IP networks provide basic transport reachability. |
|
Overlay |
Optional. It may be GRE, DMVPN, or IPsec and must be separately designed. |
Fundamental to the architecture. Secure logical connectivity is built above the transports. |
|
Transport role |
Links are often assigned fixed roles such as primary MPLS and backup Internet. |
Transport colors/TLOCs let multiple links participate in the fabric simultaneously, subject to policy. |
A key design lesson is that SD-WAN does not automatically replace MPLS. MPLS can remain as one underlay while Internet and cellular transports are added to the same SD-WAN fabric.
10.8 Path Selection: Route Reachability vs Application Experience
Traditional routing normally selects a path from prefix length, administrative distance, protocol metric, and local policy. A circuit can therefore remain technically reachable while the application experiences severe packet loss, latency, or jitter. Traditional networks can add IP SLA, object tracking, Performance Routing, or custom automation, but these are additional design elements.
Catalyst SD-WAN continuously measures overlay paths using BFD. Application-aware routing can evaluate loss, latency, and jitter against an SLA class and steer selected traffic to another eligible transport when the preferred path no longer meets policy.
|
Scenario |
Traditional WAN Behavior |
SD-WAN Behavior |
|
Hard link failure |
Routing adjacency, interface state, next-hop tracking, or IP SLA detects the failure and converges to a backup route. |
BFD/tunnel state and routing information remove the failed path and policy uses another eligible TLOC. |
|
Brownout: high loss/jitter |
The route may stay installed unless additional performance tracking is configured. |
AAR can move applications when measured path quality violates the configured SLA. |
|
Two healthy circuits |
Routing metric/PBR determines which circuit is used; one link may remain mostly idle. |
Different applications can use different active transports according to centralized policy and SLA. |
11. Advantages and Disadvantages - Traditional WAN and SD-WAN
11.1 Advantages of Traditional WAN
- Simple and predictable for small environments with only a few sites and WAN paths.
- Uses mature, standards-based routing technologies that are widely understood and interoperable.
- Does not require an SD-WAN controller fabric, certificate onboarding system, or centralized policy engine.
- Direct CLI visibility can make troubleshooting straightforward when the topology is small.
- Existing MPLS or leased-line services may already provide stable performance and provider SLAs.
- Organizations can retain complete device-level control and integrate only the automation they actually need.
- Incremental changes may be easier when the existing WAN is stable and business requirements are limited.
11.2 Disadvantages of Traditional WAN
- Repeated device-by-device configuration increases operational effort as the number of sites grows.
- Configuration drift and inconsistent routing/security/QoS policies are harder to prevent across a large fleet.
- Multi-transport designs can become complex when MPLS, Internet, broadband, and cellular must be coordinated manually.
- Traditional routing reacts primarily to reachability and metrics unless extra mechanisms are added for application-performance awareness.
- New branch provisioning can require longer staging and more manual validation.
- Cloud/SaaS traffic may be inefficient when legacy designs force data-center backhaul.
- Troubleshooting may require correlating several independent tools, provider tickets, router CLIs, and security platforms.
- Large-scale policy changes can require scripting or repeated CLI changes on many routers.
- The value of SD-WAN is strongest when the business needs many sites, multiple transports, consistent policy, centralized visibility, cloud/SaaS access, and application-aware path selection. The following advantages should still be evaluated against operational maturity and platform cost.
11.3 Advantages of Cisco Catalyst SD-WAN
- Transport independence and active use of multiple WAN circuits.
- Centralized policy, configuration, software lifecycle, and operational visibility.
- Secure overlay connectivity between authenticated edge devices.
- Faster branch turn-up through standardized onboarding and reusable configuration.
- Application-aware steering using path performance data.
- Consistent segmentation across geographically distributed sites.
- API-driven integration and automation.
- Potential cost optimization by shifting suitable traffic from premium circuits to Internet-based transports.
11.4 Disadvantages / Limitations of Cisco Catalyst SD-WAN
- The solution adds controller, certificate, policy, and overlay concepts that engineers must understand and operate.
- Underlay quality still matters; SD-WAN cannot create bandwidth or reliability that the physical/provider network does not have.
- NAT, firewalls, DNS, time synchronization, MTU, and transport asymmetry can complicate onboarding and tunnel formation.
- Poorly designed centralized policy can affect many sites quickly, so testing, staged rollout, change control, and rollback planning are essential.
- Feature behavior and scale limits vary by platform and release.
- Cloud-hosted control components create dependencies on reachability, licensing, identity, and operational processes outside a single branch router.
- End-to-end troubleshooting requires separating management, control, routing, and data-plane symptoms rather than assuming every outage is a tunnel problem.
|
NOTE |
The correct design question is not “Is SD-WAN better than MPLS?” SD-WAN is an overlay/control architecture; MPLS can remain one of its underlay transports. |
Quick knowledge check
1. Which component is the primary centralized management system?
Answer: SD-WAN Manager.
2. Which component uses OMP to distribute overlay reachability?
Answer: SD-WAN Controller.
3. What three items commonly identify a TLOC?
Answer: System IP, color, and encapsulation.
4. What is the role of transport color?
Answer: It identifies/classifies a transport TLOC and can be used by policy for path behavior.