BGP lets independently operated networks exchange routes to IP prefixes. Each network, called an autonomous system, applies its own routing policy. A reachable web server can still become inaccessible when other networks select a broken or overloaded path to it.
A route leak happens when a network propagates a learned route beyond its intended scope. The original prefix and origin can remain legitimate. That makes a leak different from a simple claim that an unauthorized network originates somebody else's address space.
Read the announcement path in the diagram
The arrows show route announcements, not user traffic. Provider A advertises routes to a multihomed customer. The customer learns those routes so it can reach destinations through A.
The error occurs when the customer exports provider-learned routes to Provider B as though it were offering transit. If B accepts and propagates them, other networks may choose a path through that customer. Traffic toward the destination then travels in the opposite direction to the announcement arrows.
The customer may lack the capacity or forwarding policy to carry that traffic. Congestion, loss and partial reachability can follow. RFC 7908 describes this as one route-leak pattern; it also documents other relationship and export-policy mistakes.
Why some users fail while others succeed
BGP selection is policy-driven. Local preference, AS-path attributes and other rules affect which available route a network chooses. A shorter AS path is not an unconditional winner.
Routers also use longest-prefix matching to forward packets once routes are installed. That is distinct from comparing alternate BGP paths for the same prefix. A diagnosis needs the advertised prefixes and actual policies, not just the statement that BGP chooses the shortest route.
Different networks can select different paths to the same service. Your office connection may work while a mobile carrier times out. A probe inside the hosting network can look healthy throughout the incident.
What origin validation can establish
An RPKI Route Origin Authorization records which autonomous system may originate a prefix, subject to its prefix-length constraints. Route origin validation can identify announcements that conflict with those authorizations.
It does not validate every relationship or export decision along the AS path. A provider-to-customer-to-provider leak can preserve the correct origin and still pass origin validation. RPKI is useful, but describing it as a complete route-leak defense gives operators the wrong expectation.
Controls need to match the problem:
- Apply explicit import and export policies to customers, peers and providers.
- Limit customer advertisements to the prefixes and paths the customer is authorized to announce.
- Use prefix limits as an additional alarm or containment measure, with thresholds chosen for the relationship.
- Deploy origin validation and maintain accurate ROAs.
- Where supported, evaluate BGP Roles and the Only-to-Customer attribute described in RFC 9234.
Implement and test policies with the network operator responsible for the sessions. A copied filter can cut off legitimate traffic if its assumptions do not match the relationship.
Collect evidence before changing routes
Record the affected hostname, resolved IP addresses, failure times and working versus failing networks. Compare DNS answers first so a DNS difference is not mistaken for a routing change.
Then compare paths and BGP observations using your upstream's looking glass or a route collector. A traceroute can provide clues, but filtered probes, asymmetric paths and routers that do not reply limit what it proves. Keep the observed prefixes and AS paths alongside the timestamps.
If you operate only the application, send this evidence to the hosting or transit provider. Avoid repeatedly changing DNS or application settings when the suspected failure is outside that layer.
Monitor the application outcome
Regional HTTP checks can show that a service is unreachable or slower from particular networks. They cannot establish a BGP route leak by themselves. DNS errors, filtering, TLS problems and application behavior can produce similar symptoms.
Use external monitoring to identify the scope and timing of the impact. Use routing evidence to investigate the cause. After a routing correction, verify affected locations again and watch for recovery of latency and error rates rather than relying on one successful request.