Building High-Availability SD-WAN Architectures for Distributed Indian Sites

Single-ISP branches are outages waiting to happen

Every multi-site organisation I walk into in India has the same quiet assumption baked into its network: the branch ISP will hold. It will not. A fibre cut on a road-widening project, a flooded exchange, a router card dying at the provider’s end — the question is never whether a branch circuit fails, only when, and for how long. If your ERP, your voice traffic and your payment terminals all hang off one link, a digger in Noida becomes a production outage in your books.

MPLS was the old answer, but a single MPLS circuit is still a single circuit — and in India the last mile often shares physical paths even when you buy from two “different” providers. I have audited dual-link branches where both circuits entered the building through the same duct. High availability is not a line item on a quote; it is an architecture. That is what a properly designed high availability SD-WAN architecture gives you — diverse underlay, intelligent steering, and failover that your applications actually survive.

I have been building branch networks since 1993, and my team at PJ Networks runs FortiGate SD-WAN estates for manufacturers, banks and retail chains across the country. What follows is the reference design I keep returning to, the decisions that separate a working SD-WAN from an expensive one, and the lessons a multi-site manufacturing rollout taught me the hard way.

The reference design: dual-ISP FortiGate SD-WAN

The pattern is deliberately boring, because boring is what survives at 2 a.m. in a branch with no IT staff.

Two genuinely diverse underlays

Each branch gets two circuits from two providers on two technologies — broadband or fibre primary, LTE/5G or a second fibre on a separate entry path as secondary. Before signing anything, I verify physical path diversity: where each circuit enters the building, which exchange it routes through, who owns the last mile. A secondary link that shares the primary’s trench is a comfort blanket, not resilience.

Application-aware steering, not round-robin

The FortiGate at each branch builds IPsec overlays across both underlays and steers traffic by application, not by packet count. Voice and video go down the link with the lowest measured latency and jitter. ERP and Citrix sessions get the most stable path. Guest Wi-Fi and bulk traffic take whatever is cheapest. The steering rules follow the business — I sit with the application owners first and rank what the branch cannot live without.

Automatic failover that nobody notices

SLA probes run continuously against real targets — not the ISP’s gateway, which lies to you the moment the problem is upstream, but an anycasted resolver or your own head-end. When a probe detects degradation past threshold, sessions shift to the surviving link in seconds. The branch notices nothing; the NOC gets an alert and a ticket.

A repeatable branch runbook

The design only counts if the fortieth branch looks like the fourth. I build a standardised branch template in FortiManager — addressing plan, overlay topology, steering policy, security profile, firmware baseline — so a new site is a documented procedure, not a fresh engineering exercise. The runbook covers staging, shipping, local handover and the first-week soak checks. Repeatability is where most DIY SD-WAN projects quietly die.

The design decisions that actually matter

Underlay versus overlay: secure both

SD-WAN marketing sells the overlay; outages and breaches live in the underlay. Every underlay interface is an internet-facing attack surface, so the branch FortiGate enforces the same IPS, web filtering and application control on local-breakout traffic as it does on tunnelled traffic. Local internet breakout is often the right call for SaaS performance — but only if inspection happens at the branch, not backhauled to a data centre that has become your new single point of failure.

SLA probes: measure what the application feels

Default probe settings fail in both directions — too sensitive and links flap, too coarse and VoIP calls degrade for minutes before anything reacts. I tune probe intervals, failure thresholds and packet-loss windows per traffic class, and I test them by physically pulling circuits during the pilot. If you have never watched your own failover happen, you do not have failover; you have a hope.

Failover that voice and ERP survive

The hardest requirement is session survival. A dropped TCP session is an irritation for browsing and a disaster for a long-lived ERP session or an active call. This is where design details earn their keep: session-aware steering, correct NAT behaviour on the secondary path, and head-end hubs sized to accept re-established tunnels at scale when a regional provider fails and forty branches fail over together. Size your hubs for the bad day, not the average one.

