Can we detect submarine cable cuts from BGP routing table?

Isp-Column
Can we detect submarine cable cuts from BGP routing table?

Background

I wrote most of this post over a week ago, but I couldn’t complete it as I was down with a viral fever, which has disrupted my schedule a bit. Anyway, to the post now. A University researcher recently sent me an email about my post on Submarine cable cuts at Jeddah. Their question was about how we can detect submarine cable cuts in detail from the BGP routing table. There was some hint to “how” in the last part of my earlier post, where a graph shows how the route announcement from Bharti Airtel (AS9498) went to zero at DE-CIX Frankfurt. Let’s find out if we can actually detect a large outage using just the BGP as the control plane. Using the data plane is always useful as one can spray packets around & find out latency/packet loss, but one can ultimately have limited source points. But for the BGP table, there are great projects collecting full routing table & publishing it for researchers like RIPE RIS, Oregon Routeviews, besides quite nice looking glass API from DE-CIX, AMS-IX, etc.



Who is expected to pull announcements?

Typically, tier 1 / transit-free networks, as well as other networks which may technically be tier 1 but have large downstream table & peerings, would not pull announcements in case of submarine cable failure. This is by design; they are expected to ensure they have enough transport capacity available to carry the traffic. If they cannot, they would arrange for that, but won’t pull off BGP announcement because pulling announcements in one region (like Europe in this case) may result in their peering partner using more capacity. This is typically not expected as per peering policies.

Some examples of peering policy enforcing consistent announcements:

1. GTT AS3257 peering policy

2.7. Each Internet Network must announce consistent routes across all interconnection points, unless mutually agreed in writing by both parties.


2. Orange AS5511 peering policy

provide consistent routing announcements, i.e., the same set of routes announced with the same autonomous system (“AS”) path length at all peering locations,


3. Arelion AS1299 peering policy

Routes: Interconnection Candidate must carry full customer routes in interconnect routers, and announce consistent routes using BGP4 at all peering locations.

Thus, it’s clear that one should not look for announcement changes by any of the free networks from a viewpoint. A notable exception here will be tier 1 transit-free networks which peer at IXPs. :)

However, tier 1 transit-free networks can be an interesting viewpoint to see changes in announcements coming from their downstream.



DE-CIX FRA announcements

This shows a major downfall on 5th Sep. Here’s the raw table:

Timestamp Routes
2025-09-05 19:30:44 294706
2025-09-05 20:30:45 294755
2025-09-05 21:31:02 294782
2025-09-05 22:31:12 294627
2025-09-05 23:30:44 282089
2025-09-06 00:30:43 282422
2025-09-06 01:31:05 282563
2025-09-06 02:31:07 282532

This shows a downfall of 12538 routes between 22:31 and 23:30. I am collecting this data from the Looking Glass API of DE-CIX, but I think the same should be visible (with more compute) from MRT dumps as RIPE RIS RRC12 carries routes fed from DE-CIX route servers on AS6695. There is a similar visible drop in routes at LINX London around the same period.


Here’s a summary of ASNs I can find from DE-CIX and LINX data which seem to be impacted:

IXP IXP Code ASN AS Name address Drop in routes_imported at IXP
DE-CIX rs1_dxb_ipv4 3356 Century Link 185.1.8.41 21
DE-CIX rs1_dxb_ipv4 8220 COLT Telecom Group plc 185.1.8.60 6823
DE-CIX rs1_dxb_ipv4 9498 Bharti Airtel Limited 185.1.8.51 3037
DE-CIX rs1_dxb_ipv4 9583 Sify Technologies Ltd 185.1.8.57 165
DE-CIX rs1_dxb_ipv6 8220 COLT Telecom Group plc 2001:7f8:73::201c:0:1 771
DE-CIX rs1_fra_ipv4 9498 Bharti Airtel Limited 80.81.196.112 9681
DE-CIX rs1_fra_ipv4 9498 Bharti Airtel Limited 80.81.194.250 9144
DE-CIX rs1_fra_ipv4 18001 Dialog Axiata PLC 80.81.192.114 241
DE-CIX rs1_fra_ipv4 35753 Integrated Telecom Company (ITC) / Salam.sa 80.81.192.26 281
DE-CIX rs1_fra_ipv4 35753 Integrated Telecom Company (ITC) / Salam.sa 80.81.194.9 105
DE-CIX rs1_fra_ipv4 58717 Summit Communications Limited 80.81.192.208 345
DE-CIX rs1_fra_ipv6 9498 Bharti Airtel Limited 2001:7f8::251a:0:2 5656
DE-CIX rs1_fra_ipv6 9498 Bharti Airtel Limited 2001:7f8::251a:0:1 3765
DE-CIX rs1_fra_ipv6 35753 Integrated Telecom Company (ITC) / Salam.sa 2001:7f8::8ba9:0:3 64
DE-CIX rs1_fra_ipv6 35753 Integrated Telecom Company (ITC) / Salam.sa 2001:7f8::8ba9:0:4 16
DE-CIX rs1_fra_ipv6 58717 Summit Communications Limited 2001:7f8::e55d:0:1 86
DE-CIX rs1_ist_ipv4 6939 Hurricane Electric 185.1.48.16 89077
DE-CIX rs1_ist_ipv6 6939 Hurricane Electric 2001:7f8:3f::1b1b:0:1 60337
DE-CIX rs1_mrs_ipv4 9498 Bharti Airtel Limited 185.1.47.7 9149
DE-CIX rs1_mrs_ipv4 10075 Fiber Home Global Ltd 185.1.47.145 663
DE-CIX rs1_mrs_ipv6 9498 Bharti Airtel Limited 2001:7f8:36::251a:0:1 3765
DE-CIX rs1_mrs_ipv6 10075 Fiber Home Global Ltd 2001:7f8:36::275b:0:1 349
DE-CIX rs1_mrs_ipv6 58717 Summit Communications Limited 2001:7f8:36::e55d:0:1 1193
DE-CIX rs1_nyc_ipv4 9498 Bharti Airtel Limited 206.82.104.130 17062
DE-CIX rs1_nyc_ipv6 9498 Bharti Airtel Limited 2001:504:36::251a:0:1 2495
DE-CIX rs2_dxb_ipv4 3356 Century Link 185.1.8.41 21
DE-CIX rs2_dxb_ipv4 8220 COLT Telecom Group plc 185.1.8.60 6823
DE-CIX rs2_dxb_ipv4 9498 Bharti Airtel Limited 185.1.8.51 3037
DE-CIX rs2_dxb_ipv6 8220 COLT Telecom Group plc 2001:7f8:73::201c:0:1 771
DE-CIX rs2_fra_ipv4 9498 Bharti Airtel Limited 80.81.196.112 9681
DE-CIX rs2_fra_ipv4 9498 Bharti Airtel Limited 80.81.194.250 9144
DE-CIX rs2_fra_ipv4 18001 Dialog Axiata PLC 80.81.192.114 241
DE-CIX rs2_fra_ipv4 35753 Integrated Telecom Company (ITC) / Salam.sa 80.81.192.26 281
DE-CIX rs2_fra_ipv4 35753 Integrated Telecom Company (ITC) / Salam.sa 80.81.194.9 105
DE-CIX rs2_fra_ipv4 58717 Summit Communications Limited 80.81.192.208 345
DE-CIX rs2_fra_ipv6 9498 Bharti Airtel Limited 2001:7f8::251a:0:2 5656
DE-CIX rs2_fra_ipv6 9498 Bharti Airtel Limited 2001:7f8::251a:0:1 3765
DE-CIX rs2_fra_ipv6 35753 Integrated Telecom Company (ITC) / Salam.sa 2001:7f8::8ba9:0:3 64
DE-CIX rs2_fra_ipv6 35753 Integrated Telecom Company (ITC) / Salam.sa 2001:7f8::8ba9:0:4 16
DE-CIX rs2_fra_ipv6 58717 Summit Communications Limited 2001:7f8::e55d:0:1 86
DE-CIX rs2_ist_ipv4 6939 Hurricane Electric 185.1.48.16 89066
DE-CIX rs2_ist_ipv6 6939 Hurricane Electric 2001:7f8:3f::1b1b:0:1 60337
DE-CIX rs2_mrs_ipv4 9498 Bharti Airtel Limited 185.1.47.7 9148
DE-CIX rs2_mrs_ipv4 10075 Fiber Home Global Ltd 185.1.47.145 663
DE-CIX rs2_mrs_ipv4 30990 DJIBOUTI TELECOM S.A. 185.1.47.25 709
DE-CIX rs2_mrs_ipv6 9498 Bharti Airtel Limited 2001:7f8:36::251a:0:1 3765
DE-CIX rs2_mrs_ipv6 10075 Fiber Home Global Ltd 2001:7f8:36::275b:0:1 349
DE-CIX rs2_mrs_ipv6 58717 Summit Communications Limited 2001:7f8:36::e55d:0:1 1193
DE-CIX rs2_nyc_ipv4 9498 Bharti Airtel Limited 206.82.104.130 17067
DE-CIX rs2_nyc_ipv6 9498 Bharti Airtel Limited 2001:504:36::251a:0:1 2495
DE-CIX rs2-bom-v4 3303 AS3303 - Swisscom (Switzerland) Ltd 103.27.170.87 2490
DE-CIX rs2-bom-v6 3303 AS3303 - Swisscom (Switzerland) Ltd 2401:7500:fff6::87 452
LINX rs1-in2-lon1-linx-net-v4 9498 Bharti Airtel Ltd 195.66.226.204 12071
LINX rs1-in2-lon1-linx-net-v6 9498 Bharti Airtel Ltd 2001:7f8:4::251a:2 5905
LINX rs2-in2-lon2-linx-net-v4 16637 MTN GlobalConnect Solutions LTD 195.66.236.18 1962
LINX rs1-in2-lon1-linx-net-v4 9583 Sify Technologies Ltd 195.66.226.6 1632
LINX rs1-in2-lon1-linx-net-v4 17494 Bangladesh Telecommunications Company Limited(BTCL) 195.66.226.78 157

