Dual ISP Failover Setup in Bangalore: A Buyer's Guide

The ₹4.2 Lakh Afternoon

On 14 August 2024, a 90-person fintech office on Bannerghatta Road lost its only internet link at 11:40 AM when a Jio fibre splice in the adjoining building was cut by a cable TV contractor. Their primary link was a 300 Mbps Jio Business connection. They had no secondary. Their SIP trunk was on the same link. Their payment reconciliation dashboard ran on the same link.

By the time Jio's field team restored the splice at 4:15 PM, the company had lost roughly ₹4.2 lakh in failed UPI settlements, missed two client SLA windows, and sent 40 staff home because there was nothing to do. The CEO approved a dual ISP project the next morning.

That is not an unusual story in Bangalore. It is the standard origin story of almost every dual ISP project we quote. The trigger is always one bad afternoon, and the question that follows is always the same: what exactly do I need to buy, and who do I buy it from?

This guide is the answer we give to IT managers and ops heads who ask us that question. It covers the three main design choices (active-passive, load balancing, hybrid), the four implementation approaches (firewall failover, BGP, SD-WAN, router-based), how to pick carriers that are genuinely diverse rather than nominally diverse, and what the whole thing costs in 2026. If you want the short version of what we install, our network solutions page covers the service, but the trade-offs are in this article.

First, Understand What "Failover" Actually Means

Failover is not a feature you buy. It is a behaviour you design. The design question is: when the primary link fails, what detects it, what switches, and how long does the user notice?

Three timers matter, and vendors routinely conflate them:

• Detection time — how long before your equipment realises the primary link is dead. On a physical cable cut this can be under a second if you monitor link state. On a routing failure upstream it can be 30-90 seconds if you rely on default BGP timers.
• Switchover time — how long the device takes to move traffic to the secondary. Good firewall failover is 2-10 seconds. Bad SD-WAN policy configurations can take 20 seconds. DNS-based failover is 60-300 seconds because you are at the mercy of TTL.
• Session survival — whether existing connections survive the switch. TCP sessions almost always break. VoIP calls survive if the SIP provider supports it and your firewall keeps state. SSH sessions die. This is the part nobody warns you about.

A dual ISP setup that switches in 3 seconds still drops every live Teams call, every active SSH session, and every in-progress file upload. That is fine for most offices. It is not fine for a call centre or a trading desk. Know which one you are before you buy.

The Three Design Choices

Active-Passive

Both links are live, but only one carries traffic. The secondary sits idle until the primary fails.

Pros: Simple, predictable, cheap. No asymmetric routing to debug at 11 PM. Both links can be from different ISPs with no coordination.

Cons: You are paying for a link you are not using. A ₹18,000/month backup line contributes zero throughput for 99.5% of the month.

Where it fits: Any office where a 10-60 second outage is tolerable but a 4-hour outage is not. This is the majority of Indian SMEs. A 50-user office with a 200 Mbps primary and a 100 Mbps backup is perfectly served by active-passive.

Active-Active (Load Balancing)

Both links carry traffic simultaneously. Traffic is distributed by session, by packet, or by application policy.

Pros: You use both links. A 200 Mbps + 200 Mbps pair behaves like ~380 Mbps for many-user workloads. Good for offices that genuinely need the bandwidth.

Cons:

• Asymmetric routing. Return traffic can come back on the wrong link, and stateful firewalls drop it unless you configure things carefully.
• Session stickiness. A user downloading a file may get 200 Mbps, not 400, because the session is pinned to one link.
• Bad links drag good ones down. If the secondary is a flaky 4G connection with 8% packet loss, load balancing will route 40% of your traffic through a bad path.
• Banking portals and government sites often break. Many Indian bank net-banking portals and GST portals will log you out if your source IP changes mid-session. Load balancing changes your source IP on every new session.

Where it fits: Bandwidth-hungry offices (media, design, dev teams pulling containers, VOIP-heavy support floors) where the traffic is mostly outbound to diverse destinations and per-session IP stability does not matter.

Hybrid: Active-Passive with Policy-Based Overflow

This is what we install for most clients above 75 users. The primary link takes everything. The secondary link takes specific low-risk traffic (guest Wi-Fi, backup uploads to cloud, bulk downloads) all the time, and takes everything when the primary fails.

The rule set is usually:

