NFD27 - Network to Code

Preamble time! Nautobot vs. NetBox has been a sensitive subject in the community. I’m not here to sway you or endorse one over the other. Use what you think fits you and your organization best.

After ZPE, Network to Code was up to talk to us about all of the latest with Nautobot. The presentations were cohesive, and they told a compelling story: you’ve got stuff to do, and we help you do those things. Maybe the most interesting thing about their presentation was that they really only covered plugins – there was no new core whizbang product or platform announced here, just “here’s more stuff you can have for free if you use Nautobot.”

Circuit Maintenance Plugin

First up was the Circuit Maintenance Plugin. This plugin is very similar to Janitor, a standalone Flask application from @NetworkAndrew, except that it’s a plugin for Nautobot. So, if you’re not a Nautobot user and/or don’t want to be one, consider looking at Janitor for similar functionality.

But if you are a Nautobot user – or if you are just curious about its features – then the Circuit Maintenance Plugin looks like it solves a serious pain point.

Keeping track of circuit maintenances is tedious work. Someone has to do it, though – or maybe some thing. This plugin reads e-mail inboxes to find and parse carrier circuit maintenance notifications. It generates and tracks initial notifications and updates, then records those items as events in Nautobot. It doesn’t stop there, though – if you have your circuits in Nautobot, you can also see what impact each maintenance will have!

“Impact” is used lightly – obviously it’s up to the operator to know just how critical any given circuit is to the continuity of business.

There’s even more, though. Prometheus metrics can be configured to show a given circuit’s operational status based on the maintenance plugin’s records. This is an expected state, though, so it’s important to look at this more like a “is this circuit currently in the maintenance window” rather than the actual operational status of that circuit.

One thing that’s missing here is event-based actions. I’d love to see plugins like this emit an event to an event/message system so that other integrations can simply listen for the event and then schedule or take actions – such as automatically removing a circuit from production use 10 minutes prior to the maintenance window and automatically returning it to service after the window. This is feedback I definitely provided to them, but it’s a bigger thing than just the circuit plugin since that would be core Nautobot functionality – which would be great to see for other reasons.

Single Source of Truth

I hit buzzword bingo!

All jokes aside, though, this was an interesting presentation that perhaps is a bit of a misnomer. The Single Source of Truth plugin isn’t so much a single source of truth (is anything?) as much as it is a system for defining unidirectional data syncs. You can tell Nautobot to ingest data from external systems – think of migrating from one DCIM (such as Device42) to Nautobot. You can also tell Nautobot to publish data to another system – think of syncing IPAM to a DNS system. These can also be bidirectional by creating two unidirectional syncs.

A lot of this, though, requires you to write some Python code to map data from one system to another. This isn’t unexpected, but if I’m making a wishlist for my ideal fantasy world, this would be something that I could do entirely via a GUI. However, as more people develop plugins to this plugin, it will be much easier to use and leverage the community efforts.


I can’t get excited about this one. 90% of what I saw was either not useful to me or was something I’d rather see in a CI/CD pipeline. Maybe using ChatOps to kick off a pipeline would be cool, but I’m not sure. That said, quickly getting data from your inventory is convenient. But getting a static Grafana graph…not so much. If I ever share a static graph, it’s for a very specific time range to show something specific, and at that point I need to be in my graph system to find what I’m looking for and set the time range anyway. Obtaining metrics data just isn’t a great use case for ChatOps.

However, an integration with IP Fabric was revealed later in NFD27 that was extremely attractive: using ChatOps to do path lookups from IP Fabric and getting that topology (nearly) instantly in Slack. There is so much value in that that I’d use ChatOps for that one bit of functionality alone.

Final Thoughts

Nautobot is worth a look. On its own, as a core thing, I don’t see it differentiating much from Netbox. The ready-to-use plugins, though… that’s compelling as an end user who doesn’t have the time or teams or expertise to develop custom plugins like the Circuit Maintenance Plugin. Coupled with the (unfortunately named) Single Source of Truth plugin, I can see someone evaluating either a complete migration to Nautobot or, at worst, an integration with other DCIMs like Device42 or even Netbox itself.

Finally, if you’re interested in giving Nautobot a spin, I spent a little bit of time creating a repository to deploy some infrastructure to DigitalOcean and deploy Nautobot to their managed Kubernetes Service here.

Published At
Tagged with