Esc
Type to search posts, tags, and more...
 Skip to content
9 min read

The Network Automation Landscape in 2026

A practitioner's map of the network automation ecosystem — from CLI parsing and config management to source of truth platforms, testing, and AI-assisted operations.

--automation--python--network-engineering--network-devops--iac
Contents

Why This Post Exists

I wrote the original version of this post in 2020, focused almost entirely on CLI text parsing. That was the state of things: most network automation meant SSH-ing into boxes, scraping show output, and hoping your regex held up.

Six years later the landscape is unrecognizable. We have model-driven APIs on most modern platforms, source-of-truth databases that actually work, proper testing frameworks for network configs, and LLMs that can parse unstructured output better than any template. CLI parsing is still relevant — legacy gear is not going anywhere — but it is one layer in a much deeper stack.

This is my opinionated map of the tools and categories that matter today.

Source of Truth

Every automation stack needs a single place that answers “what should the network look like?” Without it, you are writing scripts that encode intent in YAML files scattered across repos.

NetBox

NetBox is the de facto standard. Originally built by the DigitalOcean team, it models sites, devices, interfaces, IP addresses, VLANs, circuits, and more. It has a comprehensive REST API and a GraphQL endpoint. The plugin ecosystem is mature — you can extend it for custom fields, webhooks, and integrations.

If you are starting from zero, start here.

Nautobot

Nautobot is Network to Code’s fork of NetBox that diverged significantly. It adds a job framework (run automation tasks from the UI), a GraphQL-first API, Git-backed data sources, and an app ecosystem. The philosophy is different: Nautobot wants to be the platform you build your automation on top of, not just the data store.

Choose Nautobot if you want an opinionated platform with batteries included. Choose NetBox if you want a clean data model and want to compose your own stack.

Orchestration and Frameworks

Nornir

Nornir is a pure-Python automation framework. No DSL, no YAML playbooks — just Python. You define inventory (which can come from NetBox, Nautobot, or a simple YAML file), write tasks as functions, and run them in parallel.

from nornir import InitNornir
from nornir_napalm.plugins.tasks import napalm_get

nr = InitNornir(config_file="nornir.yaml")
results = nr.run(task=napalm_get, getters=["facts", "interfaces"])

for host, result in results.items():
    print(f"{host}: {result.result['facts']['vendor']}")

The strength is that you have the full Python ecosystem. Need to talk to an API, do math on subnet allocations, or call an LLM? Just import the library. No wrestling with a templating language.

Ansible

Still the most widely deployed network automation tool, mainly because of low barrier to entry. Ansible’s network modules cover most vendors. The ansible.netcommon and vendor-specific collections (cisco.ios, arista.eos, junipernetworks.junos) are actively maintained.

The limitations are real though: error handling is clunky, debugging is painful, and complex logic in YAML is an anti-pattern. For simple, repeatable tasks across many devices, Ansible works. For anything with branching logic, use Nornir or write plain Python.

Terraform for Networking

Terraform is not just for cloud anymore. Providers exist for Cisco ACI, Palo Alto, Fortinet, Juniper, and even NetBox itself.

The value is the same as in cloud: declarative state management with plan/apply workflow. You describe what you want, Terraform figures out the diff. This works well for platforms with proper APIs (cloud firewalls, SD-WAN controllers, load balancers) but less well for traditional CLI-driven devices.

Transport and APIs

Model-Driven APIs: NETCONF, RESTCONF, gNMI

The biggest shift since 2020 is the real-world adoption of model-driven interfaces. YANG models define the schema. The transport varies:

  • NETCONF (RFC 6241): XML-based, over SSH. Supported by Juniper, Cisco IOS-XE/XR, Nokia, Arista. Mature but verbose.
  • RESTCONF (RFC 8040): YANG data over HTTP/JSON. Easier to consume from scripts. Good support on Cisco IOS-XE.
  • gNMI (gRPC Network Management Interface): Google/OpenConfig’s answer. Binary protobuf encoding, streaming telemetry built in. This is where the industry is heading. Arista, Cisco, Juniper, Nokia, and Sonic all support it.
from pygnmi.client import gNMIclient

with gNMIclient(
    target=("router1.lab", 6030),
    username="admin",
    password="admin",
    insecure=True,
) as gc:
    result = gc.get(path=["openconfig-interfaces:interfaces"])
    for iface in result["notification"][0]["update"]:
        print(iface)

If you are building new automation against modern platforms, default to gNMI. The streaming telemetry capability alone is worth the investment.

SSH/CLI: Still Necessary

Plenty of devices will never get an API. Legacy Cisco IOS, older Junos versions, random vendor appliances — these only speak CLI over SSH. You need tools that handle this well.

CLI Parsing

This was the entire focus of my 2020 post. The tools have matured but the category is the same: convert unstructured CLI output into structured data.

TextFSM and NTC Templates

NTC Templates remains the largest community-maintained collection of TextFSM templates. Covers hundreds of commands across Cisco, Arista, Juniper, and others. The workflow: run a command, pipe output through a template, get a list of dicts.

The limitation is that every new command or output variation needs a new template or template update. The community does a good job, but you will inevitably hit gaps.