• Guest VLAN → load-balanced across both links
• Backup traffic to AWS/Azure → secondary link, always
• Business VLAN → primary link, failover to secondary
• VoIP SIP trunk → primary link, failover to secondary with session preservation enabled
• Site-to-site VPN → primary link, failover with DPD (dead peer detection) tuned to 3 seconds

You get the bandwidth utilisation of active-active for the traffic that can tolerate it, and the predictability of active-passive for the traffic that cannot. It is more work to design and more work to maintain. It is what you want.

The Four Implementation Approaches

This is where buyers get lost. "Dual ISP failover" is sold as a feature by firewall vendors, SD-WAN vendors, and ISPs alike, and they are all describing different things.

Approach 1: Firewall-Based Failover

Two WAN links terminate on one firewall. The firewall monitors both links (via ICMP probes, HTTP probes, or BFD) and switches default route when the primary fails.

Typical hardware: FortiGate 60F, 90G, 120G; Sophos XGS 2100, 3100; Palo Alto PA-440, PA-450. For a 50-user office, a FortiGate 90G is comfortable. For 150 users with SD-WAN policy needs, a 120G or Sophos XGS 3100 is the floor.

Cost: ₹95,000-₹1,60,000 for the firewall in 2026, plus a UTM subscription of roughly ₹28,000-₹55,000/year depending on model and bundle (FortiGuard UTP, Sophos Xstream Protection).

Switchover: 2-6 seconds with reasonably tuned probes.

Watch out for: Probe behaviour. By default, a FortiGate will fail over if it cannot reach its configured health-check targets, even if the link is actually fine and only the probe target is down. Configure at least two probe targets from different networks (e.g., 8.8.8.8 and 1.1.1.1) and set failover thresholds to require three consecutive failures, not one. We have seen an office fail over to a backup link for 20 minutes because Google DNS had a hiccup.

Approach 2: BGP-Based Failover

If your primary ISP will give you a BGP session with a public /29 or /30 IP block (most Indian ISPs will for business connections above ~₹15,000/month), you can run BGP to both ISPs and let routing protocols handle failover.

The reality check: Most Indian SMEs do not need BGP. BGP gives you:

• Inbound failover (external users reach you via either ISP)
• Multi-homed redundancy at the routing layer
• The ability to advertise your own IP block if you own one (rare below 500 employees)

BGP does not meaningfully speed up outbound failover versus a good firewall setup. It is not a magic bullet. Where BGP is genuinely worth it: any business that hosts services externally (mail server, VPN concentrator, customer-facing API) and needs those services reachable on either link.

The gotcha: If you advertise the same /24 (or /29) from two ISPs without proper AS path prepending or local preference tuning, you get asymmetric routing and half your inbound traffic comes in on the link you thought was standby. We have fixed this on at least four Bangalore deployments where a vendor installed "BGP failover" without prepending.

Cost: Typically a one-time setup charge of ₹8,000-₹25,000 from the ISP, plus a business plan that supports BGP (usually ₹18,000-₹40,000/month per link for 200-500 Mbps with a static /29).

Approach 3: SD-WAN Appliances

SD-WAN (Fortinet, Sophos, Cisco Catalyst SD-WAN, VMware VeloCloud) adds application-aware path selection on top of plain failover. Rules can say "Teams traffic always uses the primary if latency < 80ms, otherwise move to secondary" or "backup traffic uses the cheapest link."

Where SD-WAN earns its keep:

• Multi-site companies (2+ offices) where you want the branch links to fail over to a central hub
• Applications with latency sensitivity (VoIP, video, Citrix/RDP)
• Monthly bandwidth spend above ₹60,000, where optimising which link carries what pays for itself

Where SD-WAN is overkill: A single-office 40-user company with a ₹12,000/month primary link and a ₹6,000/month backup link will not recover the added complexity. We have quoted SD-WAN projects that we talked the client out of.

Cost: FortiGate SD-WAN is bundled with the firewall licence already, so incremental cost is zero if you already run a FortiGate. Standalone SD-WAN overlays (Cisco, VMware) start around ₹2,50,000 for hardware plus ₹80,000-₹1,80,000/year licensing for a two-site deployment.

Approach 4: Router-Based with a Managed Failover Appliance

Some offices add a simple failover router (TP-Link ER605, DrayTek Vigor 2927, Ubiquiti UDM Pro) in front of the firewall, or replace the firewall's failover function entirely.

Honest assessment: We do not recommend this for offices above 25 users. Consumer and prosumer routers do basic failover, but:

• They usually cannot do BFD, so failover is slower (10-30 seconds)
• They cannot inspect for application-level failure (link up, upstream dead)
• They often have less powerful NAT tables and will struggle with 100+ concurrent users

A UDM Pro doing dual WAN failover in a 60-user office will work, but roll back the clock three years and you would not have been able to. The absolute floor we install is a FortiGate 60F. Below that price point, use a single ISP and a 4G backup router, and accept that the 4G path is a break-glass option.

Comparison Table: The Four Approaches

Choosing Genuinely Diverse Carriers in Bangalore

This is the part where most dual ISP projects quietly fail. Two links from two ISPs are not necessarily two paths. If both ISPs buy transit from the same upstream, or both use the same fibre route into your building, or both terminate in the same duct, you have redundancy on paper and a single point of failure in reality.

The most common mistake: buying Jio + Jio Fiber + Airtel, believing three links mean three paths. Two of those are the same ISP with the same upstream peering, and the third may share conduit into your building.

The ISP Line-Up in Bangalore (2026)

Figures are indicative monthly rentals for a Bangalore commercial address with a 1:1 contention ratio and static IP, as of early 2026. Prices vary by building, contract length, and whether the address is already on-net.

How to Check if Two Carriers Are Actually Diverse

Ask the ISP three questions before signing:

1. What is the last-mile medium? Fibre, copper, or microwave. If one link is fibre and the other is microwave or 4G, you have physical diversity for free.
2. Which upstream transit providers do you use? In India, look for at least two of: Tata Communications, Airtel, Reliance Jio, Sify, Vodafone Idea (Vi). Two ISPs both single-homing to Airtel transit is one ISP with two bills.
3. What is the physical entry path into the building? Ask the building facility manager. If both fibre cables come up the same shaft and enter via the same duct, a backhoe at the gate takes out everything. For high-availability sites, route one carrier via the building's other side or terminate one link on a microwave/4G fallback.

The BUILDING FACTOR

In Bangalore, commercial buildings in corridors like Outer Ring Road, Whitefield, Electronic City, and Hebbal often have pre-installed fibre from one or two providers only, and building management controls the entry points. If your building has only one provider, your "second ISP" may be a wireless or 4G link whether you like it or not. Plan for it. A well-configured 4G backup with a business data plan (₹1,500-₹3,500/month for 500 GB-1 TB) will survive a 2-4 hour fibre cut, which is what most cuts actually are.

GST, LOA, and the Boring Paperwork

A few things that trip up first-time buyers:

• GST: Telecom services attract 18% GST. Your monthly invoice is not the headline number; add 18%. If you are GST-registered, you claim input credit, so the effective cost is the pre-GST figure for your P&L.
• LOA (Letter of Authority): If your company does not own the registered office address (leased premises), the ISP will ask for an LOA from the landlord. Get it early. This is the most common cause of last-mile delays in Bangalore.
• OFC permission in gated communities: If your office is inside a tech park or gated community, the ISP's fibre pull may need park-level NOC. Some parks block new ISP entries entirely. Confirm before you commit.

If you are running the procurement through a managed service provider, we handle the LOA, NOC, and last-mile coordination as part of the setup — see our network solutions service page.

The Failure Story: When "Dual ISP" Was Not Actually Dual

A 140-seat SaaS company in Outer Ring Road bought dual ISP from us in late 2023. Primary was Airtel 500 Mbps, backup was ACT 300 Mbps. Both terminated on a FortiGate 100F, active-passive. It worked fine for eight months.

In June 2024, a BBMP road-widening crew cut a cable bundle near the Marathahalli bridge at 9:20 AM. Both Airtel and ACT were affected because both had fibre in the same duct along that stretch. The firewall's health checks detected both links down within 4 seconds — and moved to… nothing. No third path existed. The office was offline for 5.5 hours while two field teams worked the same damaged duct from opposite ends.

The fix cost ₹92,000 in one-time spend and about ₹2,800/month ongoing:

• 1 × MikroTik LtAP LTE6 4G router in a weatherproof enclosure on the roof, ₹32,000 installed
• 1 × dual-SIM LTE plan from Vi Business with 1 TB/month, ₹2,800/month
• 1 × configuration change on the FortiGate to treat the 4G link as a third WAN with a higher cost metric, ₹0 (work by us, billed at ₹18,000 for four hours of after-hours engineering and route testing)
• 1 × re-work of the FortiGate SD-WAN rule to send Teams and SIP traffic via the 4G link if both fibre links are dead, and everything else to failover with a hard 200ms latency ceiling

