Tự động hóa mạngNetwork Automation

Part of the Network Engineer Roadmap knowledge base.

Overview

Network automation is the practice of using software — scripts, APIs, structured data, and tooling — to configure, manage, test, and operate network devices and services instead of typing commands by hand into a CLI, one box at a time.

For decades the network engineer’s primary interface was the terminal: SSH into a switch, paste a block of config, save, move on to the next device. That workflow does not survive contact with scale. When you have 5 devices you can log in to each one. When you have 500, or 5,000, or a fleet spread across cloud VPCs and on-prem data centres, manual configuration becomes slow, inconsistent, and dangerous — a single fat-fingered ACL or a subnet mask typed wrong at 2 a.m. can black-hole traffic for an entire region.

The reasons to automate are concrete:

The trajectory of the industry is a move from the CLI to Infrastructure as Code (IaC): network state is described in text files (YAML, HCL, Jinja2 templates, YANG models), stored in version control, reviewed via pull requests, and applied by tooling. This mindset — treating the network the way software teams treat applications — is often called NetDevOps: bringing DevOps culture and tooling (Git, CI/CD, testing, code review, a single source of truth) to network engineering.

This note builds up from the foundations (Linux, shell, APIs) through the core tools (Python, Ansible, Terraform) to the operational practices (CI/CD, version control, drift detection, source of truth) that make automation reliable in production. It pairs closely with the DevOps notes on Infrastructure as Code and Configuration Management, and assumes familiarity with the core protocols and cloud networking covered earlier.

Fundamentals

Linux and the shell: the non-negotiable foundation

Almost every automation tool runs on Linux, most network operating systems are Linux under the hood (Cumulus, SONiC, Arista EOS, Cisco NX-OS, IOS-XR all expose a Linux shell), and every CI runner and container is a Linux box. You do not need to be a kernel hacker, but you must be comfortable with:

• Navigating and text processing — grep, sed, awk, cut, sort, uniq, pipes (|), and redirection. Parsing a table of interfaces or filtering log lines is a daily task.
• File permissions, SSH keys, and ssh_config — automation authenticates to devices over SSH; key management and ~/.ssh/config jump-host settings matter.
• Package management and virtual environments — apt/yum, and for Python pip + venv/virtualenv to isolate dependencies per project.
• Shell scripting — a small bash script to loop over a device list, back up configs with scp, or trigger a pipeline. Shell is the glue; Python is the heavy lifting.
• Networking from the host — ip addr, ip route, ss, tcpdump, dig, curl — the same tools you use to debug the host also debug what your automation is doing on the wire.

A quick example — back up the running config of every device in a list, in parallel:

#!/usr/bin/env bash
# backup-configs.sh — pull running-config from each device over SSH
set -euo pipefail

DEVICES_FILE="devices.txt"        # one host per line
BACKUP_DIR="backups/$(date +%F)"
mkdir -p "$BACKUP_DIR"