TTP (Template Text Parser)

TTP uses Jinja2-like templates to define parsing logic. More expressive than TextFSM for nested structures. If you have hierarchical output (like show running-config sections), TTP handles it more naturally.

scrapli

scrapli is a modern SSH/Telnet client for network devices. Fast, well-typed, supports both sync and async. The companion libraries scrapli-netconf and scrapli-community extend it to NETCONF and additional platforms. It has largely replaced Netmiko for new projects in my experience — the API is cleaner and performance is better.

NAPALM

NAPALM provides a vendor-agnostic API for common operations: get facts, get interfaces, get BGP neighbors, load config, commit/rollback. It abstracts away the differences between vendors. Still useful, though the getter coverage varies by platform. Works well as a Nornir plugin.

pyATS and Genie

Cisco’s pyATS framework includes Genie parsers that cover a huge number of Cisco CLI commands. The parsers are solid and actively maintained. pyATS also includes a testing framework for before/after comparison, which makes it valuable beyond just parsing.

LLMs for Parsing

This is the newest entrant. For commands without existing templates, you can send raw CLI output to an LLM and get structured JSON back. I wrote about this approach in a separate post. It works surprisingly well for one-off parsing, but I would not use it in a production pipeline where you need deterministic, consistent output. Good for exploration, prototyping, and handling the long tail of obscure commands.

Testing and Validation

This category barely existed in 2020. Now it is essential.

Batfish

Batfish is a network configuration analysis tool. You feed it device configs and it builds a model of your network — routing tables, ACLs, reachability. Then you can query it: “Can host A reach host B on port 443?” or “What happens if this link goes down?”

The key insight: you run Batfish against your configs before deploying them. It is a pre-deployment safety net.

from pybatfish.client.session import Session

bf = Session(host="localhost")
bf.set_network("production")
bf.init_snapshot("/path/to/configs", name="candidate")

# Check for undefined references in configs
issues = bf.q.undefinedReferences().answer().frame()
print(f"Found {len(issues)} undefined references")

# Test reachability
reachability = bf.q.reachability(
    pathConstraints=PathConstraints(startLocation="@enter(core-rtr-01)")
).answer().frame()

Suzieq

Suzieq is a network observability tool that collects state from devices (via SSH, REST, or native APIs) and stores it in a time-series format. You can query current state, track changes over time, and run assertions (“all BGP sessions should be Established”).

Think of it as “show commands as a database” with history. Incredibly useful for troubleshooting and compliance checks.

pytest with Network Plugins

The Python testing ecosystem applies directly to network automation. Write pytest tests that validate your network state:

import pytest
from nornir_utils.plugins.functions import print_result

def test_all_bgp_sessions_established(nornir):
    results = nornir.run(task=napalm_get, getters=["bgp_neighbors"])
    for host, result in results.items():
        for peer, details in result.result["bgp_neighbors"]["global"].items():
            assert details["is_up"], f"BGP session to {peer} is down on {host}"

Telemetry and Observability

Streaming Telemetry with gNMI

The old model was SNMP polling every 5 minutes. The new model is gNMI streaming telemetry where devices push data at sub-second intervals. Interface counters, CPU utilization, BGP state changes — all streamed as they happen.

Telegraf with its gnmi input plugin is the common collector. Feed it into InfluxDB or Prometheus, visualize with Grafana. This is table stakes for modern network monitoring.

OpenConfig Models

OpenConfig provides vendor-neutral YANG models for network configuration and telemetry. Instead of learning each vendor’s native model, you write automation against OpenConfig models and it works across Arista, Cisco, Juniper, and Nokia (with varying degrees of completeness, admittedly).

The models cover interfaces, BGP, OSPF, MPLS, ACLs, system management, and more. Not perfect, but getting better every year.

Infrastructure as Code and GitOps

The most mature network automation teams treat configs like application code:

  1. Network intent is defined in the source of truth (NetBox/Nautobot)
  2. Config templates generate device configs
  3. Batfish validates configs pre-deployment
  4. Changes go through pull request review
  5. CI/CD pipeline deploys approved changes
  6. Telemetry confirms the change was successful

Tools like Containerlab let you spin up network topologies in Docker for testing. You can validate your automation against virtual Arista, Nokia, or Juniper devices before touching production.

What Has Changed Since 2020

To summarize the major shifts:

  • gNMI and OpenConfig went from “interesting spec” to “production default” on major platforms
  • NetBox became the undisputed source of truth standard, with Nautobot as a strong alternative
  • Nornir matured into the go-to Python framework, eating into Ansible’s share for complex workflows
  • Batfish made pre-deployment validation practical
  • Suzieq created the network observability category
  • Terraform expanded beyond cloud into network device management
  • Containerlab made network CI/CD pipelines feasible
  • LLMs appeared as a viable tool for parsing, troubleshooting, and config generation
  • scrapli replaced Netmiko as the modern choice for SSH-based device interaction
  • Streaming telemetry replaced SNMP polling in greenfield deployments

The original post listed six parsing tools and called it a landscape. The real landscape is the full pipeline from source of truth to observability, with parsing as just one component. The industry has grown up.

! Was this useful?