A BGP looking glass is a web interface that lets you run a small set of read-only BGP commands against a router you do not own. The router belongs to an ISP, an IXP, or a content provider, and they expose it so that the rest of the internet can see what their network sees. When someone reports "your prefix is unreachable from our side of the internet," the first thing you do is open three looking glasses on three different networks and check whether your prefix is actually being advertised the way you think.
For the cluster overview, see the BGP complete guide. For how looking glasses interact with MPLS L3VPNs and SRv6 deployments, see the MPLS pillar.
What a looking glass shows you
Every looking glass surfaces a small, deliberately limited subset of BGP and routing commands. The standard menu, regardless of vendor or provider, is some combination of:
| Command | What it answers |
|---|---|
show ip bgp X.X.X.X/Y | "What does this network see for my prefix? Which AS_PATH? Which next-hop? Best path?" |
show ip bgp summary | "How many BGP neighbors does this router have, and are they Established?" |
show ip route X.X.X.X | "After best-path selection, which next-hop is in this router's FIB?" |
ping / traceroute | "Can this router reach my prefix in the data plane?" |
Notice what looking glasses do not let you do: nothing that changes state, nothing that shows confidential information, and nothing that lets you exfiltrate the full routing table. show ip bgp with no arguments is usually disabled or rate-limited.
Why this is useful
BGP is a path-vector protocol. Every AS in the world sees a potentially different best path to your prefix. If a customer in Brazil cannot reach your network in Singapore, the cause might be:
- Your upstream stopped advertising the prefix on one peering
- A transit AS in the middle has a route-map deny against your prefix or your AS
- An RPKI ROA mismatch is causing a tier-1 to drop your route
- An IXP route server's filter is removing it
- The path is being prepended so heavily that an alternate path is preferred and the alternate has a problem
You cannot diagnose any of these from your own router because your own router only sees its own view of the table. The whole point of a looking glass is to give you a borrowed view from somewhere else in the topology.
The public looking glasses worth bookmarking
Most large networks run a public looking glass. The ones below are the ones operators actually keep open during BGP troubleshooting.
| Provider | URL pattern | Why useful |
|---|---|---|
| Hurricane Electric | lg.he.net | One of the largest tier-2/peering networks. Great default sanity check. |
| NTT (GIN-LG) | ntt.net/looking-glass | Multiple PoPs globally. Good for "is my prefix visible in Japan vs Europe?" |
| Cogent | cogentco.com/looking-glass | Heavy tier-1 visibility, good for routing-policy disputes |
| Telia / Arelion | lg.arelion.com | Europe-heavy view; complements US-anchored networks |
| Lumen / Level3 | lookingglass.lumen.com | Wide North American footprint |
| RIPE NCC | stat.ripe.net | Not a single router but an aggregated RIB view from RIS collectors. Best single tool for "who is propagating my prefix anywhere on the internet right now?" |
| bgp.tools | bgp.tools | Aggregator + visual AS graph. Modern UX. Free. |
For the "is this prefix being received" question, RIPE Stat and bgp.tools are usually the fastest answer. For the "where is the AS_PATH bending" question, the per-provider looking glasses are necessary because you want to see the actual chosen path from that specific vantage point.
A standard troubleshooting recipe
Customer reports "your prefix is unreachable from our location." Before you touch your own configuration:
- Open RIPE Stat on your prefix. Confirm the prefix is being seen by the RIS collectors. If RIPE shows zero AS paths, your prefix is genuinely not being propagated anywhere on the internet and your problem is upstream of you (your transit dropped you).
- Open three geographically diverse looking glasses (HE in the US, Telia in EU, NTT in Asia). Query your prefix on each. Compare AS_PATHs. If two of three show your prefix and one does not, the missing one's network has a problem.
- Run a traceroute from the affected vantage point to your prefix. Most looking glasses include traceroute. If the trace dies inside a specific AS, that AS is the failure point.
- Check RPKI status. RIPE Stat shows whether your route is RPKI-valid, invalid, or not found. If your ROA expired and your prefix is now invalid, several tier-1s will drop it within minutes.
This four-step recipe localizes the problem in 5 to 10 minutes for most cases. It is the prerequisite to any conversation with your upstream support.
Hosting your own looking glass
Running your own public looking glass takes about an afternoon and is a small but meaningful peering-relationship investment. Other networks can debug their issues against you faster, which makes peering with you more attractive.
The two open-source projects that have stood the test of time:
| Project | Stack | Notes |
|---|---|---|
| hyperglass | Python (FastAPI) + JS frontend | Modern. Multi-vendor (Cisco IOS XE, NX-OS, Juniper, Arista, Cumulus). Per-location config. Auth not required for read-only. |
| bird-lg / bird-lg-go | Python or Go | Lighter weight. Speaks to BIRD route servers directly. Heavily used at IXPs. |
A minimal hyperglass deployment looks like:
git clone https://github.com/checktheroads/hyperglass
cd hyperglass
docker compose up -d
# Edit hyperglass/devices.yaml with your router IP, SSH user, vendorLock it down at the edge:
- Put the looking glass behind a reverse proxy (nginx, Caddy) with strict rate limiting (10 req/min/IP is generous)
- Bind the backend SSH to a dedicated read-only user on the routers with a tightly-scoped privilege role (Cisco IOS XE has
privilege exec level 0with specific show commands permitted) - Never expose write commands. Standard. But worth saying.
- Publish the looking glass URL on your PeeringDB record so other operators can find it
The looking-glass commands you actually permit
For a Cisco IOS XE router being polled by hyperglass or similar, the role for the looking-glass user should permit:
username lg-readonly privilege 1 secret <hash>
privilege exec level 1 show ip bgp
privilege exec level 1 show ip bgp summary
privilege exec level 1 show bgp ipv4 unicast
privilege exec level 1 show bgp ipv6 unicast
privilege exec level 1 show ip route
privilege exec level 1 ping
privilege exec level 1 tracerouteEverything else stays at higher privilege levels the read-only user cannot reach.
Limits to be aware of
- Looking glasses show one vantage point at a time. A "good" result from one looking glass does not mean your prefix is universally reachable.
- The router behind the looking glass may not run the same RIB as the network's edge. Most providers expose a dedicated route-collector, not a production router. The view is representative but not authoritative.
- RPKI views in looking glasses can lag. If you just published a new ROA, give it 15 to 60 minutes before relying on looking-glass output to confirm propagation.
- Some looking glasses cache. If you see a stale result, hit refresh; if a particular provider's looking glass always shows the same answer, try a different provider.
Key takeaways
A looking glass is the only way to see your prefix from somewhere other than your own router. Bookmark four or five geographically diverse ones, learn the four-step recipe (RIPE Stat first, three providers second, traceroute third, RPKI fourth), and you can localize most BGP reachability problems in under ten minutes. If you run a public AS, hosting your own looking glass via hyperglass is one afternoon of work and makes your network easier to peer with.
For the underlying BGP mechanics, see the BGP pillar.
