Understanding the Architecture of Cisco SD-WAN

Cisco SD-WAN moves WAN routing decisions out of each branch router and into a controller. The edges build encrypted tunnels over whatever transport a site has — MPLS, broadband, LTE — and the controller tells them which traffic takes which path. That single change is what the whole architecture follows from, and it is also where the new failure modes come from.

This guide covers the fabric end to end: the four planes and what each one does, how OMP distributes routes, what the underlay has to provide before any of it works, TLS and DTLS, BFD, QoS and application-aware routing, how it compares with MPLS and DMVPN, and how to build the whole thing in a lab.

Cisco, one of the leading network infrastructure providers, offers a comprehensive SD-WAN solution that can help businesses transform their networks.

In this blog, we will discuss the architecture of Cisco SD-WAN, its components, and how it works.

Introduction to Cisco SD-WAN

Cisco SD-WAN is a cloud-first architecture that is designed to securely connect users to applications regardless of where they are located.

It provides a unified and secure fabric that spans across any combination of WAN transport (MPLS, Internet, LTE) and cloud gateways (AWS, Azure, Google). It simplifies network management and delivers a superior user experience.

Key Features and Capabilities of SD-WAN

At its core, SD-WAN abstracts the underlying hardware infrastructure and allows the network to be controlled through software. Instead of forcing traffic down predetermined paths, it intelligently routes traffic across multiple WAN connections, dynamically adapting to real-time network conditions to optimize performance and reliability.

Several capabilities make this possible and are worth understanding before looking at the architecture in detail:

• Traffic management: SD-WAN steers data across the network to avoid congestion and maximize throughput.
• Load balancing: Traffic is distributed across multiple connections to make the best use of available bandwidth.
• Application-aware routing: The network makes real-time forwarding decisions based on the type of application in use, prioritizing critical traffic such as VoIP and video conferencing.
• Built-in security: Encryption and segmentation protect sensitive data as it moves between branches and the cloud.
• Centralized management: Administrators implement policies, monitor network health, and respond to issues from a single pane of glass.

Together, these features reduce complexity, improve network agility, and cut costs by letting organizations use less expensive connection types—such as broadband internet—alongside or instead of MPLS.

SD-WAN vs MPLS: what actually differs

These two are compared constantly, but they are not the same kind of thing. MPLS is a transport you buy from a carrier: labelled paths across the provider's backbone, with a contractual service level for latency, jitter and loss. SD-WAN is a control layer you run on top of transport you already have. That is why the honest answer to "should I replace MPLS with SD-WAN" is usually "you are not comparing like for like".

The practical difference shows up when you add a site. An MPLS circuit means a carrier order, a lead time measured in weeks, and a router configured for that circuit. An SD-WAN edge at the same site can come up over whatever is available — business broadband, a second provider, LTE — pull its configuration from the controller, and start forwarding. What you give up is the carrier's guarantee: broadband has no SLA, so the overlay has to measure the path itself and route around it when it degrades.

Most enterprises end up running both. MPLS stays under the traffic that genuinely needs a guarantee, broadband and LTE carry everything else, and SD-WAN policy decides which is which per application. In that design MPLS becomes one transport among several — the overlay still builds its own encrypted tunnels across it, and still measures it, because a circuit inside its SLA can still be the worse path at a given moment.

The trap in this comparison is treating cost as the whole story. Moving traffic to broadband saves money on the circuit and spends it somewhere else: on controllers you now have to keep alive, on licences, and on engineers who understand an overlay well enough to troubleshoot it. That is a real trade, not a free win.

Components of Cisco SD-WAN

The architecture of Cisco SD-WAN is made up of several components that work together to provide a complete solution. Here are the key components of Cisco SD-WAN:

vEdge Routers

vEdge routers are the backbone of the Cisco SD-WAN architecture. They provide the data plane and control plane functions necessary for SD-WAN. They are deployed at the branch, campus, and data center locations.

The vEdge router architecture provides high availability, resiliency, and scalability. The routers are based on a multi-core processor architecture that provides high performance and can handle large amounts of data traffic. The routers also support a variety of WAN transport options, including MPLS, Internet, and LTE.

vSmart Controllers

vSmart controllers provide the centralized control plane function for Cisco SD-WAN. They are responsible for determining the best path for data traffic to take based on network policies and conditions. They also provide secure connectivity to the cloud and data center applications.