while read -r host; do
  [[ -z "$host" || "$host" == \#* ]] && continue
  echo "Backing up $host ..."
  ssh -o ConnectTimeout=10 "netadmin@${host}" 'show running-config' \
    > "${BACKUP_DIR}/${host}.cfg" &
done < "$DEVICES_FILE"

wait   # let all background SSH jobs finish
echo "Done. Configs saved to ${BACKUP_DIR}/"

This is automation at its simplest, and it already gives you dated, version-controllable snapshots of every device.

APIs for networking

The CLI was designed for humans; APIs (Application Programming Interfaces) are designed for machines. Modern network devices expose one or more programmatic interfaces that return structured data (JSON or XML) instead of the free-form text a show command emits. Structured data is the whole point — you no longer have to write brittle regular expressions to scrape a value out of CLI output; you ask for interfaces.GigabitEthernet0/1.oper-status and get back a clean field.

The main interfaces you will meet:

• REST is the general web pattern: HTTP verbs (GET, POST, PUT, PATCH, DELETE) act on resources addressed by URLs, with a JSON body. Most cloud and controller APIs are REST.
• NETCONF (RFC 6241) is purpose-built for network configuration. It runs over SSH, encodes everything in XML, and — crucially — supports a candidate configuration with explicit commit/rollback and transactions, so a multi-device change can be validated and applied atomically or backed out cleanly.
• RESTCONF (RFC 8040) is a REST/HTTP front end onto the same YANG data trees that NETCONF exposes — friendlier for developers who prefer JSON and URLs to XML and RPCs.
• gNMI (gRPC Network Management Interface) is the modern high-performance option, built on gRPC/Protobuf, and is the standard for streaming telemetry (subscribe once, receive a push stream of counter changes) as well as config.

YANG data models

YANG (RFC 7950) is a modelling language that describes the structure of configuration and operational state — what fields exist, their types, constraints, and hierarchy — independently of the wire encoding. NETCONF, RESTCONF, and gNMI all carry data shaped by YANG models. Two families matter:

• Vendor/native models — each vendor ships YANG models for its own features.
• OpenConfig — a vendor-neutral set of YANG models driven by network operators (Google, AT&T, and others) so the same model works across Cisco, Juniper, Arista, and Nokia. This is the dream of “write once, run on any vendor.”

SNMP vs API for configuration

SNMP is excellent at reading counters and sending traps, but it was never good at writing configuration — SNMP SET is clunky, poorly supported for config, and has weak transactional semantics. The industry consensus is: use SNMP (or better, gNMI streaming telemetry) for monitoring, and use NETCONF/RESTCONF/gNMI or a REST API for configuration. SNMP is legacy for config; treat it as read-mostly.

Idempotency: the core mental model

The single most important concept in configuration automation is idempotency: applying the same operation multiple times produces the same result as applying it once, and only makes a change when the current state differs from the desired state.

An imperative CLI script that runs interface Gi0/1 / ip address 10.0.0.1 255.255.255.0 will re-issue those commands every run whether or not they are already in place. An idempotent tool instead reads the current state, compares it to the declared desired state, and issues commands only if needed — reporting changed=0 when the device is already correct. Idempotency is what makes it safe to run your automation repeatedly (e.g. on every CI run) without causing churn, and it is the foundation of drift detection discussed later.

Key Concepts

Python for network automation

Python is the lingua franca of network automation: readable, batteries-included, and backed by a rich ecosystem of libraries installed via pip (usually into a per-project virtual environment). The key libraries:

• Netmiko is where most people start: it abstracts away the messy details of SSH, enable mode, terminal paging, and per-vendor quirks, and lets you send commands and get output back as text.
• NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) sits one level higher — it gives you structured getters that return the same dict shape regardless of vendor, plus a safe config-replacement workflow with diff and rollback.
• Nornir provides inventory and a threaded task runner in pure Python, so you can run Netmiko/NAPALM tasks across hundreds of devices concurrently without writing your own thread pool.
• Scapy is for the packet plumber — building custom packets to test firewall rules, reachability, or protocol behaviour.

A small, real Netmiko example — connect to a switch, push a VLAN, and read it back:

#!/usr/bin/env python3
"""Create a VLAN on a Cisco IOS switch and verify it, using Netmiko."""
from netmiko import ConnectHandler

device = {
    "device_type": "cisco_ios",
    "host": "192.0.2.10",
    "username": "netadmin",
    "password": "s3cret",          # in practice: read from a vault / env var
    "secret": "enablepass",        # enable-mode password
}

vlan_id = 42
vlan_name = "AUTOMATION-LAB"

with ConnectHandler(**device) as conn:
    conn.enable()                                  # enter privileged EXEC

    # Idempotent-ish: send_config_set only changes what it needs to
    config_commands = [
        f"vlan {vlan_id}",
        f"name {vlan_name}",
    ]
    output = conn.send_config_set(config_commands)
    print(output)

    conn.save_config()                             # write mem

    # Read it back as verification
    result = conn.send_command("show vlan brief", use_textfsm=True)
    print(result)   # with TextFSM, this is structured data (list of dicts)

The use_textfsm=True flag is worth noting: it runs the raw CLI output through a TextFSM template so you get back a list of dictionaries instead of a text blob — a pragmatic bridge from screen-scraping toward structured data when a real API is not available.

A NAPALM example showing the multi-vendor, structured advantage:

import napalm

driver = napalm.get_network_driver("eos")   # or "ios", "junos", "nxos_ssh"
device = driver(hostname="192.0.2.20", username="netadmin", password="s3cret")

device.open()
facts = device.get_facts()                   # same keys on every platform
print(facts["hostname"], facts["os_version"], facts["uptime"])

interfaces = device.get_interfaces()         # structured dict, not text
for name, data in interfaces.items():
    state = "up" if data["is_up"] else "down"
    print(f"{name:20} {state}")

device.close()

Ansible for network devices

Ansible is the most widely used configuration-management tool for networks. Its defining properties for network work:

• Agentless — it does not require software installed on the device. It connects over SSH (or the device’s API) from a control node and pushes changes. This matters enormously for network gear, where you often cannot install an agent on a switch or router.
• Declarative and idempotent — you describe the desired state in a playbook (YAML); Ansible’s network modules figure out what commands to run and skip devices already in the target state.
• Inventory-driven — devices and their groupings/variables live in an inventory (INI or YAML), so the same playbook targets one device or a thousand.
• Huge module ecosystem — collections like cisco.ios, arista.eos, juniper.junos, cisco.nxos, plus generic ansible.netcommon modules for NETCONF/CLI.

A minimal inventory (inventory.yml):

all:
  children:
    ios_switches:
      hosts:
        sw1: { ansible_host: 192.0.2.10 }
        sw2: { ansible_host: 192.0.2.11 }
      vars:
        ansible_network_os: cisco.ios.ios
        ansible_connection: network_cli
        ansible_user: netadmin

A real playbook (configure-vlans.yml) that configures VLANs, an interface, and saves — idempotently:

---
- name: Configure access VLANs on IOS switches
  hosts: ios_switches
  gather_facts: false

  vars:
    vlans:
      - { id: 42, name: AUTOMATION-LAB }
      - { id: 50, name: VOICE }

  tasks:
    - name: Ensure VLANs exist
      cisco.ios.ios_vlans:
        config: "{{ vlans | map('combine', {'state': 'active'}) | list }}"
        state: merged          # merged = idempotent add, no wipe

    - name: Configure access port Gi0/1 into VLAN 42
      cisco.ios.ios_l2_interfaces:
        config:
          - name: GigabitEthernet0/1
            mode: access
            access:
              vlan: 42
        state: merged

    - name: Save running-config to startup-config
      cisco.ios.ios_config:
        save_when: modified     # only writes mem if something changed

    - name: Verify VLAN 42 is present
      cisco.ios.ios_command:
        commands: show vlan id 42
      register: vlan_check

    - name: Show verification output
      ansible.builtin.debug:
        var: vlan_check.stdout_lines

Run it with ansible-playbook -i inventory.yml configure-vlans.yml. On the first run Ansible reports changed; run it again and it reports ok with changed=0 — that is idempotency in action. The state: merged keyword is the idempotent verb: it adds/updates what you declared without deleting the rest of the config (contrast with replaced or overridden).

Terraform and Infrastructure as Code

Where Ansible shines at configuration management of existing devices, Terraform shines at provisioning — declaring and creating the infrastructure itself. In networking this most often means cloud networking resources: VPCs/VNets, subnets, route tables, security groups/firewall rules, load balancers, DNS zones and records, VPN gateways, and Transit Gateways (see cloud networking).

Terraform is:

• Declarative — you write HCL describing the desired end state, not the steps. Terraform computes the diff between current and desired and executes only what is needed. (Contrast imperative: a script that says “create X, then Y” — you own the ordering and the error handling.)
• State-based — Terraform keeps a state file recording what it manages, so it knows what to add, change, or destroy on the next apply.
• Provider-based — providers exist for AWS, Azure, GCP, Cloudflare, Infoblox, Cisco ACI, Palo Alto, NetBox, and more, so the same tool provisions across clouds and controllers.

A real snippet — an AWS VPC with a subnet, a security group, and a DNS record:

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" {
  region = "ap-southeast-1"
}

resource "aws_vpc" "main" {
  cidr_block           = "10.20.0.0/16"
  enable_dns_hostnames = true
  tags = { Name = "prod-vpc" }
}

resource "aws_subnet" "app" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.20.1.0/24"
  availability_zone = "ap-southeast-1a"
  tags = { Name = "prod-app-subnet" }
}

resource "aws_security_group" "web" {
  name   = "web-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    description = "HTTPS from anywhere"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_route53_record" "app" {
  zone_id = var.hosted_zone_id
  name    = "app.example.com"
  type    = "A"
  ttl     = 300
  records = ["10.20.1.10"]
}

variable "hosted_zone_id" { type = string }

The workflow is terraform init → terraform plan (shows the exact diff, a dry run) → terraform apply (executes it). The plan step is the safety net: you review precisely what will be created, changed, or destroyed before anything happens — the network equivalent of code review for infrastructure. See the DevOps Infrastructure as Code note for a deeper treatment of state, modules, and remote backends.

Configuration management vs provisioning, and drift detection

These two words describe different jobs and the tools reflect that split:

• Provisioning — creating infrastructure that did not exist: spin up a VPC, allocate a subnet, instantiate a firewall. Terraform (and CloudFormation, Pulumi) own this.
• Configuration management — managing the state of things that already exist: which VLANs are on a switch, which ACL lines, which NTP servers, which SNMP community. Ansible (and Nornir, Salt) own this.

The line blurs — Ansible can provision cloud resources, Terraform can push some config — but the mental model holds: provision with Terraform, configure with Ansible is a common, clean division.

Configuration drift is when the real, running state of a device diverges from the intended state defined in your code — someone made an emergency change at the CLI, a manual “temporary” fix that was never removed, or a device rebooted to an old config. Drift is the enemy of a reliable network. Automation gives you two ways to fight it:

• Detection — run your automation in --check/--diff (Ansible) or terraform plan mode on a schedule. Any non-empty diff is drift; alert on it.
• Remediation / enforcement — because your tooling is idempotent, simply re-running the playbook or terraform apply snaps the device back to the declared state. When the code is the source of truth, drift is self-healing.

CI/CD, version control, and source of truth

The final piece is treating network config the way software teams treat code — the heart of the NetDevOps approach.

• Version control (Git) — every playbook, template, Terraform file, and inventory lives in Git. You get history (“who changed the BGP config, when, and why”), diffs, branches, and the ability to roll back to any past known-good state.
• Code review via pull requests — no change reaches production without a second set of eyes. The PR is the change-management record.
• CI/CD pipelines — a pipeline (GitHub Actions, GitLab CI, Jenkins) runs on every PR and merge:
  1. Lint — yamllint, ansible-lint, terraform fmt -check, terraform validate.
  2. Validate / test — render templates, run ansible-playbook --check (dry run) or terraform plan against a lab or the live device in check mode; run pyATS/Batfish to validate the resulting config offline.
  3. Deploy — on merge to main, apply to production, often gated by a manual approval.
• Source of truth (SoT) — a single authoritative database of intended network state — devices, interfaces, IP addresses (IPAM), VLANs, circuits, cabling. NetBox is the de-facto open-source SoT. Automation reads the SoT to generate config (device data → Jinja2 template → config), rather than config being hand-written. This inverts the traditional model: the database is the truth, the device config is a rendered artifact, and drift is measured against the SoT.

The end-to-end NetDevOps loop: NetBox (intent) → Jinja2/templates → Git (PR + review) → CI (lint + test) → Ansible/Terraform (apply) → device → telemetry/plan (verify + detect drift) → back to intent.

Tool comparison

Best Practices

• Start small and idempotent. Automate one safe, repetitive, read-only task first (config backups, show collection). Build confidence, then move to writes. Always prefer idempotent tools/verbs (state: merged, terraform plan) over blind CLI pushes.
• Everything in Git. Playbooks, templates, Terraform, inventories, and ideally rendered configs. If it is not in version control, it does not exist. Never edit production by hand outside the pipeline — that creates drift.
• Never hard-code secrets. Use Ansible Vault, HashiCorp Vault, environment variables, or your CI’s secret store. Passwords and API tokens must never land in a Git commit.
• Always dry-run before applying. terraform plan and ansible-playbook --check --diff show exactly what will change. Review the diff like you would review code. Make plan a required, non-skippable CI stage.
• Test in a lab first. Use virtual labs — Containerlab, GNS3, EVE-NG, Cisco CML, or cloud sandboxes — to validate playbooks before they touch production. Offline validation with Batfish can catch reachability/ACL mistakes without any device.
• Enforce review and CI on every change. No merge without a passing pipeline (lint + validate) and at least one reviewer. The PR is your change ticket.
• Adopt a single source of truth. Drive config generation from NetBox (or equivalent) so intent lives in one place and devices become rendered artifacts. This makes drift detection meaningful.
• Detect drift continuously. Schedule periodic --check/plan runs and alert on any diff. Decide deliberately whether drift triggers an alert (human decides) or auto-remediation (pipeline re-applies).
• Prefer structured APIs over screen-scraping when available. NETCONF/RESTCONF/gNMI with YANG give you reliable, typed data; fall back to Netmiko + TextFSM only where no API exists.
• Make changes small and reversible. Small, frequent, reviewed changes beat big-bang rollouts. Keep rollback paths (Terraform state, NAPALM/NETCONF candidate+commit, config backups) ready.
• Build in verification. Every change task should be followed by a check task that confirms the intended end state (e.g. the VLAN exists, the route is present, the neighbour is up). Automate the “did it work?” question.

References

• Ansible Network Automation documentation
• Terraform documentation
• Netmiko (GitHub) and NAPALM documentation
• Nornir documentation
• RFC 6241 — NETCONF Configuration Protocol
• RFC 8040 — RESTCONF Protocol and RFC 7950 — The YANG 1.1 Data Modeling Language
• OpenConfig and gNMI specification
• NetBox — Network Source of Truth