SD-WAN and Multi-Site Interconnect Services
Every site is a small cluster with one big dependency: the link. We design for the link being gone, not for it being fast.
What this usually looks like
You have grown from one site to many, and the WAN design is still whatever the first circuit installation left behind.
- A backup circuit exists on paper but requires someone to drive to the site to use it.
- All branch traffic is backhauled to a datacentre, including traffic to services that live on the internet.
- Each site has a slightly different configuration, maintained by hand, documented nowhere.
- A site losing its link means standing up a paper process until the circuit comes back.
Three ways to buy this
Audit if you want to know how bad it is. Build if you have the team and want the capability. Managed if you don't want to own the pager. Most engagements start with the audit and decide afterwards.
Audit
A fixed-price health check — the cheapest way in
- Site-by-site connectivity and dependency map
- Failover behaviour tested per site rather than assumed
- Traffic-path review: what is backhauled that should not be
- Configuration divergence report across all sites
Build
One-off delivery: design, code, hardening, handover
- Overlay across all available links with fast failure detection
- Policy routing: local breakout where appropriate, inspected path for what needs it
- Site configuration generated from templates and inventory, not edited by hand
- Centralised policy with per-site override and an audit trail
- Failover tested in one live site before wider rollout
Managed
Build plus 7×24 on-call, SLA and quarterly drills
- Per-site link quality and failover event monitoring
- Template and inventory maintenance so new sites are a data entry
- Circuit and link-vendor coordination on your behalf
- Quarterly failover test per region, rotatated so every site is proven yearly
- Bandwidth and path review each quarter against actual traffic
What we actually deploy
Specific tooling, not categories. If a version matters to your decision, ask — we will tell you which one we would pick and why, including when the answer is the older one.
Overlay
- WireGuard
- Tailscale / NetBird
- IPsec (IKEv2)
- VXLAN over WAN
- GRE tunnels
Routing & convergence
- FRR
- BGP
- OSPF
- BFD
- route-maps and policy routing
- VRF segmentation
WAN platforms
- VeloCloud
- Cisco Catalyst SD-WAN
- Fortinet Secure SD-WAN
- vendor-agnostic overlay design
Resilience
- multi-link bonding
- link-quality measurement
- local breakout
- store-and-forward for tolerant traffic
Automation
- NetBox as inventory
- Jinja2 site templates
- Ansible rollout
- Git-stored site configuration
Monitoring
- LibreNMS
- SmokePing / link latency history
- flow analysis
- failover event log
What we will be measured on
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- Any single link failure at any site is transparent to users — tested in a live site, not modelled.
- A new site is deployable from a template and an inventory entry, without bespoke configuration.
- Every site’s failover behaviour is documented, including what does not survive.
- Traffic that does not need inspection does not cross the datacentre.
- Link quality and failover events are visible per site, with history.
What we would build, and where the weak point is
The overlay hub is a control-plane dependency, not a data-plane one — which is why it must be able to be unavailable without sites losing connectivity. If your SD-WAN design loses forwarding when the controller is down, you have built a wide-area single point of failure and called it resilience.
marks a single point of failure we would raise with you rather than hide. Every architecture has one; the question is whether you know where it is.
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Requires partner
Circuit procurement and carrier contract negotiation
We specify the requirements and verify delivery. We do not sell circuits or take margin on them.
- Requires partner
Carrier SLA enforcement and escalation
We gather the evidence — latency, jitter, loss, outage windows — and you or your broker file the claim.
- Out of scope
Vendor SD-WAN licence sales and tier selection
We will tell you which tier your design requires. We do not resell the licence.
- Out of scope
Private 5G RAN, RF planning and spectrum licensing
A different engineering discipline with regulatory ownership. We will integrate a core if a specialist deploys the radio.
What it looked like last time
A retail chain with eighteen sites on a primary MPLS circuit and an unused broadband backup: rebuilt as a multi-link overlay with BFD-driven failover under one second, policy-based local breakout for cloud traffic, and site configuration generated from templates — with link failure tested in one live branch before the design went anywhere else.
Anonymised under NDA. No client names, no logos, no invented metrics. Full case library on the work page.
Talk to the network engineer about your sd-wan & multi-site
Send us the architecture, or just describe what broke most recently. You'll get an engineer's answer, not a discovery questionnaire.
Talk to a network engineer: botonwa@gmail.com · +86 130 5181 3099