The vSmart controllers are deployed in the cloud or on-premises. They use policies to determine the best path for data traffic to take based on real-time network conditions. The controllers can also detect and respond to network issues, ensuring high availability and resiliency.

vManage

vManage is the centralized management and orchestration platform for Cisco SD-WAN. It provides a single pane of glass view of the entire SD-WAN infrastructure, including vEdge routers, vSmart controllers, and cloud gateways. It simplifies network configuration, monitoring, and troubleshooting.

The vManage platform provides a web-based interface for network administrators to manage and monitor the entire SD-WAN infrastructure. It provides a comprehensive view of the network topology, including real-time network and application performance metrics. The platform also provides an API for integrating with third-party systems.

Cloud Gateways

Cisco SD-WAN supports cloud gateways for direct access to cloud applications. Cloud gateways are virtual appliances that provide secure connectivity to public cloud services such as AWS, Azure, and Google Cloud.

The cloud gateways are deployed in the cloud and provide secure connectivity to public cloud services. They are responsible for encrypting and decrypting data traffic between the SD-WAN fabric and the cloud services. The gateways also provide visibility into the performance of cloud applications.

How Cisco SD-WAN Works

The architecture of Cisco SD-WAN is based on the concept of overlay networks. The overlay network is created by connecting the vEdge routers with encrypted tunnels over any WAN transport. The vSmart controllers provide the control plane function for the overlay network. They determine the best path for data traffic to take based on network policies and conditions.

The vEdge routers provide the data plane function for the overlay network. They are responsible for forwarding data traffic over the encrypted tunnels.

OMP: how the overlay learns its routes

Once the control connections are up, the fabric needs a way to distribute reachability — and that job belongs to the Overlay Management Protocol. OMP runs between each WAN Edge and the vSmart controllers inside the control connection that is already authenticated and encrypted. It is not a protocol you point at an interface; it exists only inside the fabric.

OMP carries three things worth separating in your head:

• TLOC routes — the transport locators. A TLOC identifies a tunnel endpoint by system IP, colour and encapsulation, and it is what makes multi-transport routing possible: the same prefix can be reachable through an mpls TLOC and a biz-internet TLOC, and policy decides which one gets used.
• OMP routes — the actual prefixes learned at each site, carried with the service VPN they belong to, so segmentation survives across the fabric.
• Service routes — where a firewall, IDP or other service sits, so traffic can be steered through it rather than around it.

Why OMP is not just BGP with a new name

The shapes look similar — peers, attributes, best-path selection — and that similarity is exactly what trips engineers up. Three differences matter in practice.

First, the topology. BGP peers with its neighbours; OMP peers only with the controllers. Every edge tells vSmart what it has, and vSmart tells every edge what it should know. There is no edge-to-edge routing relationship, even though the data plane tunnels are edge-to-edge.

Second, the controller is allowed to lie — deliberately. vSmart can rewrite, filter or replace what it advertises to each site before sending it. That is not a workaround; it is the mechanism centralised policy is built on. When you write a control policy that hides one site's prefixes from another, or forces traffic through a hub, you are changing what vSmart advertises rather than configuring anything at the edges.

Third, the attributes are SD-WAN-specific. Best path takes in TLOC preference, site ID, colour and origin — concepts BGP has no equivalent for.

The operational consequence: when reachability looks wrong, the question is not "what did my neighbour send me" but "what is vSmart advertising to this site, and which policy rewrote it". You debug policy, not peerings.

Underlay design: what has to be right before the overlay works

An overlay is only as good as the transport under it, and most first deployments fail in the underlay rather than in the fabric. The overlay needs remarkably little from the transport — but it needs that little reliably.

Reachability to the controllers, before anything else. A brand-new edge has to reach the Validator to be authenticated, and the Manager to pull configuration. If a firewall in front of the site drops that, the edge never joins and the symptom looks like a fabric problem when it is a filtering problem.

NAT behaviour. Tunnels between sites are established through whatever NAT the transport imposes. Symmetric NAT at both ends is the classic case where spoke-to-spoke tunnels never come up while spoke-to-hub works fine — which is why designs facing unpredictable NAT lean on a hub, or on TLOC extension, instead of assuming a full mesh.

