Start with the problem, not the product
SD-WAN is a good answer to some WAN problems and an unnecessary answer to others. Each use case below starts with the problem that makes SD-WAN worth considering, then names what the design looks like and what to check. The cases overlap: a real network normally uses several of them at once.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Use case 1: the branch office
The branch is the classic case. It has few staff on site, applications elsewhere, and little or no IT support. The aim is a site that can be shipped, plugged in and brought into the fabric with little local work, then managed centrally.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
- Problem: slow provisioning, uneven configuration, a second circuit that sits idle.
- Design: a WAN Edge with one or two transports, both carrying tunnels. A template or configuration group gives each branch the same base setup.
- Check: that the router model suits the throughput and features the branch needs, and that the LAN side connects cleanly, for example by static routes, OSPF or BGP.
In the course lab, BR-01 (10.255.2.1, an example site 101) and BR-02 (10.255.2.2, an example site 102) are branches of this kind.
Use case 2: data centre and campus hubs
Some sites receive traffic from many others: a data centre, a headquarters campus, or a regional hub. They are usually called hubs, and branches build tunnels to them. A hub often has more transports, more throughput and a pair of edges for redundancy.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
- Problem: many branches need the same central applications, and the hub must not be a single point of failure.
- Design: two hubs, such as HUB-01 (10.255.1.1) and HUB-02 (10.255.1.2) in the lab. Control policy can make branches prefer one hub and fall back to the other.
- Check: hub capacity, which is the sum of what the branches might send at the same time, and how the hub connects to the data centre LAN.
Use case 3: direct internet and cloud access
When most applications are in the cloud, sending branch traffic through a data centre first adds delay and load. SD-WAN lets the branch send selected traffic straight out of its own internet circuit while keeping private traffic on the overlay.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
- Choose the traffic. A policy picks which applications or destinations go directly, for example a named SaaS service.
- Send it out locally. The edge applies NAT and forwards it to the internet from the branch.
- Protect it. Security is applied at the branch with built-in features, or the traffic is sent to a cloud security service.
- Keep measuring. Where a cloud connection exists, the edge can compare paths and choose the better one for the application.
This is often called Direct Internet Access (DIA) in SD-WAN design. The word also names a circuit type, as the first lesson of this unit explained, so read the context. Later lessons cover Cloud OnRamp, which helps choose and monitor paths to SaaS and to infrastructure hosted in public clouds.
Use case 4: hybrid WAN, mixing MPLS and internet
Many organisations do not remove MPLS at once. They add internet circuits beside it, send ordinary traffic over the internet, and keep MPLS for what needs its assurance.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
The table shows ideas, not rules. A real policy depends on measurements, contracts and the applications in use. Later lessons show how such a policy is written.
Use case 5: sites without good circuits
Remote sites, pop-up offices and temporary locations may not get a fixed line. A cellular circuit can serve as the only transport or as a backup. SD-WAN does not make cellular better, but it does let the edge use it as another tunnel path, and fall back to it only when needed. Data caps and variable quality are matters for the plan you buy, so check them.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Deciding if a site is a fit
On small screens, swipe sideways or focus the diagram and use the arrow keys.
- Does the site have, or could it have, more than one transport?
- Does it use cloud applications that would benefit from a direct path?
- Is the cost or delay of backhaul a real complaint, and not a guess?
- Is there a team to run central policy, with a plan to test and undo changes?
- Is the site large enough to justify the edge hardware and licences? Check pricing and licensing terms with Cisco or a partner.
Mistakes when planning an SD-WAN deployment
- Moving the circuits and forgetting the security. Direct internet access without branch or cloud inspection removes a control that the old design provided.
- Expecting the overlay to fix poor circuits. It chooses better, but it cannot create capacity or remove loss.
- Sizing the hub by branch count alone. Peak combined traffic and tunnel counts matter more.
- Treating every site the same. A tiny remote office and a regional campus have different needs.
Test yourself on use cases
Branch users complain that a SaaS application is slow, and the traffic is being sent to the data centre first. Which SD-WAN use case addresses this?
A company keeps MPLS for voice and adds internet circuits at every branch. What is this design called?
Which is the strongest reason to deploy two hubs, such as HUB-01 and HUB-02, instead of one?