BGP Route Leaks Explained: Lessons from the SafeHost Incident

A BGP route leak happens when legitimate routes travel farther across the Internet than their routing policies intended, usually because of a configuration mistake in a network you don’t run. That external origin is what makes leaks hard to catch.

Teams watching only their own infrastructure see the symptoms first, like slow performance or unreachable services, and find the cause outside the firewall later.

This analysis is written for the NetOps, SRE, and ITOps teams that keep Internet-dependent services running. It walks through a real BGP route leak and belongs to a BGP security series.

What is a BGP route leak?

A route leak is the propagation of a BGP announcement beyond its intended scope, as defined in RFC 7908. That scope comes from the BGP import and export policies that ASes use to control which routes cross a session. A leak sends a route to a neighbor the policy meant to exclude.

A route leak differs from a route hijack, and the two call for different responses. The table below compares them.

BGP routing policies usually reflect commercial agreements between ASes, and they split into two categories: provider-to-customer and peer-to-peer. In a provider-to-customer relationship, the provider announces routes to all Internet destinations. The customer announces routes to its own networks and those of its customers.

In a peer-to-peer relationship, the two ASes exchange routes only to reach their respective networks and their customers’ networks.

In one common leak pattern, an AS re-announces a route it received from a provider or peer to another provider or peer. That sends the route beyond its intended scope. RFC 7908 defines several leak types, so this is one pattern, not the whole taxonomy.

Figure 1 shows a simple provider-to-peer leak. AS 5 is a customer of AS 4 and a peer of AS 3. AS 4 announces prefix P to AS 5, and AS 5 then leaks that route to its peer AS 3.

If AS 3 accepts the leaked route, other ASes such as AS 1 can be affected. AS 5 also becomes unintended transit between peer AS 3 and provider AS 4 for traffic headed to P.

Figure 1: An example of route leak

That shift changes both traffic flow and capacity. Traffic now crosses AS 5, which didn’t plan to carry it, so AS 5 handles load it wasn’t provisioned for.

Performance degradation is the most common consequence of a route leak. The leaking AS absorbs traffic it didn’t expect on links that may be under-provisioned for the volume. Some networks ignore the leaked routes, while others pick them as the best path, so impact varies by peer, prefix, and location.

A leak can also be deliberate. In one malicious scenario, an operator diverts traffic to inspect it before forwarding it to the legitimate destination. It still counts as a leak because the origin stays legitimate, unlike a hijack’s unauthorized origin announcement.

The affected traffic is often traffic your users depend on. When a path reroutes through a network that shouldn’t carry it, the result looks like an unexplained outage or slowdown. From inside your own systems, that cause stays hidden.

Seeing the leak means watching BGP and Internet routing from the outside in.

LogicMonitor Digital Experience fills that gap by extending visibility to the Internet path your traffic actually takes.

A closer look at a BGP route leak: the SafeHost incident in Switzerland

The SafeHost incident of June 6, 2019, is a documented example of a large BGP route leak, and this is a retrospective analysis first published in 2020. It shows how a single leak spread across the Internet within hours.

Why this still matters

This still matters because BGP runs on a trust model, where networks largely accept what their neighbors announce. That model hasn’t changed, and neither has the need for distributed, external visibility, so the SafeHost lessons still apply today.

The incident drew wide coverage for two reasons: the Swiss colocation provider SafeHost was the source, and China Telecom carried the leak onward. China Telecom wasn’t the root cause.

The leak began when SafeHost (AS21217) announced more than 40,000 IPv4 routes to its provider China Telecom (AS4134). SafeHost had learned those routes from other peers and providers. The announced routes covered prefixes already in the global BGP table and prefixes that weren’t.

China Telecom accepted the routes and propagated them to its neighbors, which is how the SafeHost leak spread globally.

SafeHost route leak diagram and summary

Public route collectors captured the SafeHost leak, and their data underpins this analysis. The University of Oregon Route Views Project and RIPE NCC’s Routing Information Service each run collectors that recorded the leaked routes. Both stored the routes in MRT format and published them.

Figure 2: SafeHost leak summary

Table 1 shows three examples of leaked routes, each announced to the collectors by a different collector peer.

Routes involved in the SafeHost BGP leak

Table 1: Sample AS paths from the SafeHost leak

Each AS_PATH shows China Telecom (AS4134), then SafeHost (AS21217), then Level3 (AS3356) and other SafeHost providers.

SafeHost prepended its own AS number several times in the AS_PATH of the leaked routes. Prepending lengthens the path, which normally makes a route less preferred in BGP path selection, so it stands out here. We can observe the prepending without inferring what the SafeHost administrator intended. Public BGP data from before the leak shows no BGP connection between AS4134 and AS21217.

To measure how far the leak spread, we counted how many peers announced at least one leaked route to a collector. Peers don’t all send the same volume of BGP data, so we counted only those announcing the full routing table, called FRT peers.

FRT peers announcing leaked routes

Figure 3: The amount of IPv4 FRT peers announcing to the collector at least one leaked route

Almost every FRT peer announced at least one leaked route to the collector, as Figure 3 shows. A single distant leak reached nearly every vantage point, so checks limited to your own network understate the exposure.

