SD-WAN & multi-location business networks

An operating model, not an appliance

The technology is the easy part to describe and the wrong part to buy first. A multi-site network has three separable layers: the connections that reach each site, the routing and policy that decides how traffic moves between them, and the security inspection that traffic passes through. A software-defined overlay is largely about the middle layer, replacing per-site configuration with central policy and letting different kinds of connection serve the same site. The appliances are how that policy is enforced, not the reason to buy it. Ask a supplier to describe the operating model — who changes policy, how a new site is added, what happens when a device fails, who carries the pager — before discussing hardware, because that is the part you will live with.

• Layer one: the circuits that reach each site.
• Layer two: routing and policy between sites, which the overlay centralises.
• Layer three: where security inspection happens.
• Ask who changes policy, and who is accountable when a site drops.

What transport independence really buys

The headline promise is that a site can use whatever connection is available or economical, because the overlay runs above it rather than depending on one carrier. That is genuinely useful: a branch can run on fibre with a cellular backup where a second fixed line is uneconomic, and the same policy applies there as at head office. The trade-off is that public connections vary in quality in a way a private circuit does not, so the design has to decide which traffic may travel over which path. Application-aware routing exists to make that decision automatically, but it can only distinguish what it can see, which is why naming the latency-sensitive applications before the design is settled matters more than the feature list.

• Sites can mix connection types under one policy.
• Public paths vary in latency and loss in ways private circuits do not.
• Application-aware routing needs the critical applications named first.
• Decide deliberately which traffic may use the cheapest path.

Design from sites, applications and failure domains

Start with a site list rather than a topology diagram. For each site, record the user count, the applications that matter, the expected peak usage in both directions, the connections already present and what happens operationally when they fail. Then group the sites: locations where a short outage is an inconvenience behave differently from those where it stops revenue, and the design should reflect that difference rather than treating every branch identically. The topology follows from the group. Where most traffic goes to a central service, a hub design is economical and simple; where sites need to reach each other and the cloud directly, a full or partial mesh avoids routing everything through a choke point that also becomes a single point of failure.

• A site list with users, applications, peak usage and failure impact.
• Group sites by what an outage costs, not by headcount alone.
• Hub-and-spoke where traffic is central; mesh where it is not.
• Avoid a topology whose hub is also its single point of failure.

Internet breakout and where inspection happens

A decision that shapes both cost and risk is whether site traffic travels back to a central point for inspection before reaching the internet, or leaves directly from the site. Centralising creates a predictable security posture and a single place to manage policy, at the cost of sending ordinary browsing traffic across the network twice and making the centre's failure everyone's. Breaking out locally gives better performance for cloud services and removes that dependency, at the cost of putting inspection capability at each site. Whichever way it goes, decide explicitly what happens to traffic when the tunnel to the centre is unavailable — failing open preserves the business and weakens control, and failing closed does the reverse.

• Central inspection: consistent policy, longer paths, central dependency.
• Local breakout: better cloud performance, inspection at each site.
• Written behaviour for tunnel failure: fail-open or fail-closed, not accidental.
• Who can see what traffic, and where that is enforced.

Staging the rollout so a site cannot take the network down

A multi-site rollout succeeds or fails on sequencing. Build configuration as templates rather than site by site, so that the twentieth site inherits the decisions made for the first and divergence has to be deliberate. Start with a site that is representative but forgiving — one where a short interruption is survivable — and prove the design there before touching a revenue site. Run new and old arrangements in parallel where the budget allows, so the old path is available while the new one is being proven. Define what acceptance means per site in advance: measured throughput, latency to the critical applications, failover behaviour, and a management handover that leaves your staff able to make routine changes without calling the supplier.

• Templates and standards, not bespoke configuration per site.
• Pilot at a forgiving site before any revenue-critical location.
• Parallel running where the budget allows a fallback.
• Per-site acceptance criteria agreed before the work starts.

What to gather before asking for pricing