MTU. Every packet leaving an edge picks up IPsec overhead. If the transport path has a smaller usable MTU than the edge assumes, you get the worst class of fault: small packets pass, the tunnel comes up, and large transfers stall. Measuring path MTU rather than trusting 1500 is the difference between a working deployment and an intermittent one.

Addressing you can grow into. Every site needs deterministic addressing for its transport interfaces and its system IP, and both end up in policy, templates and troubleshooting. A scheme invented site by site becomes unusable around the point you have enough sites to need it.

Where the underlay still needs routing. An MPLS transport usually means a routing relationship with the carrier — commonly BGP — and that session is doing a different job from the overlay: it makes the tunnel endpoints reachable, nothing more. Keeping that boundary clean matters. Leaking overlay prefixes into the underlay, or the reverse, produces routing loops that are painful to unpick precisely because the two planes look independent on a diagram.

Security in Cisco SD-WAN: TLS and DTLS

The encrypted tunnels that hold the overlay together depend on two closely related security protocols: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Both protect data as it moves across the distributed enterprise, but they serve different types of traffic.

TLS in Cisco SD-WAN

Transport Layer Security is a widely adopted protocol designed to provide privacy and data security for internet communications. Within Cisco SD-WAN, TLS is primarily used to secure TCP-based communications between the vEdge routers and vSmart controllers, ensuring that sensitive data transmitted over these connections remains confidential and tamper-proof. It authenticates the network devices and encrypts the data traffic between them through a system of keys and certificates, guaranteeing that all packets originate from a trusted source. Its support for a range of cipher suites provides flexibility in balancing security level against performance.

DTLS in Cisco SD-WAN

Datagram Transport Layer Security is an adaptation of TLS designed specifically for datagram protocols such as UDP, which are typically used for streaming media, voice over IP (VoIP), and online gaming. In Cisco SD-WAN, DTLS establishes secure channels for UDP communications transparently to the user, providing the same level of encryption as TLS while catering to the different needs of UDP traffic. By minimizing session re-negotiation, DTLS keeps latency low—crucial for applications that need instant data transmission.

TLS vs. DTLS at a Glance

The key differences between the two protocols come down to the type of traffic they secure and the constraints that apply:

• Protocol type: TLS is TCP-oriented, while DTLS is datagram-oriented (UDP).
• Use case in SD-WAN: TLS maintains continuous, secure TCP connections; DTLS secures real-time, latency-sensitive applications.
• Security: TLS is highly secure with robust negotiation mechanisms; DTLS is equally secure with simpler handshakes for lower latency.
• Performance: TLS is optimal for steady, reliable connections; DTLS is better suited to conditions that demand low delay.

Despite these differences, the two protocols share a common security backbone. Both provide data integrity, encryption, and end-point authentication, and both rely on similar cryptographic algorithms—RSA and ECDSA for key exchange and AES for data encryption. Certificate-based mutual authentication is a prerequisite for each, ensuring that only known and verified devices can communicate over the network. Cisco SD-WAN leverages both TLS and DTLS together for dual-layer security across all transmission types.

As a rule of thumb, use TLS for transactional data that requires reliable, orderly delivery—such as file transfers and database communications—and DTLS for real-time communication where speed and low latency matter more than guaranteed delivery, such as VoIP and video conferencing.

BFD in Cisco SD-WAN

Bidirectional Forwarding Detection (BFD) is a network protocol designed to detect faults between two forwarding engines connected by a link. Standardized by the Internet Engineering Task Force (IETF), it works by establishing a session between two endpoints; if a link fails, BFD quickly informs the routers, leading to faster convergence and reduced downtime. In Cisco SD-WAN, BFD plays a pivotal role in maintaining network stability and efficiency.

BFD Operating Modes

BFD operates in three modes:

• Asynchronous: The most frequently used mode, involving continuous transmission of BFD control packets between devices.
• Demand: Used less often; control packets are sent only when a lack of reception is detected.
• Echo: Leverages reverse-path traffic to detect faults and is not commonly deployed in Cisco SD-WAN environments.

How BFD Integrates with the Fabric

Cisco SD-WAN integrates BFD into its vEdge routers to actively monitor the health and connectivity of WAN links. BFD sessions enable the immediate detection of network anomalies and support the dynamic routing of traffic according to the current state of the network. In failover scenarios, BFD's rapid failure detection allows for almost instant switching from a faulty link to a healthy one, maintaining service continuity. Its sensitivity can be tuned to specific needs: detection intervals can be scaled back to conserve bandwidth on less critical networks, or made more frequent for critical infrastructure that demands prompt fault detection.

