Inside a Shutdown: BGP Evidence from an Operator Who Was There

On 18 July 2024, operators across Bangladesh began withdrawing their BGP prefixes in sequence. Within hours, 170 million people lost internet access and the country vanished from the global routing table.

The event was widely reported as a deliberate, government-ordered shutdown. I run the network at one of the operators that went dark that night, giving me a direct view of how the withdrawal unfolded. Here, I compare that experience with the public routing data to examine what the evidence can and cannot tell us about the event.

The data and its limits

Before we dive into the story, a note on the data is in order. Public routing data reveals when prefixes appeared and disappeared, but not why. To reconstruct the sequence of events, I combine several public measurement sources with direct operational observations from inside AS63526.

The primary source is RIPE RIS data which is available via RIPEstat. This provides BGP routing history pulled via API for AS63526 and AS24389 across the shutdown and restoration periods. (Note that RIPE RIS records routing history in 8-hour buckets, so it cannot determine the precise timing of events that occur close together.)

Cloudflare Radar provides AS-level traffic and announced IP space, which is what gives the operator-by-operator timing. IODA contributes three independent signals (BGP, active probing, darknet) for country-level confirmation. OONI covers platform-level blocking in the days before the full outage, with the caveat that probe gaps during the outage are themselves evidence of it. The overall timeline is consistent with independent reporting from Internet Society Pulse and Cloudflare.

Two other source choices need stating upfront. I did not do RouteViews cross-validation. That is a genuine gap, though the withdrawal events are independently visible in Cloudflare Radar. My direct observations are limited to AS63526. Everything I describe inside that network is based on firsthand observation. Everything about other networks is inferred from public measurement data, and I flag it as such.

Inside AS63526

On the evening of 18 July 2024, at around 20:45 local time (14:45 UTC), we started pulling AS63526’s (Carnival Internet) prefixes. There was no script and no automation. Forty-seven prefixes, 46 IPv4 /24s and one IPv6 /48 were withdrawn the same way any operator would do it by hand: session by session, router by router, checking after each change.

The strange part was not the procedure. These are the same commands we run for routine maintenance every week. Nothing in the protocol, and nothing in our tooling, distinguishes an ordinary cleanup from disconnecting a network from the world. That ordinariness stayed with me, and it's one of the reasons I wanted to write this article.

RIPEstat records all 47 prefixes in the bucket ending 15:59:59 UTC, seen by 358 RIS peers on IPv4 and 363 on IPv6. This is the only part of the shutdown I can describe from first-hand observation. It also serves as a known reference point: I know exactly what one manual, sequential withdrawal looks like from both the router CLI and RIPEstat. I use that reference when interpreting other operator patterns in the public routing data.

What the routing table recorded

The outage did not happen all at once. It developed over roughly 20 hours, operator by operator, each withdrawal independent of the others.

The table provides the detailed chronology. Figure 1 shows the same events laid out on a common timeline, making the staggered sequence of operator withdrawals easier to see at a glance.

For more details, I focused on the RIPEstat records for two operators. Carnival Internet (AS63526) withdrew 47 prefixes (46 IPv4 /24s and one IPv6 /48), all appearing in the RIPEstat bucket ending 15:59:59 UTC and observed by 358 IPv4 and 363 IPv6 RIS peers. Grameenphone (AS24389) withdrew 138 prefixes, with 130 appearing in the same bucket and the remaining eight IPv6 prefixes not until the bucket ending 07:59:59 UTC on 19 July.

Taken together, the observations from RIPEstat and Cloudflare Radar show a consistent pattern across the operators examined.

Four signals in the data

Each of the four characteristics below has an innocent explanation on its own. Together they are harder to explain away. Before looking at each signal, one qualification applies throughout: everything below is consistent with coordinated action across operators. None of it proves coordination, and technical causation cannot be excluded on the basis of routing data alone.

Signal 1: Sequential withdrawal across a ~20-hour window

Technical failures start somewhere and cascade. The Bangladesh data shows the opposite. Per RIPEstat and Cloudflare Radar, Grameenphone (AS24389) went dark at 19:30 UTC on 17 July. Banglalink (AS25245) followed at 20:15. Robi Axiata (AS24432) between 00:30 and 01:00 on 18 July - Cloudflare Radar recorded full connectivity loss as of 01:00 UTC - and Earth Telecom (AS58715) around 12:00. Each looks independent, and no shared upstream failure is visible in the routing data. Our own withdrawal at 14:45 UTC, the one point I can verify from the inside, fits the same shape.

Signal 2: The straggler prefixes at AS24389

Eight of Grameenphone’s IPv6 prefixes, all /44 blocks in 2400:c600::, were not withdrawn in the main window. They sat in the global routing table for roughly 16 hours before being pulled at 07:59:59 UTC on 19 July (RIPEstat). Two readings fit the data equally well: prefixes missed on a manual checklist and cleaned up later, or a partially automated run that handled 130 of 138 and needed manual follow-up. Either way there was a human in the loop at some stage, but the data cannot tell us which stage.

Signal 3: IODA three-signal confirmation

IODA measures outages three independent ways: BGP routing signals, active probing, and darknet traffic. On 18 July all three went to near-zero for Bangladesh at the same time. For a measurement artefact to produce that, three unrelated systems would have to fail at once. Taken together, these provide the strongest evidence in this analysis that the outage was real, complete and country-wide, rather than a partial disruption that only appeared more extensive from some vantage points.

Signal 4: Asymmetric restoration

The fact that the restoration looked nothing like the shutdown is itself a signal. (AS63526 restoration data below is direct observation; AS24389 is from RIPEstat.)

