Most of the routing incidents that make the news get described as hijacks. A good share of them are actually leaks, and the difference matters because the two have different causes, different signatures, and different defenses.

A hijack is usually someone announcing address space they don't hold. A leak is usually someone announcing space they legitimately learned about, to a network they shouldn't have announced it to. The first is often malicious; the second is almost always a filter that wasn't there.

This piece covers the mechanics of a leak, why they keep happening, how detection actually works, and what an operator can do both to avoid causing one and to find out quickly when their own routes get caught in someone else's.

What a route leak actually is

Routing on the internet follows commercial relationships as much as topology. A network has customers who pay it for transit, peers it exchanges traffic with at no charge, and upstream providers it pays. Which routes get announced to which of those parties is governed by convention: routes learned from one upstream generally shouldn't be re-announced to another, because doing so offers to carry traffic between two networks you have no business carrying.

A route leak is the violation of that convention, and RFC 7908 is worth reading for its taxonomy of the specific patterns these take. The classic case is a multi-homed network that accidentally announces routes learned from Upstream A to Upstream B. Suddenly it appears to offer transit between two large networks, and because the announcement is valid in every technical sense, traffic starts flowing through it.

The consequences follow from capacity. A network sized for its own traffic is now receiving some portion of the traffic between two much larger networks, so links saturate, latency climbs sharply, and packets get dropped. Traffic that should have taken a direct, well-provisioned path is instead squeezed through a much smaller one, and the affected prefixes see degradation or outright unreachability until the announcement is withdrawn.

Why route leaks happen

The proximate cause is nearly always missing or incorrect export filtering. A BGP session without an explicit outbound policy will happily announce everything in the routing table, and default configurations on some platforms are more permissive than operators expect.

Complexity and change are the aggravating factors. A network with one upstream is hard to leak from; a network with two upstreams, three peers, and an internet exchange connection has many more places where a policy has to be correct, and each new session is an opportunity for an inconsistency. Leaks frequently follow a configuration change, a maintenance window, or the addition of a new peer, which is worth knowing because it tells you when to be watching.

There's also a structural reason this persists: the network that leaks is often not the network that suffers most. A small operator's misconfiguration can degrade traffic between two large networks and their customers, and since the consequences land elsewhere, the incentive to invest in careful filtering is weaker than the harm would suggest. That asymmetry is much of why the industry has pushed toward automated filtering and third-party detection rather than relying on every operator's diligence.

How route leak detection actually works

Detection is fundamentally an external exercise. You cannot see a leak of your own prefixes from inside your own network, because your view of BGP is what your neighbors tell you, not what the rest of the internet is hearing.

The infrastructure that solves this is a network of vantage points. Projects and services collect live BGP data from routers and collectors in many places around the world, building a picture of what announcements look like globally rather than locally. That collected view is what makes anomalies visible.

The signals that indicate a leak are mostly comparative. An AS appearing in the path for a prefix it has never carried before is the primary one, particularly when that AS sits in a topologically implausible position, such as a small network appearing between two large transit providers. A sudden change in AS path length across many observers, or a prefix that suddenly appears to have a new transit provider it has no relationship with, are variations on the same theme.

For an operator, the practical form this takes is alerting. Register your prefixes with a BGP monitoring service, define what a legitimate path for them looks like, and receive a notification when an unexpected AS shows up in the observed path. That converts a problem you'd otherwise learn about from customer complaints into one you learn about from a monitoring alert.

What operators can do to avoid causing or spreading a leak

Explicit outbound filtering is the foundation, and it's the first of the actions MANRS asks participating networks to commit to. Every BGP session should have a policy defining exactly which prefixes get announced to that neighbor, built from prefix lists, AS path filters, or automation driven by Internet Routing Registry data. The goal is that an accidental leak is structurally impossible rather than merely unlikely, and IRR-based automated filtering is the approach that scales as sessions multiply.

Max-prefix limits are the cheap safety net. Setting a reasonable ceiling on how many prefixes you'll accept from a session means that if a peer leaks a full table at you, the session tears down instead of your network propagating the problem onward. It's a few lines of configuration that turns a potential incident into a logged event.

