SD-WAN
Every site on more than one internet link, each kind of traffic sent down whichever link is serving it best right now, and one set of policies run from the centre.
- The fibre degradesIt never goes down, so a basic failover check sees nothing wrong. Latency jumps about and packets go missing.
- Calls moveProbes show the fibre is outside the limits set for voice, so call traffic is steered onto the second link.
- The fibre recoversCalls stay put for now. One good reading is not proof that the link is stable again.
- Calls move backOnly after the fibre has stayed within its limits through a hold-down period, so traffic doesn't flap between links.
A link can be up and still be unusable.
Ordinary dual-link failover only checks whether the link is there. It pings a gateway, and as long as something answers, traffic stays where it is. That catches a cut cable. It misses the more common trouble, where the service stays up but congestion or a fault upstream makes it slow and erratic. Calls break up, remote desktops stutter, and the firewall reports everything as fine.
SD-WAN measures how well each link is carrying traffic at that moment. The equipment at each site probes every link continuously and steers each kind of traffic against limits set for it. Calls are sensitive to jitter, backups need throughput, and the limits are set separately for each.
- Latency
- How long a packet takes to get there and back.
- Jitter
- How much that delay varies from one packet to the next. Voice is especially sensitive to it.
- Loss
- How many packets never arrive. A little is enough to wreck a call.
Different traffic, different rules
Steering is set per kind of traffic, not per site. Here is one branch with fibre, a second fixed service and a 4G/5G service for emergencies. Pick a condition to see where each kind of traffic goes and why.
Everything has a good place to go. Calls and business apps get the fibre; backups and guest Wi-Fi use the second link so they stay out of the way of calls.
| Traffic | Fibre | Second link | 4G/5G |
|---|---|---|---|
| Calls and video meetingsLowest jitter and loss wins | carries it | not used | not used |
| Business apps and remote desktopLowest latency within limits | carries it | not used | not used |
| Everyday web and emailSpread across both fixed links | carries it | carries it | not used |
| Backups, updates and file syncKept off the link calls are using | not used | carries it | not used |
| Guest Wi-FiLowest priority, always | not used | carries it | not used |
When the fibre degrades, calls and business apps move to the second link while backups and guest Wi-Fi stay on the fibre, which is still fine for traffic that can wait. If the fibre fails outright, everything shares the second link and backups are rate-limited. If only 4G/5G is left, calls and business apps carry on over it, backups wait and guest Wi-Fi is switched off.
These rules aren’t fixed. Which traffic matters most, and what may use a metered link, is agreed with you and the client while the sites and links are planned.
Where SD-WAN projects go wrong
Most of these only surface weeks later, on a bad day for the line. They are the details we design for from the start.
-
Two links that fail together
Two services from the same carrier, or in through the same pit and exchange, can share the fault that takes one of them out. When we plan the links we look at how each one reaches the site, and say so when the backup isn’t separate.
-
Limits copied from the defaults
Vendor quality profiles are a starting point. Limits are set from what each application tolerates and what each link normally looks like, so traffic moves for a real problem rather than ordinary background noise.
-
Traffic that flaps
If traffic returns the moment a link looks healthy, a link that keeps dropping in and out drags calls back and forth with it. Traffic only moves back once the link has stayed healthy through a hold-down period.
-
A new address nobody expected
Moving to another link usually changes the public IP address traffic comes from. Anything that trusts a fixed address, such as a cloud app’s allow-list, a supplier portal, conditional access rules or a site-to-site VPN, needs to know every link’s address, or those services refuse the connection the moment failover happens.
-
Tunnels too big for the path
The overlay wraps traffic in encrypted tunnels, and the extra headers leave less room for data. Get MTU and MSS wrong and most things work while a few don’t: large transfers stall and certain apps hang. It’s a classic source of “it mostly works” after a rollout.
-
Breaking out without the same protection
Sending cloud traffic straight out of each branch, instead of back through head office, is often the point of SD-WAN. It also means every branch needs the same protection at its own edge. Central policy keeps that consistent from site to site.
-
A backup nobody knows is in use
Failover that works can hide a dead primary for weeks, with the site running on 4G/5G until the data bill arrives. Monitoring and alerts are set up to reach your team, so you know when a site is running on its backup.
-
Testing by pulling a cable
Unplugging a link proves hard failover. It doesn’t prove the policy handles a degraded link, which is the case SD-WAN exists for. Each site is tested for both before its cutover window closes.
One site at a time
The policy is designed once and applied everywhere. The sites move over one by one, so anything unexpected turns up at one site rather than all of them at once.
-
Plan the sites and links
Each site’s links, how they reach it and what traffic matters most, agreed with you and the client. This becomes the site and link plan.
-
Build the policy centrally
Traffic classes, link limits, steering, failover and the policy for each site’s direct internet breakout, defined once so every site behaves the same way.
-
Cut over each site
SD-WAN configured on the site’s own equipment and cut over in an agreed window, then tested with links failed and degraded before the window closes.
-
Hand over
Monitoring and alerts pointed at your team, and as-built documentation for every site.
What you receive
- SD-WAN at each site
- Configured on the site’s equipment, with link steering, failover, central policy and monitoring in place and tested.
- A site and link plan
- Every site’s links and how they reach it, which traffic each link carries, and the limits that move it.
- As-built documentation
- The policies and settings as they were actually configured, so your team can support the client from the first day.