Why Every NOG Should Run Its Own Looking Glass

Looking glasses go down. The hosted ones get neglected, the vendor-sponsored ones get retired when a vendor exits, the community-run ones suffer when the volunteer doing it changes jobs. Five-year stability for a routing observability tool is rare, and the NOGs that have it built it themselves.

If your NOG doesn't run a looking glass under community control, you're depending on infrastructure somebody else maintains for reasons that might not survive a strategy change. That's a fine bet for a year. It's a bad bet for five.

This post is the case for community-owned looking glasses, the actual cost, the operational shape, and what good ones do that bad ones don't.

What community ownership buys

Three things, none of which are technically interesting and all of which matter operationally.

Persistence. Vendor looking glasses get retired when the vendor changes priorities. Hosted services get rate-limited or paywalled. Community-run infrastructure maintained by a NOG outlives all of those. Five-year operational continuity is achievable when the operator is the community that needs the tool.

Trust profile. A NOG-operated looking glass tells you what the NOG's vantage point sees. That's a known and stable trust profile. Vendor and third-party looking glasses introduce trust dependencies on entities whose interests aren't aligned with yours.

Customisation. Community-owned tools can be customised to the community's needs — additional measurements, integration with other community-run infrastructure, query patterns specific to the operational issues that NOG has. None of that is available to the same degree on hosted alternatives.

The cost, honestly

Running a looking glass for a NOG community is genuinely cheap. The components:

A small VPS or container. Two cores, four gigs of RAM, twenty gigs of storage. Forty to sixty euros a year at competitive prices.

An ASN. The NOG probably already has one. If not, a few hundred euros one-time fee to the local RIR.

A small IP allocation. A /29 IPv4 and a /48 IPv6 is sufficient. Probably already in NOG hands.

Public BGP peering at the NOG's preferred IXP. Usually free for NOG-affiliated infrastructure. Sometimes a small port fee.

Software. bird-lg-go is the current standard. Open source, well-maintained, well-documented. Setup takes a competent volunteer about a weekend.

Domain name and TLS certs. A few euros a year.

The recurring cost is the volunteer hours to maintain it — software updates, BGP session monitoring, occasional debugging. Realistic estimate: ten hours per quarter once it's running. That's two hours a week of one volunteer's time, on average, with most weeks being zero hours and a few weeks being half a day.

Total annual cost to the NOG, fully loaded: under a thousand euros plus the volunteer time. For an organisation with multi-thousand-member-strong mailing lists, this is a rounding error.

What a good looking glass actually does

Beyond the basic show-me-the-route query, a well-run community looking glass should offer:

Multi-vantage queries from a single interface. If your NOG runs multiple instances at different IXPs, the looking glass should let users query all of them in one go and present the diff. This is the most useful single feature for routing investigation.

Historical query support. Snapshots of the looking glass state on an hourly basis, queryable retroactively. Most public looking glasses don't have this. Adding it is small operational overhead and significant analytical value.

Integration with other observability sources. Hooks into RouteViews data, RIPE Atlas measurement endpoints, RPKI cache state. The community looking glass can become the natural gluing layer for operator-facing routing diagnostics.

Reasonable rate limits with NOG-member authentication. Public anonymous queries get standard rate limits. Authenticated NOG members get higher limits. Prevents abuse from external traffic, gives community members the responsiveness they need.

API access alongside the web UI. Most operator investigations are scripted now. The looking glass that's only a web interface is useful for casual queries. The looking glass with a documented API is useful for production operations.

Why peering with other NOG looking glasses matters

A single looking glass at a single IXP shows you one regional vantage. The interesting routing questions are usually about disagreement between regions. A NOG looking glass that peers with the looking glasses of three or four sister NOGs in different regions becomes a much more useful tool.

The mutual-peering pattern between NOG looking glasses exists in some communities and not in others. Where it exists, the routing investigations are faster and more complete. Where it doesn't, every operator has to query four or five separate web interfaces and manually correlate.

The peering arrangement is cheap to set up — a BGP session over the IXPs the looking glasses are already connected to. The volunteer hour cost is small. The benefit accrues to every community member who runs a routing investigation.

If your NOG already runs a looking glass and isn't peering with sister NOGs' looking glasses, that's the next operational step worth taking. Reach out, set up the peering, share the visibility.

The operational pattern that works

NOGs with stable, useful looking glass operations have, almost without exception, a small core of two or three volunteers who own the operation collectively. One person operations doesn't survive a job change. Five-person committees move too slowly. Two or three people with shared root access, a documented runbook, and a clear succession plan is the model that holds up.

The runbook covers: software updates, BGP session monitoring, certificate renewals, user-account management, IXP-peering changes, post-incident review. None of these are individually demanding. The discipline is having them documented so the next volunteer can step in cleanly when one of the current ones cycles out.

The succession plan covers: who has admin credentials, where they're stored, how a new volunteer is on-boarded, what training they need. Most NOG infrastructure dies not from technical failure but from the original volunteer leaving without a successor.

What I'd avoid

Three failure patterns I've watched up close.

Single-volunteer ownership. One person runs everything. They get promoted, change jobs, burn out. The infrastructure dies. Avoid by enforcing the two-person minimum from day one.

Over-engineering the first version. A looking glass that takes six months to launch never launches. Get bird-lg-go running in a weekend, point at one IXP, ship it. Iterate from there.

Letting the looking glass become "the IT person's project". Community-owned means the community owns it. If the looking glass is positioned as one volunteer's personal project that the NOG uses, the bus factor is one and the budget is fragile.

What this is actually about

The thing that makes a NOG durable is the infrastructure the community owns collectively. Mailing lists are easy. Meetings are easy. The harder work is the technical infrastructure — looking glasses, BGP visibility, abuse contact databases, member directories — that requires sustained operational discipline.

NOGs that own this infrastructure are stronger five years out than NOGs that rent it. The renting pattern works until the renter raises prices, changes terms, or exits the market. The owning pattern requires more volunteer effort but produces resilience that can't be bought.

If your NOG has a looking glass, treat it as infrastructure worth maintaining. If your NOG doesn't, start one. The cost is small, the benefit compounds, and five years from now your community will be one of the ones with stable visibility into routing reality.

The window is worth owning.