The 4G link now runs at 40-90 Mbps during the day and carries the office for 30-90 minutes at a stretch. That is enough. Since June 2024, the office has failed over to 4G on six separate occasions, the longest for 100 minutes, with no reported business impact.

The lesson: If both fibre paths enter your building via the same duct, you do not have dual ISP redundancy. You have twice the bandwidth on the same single point of failure. Ask the question. Most carriers will actually tell you if you push.

Cost: What a Real Dual ISP Setup Costs in Bangalore (2026)

Here is what we quote for actual deployments. These are typical 2026 figures for a Bangalore commercial address. Add 18% GST on services; hardware is billed at 18% GST too.

Small office, 15-40 users, active-passive

Medium office, 40-100 users, active-passive with optional secondary use

Larger office, 100-250 users, SD-WAN with policy-based routing

Multi-site (3 branches + HQ)

Add roughly ₹1,80,000-₹3,20,000 one-time for hub licensing and per-branch SD-WAN equipment, and ₹60,000-₹1,20,000/year for the SD-WAN overlay licence. The per-site ISP cost typically lands in the medium-office range.

Rough sanity check: a two-ISP redundant setup costs 1.6-2.2× a single-ISP setup to run, and 4-6× the firewall cost of a single-ISP setup to build. If the business value of a 4-hour outage is under ₹2 lakh, active-passive firewalls plus a 4G tertiary is usually the right answer. If it is over ₹20 lakh, look at BGP and carrier diversity more seriously.

What We Actually Test Before We Hand Over

A dual ISP setup is only as good as its last test. We run the following before signoff; if your current provider does not, ask why.

1. Physical disconnection test. Unplug the primary WAN cable from the firewall. Measure the time to full service restoration. Should be under 8 seconds.
2. Upstream failure test. Block the ISP's gateway IP via ACL. This simulates the link being up but upstream dead — the case most failover systems miss. Should also be under 10 seconds.
3. Application-level test. Not just ping. Open a Teams call, start a file upload to S3, log in to a bank portal, and observe behaviour through a failover event. Document which sessions survive.
4. Recovery test. Restore the primary. Verify traffic returns without manual intervention and secondary link goes back to standby. Auto-recovery is the part vendors skip; a failover that requires human intervention is not a failover.
5. Flap test. Disconnect and reconnect the primary five times in five minutes. Some setups fail over correctly once and then lock up because of stuck state. Verify.
6. Speed test on both links, and after failover. Confirm the backup carries the load. A 100 Mbps backup cannot silently be expected to run a 200-user office.
7. SIP/VoIP regression. Call in, call out, and hold a call through a failover event if the design claims call survival. Most designs do not survive this; document it so users are not surprised.

Common Mistakes We See (and Fix)

• Same-ISP backup. "We have two links, both Airtel." That is one ISP with two bills. Fix by adding a diverse carrier or a 4G tertiary.
• Single probe target. Failover triggered by a DNS blip. Fix by using multiple, diverse health-check targets.
• Failover works, recovery does not. After the primary comes back, traffic keeps flowing on the secondary. Fix by correctly setting metric/preference and testing recovery in the signoff.
• Backup link too slow. A 100 Mbps backup on a 300 Mbps primary office is fine for a 4-hour bridge but not for a full working day with cloud apps. Fix by matching backup capacity to at least 50% of primary.
• State-aware apps break on failover. Bank portals, some government sites, and a few SaaS apps invalidate sessions when the source IP changes. Fix by pinning those users' traffic to a specific link via policy, or by reserving failover for full-link-down events rather than flapping links.
• No metrics. Nobody knows how often failover actually triggers. Fix by exporting firewall logs to a dashboard and reviewing monthly. If failover triggers three times a month, you have an upstream problem with the primary ISP and should escalate.

Data, Compliance, and the DPDP Angle

Two things to keep in mind that Indian buyers often miss:

• CERT-In directions (April 2022) require covered entities to report certain cyber incidents within 6 hours, and to maintain logs for 180 days. If your internet is your only path for log export, dual ISP matters for compliance, not just uptime. A log-export path that dies with the primary link is a compliance gap.
• DPDP Act 2023 does not directly mandate dual ISP, but if you process personal data and your business continuity plan claims continuous availability, an auditor will ask you to evidence it. Dual ISP is table stakes for that conversation. Keep the test reports.

