Redundancy inside one metro cannot survive the loss of that metro. Geo-redundancy places a full, independent on-ramp in a second metro, so a metro-level outage shifts traffic to the other location under BGP control rather than taking the service down.
When to use it
Use geo-redundancy when your availability requirement is larger than any single facility can meet – regulated services, national platforms, anything where “the metro went dark” must not mean “the service went dark”. It is the connectivity side of the Maximum resiliency tier and the network foundation under multi-region active-active designs.
How it works
Each metro hosts a complete on-ramp: its own edge, its own connections into the clouds, its own paths. The two on-ramps are independent, so no single metro failure affects both. Users and workloads normally use the nearer on-ramp; on failure, traffic moves to the other.
The failover is routing-driven. The same application prefixes are reachable through both metros, weighted with BGP so one is preferred and the other is a standby route (local preference 400 versus 300, with AS-PATH prepend on the backup). When the preferred metro’s paths fail, BFD detects the loss quickly and BGP reconverges onto the second metro’s on-ramp. Because both on-ramps are pre-built and already peering, there is nothing to provision during the event.
Two design points keep this clean. Place each on-ramp near the cloud and carrier edges it serves, so normal-state latency is good from each. And honour any cloud-mandated circuit diversity within each metro, so the on-ramp is itself resilient – geo-redundancy protects against losing a metro, not against a sloppy single path inside one.
Example
An e-commerce company serves a national market and cannot tolerate a regional connectivity outage during peak sale events. It builds on-ramps in two metros, each with independent connections into its AWS and Azure environments. Shoppers are served through the nearer metro; the prefixes are advertised through both with BGP weighting. During a peak event, one metro loses connectivity – BGP withdraws its paths and all traffic converges on the second metro’s on-ramp within seconds, and the sale continues.
Bandwidth planning
Each metro on-ramp must be able to carry the full load alone, because a geo-failover puts everything on one of them. Sizing each for half the traffic defeats the purpose. Account for the cost of that headroom explicitly – geo-redundancy trades higher steady-state capacity for the ability to lose a whole location.
IZO™+ Multi Cloud Connect components in this architecture
Geo-redundancy places a full, independent on-ramp in each of two metros – a dual build spread across locations:
IZO™+ Multi Cloud Connect Direct (private MPLS underlay):
-
Fabric Port ×2 (two metros) – an independent on-ramp per metro.
-
Virtual Cloud Connection ×2 – metro-diverse landings into the clouds.
IZO™+ Multi Cloud Connect Flex (internet underlay with an in-path VNF):
-
Fabric Port ×2 (two metros), Edge Connect ×2, VNF (optional) ×2, Device Interconnection – where an in-path function is replicated per metro.
-
Virtual Cloud Connection ×2.
From the IZO™+ Multi Cloud Connect side, this architecture uses a Fabric Port and Virtual Cloud Connection in each of two metros; the Tata Communications-billed parts run to the Virtual Cloud Connections, while each cloud port/attachment and egress sit on your cloud bill.
Considerations
-
Each metro carries the full load - A geo-failover puts everything on one on-ramp – size each metro for the whole load, not half.
-
Failover is routing-driven - The same prefixes are advertised through both metros, BGP-weighted (LP 400 vs 300); BFD detects a metro’s loss and BGP reconverges onto the survivor.
-
In-metro resilience too - Honour any cloud-mandated dual-circuit requirement within each metro – geo-redundancy protects against losing a metro, not a sloppy single path inside one.
-
Placement - Site each on-ramp near the cloud and carrier edges it serves so normal-state latency is good from each metro.
-
Cost - The steady-state headroom (full capacity in two metros) is the deliberate trade for surviving the loss of a whole location.
What’s on the cloud side
The cloud connections in each metro are created in the cloud provider’s console. This page covers how the two independent on-ramps and their failover are delivered on the Tata Communications side; for the cloud-side connection request and routing, see the relevant per-cloud section.