Route origin validation via RPKI catches an adjacent category. It won't detect a leak that preserves the correct origin AS, which is most of them, but it does catch announcements with the wrong origin, and the two mechanisms together cover meaningfully more than either alone.

There's also a newer piece worth knowing about. RFC 9234, published in 2022, moves relationship signaling into BGP itself: peers negotiate a role (provider, customer, peer, route server, or route server client) when the session opens, and an Only to Customer attribute marks routes learned from a provider or peer so they can't be propagated where they shouldn't go.

The useful property is that it catches leaks in-band rather than depending on every operator's manual policy being correct, and it allows detection at a distance rather than only at the point of the mistake. It isn't universally deployed yet, but it's the direction this problem is being solved from, and it's worth asking upstreams whether they support it.

What to do if you suspect your routes are being leaked

Confirm externally first. Check public looking glasses and BGP monitoring tools to see what the internet is actually hearing for your prefixes, since your own routers won't show you the problem. You're looking for an unexpected AS in the path and for how widely that path has propagated.

Then contact the offending network directly. Most operators publish NOC contact details through PeeringDB, and since the overwhelming majority of leaks are accidental, a specific and factual message tends to get a fast response. Include the prefixes involved, the AS path you're observing, and where you're observing it from; that's enough for a competent NOC to find their own misconfiguration quickly.

While waiting, look at what you control. If the leak is propagating to you through a particular upstream, your own filters and max-prefix settings determine whether you pass it along further. Announcing more specific prefixes can sometimes pull traffic back to the correct path as a temporary measure, though it's a blunt tool that adds routing table churn and is better treated as a short-term mitigation than a fix.

Afterwards, write down what happened. Leaks tend to recur from the same sources and through the same paths, and a short record of which prefixes were affected, which AS caused it, and which contact resolved it makes the next occurrence much faster to handle.

Wrapping up

Route leaks are mostly honest mistakes with disproportionate consequences, caused by filtering that wasn't strict enough and found by monitoring that watches from outside your own network.

The defensive work splits cleanly in two. To avoid causing one, filter outbound announcements explicitly, set max-prefix limits, and treat every new session, and every block of address space you announce, as a policy to get right. To find out quickly when one affects you, register your prefixes with an external monitoring service so you hear about it from an alert rather than from a customer.

Thanks for reading! If your network relies on its own BGP sessions, xTom offers IP transit alongside enterprise-grade dedicated servers, colocation, NVMe-powered KVM VPS through V.PS, shared hosting, and general IT services for whatever else your infrastructure needs.

Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.

Frequently asked questions about BGP route leak detection

What's the difference between a route leak and a route hijack?

A hijack is announcing address space you don't hold, and it's often deliberate. A leak is announcing legitimately learned routes to a network you shouldn't have announced them to, usually because an export filter was missing, and it's almost always accidental.

How long does a typical route leak last before it's caught?

Anywhere from minutes to hours, depending on how visible the disruption is and whether affected networks have monitoring in place. Operators with external BGP alerting typically find out in minutes; those relying on customer reports can take considerably longer.

Can RPKI prevent all route leaks?

No. RPKI validates which AS originated a prefix, and most leaks preserve the correct origin while inserting an extra network into the path. It catches wrong-origin announcements, so it's worth deploying, but it isn't a complete answer to leaks specifically.

How do I monitor my own prefixes for a potential leak?

Register them with a BGP monitoring service that collects data from many global vantage points and alerts you when an unexpected AS appears in the observed path. Monitoring from inside your own network can't detect this, since you only see what your neighbors tell you.

What should I do if I discover I'm the one who leaked routes?

Fix the export filter immediately to stop the announcement, then verify externally that the leaked paths have withdrawn. If the disruption was significant it's worth notifying affected peers, since a promptly acknowledged and corrected misconfiguration is generally handled with understanding.

Do route leaks only affect large networks?

No. Any network's prefixes can be caught in a leak, and small networks are frequently the ones causing them. The scale of disruption tracks how much traffic gets pulled onto the wrong path rather than the size of the network that leaked.