bgproutes.io vs Looking Glass vs RIPE Atlas — Pick Two

I get asked variations of this question every quarter. We need BGP visibility — do we use bgproutes.io, run our own looking-glass, or buy a RIPE Atlas anchor? Followed by the wishful version: can we just use one?

The answer is no. Three tools, three different shapes of data, three different failure modes. You need at least two and ideally three. The interesting question is which two for which investigation.

What each one is actually for

bgproutes.io — A public BGP route database that captures BGP UPDATE messages from a network of monitors and exposes them via a queryable API. The data is the actual BGP messages, with timestamps. Best for: historical questions ("what was the path on Tuesday at 14:00", "when did this AS-path change appear"). Worst for: real-time enforcement. Lag from event to query availability is on the order of minutes to tens of minutes.

Looking glass (your own or somebody else's) — A web/CLI interface to a live router's RIB. Best for: present-tense queries ("what does this router see right now", "what's the active path for this prefix"). Worst for: history, aggregation across vantage points, anything that needs more than one data source.

RIPE Atlas (probes + anchors) — A network of ~13,000 small probes distributed across the internet, programmable to run measurements (ping, traceroute, DNS, HTTP, TLS). The thing that gives you reachability and path-trace data, not BGP routes. Best for: "is my prefix actually reachable from these 1,000 locations", traceroute studies, DNS-resolution comparison. Worst for: BGP state. Atlas doesn't speak BGP. It tells you what the data plane does, not what the control plane decided.

The "pick two" matrix

If you understand the matrix, the question of which to pick stops being a debate and starts being a function of the investigation.

Real-time + multi-vantage — looking glass + Atlas. You query a few looking glasses to see active BGP paths, then Atlas to verify data-plane reachability matches. This is the right pair for active-incident triage. You skip the history because you don't need it yet.

History + multi-vantage — bgproutes.io + Atlas. You query bgproutes for what the BGP state was at the time of the issue, then Atlas's historical measurements to see what reachability looked like. This is the right pair for post-incident analysis when the event is over.

Real-time + history — looking glass + bgproutes.io. You see what's happening now and you correlate against when the change started. This is the right pair for investigating a slow-burning issue you've just noticed. You skip Atlas because you don't yet care about data-plane verification.

The pair you almost never want is bgproutes.io + looking glass without Atlas — that gives you a complete BGP picture and no idea whether anyone's actually reaching the prefix.

What each one consistently misses

bgproutes.io misses things its monitors don't see. It captures a wide sample but not every BGP session. A path change that propagates only inside one AS's customer cone might never reach the public monitor network. The data is incomplete in ways you can't see from the data itself.

Looking glass misses everything that isn't this one router. Already covered in the previous post. Single vantage, single moment, single policy.

Atlas misses the BGP control plane entirely. A prefix can be perfectly announced and still unreachable from the data plane (think MTU issues, ACLs, transit drops). And the reverse — a prefix can be reachable today via a path that's about to disappear because BGP is converging. Atlas tells you only what packets are doing, not what they're about to do.

The procurement question

Atlas probes are not free, but they're cheap. An anchor (heavier probe, more measurements per minute) costs more. RIPE NCC subsidises both for member networks. The marginal cost to your organisation is small.

bgproutes.io has a free tier sufficient for most operational use and a paid tier for production-scale queries. Most networks I see run on the free tier for years.

A looking glass on your own infrastructure costs you a small VPS, a public IP, an ASN, and the time to maintain. The recurring cost is operational discipline — keeping the software current. The benefit is you control the vantage point. If you're an AS that peers at three or four IXPs, hosting your own looking-glass at one of them is worth doing.

The pattern that holds up over time

The networks I've worked with that have the most reliable incident response have all three tools. They don't deliberate about which to use — they have dashboards that pull from all three and they cross-reference automatically. The investigation time on a routing issue at those organisations is hours, not days, because the data is already there when they need it.

The networks with one tool have long incidents and uncertain RCAs. The networks with two tools are in the middle.

The marginal cost of running all three is small compared to the cost of running one. The "pick two" framing in the title is the realistic minimum. The honest answer is "use all three, and know what each one is for".

Where bgproutes.io is genuinely different

The thing bgproutes.io does that nothing else does well is let you query the historical BGP state at arbitrary timestamps. That capability is what closes the loop on the "what did the network look like at 02:14 last Tuesday" question that every post-mortem needs.

If you have to pick one of the three to start with, pick the one that fills the biggest gap in your current visibility. For most networks, that's bgproutes.io, because the others (looking glass, Atlas) tend to already exist in some form. Add it. Run the historical queries against past incidents. Watch how much faster the third one resolves.

The "pick two" was for argument's sake. Three is what works.