On August 18, 2026, a technical incident at M9, one of Moscow’s major telecommunications hubs, caused widespread disruptions across Russian internet infrastructure.

M9 has long been considered an important part of Russia’s internet infrastructure. But how significant is its role in practice? The outage gave us a rare opportunity to put a number on that dependency. Using BGP visibility data, we reconstructed the incident and measured how many autonomous systems were affected — and how severely.

What happened on August 18, 2026

On the evening of August 18, a power outage affected several districts in southwest Moscow, including the area where M9 is located. Multiple sources confirmed that parts of the M9 facility lost power, with the problem reportedly originating in the external power infrastructure rather than the data center itself.

According to Rostelecom, Russia’s largest telecom operator, backup power sources, including diesel generators, were activated while the electricity supplier worked to restore the main power supply. However, the backup systems were apparently unable to provide enough power to keep all the equipment at the facility running.

The effects quickly became visible beyond the facility. Internet providers reported connectivity problems, while users across Russia experienced difficulties accessing websites and online services. Reg.ru, one of Russia’s largest hosting and domain-registration providers, attributed problems affecting its infrastructure to the power disruption at a major communications hub. At the same time, aggregate traffic exchanged through MSK-IX fell sharply.

What is M9?

M9, formally Moscow Long-Distance Telephone Exchange No. 9 (MMTS-9), is a major telecommunications facility at 7 Butlerova Street in Moscow. Originally built as a telephone exchange in the late 1970s, it already had much of the infrastructure that would later make it attractive to internet providers: telecommunications lines, technical space, power infrastructure, and, crucially, the presence of multiple network operators.

As commercial internet access developed in Russia, M9 became a natural place for those networks to interconnect. In 1995, representatives of seven providers agreed to establish a platform for exchanging IP traffic, and the first node of the Moscow Internet Exchange opened at M9 that November. That exchange eventually became MSK-IX.

From there, M9 benefited from a simple network effect: the more operators established a presence there, the more useful it became for others to do the same. By 2017, MSK-IX described M9 as Russia’s most popular location for inter-operator connectivity, with more than 440 providers present at the facility.

One distinction is important here: M9 and MSK-IX are not the same thing. M9 is a physical telecommunications facility, while MSK-IX is an internet exchange with a geographically distributed infrastructure. Today, MSK-IX operates across 45 locations in 10 Russian cities, with M9 being just one of its Moscow sites.

So the incident at M9 did not mean that MSK-IX, let alone the Russian internet as a whole, went offline. However, what makes M9 important is the concentration of logically independent network infrastructure at a single physical location. The August 18 incident gave us an opportunity to measure just how significant that concentration is.

Measuring the blast radius of the M9 outage

So how much of the internet infrastructure was actually impacted by the M9 failure?

Our analysis identified 467 autonomous systems whose BGP visibility changed significantly in a way consistent with the M9 incident. Together, they accounted for 2,546 affected prefixes. Most of these ASes — 371, or about 79% — were registered in Russia, but the impact extended beyond the country.

These 467 ASNs did not all experience the incident in exactly the same way. We identified two closely related waves: a core group of 360 ASNs, whose visibility began dropping at around 17:15–17:23 UTC (20:15–20:23 MSK), and a secondary group of 107 ASNs, affected slightly earlier, at around 17:00–17:10 UTC (20:00–20:10 MSK).

Both groups recovered at roughly the same time, around 17:55–18:15 UTC (20:55–21:15 MSK), and their visibility losses followed the same characteristic pattern.

The extent of impact on individual networks

The impact also varied considerably in scope. For some large networks, the incident touched only a small fraction of their advertised address space. For others, virtually the entire network disappeared from BGP view. For 165 of the 467 ASNs — 35% — at least 90% of their own prefixes were affected. In other words, for more than a third of the networks we linked to the incident, the M9 failure affected almost their entire advertised footprint.

For example, AS2683 (SINP MSU) was among the networks hit almost entirely. One of its prefixes, 2a13:22c0::/29, was visible to around 481 BGP collector peers before the incident. At 17:13 UTC (20:13 MSK), its visibility began to collapse, falling to almost zero within minutes. It remained at that level for roughly 35 minutes before recovery began at around 17:55 UTC (20:55 MSK).

At the other end of the spectrum was AS12389 (Rostelecom), a much larger network originating around 1,900 prefixes. Only one of them — 84.42.108.0/24 — or about 0.05% of the network’s advertised footprint, was affected. Its visibility followed essentially the same pattern: it dropped at 17:19 UTC (20:19 MSK) and began recovering at 17:54 UTC (20:54 MSK).

These two cases illustrate why the sheer number of affected ASNs does not capture the full impact of the incident. The same M9 failure could affect virtually everything an ASN advertised or only a tiny fraction of a much larger network.

How we separated the M9 incident from other BGP events

Not every loss of BGP visibility during this time period was necessarily caused by the M9 incident. To separate the outage from unrelated events, we first looked for prefixes that had substantial visibility before the incident — at least 100 collector peers at 16:00 UTC — and had lost more than half of that visibility by 17:30 UTC. This initial filter produced 4,710 prefixes.

We then reconstructed per-minute visibility timelines for the affected networks and compared when their visibility dropped, when it recovered, and how deep the drop was. Networks with similar patterns were grouped together, allowing us to isolate the two waves associated with the M9 incident from other BGP events occurring around the same time.

Amazon’s AS16509 provides a useful example of why this step matters. Of the more than 21,000 prefixes originated by this network, 43 passed our initial filter. One of them showed a near-total visibility loss and recovered at around 17:57 UTC (20:57 MSK), seemingly matching the M9 incident. But its visibility had started falling at 16:54 UTC (19:54 MSK) — roughly 20 minutes before the main M9-related wave. We therefore classified it as a separate, coincidental event rather than part of the M9 outage.

This is how we narrowed the much larger initial set of visibility losses down to the 467 ASNs whose timing and behavior were consistent with the M9 incident.

How important is M9?

The August 18 outage provides a fairly clear answer to the question we started with. M9 is not a single point of failure for the Russian internet: MSK-IX is geographically distributed, and the incident did not take either the exchange or the Runet as a whole offline. But an incident at this one physical location still affected 467 autonomous systems, and for 165 of those — 35% of the ASNs affected by the outage — at least 90% of their advertised prefixes were impacted.

The scale and depth of these disruptions demonstrate the consequences of concentrating logically independent network infrastructure at a single physical location. While the M9 outage did not bring the Russian internet down, it showed just how much network infrastructure can depend on what happens inside a single building.