The withdrawal was fast and near-total. The restoration was neither. Broadband came back first while mobile took another five days. Mobile networks do carry deeper dependencies. HLR, MSC and packet gateways all have to come up in order, so a purely technical explanation survives here too. But when infrastructure recovers from a failure, things come back in the order they get fixed. A five-day gap that splits cleanly by access technology, across multiple operators, is not that. The peer-count instability between waves points to prefixes being re-announced and adjusted incrementally rather than restored in one pass.

What this data cannot establish

There are certain limitations in the public data we have to keep in mind:

• The instruction chain behind the withdrawals. No written regulatory order has been publicly disclosed.
• IIG-level bandwidth restriction. This is inferred from IODA's active-probing signal and the wider operational context, not directly observed in BGP data. BGP withdrawals alone can produce near-complete reachability loss; the probing results are also consistent with additional transit-level restrictions. I therefore treat this as an inference from converging signals rather than an established fact.
• Precise withdrawal timing within each RIPEstat 8-hour observation window. Operators appearing in the same bucket may have withdrawn hours apart.
• Actions within mobile networks. Throttling or other changes inside mobile infrastructure are not visible through external BGP or traffic measurements.
• Mobile-network internal actions. Throttling inside mobile infrastructure is invisible to external BGP and traffic measurement.

Two additional data sources would have strengthened this analysis, and I would recommend both for similar work. RouteViews would provide an independent check on prefix-level withdrawal timing, while RIPE RIS Live would help reconstruct events within each RIPEstat observation window instead of relying on bucket endpoints.

How the Bangladesh case compares

Operator-by-operator shutdowns are not unique to Bangladesh. Iran's November 2019 blackout rolled out across ISPs over roughly five hours, cellular operators first (see notes [1],[2]), and Myanmar’s February 2021 shutdowns hit multiple operators under a ministry directive that Telenor later disclosed publicly (see [4],[5]).

What I have not found anywhere else in public reporting is prefix-level straggler evidence of the kind in Signal 2, or an operator-granular BGP timeline anchored by a first-hand account.

That, not the sequencing, is what makes the Bangladesh record unusual. The table below is based on the referenced public documentation; "not publicly documented" means I found no public analysis of that signal, not that it was absent.

What makes the Bangladesh data unusual is not the event. It is how much of it is visible at the routing layer, and the fact that the measurement infrastructure recording it was already running before the event began. Nothing had to be set up.

Three takeaways for the community

Measurement

RIPEstat’s 8-hour buckets were fine for reconstructing the event afterwards. They are useless for catching it while it happens. RIPE RIS Live streams BGP updates in real time and already exists; it should be the default for outage monitoring, not something you reach for after the fact. Automated cross-AS restoration-pattern detection would also make the kind of wave analysis in Signal 4 reproducible instead of manual.

Routing security

Bangladesh has 98% RPKI ROA coverage, among the highest in South Asia (I documented the baseline on the APNIC Blog in November 2025). But ROA coverage and ROV enforcement are different things. ROV filters invalid announcements. It is not designed to stop an operator withdrawing its own prefixes, and it can’t. What ROV enforcement at the IXP level does provide is a cryptographically auditable environment for routing changes. Without it, the 18 July withdrawals left no trace in the routing security layer. The only record comes from measurement tools and accounts like this one. IXPs and transit providers in high-ROA regions should state publicly whether they enforce. The coverage number means little without that.

Resilience

Only 7.6% of Bangladesh’s networks peer locally through domestic IXPs (same APNIC Blog baseline). During the outage, the networks that peered through BDIX kept talking to each other. BDIX traffic crosses no international link and has no IIG dependency, so it simply kept running. Everything that depended on international transit went dark. This is not specific to Bangladesh: any economy where most domestic traffic routes internationally before returning has no resilience layer below BGP. More local peering does not change what BGP can do, but it does mean more of the network survives events that operate at the BGP and international-transit layer.

Closing

BGP is a mechanism for connecting networks. The same routing infrastructure, using entirely standard operational procedures, can disconnect a country. The routing table records what happened. It does not record why. Making that record more complete, with finer-grained timing, cryptographic auditability, and more resilience below the international transit layer, is worth the community’s attention.

Notes:

* A complete list of RIPEstat API queries used for this analysis, the full prefix list for AS63526 (47 prefixes as of 18 July 2024), and other data sources are available here.

[1] IODA and OONI, “Iran’s nation-wide Internet blackout: Measurement data and technical observations”, November 2019. ioda.inetintel.cc.gatech.edu/reports/irans-nation-wide-internet-blackout-measurement-data-and-technical-observations

[2] Amnesty International, The Hertie School and IODA, “A web of impunity: The killings Iran’s internet shutdown hid”, 2020. iran-shutdown.amnesty.org

[3] ARTICLE 19, “Tightening the Net: Iran’s November 2019 internet shutdown”, 2020. article19.org/resources/report-on-irans-internet-shutdown

[4] OONI, “Myanmar: Data on internet blocks and internet outages following military coup”, March 2021. ooni.org/post/2021-myanmar-internet-blocks-and-outages

[5] Internet Society Pulse, shutdown documentation for Myanmar, Pakistan, India and Bangladesh. pulse.internetsociety.org/shutdowns

[6] NetBlocks, “Internet disrupted in Pakistan amid arrest of former PM Imran Khan”, May 2023. netblocks.org

[7] Human Rights Watch, “No Internet Means No Work, No Pay, No Food: Internet Shutdowns Deny Access to Basic Rights in Digital India”, June 2023. hrw.org/report/2023/06/14

[8] SFLC.in Internet Shutdowns Tracker, Jammu and Kashmir. internetshutdowns.in

[9] Cloudflare, “Forced offline: the Q3 2024 Internet disruption summary”. blog.cloudflare.com/q3-2024-internet-disruption-summary

[10] Access Now, #KeepItOn campaign documentation, 2024. accessnow.org