How to succeed with Network Automation using NetBox, Slurp’it and Netpicker

Originally hosted on the Netpicker.io blog at netpicker.io/how-to-succeed-with-network-automation-using-netbox/.

Guest Author: Wim Gerrits

Preface by Mark Coleman

Mark: This is the first time we’ve done a guest blog at NetBox Labs, but we thought it was such a great post that we wanted to make sure it gets the attention it deserves. In this blog Wim Gerrits from SlurpIT and Netpicker shows how the Network Automation Reference Architecture we created with the NetBox community is taking root across the industry.


Starting with network automation can be daunting, especially when you don’t have a roadmap to guide you or a proven reference architecture to help you succeed.

In this post, we’ll outline step-by-step how you can succeed with network automation and give you a proven methodology plus the tools to get in full control of all your network automation use cases. 

What it boils down to in the end is that you need to tackle these 3 challenges:

  1. Know the current state of your network
  2. Define and manage your intended state
  3. Deploy your intended state and stay in full control going forward

It was not straightforward how to achieve this, so we decided to clarify this.

The NetBox community and the NetBox Labs team have been leading the way with using the concept of a Network Source of Truth (NSoT). But just having a NSoT is not enough. You also need steps and processes to manage the state of your production network and be able to reconcile and manage any differences. This is where Slurp’it and Netpicker come in.

Together with the NetBox Labs team, we developed a step-by-step approach that integrates automated Discovery and Validation with NetBox. It allows you to get in full control of your data and change processes.

These are the steps:

  1. Discover your network. Find all your devices and inventory data
  2. Validate state against hardening (CIS), vulnerabilities, design rules etc.  
  3. Onboard discovered network in NetBox
  4. Reconcile differences to define the intended state 
  5. Generate configs to achieve the intended state 
  6. Validate compliance before deployment 
  7. Deploy intended changes 
  8. Monitor non-intended changes with closed-loop NMS integrations

In the picture below, all these steps are highlighted in the reference architecture that is developed by the NetBoxSlurp’it and Netpicker teams.

Netpicker reference architecture

Let’s dive in and explain how this can be done:

1. Discover your network with Slurp’it

Slurp’it allows you to discover all devices in your network and then parse any show command/API output in a structured way. It comes out of the box with tested TextFSM templates for the most common attributes so you have a digital copy of your entire inventory in JSON format. It’s very flexible, so you can add as many templates as you like. 

The device discovery requires SNMP and parsing all data uses SSH connectivity. Out of the box, 117+ Netmiko vendors are supported and the entire discovery process takes several hours to a few days for a medium to large network. For lab testing, the whole process takes only a few minutes.

2. Validate your network with Netpicker

The second step to know the current state of your network is to run a ‘compliance’ audit against your configuration state. This is what Netpicker does. It uses Netmiko to connect to all network devices and back up all device configs. It then uses Pytest to run tests to validate if you comply with all kinds of things, like vendor hardening (some CIS libraries come out of the box), CVE vulnerabilities or your own design rules.

Netpicker integrates with both Slurp’it and NetBox, so it can fetch all the devices that Slurp’it has discovered, or that you might have already in NetBox. After getting all your device configs it only takes seconds to run your initial scan based on the built-in test libraries. You can also build tests or let Netpicker’s ChatGPT prompt build them. Just describe what you want and then copy/paste and test it in Netpicker.

3. Onboard NetBox with Slurp’it plugin

Now it’s time to onboard your network into NetBox. This is done with the Slurp’it plugin. The process is simple. After filling in API keys on both sides, all the discovered devices and data will show up in the NetBox application. The device list will be kept in sync by Slurp’it if it finds a mismatch between discovered and NetBox-registered devices. The plugin can map IPAM and interface data into NetBox’s data model. All other data discovered by Slurp’it is stored in the plugin and Slurp’it application. 

4. Reconcile differences to define the intended state 

In the next step, it’s important to make a conscious decision about what you want the intended state of your network to be. For example, if Slurp’it shows that certain interfaces are not shut and you intend to have them shut, you need to ‘mark’ for action in the next step and shut them.  The Slurp’it reconcile functionality will help you do this. The plugin will inform you when Slurp’it discovers new deviations so you are in full control.

5. Generate configs to achieve the intended state 

After you have gone through the administration of what you ‘accept’ as your intent and what you need to change to get there, you are ready for the next step. Now you must create the configs and jobs you need to deploy in your network.

There are many NetBox training videos on this, but in essence, you need to create or update your Jinja or Ansible templates and parametrise them so you can generate your intended configs automatically based on the intended data in NetBox.

6. Validate compliance before deployment 

This step is often left out, but you want to make sure that you also run compliance tests on the new configs before you plan to deploy. In this way, you keep your network ‘clean’ and compliant.

Netpicker can fully automate this process and check the new configs against your compliance policies. 

7. Deploy intended changes 

Now you can deploy your changes. Most engineers do this with AnsibleNornir or their own Python scripts. In the next release of Netpicker, you will also be able to schedule and deploy these changes with a nice user interface.

8. Monitor non-intended changes 

Finally, to stay in control, you need ongoing monitoring of your production to make sure everything stays as intended. Netpicker allows you to do this and also configure webhooks to automate closed-loop integrations with other NMS and ticketing systems.

Share the Post:

Related Posts