The leak didn’t spare any Internet region. It affected FRT peer routing regardless of the region each peer belonged to. We mapped each AS to its Regional Internet Registry (RIR) using the IP to ASN mapping from Team Cymru.

Internet region distribution of FRT peers announcing

Figure 4: Internet region distribution of FRT peers announcing to the collector at least one leaked route

Because the impact spanned every region, monitoring from a single location would have missed most of it. Monitoring from several regions is a reliable way to see a leak’s full footprint.

Reach alone doesn’t show how many leaked routes each peer saw. To measure severity, we counted how many leaked routes each FRT peer announced to its collector, which separates heavily affected peers from lightly affected ones. Figure 5 shows the distribution of origins, and Figure 6 shows the distribution of subnets each peer saw in a leaked route.

Only 20% of FRT peers announced leaked routes involving more than 100 origin ASes and more than 2,000 subnets. Peers closest to China Telecom, or directly connected to it, announced the most leaked routes. One China Telecom client announced leaked routes involving more than 3,000 origins and more than 25,000 subnets.

Number of origins per FRT peer

Figure 5: CCDF number of origins involved per FRT peer

Presence and severity are separate measures. Most peers saw modest exposure, so counting how many routes each vantage point sees matters as much as whether it sees the leak at all.

Number of subnets per FRT peer

Figure 6: CCDF of subnets involved per FRT peer

Proximity to the leaking network predicted severity. Peers near China Telecom absorbed far more of the leak, so during a live incident you’d watch the networks adjacent to the source most closely.

The SafeHost leak lasted almost four hours and affected more than 6,000 origin ASes. Figure 7 traces how the count of affected origins changed over that window, with several peaks. At 10:40 am, more than 2,500 origins were affected at once.

Number of origins affected

Figure 7: Evolution of the number of origins affected by the leak during time

Impact fluctuated throughout the event rather than holding steady. A point-in-time check could have missed the 10:40 am peak, which is why continuous monitoring is more likely to capture the worst moments.

The affected origins included ASes hosting WhatsApp and Microsoft, plus ISPs, banks, and content delivery networks. When routes to services like these shift, the fallout reaches real users and revenue.

For the businesses behind those origins, the downstream effects can include:

• Failed or delayed transactions when routes to a bank reroute or slow down.
• SaaS applications that turn slow or unreachable, stalling the workforce that relies on them.
• Degraded content delivery that users experience as buffering, timeouts, and slow page loads.
• SLA breaches and long incident triage while teams hunt for a cause outside their own network.

Detection and response for a BGP route leak

You detect a BGP route leak by comparing internal telemetry against external vantage points and watching for a few signals. During SafeHost, an engineer would have seen their own prefixes suddenly reachable through an AS_PATH containing China Telecom and SafeHost. Watch for these signs:

• Sudden AS-path changes while the legitimate origin for a prefix stays the same.
• Abnormal announcements that touch many prefixes or span multiple regions at once.
• Latency, reachability, and application availability degrading at the same time.
• A gap between healthy internal device telemetry and degraded results from external vantage points.

Once the pattern is clear, scope the impact before escalating. Use external measurements to identify which users, services, and providers are affected, then confirm that your own systems are healthy so you can rule out an internal fault.

Different data sources answer different questions during triage. Route collectors show where the bad announcement spread. Distributed external monitoring shows which regions and networks saw the leaked path, while reachability and performance measurements show the customer impact. Internal infrastructure telemetry helps rule out internal causes and shortens the “is it us or the Internet?” question.

When you escalate to a transit provider or ISP, bring evidence they can act on: the affected prefixes, the observed AS paths, timestamps for when the change appeared, and the vantage points that saw it.

What the SafeHost leak teaches us about Internet visibility

The main operational lesson from SafeHost is that route leaks are hard to manage from inside an affected network. None of the 6,000-plus affected origins caused the leak, and few could do anything to stop it, because their traffic was rerouted by decisions made in other networks.

That points to a hard limit on prevention. An affected organization generally can’t stop a third party’s routing policy error directly. Its practical advantage is earlier detection, faster impact assessment, and quicker escalation to the provider that can fix it.

Routing safeguards have improved since 2019. RPKI-based Route Origin Validation lets networks reject announcements from unauthorized origins, and RFC 9234 defines BGP roles that help catch common leak patterns. These measures reduce risk, yet they don’t remove the need for external monitoring, because a route leak can preserve the legitimate origin and slip past origin validation.

How outside-in monitoring helps

Outside-in monitoring helps by watching BGP routing, reachability, and user experience across the Internet path, which is where a leak like SafeHost appears first. A team relying only on internal telemetry would have seen degraded performance during SafeHost with no clear cause.

Applied to a case like SafeHost, LogicMonitor Digital Experience watches BGP announcements, withdrawals, and AS paths, so teams can detect leaks and hijacks as they propagate and observe global routing changes. It also correlates those routing shifts with reachability and performance data.

Connecting a routing event to the specific services and users it affects depends on the telemetry you’ve configured and the correlation you set up across those signals.

FAQs