Benefits and Best Practices

Deploying BFD in Cisco SD-WAN reduces downtime and improves end-to-end application performance for services that rely heavily on network availability, such as real-time analytics and customer-facing applications. It also adds a layer of resilience for security, since quick link recovery helps keep firewalls and intrusion detection systems operational during disruptions.

The main challenge is the additional signaling traffic BFD can introduce, so administrators must configure its timers and multipliers carefully to balance prompt failure detection against network overhead. Best practice is to start with a thorough network assessment to determine optimal settings, implement scalable configurations that adapt to expansions or shifts in traffic patterns, and update the configuration as the network changes. Involving both network and security teams in planning and monitoring helps keep BFD aligned with the wider network strategy.

QoS and application-aware routing: two different mechanisms

These get discussed together and they solve different problems. Application-aware routing decides which path a flow takes. QoS decides what happens in the queue once the path is chosen. You need both, and configuring one does not compensate for the other.

Application-aware routing

Each tunnel is measured continuously — loss, latency and jitter — using BFD probes that ride the tunnel itself, so the numbers describe the path the traffic actually uses. You then define an SLA class: a policy might say voice tolerates 1% loss, 150 ms latency and 30 ms jitter. Traffic matched to that class is placed on a tunnel meeting the SLA, and moved when the tunnel stops meeting it. If no path qualifies, the fallback behaviour is yours to define — and defining it deliberately matters, because the default may not be what you want during a brownout.

This is what makes broadband usable for traffic that would traditionally have demanded MPLS: the overlay does not trust the path, it verifies it every few seconds.

QoS on the edge

Path selection cannot help when the bottleneck is your own uplink. That is queueing: classify traffic, assign it to queues, schedule between them, and shape to the rate the transport can actually deliver. Two details cause most of the disappointment here. Shaping has to reflect real available bandwidth rather than the number on the contract — otherwise you queue in the provider's equipment, where your policy has no effect. And IPsec encapsulation means the DSCP marking the transport sees is the one on the outer header, so if a carrier is expected to honour markings, the outer header has to carry them.

The honest limit: SD-WAN QoS controls what leaves your edge and which path it takes. It does not control what happens inside someone else's network. On a broadband path, that is most of the journey — which is exactly why measuring paths and being willing to switch matters more than queue tuning.

Real-World Applications of SD-WAN

Looking at where SD-WAN is deployed helps illustrate its value:

• Retail: Retail chains use SD-WAN to quickly and securely connect multiple outlets to head offices and data centers, keeping point-of-sale and inventory processes synchronized even during high-traffic events such as sales or product launches.
• Healthcare: Healthcare organizations prioritize critical applications such as electronic health records (EHR) systems, improving the reliability and performance of applications vital to patient care.
• Real-time communications: Because SD-WAN can prioritize traffic and recover from link failures quickly, it supports VoIP and video conferencing with minimal packet loss and high call quality.
• Financial services: Firms running around-the-clock trading rely on rapid failover to preserve the integrity and security of real-time transactions.

Cisco SD-WAN vs. Cisco DMVPN

SD-WAN is not the only way to connect geographically dispersed sites. Cisco DMVPN (Dynamic Multipoint Virtual Private Network) is an established alternative, and understanding how the two differ helps clarify where SD-WAN fits.

DMVPN builds scalable, secure IPsec VPNs by dynamically establishing a mesh of encrypted tunnels between remote sites over the Internet, without requiring each site to have a permanent IP address. This dynamic nature makes it well suited to organizations that need spontaneous or intermittent connectivity, and it reduces the manual work of adding or removing sites.

The two technologies suit different situations:

• Management and automation: SD-WAN offers centralized, policy-based management and automation; DMVPN typically requires per-site configuration of tunnel interfaces and more manual effort.
• Scalability: SD-WAN is inherently scalable thanks to its cloud-delivered nature, supporting rapid deployment of services and secure connectivity to multiple clouds; DMVPN scales well where the number of sites varies frequently, though its manual aspects can become a bottleneck in rapidly changing environments.
• Cost: SD-WAN often involves a higher initial investment but can deliver a lower total cost of ownership through operational efficiency and reduced downtime; DMVPN has lower initial setup costs and can be budget-friendly for smaller, stable networks.
• Best fit: SD-WAN suits dynamic, large-scale networks that need high security, flexibility, and ease of management; DMVPN suits stable, site-to-site connectivity with fewer topology changes.