Central management from day one

FortiManager and FortiAnalyzer are not optional extras. Templates, firmware discipline, config revision control and centralised logging turn forty boxes into one estate — and when a remote site breaks, “what changed since Tuesday” is a query, not an investigation.

Lessons from a multi-site manufacturing rollout

A manufacturing group with plants and depots across three states engaged me to replace a fragile mix of single MPLS circuits and consumer broadband. The target the board set was 99.99% uptime for plant connectivity — roughly fifty minutes of downtime a year. Three lessons from that programme stay with me.

First, the pilot told the truth. We ran two plants as pilots for a month and deliberately failed links during production hours. The steering worked; the LTE secondary at one site did not, because the coverage map had lied. We moved that site’s secondary to a second fibre on a separate entry path before rolling out further. Pilots are where you buy certainty cheaply.

Second, the plants did not fail on technology — they failed on process. A local contractor re-patched a cabinet during unrelated electrical work and took out both WAN ports of a branch unit. After that, every site got a photographed, labelled cable map, and cabinet access went into the change log — high availability includes the physical layer and the humans near it.

Third, 99.99% is an operational discipline, not a design artefact. The uptime number came from the runbook — firmware cadence, config drift checks, monthly failover tests on a rotating subset of sites, and a NOC that watches SLA probe trends rather than waiting for down-alerts. They hit the target in year one.

When SD-WAN is overkill

Honesty first: not every network needs this. If you have five small branches running cloud email and a browser-based CRM, with staff who tolerate a reconnection after lunch, a properly configured dual-WAN FortiGate with basic failover does the job at a fraction of the cost and complexity. SD-WAN earns its premium when you have real-time traffic that cannot drop, many sites to keep consistent, or compliance obligations that demand central visibility and change control. If a vendor proposes SD-WAN for three sites with no voice traffic, ask what problem it solves that simpler failover does not.

How I work

Every engagement follows the same arc. Assess: I map your sites, circuits, applications and failure history, and I verify physical path diversity myself. Architect: the reference design adapted to your traffic mix, with the steering policy written from your application owners’ priorities. Deploy: a pilot, a witnessed failover test, then the templated rollout with the branch runbook. Operate: handover with monitoring, failover-test cadence and drift checks — or my team at PJ Networks runs the NOC for you. You can read more about how I work and where I come from on my about page.

Frequently asked questions

Is SD-WAN a replacement for MPLS in India?

Often, but not always. Dual broadband plus LTE with a well-built overlay matches or beats single-circuit MPLS availability for most branch workloads, at lower cost. I still keep MPLS where a site needs hard latency guarantees to a data centre, or where local broadband is genuinely poor. Many estates end up hybrid: MPLS at the core sites, SD-WAN everywhere else.

How fast is failover in practice?

With tuned SLA probes, traffic steers to the surviving link in a few seconds. Whether the application notices depends on the session: browsing and SaaS usually continue uninterrupted, voice calls survive with a brief blip if steering is session-aware, and long-lived ERP sessions may need a reconnect unless the design specifically protects them. This is exactly what the witnessed failover test verifies.

Do we need FortiManager for a small deployment?

Below about five sites you can manage units individually without losing control, though you give up templates and central revision history. Past that point, manual management is how config drift begins, and drift is how identical branches become forty unique snowflakes that nobody can troubleshoot at 2 a.m.

What does a high availability SD-WAN architecture cost compared to MPLS?

In most Indian multi-site estates I assess, dual broadband plus LTE underlay costs meaningfully less per site than MPLS, even after the SD-WAN licences and management — often funding the rollout itself within the first contract cycle. The honest caveat: the business case depends on your circuit mix and site count, which is why the assessment comes before the proposal.

Talk to me about your branch estate

If you are running distributed Indian sites on single circuits, or you have SD-WAN licences and a nagging feeling the failover has never truly been tested, start with a conversation. Book a working session and we will map where your estate actually stands. Based in Delhi, working with enterprises across India.