Case study
Peering requests that arrive ready to configure
Summary
The problem
Peering requests arrived as emails with missing details, so every one needed a round of questions before a session could be configured. Peers had no way to look at routes or session state themselves.
What we did
Built a peering request site that looks up the requesting network in PeeringDB, shows the IXs and facilities both networks share, flags a missing IRR as-set or NOC contact before the request is sent, and lets a signed-in peer see its existing sessions. Rebuilt the public looking glass with a backbone map, BGP community decoding, and traceroutes annotated with ASNs and IX names.
Outcome
Requests arrive with what the NOC needs to configure the session, and peers can check routes and paths without a ticket.
In more detail
Requests that are ready to configure
To configure a session, the NOC needs to know where the two networks can meet and who to call. The request site fills that in from PeeringDB: the shared IX LANs for public peering, the shared facilities for a private interconnect, and the contacts and as-set on record. If something is missing, the requester sees it before the email is sent instead of hearing about it two days later.
A looking glass people use
The looking glass runs route, community and path queries against the backbone routers and explains the answers: communities are decoded into plain language, and every hop of a traceroute shows the network and IX it belongs to. A map of the backbone shows where each query ran.