I run Peering Manager as the inventory of who I peer with. It is a lovely tool and it has one failure mode that matters: the moment a session is created or removed on a router without going through it, the database is quietly wrong. And a wrong inventory is worse than no inventory, because you start trusting it.
Mirror on write, reconcile on a timer
Approving a request in my dashboard now does two things: enable the session on the router, and upsert it into Peering Manager. Removals delete it there too. That is best-effort — if the mirror fails, the router action still succeeds, because the router is the thing that carries traffic.
The mirror alone is not enough, since it only covers changes that go through the portal. So a reconcile job runs every 15 minutes: read every IX session from the routers, compare with Peering Manager, create what is missing, delete what no longer exists. The first run created around 230 sessions and 27 AS objects and removed 16 stale ones, which tells you how far apart things had drifted.
Things the API taught me the hard way
- Authentication is a
Tokenheader, but the instance sits behind Cloudflare — with the default Python user agent you get a 403 and no hint why. - Several filter parameters are accepted and then ignored. Fetch and match locally instead of trusting the server to narrow results.
- Pagination
nextlinks are absolute URLs. Prepending your base URL gets you nonsense. - Creating an autonomous system requires a name; an ASN on its own is a 400.
Pin your images
While I was in there I found the stack running an old scheduler service that had been
removed from the image and was crash-looping, so the daily PeeringDB sync had not run in a
week. The cause was a floating :latest tag. It is pinned to a digest now, with the modern
housekeeping and sync services in its place.
Boring conclusion, hard-won: automate the write path, then verify it on a timer anyway.