SD-WAN Architecture

Before you understand SD-WAN, you need to see the problem it solves.
For decades, enterprise WANs have followed a straightforward model: lease MPLS circuits from a service provider, connect every site to the same private network, and manage each router individually through CLI.

This model worked well when most traffic stayed inside the enterprise.
But the world has changed.

MPLS Only

In a traditional WAN, your Headquarters (HQ) and branch sites connect through MPLS circuits leased from one or more service providers.
MPLS provides reliable connectivity with built-in QoS guarantees, but it comes at a high price per megabit.

Figure 1 – Traditional WAN: every site depends on expensive MPLS circuits

Every site needs its own MPLS circuit. Adding a new branch means ordering a new line from the provider, which can take weeks or months.
And MPLS is the only transport option. There is no failover, no alternative path, and no way to leverage cheaper broadband Internet.

The Backhauling Problem

Today, most enterprise applications live in the cloud: Microsoft 365, Salesforce, AWS, Webex.
Your users at branch sites need fast, direct access to these services.

But in a traditional WAN, branches have no direct Internet exit. All traffic must travel back to HQ through MPLS, exit to the Internet at the HQ firewall, and then reach the cloud.

This is called backhauling.
It adds latency, wastes expensive MPLS bandwidth, and overloads the HQ router with traffic it should never handle.

Figure 2 – Backhauling: branch traffic takes a detour through HQ to reach cloud applications

A user at Branch 2 wants to access Microsoft 365. Instead of going directly to the cloud, the traffic follows a two-step detour: first through MPLS to HQ, then out to the Internet.

SD-WAN exists to eliminate this problem.

SD-WAN (Software-Defined Wide Area Network) solves these problems by introducing two major changes: multiple transports instead of MPLS only, and a centralized controller architecture instead of box-by-box management.
Let’s build this architecture step by step.

Multiple Transports

With SD-WAN, your sites are no longer limited to MPLS.
Each site can connect through any combination of transports: MPLS, broadband Internet, 4G/5G, or even satellite.

Figure 3 – Multiple transports: sites connect through MPLS, Internet, and 4G/5G simultaneously

This changes the economics of your WAN completely. You can use a cheap Internet link for bulk traffic and keep MPLS for critical applications.
If one transport fails, traffic automatically shifts to another.

But using multiple transports creates a new challenge. How do your routers know which path to use? Who coordinates all of this?

That is where the SD-WAN components come in.

WAN Edge – The Site Router

At every site, the traditional router is replaced by a WAN Edge router (also called vEdge or cEdge).
This is the device that sits at the boundary of your site and connects to the available transports.

Figure 4 – WAN Edge routers deployed at every site, but what controls them?

If you SSH into a WAN Edge router, it looks familiar. Run show system status to see its identity: