Event-Driven Network Automation with NetBox and Ansible Automation Platform

In today’s fast-paced IT landscape, the complexity and scale of networks continues to grow. Businesses depend on these networks to deliver services efficiently, securely, and without downtime. However, managing and maintaining these intricate infrastructures manually is not only time-consuming but also prone to human error. This is where network automation comes into play. By automating routine tasks and responding proactively to network events, organizations can achieve higher efficiency, reduce errors, and free up teams to focus on strategic initiatives.

NetBox and Ansible – a Network Automation Power Couple

NetBox and the Ansible Automation Platform are two of the most powerful tools available for modern network automation. NetBox serves a Network Source of Truth (NSoT) which is a representation of the intended configuration and state of the devices, connections, and services of the network. It captures the intended state, which is different than the operational state. It uses a structured, cohesive, comprehensive data model for network intent, that forces completeness and correctness in design, planning, configuration management and operations.

Red Hat Ansible Automation Platform is an all-in-one solution for strategic automation. It provides the security, functionality, integrations, and adaptability required to scale automation across domains, coordinate critical workflows, and streamline IT operations.

Event-Driven Architectures

This blog explores how NetBox and Ansible Automation Platform can work together to create event-driven architectures. By sending event data from NetBox to Ansible we can truly unlock the potential for dynamic, event-driven network automation. Instead of waiting for scheduled tasks or manual intervention, Event-Driven Ansible (EDA) reacts to real-time triggers, such as a new device being added to NetBox or a change being approved and a branch being merged.

Using a real-world example, we will demonstrate how to combine NetBox with Event-Driven Ansible to automate network management tasks. This results in collaborative workflows, streamlined management processes, and enhanced responsiveness and resiliency, realizing the true potential of a modern network automation architecture.

Watch the full demo of this solution live in our upcoming Webinar: Event-Driven Network Automation with NetBox and Ansible Automation Platform. Register here

Building on an Existing Integration – The Ansible Certified Collection for NetBox

One of the building blocks for this solution is the Ansible Certified Collection for NetBox, which is already used by thousands of companies worldwide. The collection is supported by both Red Hat and NetBox Labs, and contains modules to define the intended network state in NetBox, and plugins to drive automation of the network using data from NetBox.

The main use cases for the collection are:

NetBox as a Dynamic Inventory Source for Ansible
Define Intended Network State in NetBox
Query and Return Elements from NetBox

This solution builds on top of the collection, by sending webhooks from NetBox to Ansible based on events happening to objects in the NetBox database. For example, when we update the NTP servers for a site in NetBox, that event fires a webhook to Ansible that in turn triggers the run of a playbook to automatically push out the new NTP configuration to affected devices.

Automating Common Network Tasks

In this blog we will highlight using event-driven automation for one specific task (NTP server updates), but below are some other key workflows that you will find example code for in the accompanying GitHub Repo:

NTP Server updates
Login Banner updates
VLAN provisioning
New device deployment

Regardless of which task we are automating, we will be making use of the Branching and Change Management* features of NetBox and the general workflow will be as follows

Create and activate a new branch in NetBox
Update the affected objects in the working branch
Create a Change Request in NetBox
On approval of the Change Request, merge the branch into the Main NetBox Database
On a Branch Merge event in NetBox, fire a webhook to Ansible EDA to trigger a playbook run based on a pre-defined Job Template
Ansible Automation Platform executes the playbook, pushing out the required changes to the affected network devices

*Available in NetBox Cloud and Enterprise editions

Ansible Automation Platform (AAP) Set Up

In the latest version of AAP (v2.5) there is now a unified User Interface that includes both Automation Execution (running playbooks with jobs and templates) and Automation Decisions (Event Driven Ansible) in a single interface:

Dynamic Inventory

Here you can see that we have our Dynamic Inventory for Ansible sourced from NetBox and it contains the host devices (Arista cEOS switches) running on our lab network:

Job Templates

We also have various job templates configured for each of the playbooks that are used to automate configuration of network devices. Jobs can be executed using these templates either manually, or when specific events happen in NetBox:

Rulebook Activations

We have a Rulebook Activation called aap-netbox-rulebooks set up and running that is listening for events coming from NetBox. When an event happens in NetBox (such as adding an NTP server in a branch that then gets merged after change approval) then if the rulebook activation is fired it will trigger the associated action(s) which could be running a playbook or a full workflow.

This is what the code for our example rulebook activation looks like – you can see it is listening for incoming webhooks on port 5001 on all interfaces:

---
- name: Listen for netbox events on a webhook
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5001

Then if we look at the specific rule for NTP Updates, we can see that the Configure NTP Servers job template will be triggered when a webhook is received that matches the following conditions:

Event is job ended
Model is branch
Log contains the string config context ntp_servers

  rules:

## NTP
  - name: NTP updates
    condition: event.payload.event == "job_ended" and event.payload.model == "branch" and event.payload.data.log is search("config context ntp_servers", ignorecase=true)
    action:
      run_job_template:
        organization: "Default"
        name: "Configure NTP Servers"

NetBox Set Up

Devices

In NetBox we have a site called Melbourne that contains three Arista cEOS switches:

Config Contexts

We also have our NTP server data stored as a Config Context (under Provisioning > Config Contexts) that is assigned to the Melbourne site, meaning that these NTP servers will be used for all network devices in Melbourne:

Event Rules

We need to configure NetBox to send a notification to Ansible when an event happens to trigger a Rulebook Activation. We do this under Operations > Event Rules. We have set up a rule that sends a webhook (called EDA Webhook) on event types of Job Completed for Branch object types.

