Dual ISP in Dubai: Failover That Actually Fails Over
Dual ISP failover means your office edge device watches two internet circuits and moves traffic to the second one when the first stops working. It only protects you if three things are true: the two circuits do not share a physical path, the edge device can tell a dead circuit from a live one within seconds, and the services you care about (phones, VPNs, anything published to the internet) survive the change of public address. Most Dubai offices that pay for a backup line have the first thing and none of the others.
Below are all three, with the detection timers vendors actually ship by default.
Two circuits from two operators, entering by two routes
The UAE fixed market is served by two fully integrated operators, e& (formerly Etisalat) and du, as the UAE government portal u.ae states. For an office that wants real diversity, that makes the first decision simple: one circuit from each. Two circuits from the same operator share the same exchange, the same core and usually the same fault.
The second decision is physical. In a Business Bay or JLT tower, both operators often reach your floor through the same riser and the same building distribution room. A contractor cutting through that riser on a fit out two floors below takes both lines down together, and no router setting fixes that. Ask the landlord's facilities team and both operators where each circuit enters the building. If it is the same room, a fixed wireless or 5G line from the other operator avoids the riser entirely.
Power is the third shared path: if the provider terminals, firewall and core switch are not on protected power, one supply dip in July reboots the whole edge.
How the edge device decides a circuit is dead
A circuit can fail hard or soft. A hard failure is the Ethernet link to the provider's box going down, which every platform detects instantly. A soft failure is the link staying up while nothing gets through: the operator's upstream is broken, the terminal has hung, or the circuit is up but dropping most packets. Soft failures are the harder case to catch, and each vendor handles them differently.
| Platform | Default soft failure detection | Source |
|---|---|---|
| Cisco Meraki MX | Uplink fails over once both HTTP and ICMP tests have failed for more than 300 seconds, so roughly five minutes | Meraki documentation, Connection Monitoring for WAN Failover |
| FortiGate (FortiOS 7.6.3) | SD-WAN health check probes every 500 milliseconds and marks a member dead after 5 failures, so about 2.5 seconds | FortiOS 7.6.3 CLI reference, config system sdwan |
| Cisco IOS router with IP SLA tracking | Cisco's example uses a 60 second probe frequency with 5000 millisecond timeout and threshold, so detection takes up to a minute or more | Cisco, Configure ISP Failover with Default Routes Using IP SLA Tracking, updated 16 November 2023 |
None of these defaults is wrong. A five minute Meraki window avoids flapping on a circuit that stutters for thirty seconds. A 2.5 second FortiGate window catches a failure before most users notice, but on a noisy link it can bounce traffic back and forth. The mistake is not knowing which one you have. An office manager told "we have a backup line" will reasonably expect calls to keep working, when on the default Meraki behaviour they will drop for up to five minutes on a soft failure, where the circuit stays up and simply stops passing traffic.
What the probe is aimed at matters more than how often it fires
The Cisco example probes the next hop gateway. That tells you the operator's first router answers, not that the internet is reachable beyond it. If the operator's upstream fails but its edge router still replies to ping, the track object stays up and your office sits on a dead circuit with failover switched on. Point probes at two or three well known public targets instead, and make sure each probe is forced out of the interface it is testing. A probe to a public address that follows the default route will happily leave by the backup circuit after failover and report the primary as healthy.
Meraki publishes its fixed targets (DNS lookups, ICMP to 8.8.8.8 and an HTTP request); FortiGate lets you name your own. Either way, write the targets and timers into the network documentation.
What breaks when the public address changes
Failing over to a second operator means your office appears on the internet from a different public IP address. Anything that depended on the old address has to recover, and some things do not recover on their own.
- Existing sessions. A remote desktop session or live Teams call started on circuit A cannot continue on circuit B, because the far end is talking to the old address. Meraki's default graceful mode keeps existing flows on the primary path until they expire and sends new flows to the backup, which is sensible when the primary is merely degraded and useless when it is dead.
- IP phones. A SIP phone behind the firewall is reachable for inbound calls only while its registration is current. RFC 3261 leaves the interval to the server, and its own examples use 3600 seconds. If your hosted PBX lets registrations run that long, phones can make calls after failover but miss incoming ones until they next register. Ask your provider for a short registration interval, or confirm that the phones re-register on a network change. The trade offs of on premises PBX versus cloud calling look different once you factor this in.
- Site to site VPNs. A tunnel to a Jebel Ali warehouse or a head office abroad is usually built to your primary public address. The remote side needs a second peer defined for the backup address, or dead peer detection and a tunnel on each circuit.
- Allow lists. Banks, government portals, cloud consoles and SaaS tools that only accept logins from your office IP will lock staff out on the backup circuit. Add the backup address to every allow list on installation day.
- Inbound services. A camera recorder, a mail server or anything published through port forwarding on the primary address disappears on failover. Either publish it on both addresses with DNS records that can be switched, or accept that it is offline until the primary returns.
The only way to keep one public address across two operators is to announce your own address space over BGP to both. That needs your own IP block and autonomous system number, which in the UAE come from the RIPE NCC, the registry for Europe, the Middle East and parts of Central Asia with a regional office in Dubai, plus a BGP session from each operator, which you need to confirm they will provide on your circuit type. Right for a DIFC trading floor; rarely worth it for a thirty person office.
Active and standby, or both at once
Paying for a second circuit that carries nothing until the first fails is the simplest design and the easiest to reason about. The alternative is to use both: guest Wi-Fi and software updates on the backup, business traffic on the primary, with each failing over to the other. That keeps the backup under daily load, so you learn it is broken on a Tuesday afternoon rather than during an outage. Load sharing must pin each session to one circuit, for the address reason above.
If you run several sites, this is where SD-WAN starts to pay for itself, and our guide to SD-WAN for UAE businesses with more than one site sets out when that threshold is reached. For a single office, a firewall with two WAN ports and properly tuned health checks is enough. The wider edge decision is in our business router guide.
A failover test that proves something
Pulling the primary cable proves only hard failure detection, which was never in doubt. A useful test simulates a soft failure and watches what users feel.
- Pick a working hour with someone on a call, someone on the VPN and someone logged into your most IP restricted system.
- Leave the primary link physically up and block its upstream instead, for example with a firewall policy that drops all outbound traffic on the primary interface, so the port stays green while nothing gets through.
- Time how long until new traffic flows over the backup, and compare it with the timer you expected from the table above.
- Place an inbound call to a desk phone, check the site to site tunnel, and try the restricted login.
- Restore the primary and time the return. Recovery has its own timer: FortiOS 7.6.3 wants 5 successful probes by default before a member is considered recovered.
- Write down what broke and fix it before the next test in six months.
What to specify when you buy
For the edge device, you need two WAN interfaces at your circuit speed, configurable health checks with named targets and timers, per session load sharing if you want active and active, and VPN support for more than one peer address. Codeeo Tech supplies edge platforms including Fortinet, Cisco and Cisco Meraki, Juniper and SonicWall, all on request for quote. Send us your two circuits, their speeds and what must stay up during an outage through the contact page, and we will quote an edge device that matches.
Cover photo: Fiber optic cable installation (rubin-20170124-101126) by Rubin Observatory/NSF/AURA, via Wikimedia Commons (CC BY 4.0).
