Why a BGP Route Leak Looks Like Your Host's Outage But Isn't

A customer tells you the site is slow or timing out, and the first instinct on both sides is to blame the server. Check CPU, check memory, maybe restart a service, and when all of that looks fine, the next move is usually to open a ticket with hosting support asking why the server is down. Sometimes the server never was the problem. The traffic to reach it just took a bad detour somewhere in the middle of the internet, and that detour is what a BGP route leak looks like from the outside. Border Gateway Protocol (BGP) is the routing protocol that networks use to tell each other which paths lead where. It runs on trust: when a network advertises it has a route to a block of addresses, neighboring networks generally accept that advertisement and pass it along. A route leak happens when a route learned from one network (say, a transit provider) gets improperly re-advertised to another network it should never have reached, breaking what's called valley-free routing. Normal routing follows a sensible hierarchy, customer to provider, peer to peer, provider to customer. A leak sends traffic along a path that violates that hierarchy, often through smaller or more congested networks that were never meant to carry that volume. When that happens, traffic meant for a data center or cloud region gets funneled through unplanned, under-provisioned paths. The result on the user's end looks exactly like a server problem: pages hang, connections time out, latency spikes. But the server itself may be sitting idle, healthy, and wondering why nobody's knocking. Here's a checklist to work through before escalating a 'my site is down' ticket as a hosting infrastructure issue.

Check if the problem is one-directional or everywhere

Ask the reporting user, or check yourself, whether the site is unreachable from every location or just from certain ISPs, regions, or mobile networks. A real server-side outage (crash, out of memory, Apache or Nginx down) is usually visible from everywhere, consistently. A route leak tends to be patchy: some users reach the site fine, others on a different ISP or in a different country hit timeouts or terrible latency. That patchiness is a strong early signal you're not looking at a dead server. If you have access to multiple vantage points (a VPN in another region, a colleague overseas, an online tool that runs traceroutes from different countries), use them. Consistent failure everywhere points server-side or DNS-side. Inconsistent failure that correlates with geography or ISP points to routing.

Run MTR and read the hop pattern, not just the last hop

MTR (My Traceroute) combines ping and traceroute into one continuous report, showing packet loss and latency at every hop along the path, not just the destination. This is the single most useful diagnostic here because a route leak shows up as a specific pattern: normal latency for the first several hops (your local network, your ISP), then a sudden latency jump or packet loss that starts at one hop and persists at every hop after it.

BASH

mtr -rwc 50 example.com

That example runs MTR in report mode ('-r'), with wide output for full hostnames ('-w'), sending 50 cycles ('-c 50') for a more stable average than a single pass. Contoh format output might look like this, with made-up numbers for illustration:

TEXT

HOST: client-workstation          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. local-gateway                  0.0%    50    0.5   0.6   0.4   1.1   0.1
  2. isp-edge-router                0.0%    50    4.2   4.5   3.9   6.0   0.3
  3. isp-core-router                0.0%    50    5.1   5.3   4.8   7.2   0.4
  4. transit-provider-hop           2.0%    50   88.7  91.2  85.0 110.4   6.2
  5. unexpected-asn-hop             4.0%    50   89.1  93.0  86.2 115.7   7.1
  6. destination-network            4.0%    50   90.0  94.5  87.1 118.9   7.5

The jump from under 10ms at hop 3 to nearly 90ms at hop 4, with loss appearing and staying roughly constant from that hop onward, is the shape you're looking for. A healthy path degrading because of a real server problem won't show this mid-path cliff; it usually shows clean hops all the way to the destination, with the last hop (or no response at all) being where things fall apart, because the server itself is the one struggling to respond, not the network getting there.

Look up the ASN of the hop where things change

Once you spot the hop where latency or loss jumps, look up which Autonomous System (AS) owns that hop. Most MTR output shows IP addresses, which you can check against any public ASN lookup or Whois tool. If that hop belongs to a transit network or ISP that has nothing to do with your hosting provider's normal path, and especially if it's a network in a region your traffic has no business routing through, that's consistent with a leak. Traffic that should go from Jakarta to a data center in Singapore suddenly hopping through a network based in another continent is the kind of detour a leak causes, since the "shortest" advertised path isn't always the physically shortest one once a leak distorts it. This step takes a few minutes and tells you far more than guessing. It's also the detail that makes an escalation ticket useful: saying "traffic degrades at this specific ASN hop" gives the network team something concrete instead of "internet is slow."

Check the hosting provider's and transit networks' status pages

Before assuming a leak, rule out the boring explanation: check your hosting provider's public status page for any acknowledged incident. If the provider already posted about a network event, you've saved yourself the deep dive. Route leaks affecting major transit providers or cloud regions are often picked up and reported by third-party network monitoring services or discussed in networking communities within a short window, since the shift in traffic patterns is visible to anyone watching global routing tables, not just the networks directly involved. If your own provider's status page is clean but users still report regional slowness, that mismatch (provider says healthy, users say broken, but only from some locations) is again a routing symptom rather than a server symptom. A server crash doesn't selectively affect only users in certain countries.

Separate 'can't connect' from 'connects but slow'

A fully dead server (crashed service, server powered off, firewall misconfigured to drop everything) usually gives a clean, fast failure: connection refused, or no response at all, consistently. A route leak more often produces something messier: the connection eventually succeeds but takes far longer than normal, or succeeds for some requests and times out for others under load, because packets are now crossing a path with less capacity and more congestion than the original route had. If you can establish a TCP connection at all, even a slow one, that's evidence the server is up and listening. From there the question becomes about the path quality, not the server's health. Checking this distinction before opening a server-side ticket saves time on both ends, since a hosting support team can confirm the server is responding on their end in minutes, while untangling a routing issue upstream is out of their control entirely and depends on the networks involved fixing their advertisements.

Watch for the pattern resolving itself without any server-side change

Route leaks get corrected once the network that caused them withdraws the bad advertisement, or once upstream providers apply filtering to reject it. If the server-side team made no changes, no restarts, no deploys, no config edits, and the slowness clears up on its own after some time, that's a strong retroactive confirmation it was a routing event rather than anything the hosting side did or didn't do. It's worth noting the timestamps when things started and stopped behaving oddly, since that timeline is useful if you want to cross-reference it against any public incident reports from the networks involved afterward. For more background on how these leaks happen in the first place, specifically how automated route policies can accidentally violate valley-free routing and turn a small network into unintended transit, see Anatomy of an Accidental Transit: When Automated BGP Policies Violate Valley-Free Routing. And if the symptom you're chasing looks more like a round-trip asymmetry than a clean mid-path degradation, it's worth comparing against Deciding If Inter-VPC Timeouts Are Asymmetric Drops or a Dead Path, which covers a related but distinct failure shape. None of this requires special tooling, just MTR, a Whois lookup, and the habit of checking more than one vantage point before assuming the worst about your own server. The habit worth building is simple: when something looks like an outage but the service checks out healthy on your end, trace the path before you trace the logs. It's usually faster, and it tells you whether you're escalating to the right team at all.