Netbox sync plugin

[gusmb]

I would like to open a thread to discuss an idea that I think could be really useful. I use AVD models in my pipelines and my source of truth is usually Git. However, my intention is to use Netbox as my IPAM for things like tenant IP allocations (SVIs, L3 interface IPs, etc). For that to happen, Netbox needs to know about the topology (interfaces and IP addresses) in the deployment. AVD hides a lot of this logic and the data model is not really device-centric, so it doesn't pair very well with Noetbox out of the box.

Here I think a sync plugin based on the devices structured data could be really useful. As part of the deployment process, I would like to generate the configurations using AVD, which gives me structured data for each device. I could then use an Ansible plugin to translate the eos structured data for each device into Netbox objects (devices, interfaces, ip addresses, VRFs and VLANs). The plugin would then fetch the "current" Netbox state and as a result build a "list of Netbox objects to add" and a "list of Netbox objects to delete" in order to keep Netbox in sync with the topology, assuming Git is the primary source of truth.

By doing this, at the end of each deployment, Netbox has the overall picture of the Network and can perform idempotent IP or subnets allocations for tenants, which would then be retro-fed to Netbox via the sync plugin. An example could be an allocation of a range to be used for tenant loopback addresses. The sync plugin would feed all loopbacks created with their respective IP address back to Netbox at the end of the deployment.

An idea in this direction is implemented on tools like Jerikan: https://vincent.bernat.ch/en/blog/2020-syncing-netbox-ansible
which considers Git as the primary SoT for data driven deployments using GitOps.

[ClausHolbechArista]

This is a great idea. I would suggest to implement this as a role similar to eos_cli_config_gen, where it can read vars structured_config if run as stand-alone, or from hostvars if run as part of a play with eos_designs.

I don't think we would include this plugin in the arista.avd collection itself, but we have been talking about starting an arista.community collection for extensions like this.

[gusmb]

Agree Action Plugin+role is a good combination, where user can select which Netbox models to sync, and adds check mode and diff mode features to preview what changes are going to be made in Netbox. I like the idea of a separate collection, facilitates more plugins like this.

[gusmb]

I'm working on an implementation of a "Netbox Sync" plugin for my design, which takes the AVD structured configs, hostvars and my switch facts as input, and generates intended Netbox objects to maintain the state of Netbox (one-way sync) by using a list of "synchronizers". Unfortunately this is tailored to my specific vars and wouldn't work 100% with AVD switch facts. However, I already see the potential value of this on a multivendor envrionment. The idea is to use Netbox as the SoT for "structured config", using Netbox internal rendering engine to render the structured config directly from Netbox objects. This makes a much more efficient use of templating as the Netbox rendering engine has full access to the Django models and Netbox functionality, making it easier to use. This applies to any vendor, so the rendered config would be still valid using Arista spine and Cisco leaf, by using the corresponding templates depending on the device platform.

The real benefit is on the design phase. Currently "eos_designs" works well with an EOS fabric, but it is not typically used for a multi-vendor fabric, although the data models are not necesarilly vendor specific. If the output of eos_designs was Netbox objects instead of AVD structured data, the following 2 steps are then completely de-coupled:

• Design to intended state
• Intended state to deployable artifacts (configs)

This "Netbox Sync" plugin is for me a first step towards the real goal, which would be supporting a database-driven SoT the design output, to store the intended state. Netbox is the cool kid today, but there will be next generation SoTs that can also be added in the future. Then the structured data can be generating by adding the corresponding functionality to the SoT, and deployment pipelines become straightforward, even for vendor migrations. An additional benefit of this is that the intended state can be exposed by APIs. Currently AVD only exposes it on Markdown files as documentation, but I am already seeing improvements by pushing intended objects to Netbox. For intance, Device platforms inherit all required interfaces and the platform base baseline config which can be now maintained outside of the design. DC sites, rooms, racks etc are maintained by the SoT, IPAM can be delegated rather than maintaining the IP pools/ranges in YAML data, etc etc.