Yesterday's BGP Route Leak — How a Small ISP Rerouted the Internet

Yesterday morning, a sizeable chunk of the internet took a wrong turn through a metals company in Pennsylvania. That's not a metaphor. For roughly two hours starting around 10:30 UTC on June 24, traffic destined for Cloudflare, Amazon, Facebook and others was routed through networks that had no business carrying it — and in many cases simply couldn't, so the traffic died. Cloudflare reportedly lost around 15% of its global traffic at the peak. Sites behind the affected networks were unreachable for many users while being perfectly fine for others.

Nobody attacked anything. The internet's routing system did exactly what it was built to do — which is the problem. If you run anything on the web, yesterday is worth understanding, because it's a category of outage that originates entirely outside your infrastructure and outside your control.

What actually happened

The chain of events, as pieced together from routing data and the reports published so far:

• A small ISP ran a BGP "route optimizer." DQE Communications, a regional provider in Pennsylvania, used software that splits routes into smaller, more-specific prefixes to steer traffic over preferred internal paths. Those synthetic routes are meant to stay inside the network.
• They leaked to a customer. The optimized routes were announced to one of DQE's customers — Allegheny Technologies, a steel company — whose network passed them along to its other upstream provider.
• That upstream was Verizon — and Verizon accepted them. This is the step that turned a local mistake into a global incident. Verizon, one of the largest transit networks in the world, propagated the leaked routes to the wider internet without filtering them.
• More-specific always wins. BGP's rule is simple: given two routes to the same destination, routers prefer the more specific prefix. The leaked routes were more specific than the legitimate ones — so routers across the internet dutifully sent traffic for Cloudflare, Amazon and others toward a path that funneled through a steel company's network connection. That link did what any small pipe does when the internet shows up: it drowned.

Around two hours later, the leak was withdrawn and routes converged back to normal. Two hours is a long outage — and for affected users it was total.

BGP runs on trust — still

The Border Gateway Protocol is how the internet's ~65,000 independent networks tell each other which IP addresses they can reach. It dates to an era when the internet was small enough that everyone roughly knew everyone, and it shows: at the protocol level, announcements are believed. If a network says "I have a route to these addresses," its neighbors accept it unless they've configured filters saying otherwise.

The safety net is supposed to be exactly those filters — each network vetting what it accepts from customers and peers, using registries of who legitimately holds which prefixes. Small networks get this wrong regularly, and the blast radius stays small. What made yesterday different was a tier-1 transit provider accepting and re-announcing thousands of leaked, more-specific routes from a customer. Filtering at that boundary — a prefix limit alone would have helped — is table stakes for a network of that size, and it evidently wasn't there.

There is a cryptographic fix in progress: RPKI (Resource Public Key Infrastructure) lets address holders sign statements about which networks may originate their prefixes, and lets routers automatically reject invalid announcements. Cloudflare and a handful of others have been vocal adopters; some large carriers, including AT&T, have begun dropping RPKI-invalid routes this year. But adoption across the industry remains thin — a minority of routes are signed, and fewer networks validate. Until that changes, incidents like yesterday's remain a structural feature of the internet, not a freak event.

The monitoring lesson: "down" is not one thing

Here's the part that matters even if you never touch a router. During yesterday's leak, a site behind an affected network was, simultaneously:

• Completely unreachable for users whose traffic followed the poisoned routes,
• Perfectly fine for users whose providers never accepted the leak, and
• Perfectly fine from inside its own datacenter — servers up, dashboards green, load balancers passing health checks.

That last point deserves a moment. Every internal signal said healthy, because nothing internal was broken. The failure lived in the path between your users and your infrastructure — and the only way to see a path failure is to stand where your users stand, in several different places at once.

This is the strongest argument for multi-location external monitoring:

• One probe location can't tell you much. If your single monitoring node sits on a network that accepted the leaked routes, you get a false "everything is down." If it sits on a clean network, you get a false "everything is fine." Either way you're blind.
• Multiple locations turn confusion into diagnosis. Three of five regions failing to reach you while two succeed is a distinctive signature — it says routing or network path, not your server. That single fact changes your entire incident response: you're checking BGP looking glasses and your providers' status pages instead of restarting services that were never broken.
• It changes what you tell customers. "Some networks are currently unable to reach us due to an internet routing incident; our systems are operational" is a very different message from a generic apology — and you can only send it if your monitoring can actually distinguish the two cases.

# The view from one network is not the view from the internet.
# Yesterday, these could disagree for two hours:
curl -sI https://yoursite.com   # from your office: 200 OK
curl -sI https://yoursite.com   # from a leaked-route network: timeout

What you can actually do

You can't fix BGP from your web app, but you're not powerless either:

• Monitor from multiple, geographically distinct locations — and pay attention to partial failure patterns, not just up/down.
• Ask your providers about routing hygiene. Do your transit and hosting providers filter customer announcements? Have they deployed RPKI origin validation? These questions are becoming fair game in vendor conversations.
• Have a status page and a comms plan for outages that aren't your fault — because your users can't tell the difference, and "not our fault" without proof reads as an excuse.
• Log the timeline. Multi-location check history gives you the start, end and geographic scope of an incident — exactly what you need for the postmortem and the SLA conversation.

Standing where your users stand

Yesterday's leak was resolved by engineers at other companies, on infrastructure you'll never touch — and the next one will be too. What's in your control is knowing, within a minute or two, that it's happening, where it's happening from, and whether the problem is your stack or the internet between you and your users. CompleteStatus runs your uptime checks from multiple locations and shows you exactly which vantage points can and can't reach you, with alerting the moment a confirmed failure appears — see everything it checks, or create a free account and get a second, third and fourth opinion on your uptime. On days like yesterday, that's the difference between diagnosing and guessing.