Choosing a Provider

Three kinds of vendors sell this:

1. The ISP directly. Cheapest on hardware markup, but each ISP only knows its own link. They will not engineer cross-ISP failover properly, and they will not diagnose a competitor's link.
2. A traditional system integrator. Good at procurement and cabling, variable on network engineering. Ask for the engineer's name and their Fortinet/Palo/Cisco certifications. Ask what test report they hand over.
3. A managed network services partner. Slightly higher setup cost, but the design, tuning, and monthly failover reporting are their job. This is what we do, and where the network solutions practice sits, but it is not the right fit if you have an in-house CCIE-level network engineer who can own it. In that case, buy the hardware and let your engineer build it.

Before you appoint anyone, ask for:

• The reference architecture for your size and building type
• A specific test plan with measurable pass/fail criteria
• A list of the exact hardware models and firmware versions to be deployed
• Post-deployment SLA for failover incidents (not just link restoration — failover diagnosis)
• Two references from Bangalore offices of similar size in the last 12 months

If you want to talk through your specific building and budget, reach out to us and we will tell you honestly whether dual ISP is the right spend or whether you should put the money somewhere else first.

FAQ

How much does a dual ISP failover setup cost in Bangalore in 2026?

For a 40-user office, ₹1,03,000 one-time plus ₹18,500/month recurring. For 100 users with SD-WAN rules and a 4G tertiary, ₹1,89,000 one-time plus ₹52,800/month. Multi-site deployments add ₹1,80,000-₹3,20,000 in one-time cost for hub licensing and per-branch equipment. All figures exclude 18% GST.

Do I really need two different ISPs, or can I use two connections from the same ISP?

Two connections from the same ISP share upstream transit and often share last-mile infrastructure. If the ISP has a core outage, both links fail together. Use two different ISPs, and if possible ensure their last-mile paths into your building are physically diverse. A same-ISP pair plus a 4G tertiary is better than nothing, but it is not what "dual ISP" usually means.

Is BGP required for dual ISP failover?

No. For most offices under 200 users, firewall-based failover with health checks (FortiGate, Sophos, Palo Alto) handles the failure correctly in 2-6 seconds. BGP matters when you host services externally and need inbound traffic to reach you via either ISP. BGP convergence is slower (30-180 seconds) than firewall failover, so it is not a faster path — it is a different problem being solved.

How fast is the switchover, and will my calls drop?

Good firewall failover is 2-6 seconds. File uploads and SSH sessions almost always break because the source IP changes. SIP calls can survive if your SIP provider supports mid-call failover and your firewall keeps state; most small offices do not have that, so plan on calls dropping and redialling. If call continuity matters, design for it explicitly or accept the drop window.

Can I use 4G or 5G as my backup instead of a second fibre link?

Yes, and for many Bangalore offices it is the right choice. A business 4G/5G plan with 500 GB-1 TB per month costs ₹1,500-₹3,500 and will bridge a 2-4 hour fibre cut. It will not carry a 100-user office for a full day of cloud work — latency and data caps get in the way. Use it as a tertiary failover, not as the only backup.

What about the DPDP Act and CERT-In — does dual ISP help with compliance?

CERT-In's 2022 directions require incident reporting within 6 hours and 180-day log retention. If log export depends on a single internet path, a link failure can breach that obligation. DPDP does not mandate dual ISP by name, but any auditor reviewing your availability claims will look for evidence of redundancy and test reports. Dual ISP with documented failover testing supports both, but it is not by itself a compliance solution.

What to Do Next

Take the following three steps this week, before you talk to any vendor:

1. Ask your building facility manager which ISPs have fibres in the building and where they enter. If the answer is "one ISP, one duct," you know your design already.
2. Write down the true cost of a 4-hour outage for your business. Rupee value, not a feeling. That number will tell you whether you are a firewalls-active-passive buyer or an SD-WAN-with-BGP buyer.
3. Run a failover test on your current setup if you have one. Unplug the primary WAN at 6 PM on a Friday, and watch what actually happens. Most offices discover their "failover" does not work at all.

If you want help turning those answers into a costed design and a deployment you can trust, get in touch with our team. We will come look at the building, quote a real number in rupees, and tell you if dual ISP is not the right first spend for you. Sometimes the right recommendation is a UPS upgrade, or a better firewall, or moving your SIP trunk to a carrier that supports mid-call failover — and we will say so.