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:

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:

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.