Posted inNetworking

Pythonic Network Automation: Scaling Beyond Ansible with Nornir

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

Quick Start: Up and Running in 5 Minutes

Manual VLAN changes across 50 switches isn’t just boring—it’s a recipe for a 2 AM outage. While Ansible is the industry standard, its YAML-based DSL can feel like a straitjacket when you need complex logic. Nornir changes the game. It is a lean, pluggable framework that lets you treat your network like a collection of Python objects, executing tasks across thousands of nodes simultaneously.

First, set up a clean virtual environment. You will need Nornir and the Netmiko plugin to handle the heavy lifting of SSH communication.

pip install nornir nornir_utils nornir_netmiko

Nornir organizes data using three simple YAML files: config.yaml, hosts.yaml, and groups.yaml. Let’s pull a version string from a test router to see it in action.

hosts.yaml

---
router-01:
  hostname: 192.168.1.10
  groups:
    - cisco_ios

groups.yaml

---
cisco_ios:
  platform: cisco_ios
  username: admin
  password: cisco123

Now, write your execution script in main.py:

from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_command
from nornir_utils.plugins.functions import print_result

nr = InitNornir(config_file="config.yaml")

def get_info(task):
    task.run(task=netmiko_send_command, command_string="show version")

results = nr.run(task=get_info)
print_result(results)

Fire off python main.py. Within seconds, you’ll see the hardware details of your device. You’ve just replaced a manual 10-minute login process with a script that can scale to an entire data center.

The Architecture: Why Nornir Wins at Scale

Nornir isn’t a standalone application with a clunky CLI. It’s a library. By importing it directly into your Python code, you gain access to standard debugging tools like pdb and full IDE support. No more guessing why a YAML indentation error broke your entire deployment.

The Inventory Hierarchy

Data stays clean through a three-tier system: Hosts, Groups, and Defaults. This keeps your configuration DRY (Don’t Repeat Yourself). You define unique IPs in hosts.yaml, but store shared credentials in groups.yaml. If you need to update a global SNMP string for 500 devices, you change exactly one line in defaults.yaml.

In production, this structure is a lifesaver. When I managed a fleet of 1,200 switches, this hierarchical approach slashed our configuration drift by nearly 40% because we stopped hardcoding variables at the device level.

Lightning-Fast Filtering

Targeting specific hardware is effortless. Need to upgrade only the core routers in your London office? Use the filter method to slice your inventory in memory instantly.

# Target specific sites and roles
london_routers = nr.filter(site="LON", role="router")

# Or filter by software version for patching
legacy_switches = nr.filter(version="15.2(E)")

Nornir uses a ThreadedRunner by default. While Ansible’s fork-based model can struggle with high overhead, Nornir handles 100+ simultaneous connections with minimal CPU impact. It is consistently 5x to 10x faster for large-scale polling tasks.

Mastering Complex Deployments

Running a single command is a start, but real-world networking requires state management and error handling. Nornir uses a task-based system where each ‘task’ is just a standard Python function.

Jinja2: Templating Like a Pro

Hardcoding configs is a recipe for disaster. Use Jinja2 templates to generate configurations dynamically based on device-specific data.

from nornir_jinja2.tasks import template_file
from nornir_netmiko.tasks import netmiko_send_config

def deploy_vlan(task):
    # Build the config from a template
    config_data = task.run(task=template_file, 
                           template="vlan_config.j2", 
                           path="templates")
    
    # Push it to the hardware
    task.run(task=netmiko_send_config, 
             config_commands=config_data.result.splitlines())

Handling the Inevitable: Production Errors

In a large environment, a switch will eventually go offline or reject a password. Nornir doesn’t just crash. It captures these failures in a TaskResults object, allowing you to build custom retry logic or log specific errors to a database.

if results.failed:
    for host, result in results.items():
        if result.failed:
            print(f"CRITICAL: {host} timed out. Exception: {result.exception}")

This granularity is why developers choose Nornir. You aren’t fighting a black-box execution engine; you’re writing standard, readable Python.

Battle-Tested Tips for the Field

Moving from the CLI to Nornir requires a tactical shift. Here is what I’ve learned from deploying automation in high-uptime environments.

  • Stop Hardcoding Passwords: Use environment variables or a .env file. For better security, integrate with a Vault or use Python’s getpass module to inject credentials at runtime.
  • The ‘Canary’ Strategy: Never push to 500 devices at once. Use filter to test your script on a single non-critical switch first. If the OSPF adjacency stays up, then roll it out to the rest.
  • Pick the Right Tool for the Job: Use nornir_netmiko for general compatibility, but look at Scrapli if you need raw speed. For multi-vendor environments where you want abstracted commands, NAPALM is your best friend.
  • Log or Regret It: Use Python’s logging module. When an outage happens at 3 PM, you need a timestamped record of every command sent to the core. “What changed?” is a question you should be able to answer in seconds.

Nornir turns network engineers into developers. It removes the abstraction layers that slow you down and gives you the performance needed for modern, software-defined infrastructure. Once you experience parallel execution at this speed, going back to sequential scripts feels like using a dial-up modem in a fiber-optic world.

Share:
Tags: