Network automation is software making the configuration changes and checks an engineer would otherwise type into each device. It reaches devices three ways: screen scraping the CLI over SSH, NETCONF with XML over SSH on TCP port 830 by default, or RESTCONF over HTTPS with TLS required.
NETCONF can stage changes in a candidate datastore and use a confirmed commit that reverts after 600 seconds unless confirmed. Ansible supports all three and says CLI over SSH is the most common.
- Network automation replaces hand-typed device changes with software
- Screen scraping drives the CLI; it works where no API exists
- NETCONF uses XML over SSH, TCP port 830 by default
- A NETCONF confirmed commit reverts after 600 seconds unless confirmed
- RESTCONF carries YANG-modeled data over HTTPS and requires TLS
On this page
What it automatesWhat network automation actually automates
Network automation covers any task where an automated process, rather than a person at a terminal, makes or checks a change on network equipment, across networks of any size.
Configuration management. For example, adding a VLAN to forty switches, updating an access list on every branch firewall, rotating SNMP credentials, pushing a new NTP server. The same change made by hand forty times is forty chances for a typing error, and forty times the engineering time.
Validation and state collection. Reading interface counters, neighbor tables, routing tables and software versions from every device and comparing them to what they should be. Much of the value of network automation is in the reading, because these automated tasks tell you whether the network matches its design, and how it is performing, before anyone changes anything.
Compliance, security and drift. Checking that every device still has the security and management configuration it is supposed to have, which is the same problem infrastructure as code calls drift, applied to boxes that were historically configured by hand.
Provisioning new devices. Bringing a device from factory default to a working configuration. The ipSpace.net knowledge base notes a practical limit here: tools that run on top of a telnet or SSH session can only connect to an already-configured device, so a device straight out of the box needs a zero touch provisioning process first.
The benefits of network automation
The case for network automation is the same in a ten switch office and a data center.
- Fewer errors. Manual processes fail through typing mistakes and skipped steps. An automated task runs the same way every time.
- Less time on repetitive tasks. Network management work that took an afternoon of logins becomes one reviewed change, which frees engineers for design and troubleshooting.
- Consistency. Every device gets the same security and management configuration, so the network infrastructure matches its documentation.
- Faster recovery. Backups and a known intended state mean a failed device can be replaced and restored without rebuilding its configuration from memory.
The typesTypes of network automation
Network automation is usually described in four types, in rising order of ambition.
Script-driven automation. An engineer writes scripts, most often in Python, to automate one task such as a backup or a VLAN change. It is where most teams start, and it depends on the person who wrote it.
Tool-based automation. A configuration management tool such as Ansible holds the inventory, the templates and the run history, so automated processes are repeatable by anyone on the team and can be reviewed like code.
Controller-based and intent-based networking. A controller, as in software-defined networking or a cloud managed network, owns the devices. The administrator states the intended policy, and the controller works out and applies the device configuration.
Network orchestration. Orchestration chains automated tasks across systems into one workflow: a ticket is approved, addresses are allocated, the network, the firewall and the cloud network are configured, and monitoring is updated.
The interfacesThree ways software talks to a network device
The interface matters more than the network automation tool, because it decides what the software can know about the change it just made.
Screen scraping, CLI over SSH. The software opens an SSH session, sends the same commands a person would type, and parses the text that comes back. ipSpace.net describes screen scraping as automating interaction with devices that have no native APIs, and lists tools in this category such as Pexpect, Netmiko and NAPALM, and Ansible used with command and configuration modules.
It works on any device with a command line reachable over SSH, which is its strength in multi-vendor networks. Its weakness is that command output is written for people: a software upgrade that changes a column or a message breaks the parser.
NETCONF, XML over SSH. RFC 6241 defines the Network Configuration Protocol as a way to install, manipulate and delete the configuration of network devices, using XML-encoded data and operations realized as remote procedure calls.
RFC 6242 runs it over SSH as the netconf subsystem and requires servers to offer that subsystem by default on the IANA-assigned TCP port 830, so that NETCONF traffic can be identified and filtered by firewalls. The data comes back as structure, not as text to be parsed.
RESTCONF, HTTPS with YANG data. RFC 8040 describes an HTTP-based protocol that provides a programmatic interface to data defined in YANG, using the datastore concepts NETCONF defines. It is the same model through a web-style API, and the RFC is explicit about security: a RESTCONF server must support TLS, and RESTCONF must not be used over HTTP without it.
What ties the last two together is YANG. RFC 7950 defines YANG as a data modeling language for configuration data, state data, remote procedure calls and notifications. A YANG model says what an interface or a routing instance looks like on that device, which is what lets software change it without guessing from text.
Models, not textWhy a configuration model beats parsing text
The difference is not style. NETCONF has operations built for making network changes safely, and screen scraping has no equivalent.
A candidate configuration to work in. RFC 6241 defines a candidate configuration datastore as one that can be manipulated without impacting the device's current configuration and then committed to the running configuration.
The whole change is assembled, validated if the device supports validation, and applied at once. The RFC also notes that not all devices support a candidate datastore, which is worth checking before designing around it.
A commit that undoes itself. With the confirmed commit capability, a confirmed commit must be reverted if a confirming commit is not issued within the timeout period, which RFC 6241 sets at 600 seconds by default.
A change that cuts off the automation's own access to the device rolls back on its own after ten minutes, instead of waiting for someone to drive to the site.
A lock against everyone else. The NETCONF lock operation lets a client lock the configuration datastore so a change is made without interference from other NETCONF clients, from non-NETCONF clients such as SNMP and CLI scripts, and from human users. The RFC describes these locks as intended to be short-lived.
Structured answers. When the software reads state through a YANG model, a field is a field. Nothing depends on the spacing of a table printed for a person, and nothing breaks when the vendor rewords a message.
Screen scraping is still sometimes the only option. Some devices offer nothing but a command line. The practical answer is to use structured interfaces where the device offers them and to confine scraping to the devices that give you no choice.
The toolsNetwork automation tools, by the job they do
Network automation tools fall into a few groups, and most working setups combine one from each. The descriptions below are the projects' own.
| Job | Tool | What its documentation says it is |
|---|---|---|
| Source of truth | NetBox | Defines the intended state of the network, and does not interact with network nodes directly |
| CLI connections | Netmiko | A multi-vendor library to simplify CLI connections to network devices |
| Vendor abstraction | NAPALM | A Python library with a unified API across different vendors' devices |
| Python framework | Nornir | A pure Python automation framework that handles inventory and dispatches tasks |
| Configuration management | Ansible | Covered in the next section |
Vendor controllers and cloud managed networking dashboards are network automation tools as well. They automate the vendor's own devices well, and the open source tools above are what teams use when the infrastructure is mixed. Monitoring sits alongside, in network management software.
AnsibleWhere Ansible fits
Ansible network automation is documented as its own case, and its documentation explains how it differs from the server automation Ansible is better known for.
Network modules run on the control node. Most Ansible modules run on the machine being managed. Ansible's network documentation says the opposite for network devices: because the majority of network devices cannot run Python, Ansible network modules are executed on the control node, where ansible or ansible-playbook runs.
It speaks all three interfaces. Because the modules run on the control node, they can use multiple communication protocols. The documentation lists CLI over SSH through network_cli, XML over SSH through netconf, and API over HTTP or HTTPS through httpapi, and states that the most common protocol is CLI over SSH.
Backups land on the control node. Network configuration is not written in files on the device the way a Linux configuration is, so Ansible network modules that offer a backup write it on the control node.
The tool does not choose the interface for you. A playbook built on CLI modules is screen scraping with better organization. The same tool pointed at NETCONF on devices that support it gets the candidate datastore and confirmed commit described above. How Ansible compares with Terraform for servers and cloud resources is covered on the infrastructure as code page.
Starting smallStarting small without breaking the network
Start by automating the reading, not the writing. For example, collecting versions, interface states and configuration backups from every device is useful on day one, cannot cause an outage, and builds the inventory every later automated process needs. Network operations teams also get performance and state data they did not have before.
Keep a source of truth. Network automation that pushes configuration needs something to push from: the intended VLANs, addresses and policies, written down in one place. Without it, automation reproduces whatever the last device had, mistakes included.
Use the safest interface each device offers. Where a device supports NETCONF with a candidate datastore and confirmed commit, use them. Where it only has a command line, make the change small and the rollback obvious.
Protect the credentials the automation uses. A service account that can change every device in the network is the most valuable credential in it. Allow NETCONF port 830 and SSH to the devices only from the automation host.
Store the credential in a secrets manager, scope it, and log what it does, the same way network management software credentials should be handled.
Change one site before all sites. The value of network automation is that it lets you automate the same change across all networks at the same time. That is also the risk.
PitfallsWhere people go wrong
Choosing a network automation tool before understanding the devices. The interfaces the network equipment supports decide what the automation can do safely. Inventory them first.
Scraping text on devices that offer NETCONF. It works until the next software upgrade changes the output, and it gives up the candidate datastore and the confirmed commit.
Pushing changes with no way back. A change that locks the automation out of the device needs a revert that does not depend on reaching the device. On NETCONF that is the confirmed commit; on a command line it has to be designed.
Letting RESTCONF run without TLS. RFC 8040 forbids it, and a management interface in plain text carries credentials and configuration anyone on the path can read.
Forgetting that people still log in. Network automation and manual changes on the same device collide. NETCONF locks exist for exactly this reason, and on devices without them the process has to prevent it.
Treating the network automation account as a normal user. It is a key to every device at once, and its security deserves stronger storage, scope and monitoring than any individual engineer's login.
ComparisonThree ways software talks to a network device
| Criterion | CLI over SSH | NETCONF | RESTCONF |
|---|---|---|---|
| Defined by | Each vendor's command line | RFC 6241 | RFC 8040 |
| Transport | SSH | SSH, TCP 830 by default | HTTPS, TLS required |
| Data format | Text written for people | XML | XML or JSON |
| Data model | None | YANG | YANG |
| Stage a change before applying | No | Candidate datastore, if supported | Uses NETCONF datastore concepts |
| Automatic revert on lost access | No | Confirmed commit, 600 s default | Not covered here |
| Works on devices with no API | Yes | No | No |
The last row is the only one CLI scraping wins, and it is the reason it has not gone away.
FAQFrequently asked questions
What is network automation?
Using software to make and verify configuration changes, collect state and performance data, and check compliance on network devices as automated tasks, instead of an engineer typing commands into each device by hand.
What is the difference between NETCONF and RESTCONF?
NETCONF, RFC 6241, exchanges XML-encoded remote procedure calls over SSH. RESTCONF, RFC 8040, is an HTTP-based interface to the same YANG-modeled data using NETCONF's datastore concepts, and it must run over TLS.
What port does NETCONF use?
TCP port 830 by default. RFC 6242 requires NETCONF servers to offer the netconf SSH subsystem on the IANA-assigned port 830 by default, and says servers should be configurable to allow other ports.
What is YANG?
A data modeling language, defined in RFC 7950 as version 1.1, used to model configuration data, state data, remote procedure calls and notifications for network management protocols such as NETCONF and RESTCONF.
What is screen scraping in network automation?
Automating a device through the same command line a person uses and parsing the text it returns. ipSpace.net describes it as automating interaction with devices that have no native APIs.
What is a NETCONF confirmed commit?
A commit that must be confirmed by a second commit within a timeout, 600 seconds by default in RFC 6241. If the confirmation never arrives, the device reverts the change, which protects against a change that cuts off access.
Does Ansible use NETCONF?
It can. Ansible's network documentation lists three connection types: network_cli for CLI over SSH, netconf for XML over SSH, and httpapi for APIs over HTTP or HTTPS. It notes that CLI over SSH is the most common.
Why do Ansible network modules run on the control node?
Because most network devices cannot run Python, which Ansible modules are written in. The modules run on the control node and talk to the device over the chosen protocol.
Can network automation work on old devices?
Through screen scraping, if the device has a command line reachable over SSH or telnet. Tools that work that way can only reach devices that are already configured, so new devices need a provisioning step first.
Is network automation risky?
It makes the same change across every device at the same time, which is both the benefit and the security risk. Starting with read-only collection, using candidate datastores and confirmed commits where devices support them, and changing one site first all reduce it.
What is a source of truth?
The place the intended network is written down, such as VLANs, addresses and policies, that automation reads from when it builds configuration. Without one, automation has nothing reliable to enforce.
Does network automation replace SNMP?
They overlap on reading state. SNMP is a monitoring protocol at heart, while NETCONF and RESTCONF were designed for configuration as well as state, with structured models and, in NETCONF, staged and confirmed commits.
Keep readingRelated concepts
Read next · Tools Network Management Software, and the Three Questions It Has to Answer The monitoring side of the same devices, and the credentials both depend on. Open this next11 min- Operations · 11 min Infrastructure as Code, and the File That Knows What Exists The same drift and state problem for servers and cloud resources, and Ansible against Terraform.
- Ports · 10 min Port 22, and Why Changing It Is Not the Fix People Think The transport that both screen scraping and NETCONF ride on.
- Operations · 8 min PowerShell vs Bash, and Why the Platform Decides for You The shells underneath that work: objects in PowerShell, text in Bash, and when each fits.