Ansible for Network Automation

Ansible is an open-source automation tool developed by Red Hat. It is designed to automate IT tasks such as configuration management, application deployment, and task orchestration. For networking, Ansible allows engineers to manage network devices (routers, switches, firewalls) in a consistent, repeatable, and scalable way. Before Ansible, network automation was often done with custom scripts (Python, Expect, TCL) that were brittle and hard to maintain. Ansible provides a standardized framework with reusable modules, idempotent operations (applying the same configuration multiple times yields the same result), and a simple YAML syntax that even non-programmers can learn.

Ansible uses a push model: the control node (where Ansible is installed) connects to managed nodes (network devices) via SSH and executes tasks. Here is the step-by-step flow:

- Control Node: Any machine with Python and Ansible installed. Linux is preferred; Windows can be used via WSL. No agents are installed on managed nodes. - Managed Nodes: Network devices that support SSH. No additional software is required. - Inventory File: Default location /etc/ansible/hosts. Example:

[routers]
  R1 ansible_host=192.168.1.1 ansible_user=admin ansible_ssh_pass=cisco ansible_connection=network_cli ansible_network_os=ios
  R2 ansible_host=192.168.1.2 ansible_user=admin ansible_ssh_pass=cisco ansible_connection=network_cli ansible_network_os=ios

- Playbook: Written in YAML. Example:

---
  - name: Configure OSPF on routers
    hosts: routers
    gather_facts: no
    tasks:
      - name: Enable OSPF
        ios_config:
          lines:
            - router ospf 1
            - network 10.0.0.0 0.255.255.255 area 0
          provider: "{{ cli }}"

- Modules: Cisco-specific modules are in the cisco.ios collection. Key modules: - ios_config: Sends configuration commands. - ios_command: Sends show commands and returns output. - ios_facts: Gathers device facts. - Vault: Ansible Vault encrypts sensitive data like passwords. Use ansible-vault create secrets.yml.

To verify Ansible is working correctly:

1. Ping module: Tests SSH connectivity.

ansible routers -m ping -i inventory.ini

Output:

R1 | SUCCESS => {
       "changed": false,
       "ping": "pong"
   }
   R2 | SUCCESS => {
       "changed": false,
       "ping": "pong"
   }

2. Gather facts:

ansible routers -m ios_facts -i inventory.ini

Output (truncated):

R1 | SUCCESS => {
       "ansible_facts": {
           "ansible_net_hostname": "R1",
           "ansible_net_version": "15.7(3)M",
           "ansible_net_interfaces": {
               "GigabitEthernet0/0": {
                   "macaddress": "aabb.cc00.0100",
                   "ipv4": [{"address": "192.168.1.1", "masklen": 24}]
               }
           }
       },
       "changed": false
   }

3. Run a playbook:

ansible-playbook ospf.yml -i inventory.ini

Ansible relies on SSH (TCP/22) for connectivity. It does not use SNMP or NETCONF by default (though it can use them via specific collections). For Cisco devices, the network_cli connection plugin emulates a terminal session, sending commands and waiting for prompts. This is similar to how a human would use SecureCRT or PuTTY. Ansible also supports ansible_connection=local for older devices, but network_cli is preferred for IOS.

In a real enterprise network, Ansible is used to automate repetitive tasks that are error-prone when done manually. For example, a global company with 500 branch routers needs to add a new loopback interface for management on every device. Instead of SSHing to each router and typing interface loopback0, ip address 10.0.0.x 255.255.255.255, a network engineer writes a playbook that loops through an inventory and configures each device. The playbook can also generate unique IPs using a variable from the inventory (e.g., {{ inventory_hostname }}). This reduces a week-long task to a few minutes and eliminates typos.

Another scenario: compliance auditing. A financial institution must ensure that every switch has SSH version 2 enabled and no telnet access. An engineer writes a playbook that checks the running config and reports any violations. The playbook can even auto-remediate by applying the correct configuration. This is done daily via a cron job on the Ansible control node. The results are logged to a file for audit trails.

Common pitfalls include misconfigured inventory (wrong IP or credentials), playbook syntax errors (YAML is whitespace-sensitive), and network issues (SSH timeouts). When a playbook fails halfway, Ansible reports the failure but does not roll back changes. Engineers must implement error handling using rescue blocks or manually revert. Also, Ansible's push model means the control node must have network access to all devices; in a segmented network, you may need a jump box. Despite these challenges, Ansible is widely adopted because it is agentless and uses existing SSH infrastructure.