Skip to content

SD-WAN & SD-Branch

Make the branch network something you configure centrally and reason about once.

What this is

Software-defined WAN puts an overlay across whatever transport each branch has — broadband, LTE, private circuit — and selects the path per application against measured link quality. SD-Branch extends the same central control to the branch LAN, wireless and security stack.

The business case is usually cost: replacing or supplementing expensive private circuits with broadband. The operational case is often larger — a hundred branches configured from policy rather than one at a time.

When you need it

If more than one of these is true, this is usually the right place to start.

  • Private circuits whose cost has stopped matching the bandwidth they deliver.
  • Cloud and SaaS traffic backhauled to a central data centre only to be sent back out.
  • Branch changes that require a visit or a per-site configuration by hand.
  • No usable per-application view of why a branch is slow.

What the scope covers

  • Transport strategy per site class: what each branch needs, and where broadband can carry the load.
  • Overlay and path-selection design: which applications steer on what measurement, and what happens when a link degrades rather than fails.
  • Local internet breakout with the security controls that must follow it out of the data centre.
  • Branch stack consolidation — routing, switching, wireless and security under one policy.
  • Migration per site with rollback, and a pilot group that proves the design before the estate follows.

What you receive

DeliverableWhat it contains
Site classificationBranches grouped by size, criticality and application profile, with a transport and hardware pattern per class.
Policy designApplication groups, path preference, thresholds for steering, and behaviour under brownout as well as failure.
Security design for breakoutWhat inspection and filtering follows the traffic when it stops passing through the data centre.
Rollout planPilot, wave plan, per-site runbook and rollback, with the criteria that must be met before the next wave.

Reference architecture

A reference, not a template. Your estate decides which parts apply and in what order they arrive.

SD-WAN reference architecture: edge, control and visibility layersEdge: Branch Edge, Broadband + LTE, Local Breakout. Control: Orchestrator, Path Selection, Application Policy. Visibility: Link Quality, Application Performance, AlertingEdgeBranch EdgeBroadband + LTELocal BreakoutControlOrchestratorPath SelectionApplication PolicyVisibilityLink QualityApplication PerformanceAlerting
SD-WAN reference architecture: edge, control and visibility layers

How success is measured

Targets are agreed with you before the work starts, and reported against for its duration.

  • Application performance at the branch, measured before and after rather than inferred from link speed.
  • Time to make a policy change across the estate, compared with the per-site process it replaced.
  • Circuit cost per site against delivered bandwidth, tracked as the transport mix changes.

Questions we are asked

  • Will this let us drop our private circuits?

    Often it lets you reduce them rather than remove them: broadband plus LTE as the primary pair, with a private circuit retained where an application genuinely needs guaranteed latency. The site classification is where that gets decided honestly.

  • Is local breakout safe?

    Only with the security design done first. Breakout removes the data-centre inspection path, so the controls have to follow the traffic — cloud-delivered security or an on-site stack. Breakout enabled without that decision is the most common mistake here.

  • What does SD-Branch add?

    It extends the same central management to the branch LAN, wireless and security instead of just the WAN edge. The value is operational: one policy model and one console rather than four.

  • How does it handle a link that is degraded but not down?

    That is the case it handles better than traditional routing, which mostly sees up or down. Path selection works on measured loss, latency and jitter, so a brownout moves traffic before users start complaining.

  • Can we migrate gradually?

    Yes, and you should. The overlay coexists with existing routing, so sites move in waves behind a pilot, with the exit criteria for each wave agreed in advance.

  • Do we still need people who understand routing?

    Yes. Central policy makes routine change easier; it does not remove the need to understand what the network does when something breaks. The handover assumes your team will operate it.

Continue reading

  • Networking

    The full domain, and the other capabilities within it.

  • Network Access Control

    802.1X, device profiling and posture-based access — deployed in monitor mode first, so enforcement is based on what is actually on your network.

  • Network Monitoring

    Discovery, telemetry and alerting tuned so that an alert means something — with thresholds set from observed baselines rather than defaults.

Start with an assessment

The fastest way to a useful answer is a short, scoped look at what you already have.