Note:

  1. The impact here varies from a few hours to weeks. The above table does not reflect that.
  2. Routes going off from IXP aren’t necessarily a bad thing. Reduction in routes does not mean loss of connectivity because there will always be alternate (less direct) paths between the networks.

MRT dumps

Let’s look at updates from RIPE RIS RRC12 in Frankfurt. Just the size of the MRT update files gives the hint:

4.5M    updates.20250905.2200.gz
3.6M    updates.20250905.2205.gz
3.4M    updates.20250905.2210.gz
3.7M    updates.20250905.2215.gz
3.7M    updates.20250905.2220.gz
3.5M    updates.20250905.2225.gz
4.8M    updates.20250905.2230.gz
4.9M    updates.20250905.2235.gz
4.3M    updates.20250905.2240.gz
9.0M    updates.20250905.2245.gz
14M     updates.20250905.2250.gz
8.3M    updates.20250905.2255.gz
4.1M    updates.20250905.2300.gz
3.7M    updates.20250905.2305.gz
3.6M    updates.20250905.2310.gz
3.7M    updates.20250905.2315.gz
3.6M    updates.20250905.2320.gz
3.8M    updates.20250905.2325.gz
4.0M    updates.20250905.2330.gz
3.7M    updates.20250905.2335.gz
3.4M    updates.20250905.2340.gz
3.5M    updates.20250905.2345.gz
3.4M    updates.20250905.2350.gz
3.4M    updates.20250905.2355.gz

A detailed analysis of prefixes having withdrawal and re-announcement gives a clue on who is impacted.


What about transit-free tier 1 networks?

As stated earlier, we cannot use these methods on transit-free tier 1 networks. Their route announcement is mostly consistent unless they suffer a massive failure, taking down routers or entire transport in a given region. For detecting issues within them, I think only hints can be announced from their downstream side. E.g. looking at routes tagged with EU or APAC customer BGP community besides just spraying measurement traffic to destinations on those networks.