Ultimately, the right choice depends on matching your current and future networking demands—along with implementation, scalability, and cost considerations—to the strengths of each technology.

Implementing Cisco SD-WAN

Getting the most out of SD-WAN depends on a structured implementation plan. The following steps outline a practical path from assessment to ongoing operation:

1. Evaluate your network requirements. Analyze your existing architecture and identify your business's specific needs—the types and amounts of data transmitted, scalability needs, security requirements, and the geographic distribution of the network.
2. Choose the right SD-WAN vendor. Select a solution that aligns with your objectives, weighing deployment cost, ease of integration with your existing IT environment, quality of support, and the scalability of the solution.
3. Plan and design the deployment. Decide on the network topology, determine how existing and new traffic will be routed, and establish how policies will be set. Involving professionals experienced in SD-WAN helps maximize performance and reliability.
4. Deploy and configure the solution. Install the SD-WAN appliances or software in the designated locations and configure them to your design, ensuring internet, MPLS, and other services work cohesively. Rigorous testing at this stage is essential.
5. Monitor and optimize the network. Use the built-in analytics and real-time monitoring tools to observe performance, identify and rectify issues, and continually tune the network as business needs evolve.

Building an SD-WAN lab

SD-WAN is one of those topics that stays abstract until you have brought a fabric up yourself, watched a certificate fail, and fixed it. A virtual lab is enough — no hardware needed — but the resource requirements are real and the build order is not obvious.

Bring the controllers up in the right order. Validator first, since it authenticates everything that follows; then Manager, which is where configuration and certificates are handled; then Controller. Only after all three are healthy does onboarding an edge make sense. Starting with an edge is the most common way to end up debugging the wrong thing.

Expect to spend real time on certificates. In a lab you generate and sign them yourself, which is precisely the part production deployments also stumble on. It is worth doing slowly: understanding why an edge is rejected is more useful than a fabric that happened to come up.

Size the host honestly. Controllers are memory-hungry, and a fabric of three controllers plus a handful of edges will ask for more RAM than a typical laptop has spare. Building a smaller topology that runs comfortably beats a large one that swaps.

Give yourself more than one transport. A lab with a single path cannot demonstrate the thing SD-WAN exists for. Two transports — one standing in for MPLS, one for internet — let you watch path selection, break a path and see traffic move, and test the policy you wrote instead of assuming it works.

Then break it deliberately. Add loss to one transport and watch application-aware routing react. Take a controller down and confirm the data plane keeps forwarding — edges already have their configuration and tunnels, which is why a controller outage is not immediately an outage for traffic. These are the exercises that turn topology knowledge into troubleshooting ability.

If you want to see the topologies these courses actually build before committing to one — the full Viptela fabric with its controller sites, the Versa head end, the Fortinet hub-and-branch lab — they are laid out on the SD-WAN training page.

A Learning Path for SD-WAN

For anyone building SD-WAN expertise, it helps to progress through clear stages, each building on the last:

• Beginner: Focus on networking fundamentals—IP routing, basic LAN and WAN principles, network design, and the overall architecture of SD-WAN, including the WAN technologies it can replace or augment.
• Intermediate: Move into deployment and initial management—setting up an SD-WAN solution, configuring devices, and monitoring network health. A lab or simulation environment is valuable for gaining hands-on experience.
• Advanced: Concentrate on optimization and security—advanced routing techniques, Quality of Service (QoS) settings, and integrating security frameworks such as next-generation firewalls (NGFW) into the SD-WAN structure, along with compliance and continuous monitoring.

To build both the theory and the hands-on skills behind these stages, explore the SD-WAN courses available on the platform.

Conclusion

In conclusion, Cisco SD-WAN is a powerful solution that can help businesses transform their networks by providing a cloud-first architecture that simplifies network management and delivers a superior user experience. The components of Cisco SD-WAN work together to provide a comprehensive solution that can meet the demands of modern businesses.

If you're interested in learning more about Cisco SD-WAN, Orhan Ergun's SD-WAN course is a great place to start.

His course provides a comprehensive overview of Cisco SD-WAN and covers topics such as deployment, configuration, and troubleshooting.