Bring the site list with user counts and connection types, the applications that must perform and what latency they tolerate, the peak upload and download at each site, any regulatory or data-residency constraint on where traffic may travel, the existing circuits and their contract end dates, and whether addresses or routing must move with the design. Add the operational constraints: which sites can be touched during business hours, whether anyone is on site to assist, and who currently holds administrative access to the network equipment.

• Sites, users and the connection type at each.
• Critical applications and the latency they need.
• Existing circuit contracts and their end dates.
• Access, maintenance windows and who holds the equipment credentials.

SD-WAN is a service definition before it is a product

The label on a proposal is the least useful thing in it. MEF 70, the published SD-WAN service definition, describes the service by its externally visible behaviour and its agreed attributes rather than by any required protocol or tunnel. Its building blocks have names worth asking for: the SD-WAN UNI, the demarcation between your network and the provider's responsibility; the SD-WAN Edge, the function at your premises or in the cloud that enforces the service; the underlay connectivity service, the access or transport beneath the overlay; the overlay tunnel that runs across that underlay; and the service attributes themselves, covering traffic-handling rules, application or class-based policies, performance objectives and operational responsibilities. Nothing in that list names a technology, which is the point: an overlay is assembled from standards that already exist. IPsec supplies the encrypted tunnel architecture, BGP exchanges reachability between sites and providers, and a provider-managed Layer 3 VPN is a different construction again. So when a proposal offers SD-WAN, ask for the attributes: which demarcation points, which underlays, which policies, which performance objectives, and who is accountable for each. A supplier that cannot name them is selling a label.

• MEF 70 defines the service by behaviour and agreed attributes, not by a protocol.
• Ask for the demarcation, the edge, the underlays and the overlay tunnels.
• Ask which policies apply to which applications, and who is accountable.
• IPsec, BGP and provider-managed Layer 3 VPNs are the parts it is built from.

Where MPLS ends and the overlay begins

MPLS is an underlay, not the opposite of an overlay. The provider-managed Layer 3 VPN is a standard construction: the carrier distributes reachability with BGP and forwards traffic inside its own network, which is why a private circuit can offer reachability that public internet transport does not. An overlay can run on top of that VPN, replace selected traffic with internet or wireless transport while leaving the private service in place, or sit over a mix of both. What changes when private transport gives way to broadband under a policy layer is not the topology diagram but three things. The transport becomes shared, so its latency and loss vary with other subscribers and the design has to state which flows may travel where. Reachability becomes your policy rather than the carrier's, so you own the routing decisions and their consequences. And one private-network commitment is replaced by per-underlay commitments you must stack and reconcile. Replacing MPLS is a commercial use case rather than a technical definition, and the case for keeping it is narrow but real: a legacy application that depends on predictable private routing, or a regulatory obligation that turns on the traffic staying inside a private network.

• MPLS and SD-WAN are layers, not alternatives: an overlay can sit on MPLS.
• A provider-managed Layer 3 VPN distributes reachability with BGP and forwards privately.
• Moving to shared transport changes variability, ownership of routing, and the SLA basis.
• Keep private transport where an application or an obligation depends on it.

Failover, steering, and the state between up and down

Ordinary failover is a link-state decision: the secondary path carries traffic when the primary is down, and a hard failure is handled. Anything short of that - congestion, packet loss, rising latency on a circuit that is still technically up - is invisible to it, so users experience a degraded service the design never notices. An overlay that steers on measured performance as well as availability reacts to that middle state, but only for the traffic it can identify, and switching a path mid-session still drops the sessions already in flight. Design the transition explicitly instead of assuming it: name the applications that must survive a path change without interruption, those that may re-establish, and the tolerable interruption for each class. A failover that is immediate but coarse and one that is fine-grained but blind to some traffic are different products solving different problems, and the business requirement, not the feature list, decides which is worth buying.

• Link-state failover misses degradation on a circuit that is still up.
• Performance-based steering reacts to loss and latency, not only outages.
• Any path change drops sessions already in flight, however fast the switch.
• Write the tolerable interruption per application class before comparing products.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions