Peering Manager is an open-source BGP session management solution that allows you to track, maintain, and configure BGP sessions from a centralized management point instead of the usual manual provisioning. We spoke to Guillaume Mazoyer, Backbone Network Engineer & OpenSource Software Developer and the brains behind the tool, about conceiving the tool, its current state, and what is coming next.
Where did the idea for the Peering Manager come from?
I was working as the only network engineer in a small start-up, and, as part of my job, I had to manage hundreds of BGP sessions – 500 of them being peering sessions. At first, I used to copy and paste some configuration snippets when setting up BGP sessions but soon got tired of this. I started working on a CLI tool to generate those snippets automatically. After seeing other network-related projects, I decided to convert this tool to a web-based application that people like me could use.
What did you set out to achieve initially?
The initial idea was to provide a source of truth for BGP sessions, especially for public peering sessions over Internet Exchange Points (IXPs). That’s why the early releases of Peering Manager are focused on this specific feature. While managing IXP sessions can be time-consuming, it can be easily automated, as most of us network engineers re-use existing configuration snippets to configure new sessions. Having a decent source of truth helped a lot in improving this task.
What is under the hood? How is it built?
When I decided to make the Peering Manager open-source, I also switched my code from Go to Python. I thought that it would be easier to deep dive into a Python codebase rather than one in Go. As it also aims to be web-based, I chose the Django framework.
So basically, Peering Manager is written in Python with Django as a primary component of the code. It also relies on PostgreSQL and Redis to manipulate and store data. The code is released under the Apache version 2 license, so anyone can use it.
How does it work with other related tools?
Working on a source of truth related to peering and BGP is tricky. There is a lot of other software out there (mostly provided as services) holding data that users might use for automating their peering workflow, for example, PeeringDB and IX-AP. I decided to support PeeringDB as early as possible because it’s kind of an industry standard in our field of expertise. Peering Manager can retrieve data from the PeeringDB API to auto-fill data, so users do not have to this manually.
Recently, the support for IX-API was added to enrich data. When it comes to in-production services and available features on an IXP network, the IXP knows best. IX-API helps us to find out what an IXP has in its records and what can be of use for users.
What kind of features are available?
Peering Manager packs a lot of features to help people in automating their peering workflow. It can store autonomous system data, Internet Exchange data, and all BGP session details for public peering and other kinds of sessions (such as transit, customer, etc.). It can also build device configurations based on templates and install these configurations, so users don’t have to do it on their own. A REST API is provided so Peering Manager can be integrated in an existing automation workflow.
What is the connection to IX-API?
I learnt about IX-API after a user opened an issue on Peering Manager’s issue tracker. As it was a big feature to implement, it got delayed until I had the time to work on it. Thanks to the support and help of DE-CIX, the feature came to life faster than expected.
Developing tools to connect to third party APIs can be time-consuming for a lot of network-oriented companies as they do not have the time or the developers to do it. The long-term goal is for Peering Manager to be a client of IX-API. I want users to be able to review what IXPs they are peering at and know about their networks, but I also want them to be able to change data. For example, when we do maintenance, we sometimes need to change the hardware connected to an IXP. For the time being, we need to email the IXP so it can whitelist the new MAC address. I hope that this could be addressed, in the future, by connecting Peering Manager to the IX-API.
IX-API provides a lot of features and so does Peering Manager, but they still are two different projects which were not developed with the same concepts. It’s hard to find common ground and correlate data properly. That’s why it takes time to implement new features.
What is coming next?
In the coming weeks and months, I want to focus my work on improving the global shape of the codebase. It currently suffers from old concepts that need to go and need to be replaced by cleaner code.
I also have several features or improvements in mind, such as deploying configurations to Git repositories for even better integration into existing automation workflow, enhancing email communication from within the software so it can be of better use (to send maintenance, peering requests, etc.). I would also like to provide API endpoints for people to build peering portals which other networks can use to ask for peering – just like the big players already provide.
Thank you for the interview Guillaume!