Red Sea Submarine Cable Cuts (Sep 2025)
Summary: Starting in early September 2025, multiple submarine cables in the Red Sea were cut or damaged near the Bab el-Mandeb / Jeddah corridor. The damage forced large volumes of traffic to reroute via alternate, longer paths (often through Singapore/Asia) and produced elevated latency and packet loss—particularly visible on Tata Communications (AS6453) segments. Repairs and capacity restoration are expected to take days-to-weeks depending on vessel availability and security in the region.
Confirmed reports & sources
- Reuters — Red Sea cable cuts disrupt internet across Asia and the Middle East
- ITPro — Microsoft warns of slow Azure traffic
- AP News — Commercial shipping likely cut Red Sea cables, experts say
- Al Jazeera — Internet disruptions in Middle East and South Asia after Red Sea cable cuts
- The National — Repairs may take weeks or months
Observed network evidence
Operator telemetry and user MTR traces (example captured from UAE → London) showed:
- Transit via unexpected Asian hops (e.g., Singapore/India) rather than direct Mediterranean/Red Sea paths.
- Large increase in round-trip time (RTT) to ~250–320ms for European destinations that normally show 60–120ms.
- High and persistent packet loss on Tata (AS6453) backbone hops (40%–>80% observed on some traces).
Timeline (high level)
| When | Event |
|---|---|
| Sep 6–7, 2025 | Multiple undersea cable systems in the Red Sea reported cut/damage (SMW4, IMEWE and others reported by media & network monitors). |
| Sep 7–9, 2025 | Traffic shifts observed: major operators (including Tata/AS6453) reroute traffic via Asia and alternative Mediterranean/Africa paths; increased latency & loss reported across impacted regions. |
| Ongoing | Repair scheduling and cable ship availability remain the limiting factors—restoration may take days to weeks. |
How to verify from your vantage
Run these checks from affected PoPs to confirm reroute & impact (replace DEST_IP or HOSTNAME accordingly):
# MTR (TCP) to destination
mtr -T -P 443 -c 50 DEST_IP
# TCP traceroute (shows TCP path)
tcptraceroute DEST_IP 443
# Compare latency & hops to a European IP and to an Asia IP
mtr -c 40 -T -P 443 8.8.8.8
mtr -c 40 -T -P 443 1.1.1.1
# Packet capture during test (client side)
sudo tcpdump -nni any 'tcp and (host DEST_IP) and port 443' -w /tmp/capture.pcap
Root cause hypotheses
- Physical cut / anchor drag: Ship anchor or other maritime activity damaging multiple fiber systems in a constrained chokepoint (Bab el-Mandeb / Jeddah area).
- Simultaneous faults: Multiple systems impacted or one failure causing cascading effects on multiple operator routings.
- Operational reroutes causing congestion: Rapid reroute of high-volume circuits onto alternate paths (Asia↔Europe) congesting those backbones (Tata/other), causing packet loss.
Impacted operators & regions (examples)
- India, Pakistan, UAE, and other Middle East & South Asia regions experienced degraded performance.
- Tata Communications (AS6453) frequently observed carrying the rerouted traffic and showing high loss in some traces.
- Major cloud providers (e.g., Microsoft Azure) warned of increased latency for customers in affected regions.
Operational recommendations
- Traffic engineering: Broadcast alternate prefixes and leverage dynamic BGP (MED/local-pref) to steer traffic to less-congested egress points where available.
- Diversify egress points: Use additional submarine cable entries (Africa/Med) or private backhaul to reduce dependence on a single chokepoint.
- Anycast & POP placement: Temporarily shift critical services to POPs with healthy return paths to customers (e.g., regionally colocated caches).
- Rate limiting & anti-congestion: Apply per-prefix QoS to avoid amplifying congestion on overloaded backbone segments.
- Customer comms & mitigations: Publish clear status updates and recommended fallbacks (mirrors, alternate API endpoints, retry strategies).
- Monitor & alert: Add RST/packet-loss/RTT spike alerts aggregated by ASN and egress location for faster detection.