The FullCtl team recently participated in the NANOG 87 hackathon. The theme of the hackathon was “interacting with sources of truth” and our team chose to focus on syncing data between PeeringDB and PeerCtl without the need to share credentials between the two applications. While we used PeerCtl in our proof of concept, this new PeeringDB feature could be leveraged by any configuration management solution once its officially adopted.
Configuration Management
Many of us use configuration management tools these days. They range from simple sources of truth (SoT) to elaborate intent based networking solutions. In some cases these tools are reactive repositories of configuration data as it is in the network. And in others it is a proactive solution that fuels automation and determines how the network is configured.
Some examples include NetBox, Nautobot, the classic RANCID, and our very own PeerCtl, which focuses specifically on driving BGP configurations for all types of interconnection. In all cases, the upshot is that the configurations in the network match the configurations in the management tool. There are cases, however, where that’s not quite enough.
PeeringDB Updates
In the world of internetworking and interconnection, the de-facto public source of truth is PeeringDB. Individuals and organizations from all over the world use PeeringDB every day to learn about internet exchanges, networks, facilities, and now carriers. And this isn’t just casual scrolling, folks are using this data to make real-world business decisions, understand market trends, and configure their networks.
This makes it crucial to keep PeeringDB as accurate as possible. Today this can be done manually, by logging into the website and making changes to records you have access to, or using software via the RESTful API. Of course, to use the API requires that you provide the API keys to the software that will make the update. What if you want to be able to synchronize changes from your configuration management system, but you don’t want to provide (and store) your PeeringDB credentials in that system?
Today, if you want to update PeeringDB from your configuration management solution, you have two choices:
-
Provide your PeeringDB credentials to the configuration management system and leverage the PeeringDB API, or:
-
Keep your PeeringDB credentials private, and manually “copy/paste” the changes from the configuration management tool into PeeringDB yourself.
During the recent NANOG 87 hackathon focused on “Interacting With Sources of Truth” the FullCtl team created a proof of concept (PoC) that opens up a third option!
NANOG 87 Hackathon
Our N87 hackathon team consisted of Stefan Pratter, Guillaume Mazoyer, and Matt “Grizz” Griswold. The PoC they hacked together during the event adds a new endpoint to PeeringDB to allow third party applications to let users update PeeringDB records without needing to share credentials.
Essentially, this allows your configuration management solution (or any software tool) to queue up the PeeringBD changes needed and pass them to PeeringDB as a changeset that an authorized user can then accept. Yes, you still have to login to PeeringDB. But, unlike the current reality, with this new feature you don’t have to give your credentials to the software tool and you don’t have to manually enter the changes into PeeringDB either.
Proof of Concept
What does this look like in practice? Let’s take a look.
In this PoC the FullCtl team used PeerCtl as our example third party application. In PeerCtl, we pull data from PeeringDB to populate the local SoT. Then we allow you to override any variable that is wrong or has changed since the last time PeeringDB was updated. Because PeeringDB is public data, none of this requires logging in — no credentials needed.
And now, with this new PoC feature in PeeringDB, we add a button to “Update PeeringDB” at the bottom of this configuration / override screen:
When you click that button, it takes you to PeeringDB. And once you authenticate, PeeringDB presents the changes to be made:
At this point you simply click “Accept selected changes” and now you’ve synchronized your local SoT with PeeringDB — without sharing your credentials!
Use-Cases
The most obvious use case for this functionality is highlighted in our example above. You want to make changes in a local configuration management system, SoT, or other application and have them reflected in PeeringDB as easily as possible, without sharing your credentials.
This use-case can be expanded when we think about a typical network team that may have multiple engineers but only one with write access in PeeringDB. The team can queue up the changes and let the authorized user review and synchronize them, again, without the need to share their credentials, this time with the team or the app.
Another possible use-case is for providing recommended updates to a third-party. This could be another team or department in your own organization. Or it could be a totally distinct organization. In any case, with this functionality you could queue up needed changes in a compatible application and then simply provide the third-party with a link that will allow them to review and make the changes to their PeeringDB records themselves.
Next Steps
The PoC feature that our team added to PeeringDB has now been submitted as issue #1328 “support web updates from a source of truth” and we expect it to be pulled into the production PeeringDB code base in the near future.
If you have questions or comments about this PoC, or anything to do with FullCtl, please feel free to reach out today!