Case
Peering requests that arrive ready to configure
Deze case is voorlopig alleen in het Engels beschikbaar.
Samenvatting
Het probleem
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.
Wat we deden
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.
Resultaat
Requests arrive with what the NOC needs to configure the session, and peers can check routes and paths without a ticket.
Meer in 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.