Webhook

The associated webhook that gets fired when the Event Rule is matched is called EDA Webhook and sends it’s payload to the URL endpoint for EDA:

Putting it All Together

OK, so now the building blocks are in place we can put the whole thing together for our example use case of updating the NTP servers for all devices in the Melbourne site. Let’s step through it:

Create and Activate a New NetBox Branch

Under Branching > Branches we add a new branch called Update NTP Servers and then click Activate:

Update NTP Server Config Context

With our branch active we can add a new NTP server for the Melbourne site. Under Provisioning > Config Contexts, we edit the ntp_servers Config Context and add the new server 192.168.1.102 to the list:

Create a Change Request

Now click on View Branch in the top-right to view the diff between our active branch and the main NetBox database:

Next click on Request Review to raise a Change Request:

Enter the required information for the change request. Note that in our demo we already have some pre-defined change policies configured eg. Standard Change, and you can tailor these policies to suit your own organisational requirements:

Now the change has been raised we can see that it requires a review as per our Standard Change policy, so in this contrived example, I will add a review and approve the change request. Once approved we can now Merge the branch into the main NetBox branch by clicking on Merge:

In the next dialog box we tick the box to commit the changes to the database and then click on Merge Branch:

Event Rule is Matched and Webhook Fires

Once the branch has been merged this triggers our Event Rule which in turn fires the webhook from NetBox to Ansible. The Payload in the webhook is important and in order to trigger the Rulebook activation it needs to match the specific data that EDA is looking for (below in bold). The payload for our event looks looks like this:

{
  "event": "job_ended",
  "timestamp": "2024-11-20T14:08:29.636416+00:00",
  "model": "branch",
  "username": "admin",
  "request_id": null,
  "data": {
    "log": [
      "Merging branch ntp (branch_ttuylbjz)",
      "Found 1 changes to merge",
      "Setting branch status to merging",
      "Applying change Extras | config context ntp_servers updated by admin using default",
      "Setting branch status to merged",
      "Recording branch event: merged",
      "Merging completed"
    ]
  }
}

Ansible Automation Platform Executes the Job Template

The webhook is received by EDA and because the payload matches the required data to trigger the rulebook activation it kicks off a job based on the Update NTP Servers template. Prior to this it also runs a job to update the Dynamic Inventory to ensure we are always automating against the intended devices as defined in NetBox.

Remember, the rule for NTP Updates looks like this:

## NTP
  - name: NTP updates
    condition: event.payload.event == "job_ended" and event.payload.model == "branch" and event.payload.data.log is search("config context ntp_servers", ignorecase=true)
    action:
      run_job_template:
        organization: "Default"
        name: "Configure NTP Servers"

Here is the full output from the completed playbook job, showing the new NTP server configuration being pushed out to the three devices in Melbourne:

PLAY [Configure NTP on network devices using NetBox inventory config_context] ***

TASK [Extract NTP servers from NetBox inventory config_context] ****************
ok: [ceos2]
ok: [ceos1]
ok: [ceos3]

TASK [Render NTP configuration using Jinja2 template] **************************
changed: [ceos2]
changed: [ceos3]
changed: [ceos1]

TASK [Apply NTP configuration to Arista EOS devices] ***************************
ok: [ceos2]
ok: [ceos3]
ok: [ceos1]

TASK [Retrieve running configuration NTP section] ******************************
ok: [ceos2]
ok: [ceos3]
ok: [ceos1]

TASK [Display NTP configuration] ***********************************************
ok: [ceos2] => {
    "ntp_config.stdout_lines": [
        [
            "ntp server 192.168.1.100",
            "ntp server 192.168.1.101",
            "ntp server 192.168.1.102"
        ]
    ]
}
ok: [ceos1] => {
    "ntp_config.stdout_lines": [
        [
            "ntp server 192.168.1.100",
            "ntp server 192.168.1.101",
            "ntp server 192.168.1.102"
        ]
    ]
}
ok: [ceos3] => {
    "ntp_config.stdout_lines": [
        [
            "ntp server 192.168.1.100",
            "ntp server 192.168.1.101",
            "ntp server 192.168.1.102"
        ]
    ]
}

TASK [Remove temporary NTP configuration files] ********************************
changed: [ceos1]
changed: [ceos3]
changed: [ceos2]

PLAY RECAP *********************************************************************
ceos1                      : ok=6    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
ceos2                      : ok=6    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
ceos3                      : ok=6    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

So there have it – NetBox and Event Driven Ansible combined to deliver an event-driven network automation workflow that requires approval of network changes before they can be automatically deployed to the network devices! As I already mentioned you could easily adapt this to all sorts of network automation workflows based on events happening to objects in the NetBox database. The GitHub Repo has all the code used in this blog, plus example code for Login Banner updates, VLAN updates and even a full workflow to push initial configuration out to new devices after they have been onboarded into NetBox.

Learn More in our Upcoming Webinar

Learn more and see a full demo of this solution in our upcoming Webinar: Event-Driven Network Automation with NetBox and Ansible Automation Platform. This will be a joint session with NetBox Labs and Red Hat that will showcase the seamless integration of NetBox as a Source of Truth with Ansible Automation Platform (AAP) and Event-Driven Ansible (EDA). The webinar is on Jan 23rd at 11 AM EST / 4 PM GMT. Register here.

Share the Post:

NetBox 4.2 Is Now Generally Available

A few weeks ago, we introduced the NetBox 4.2 beta release, which brought a range of significant updates tailored to

NetBox Discovery – Quickstart Guide

The purpose of this quickstart is to get you up and running with NetBox Discovery as quickly as possible. In