Ansible Network Automation Configuration Example

The Ansible network automation platform is a widely used network automation tool that is easy to learn, making it capable of being efficient in addressing complex work that requires users to learn more about Ansible’s configuration management itself.

Ansible is an automation language that attracts network engineers because of its simplicity and power to interface with various network infrastructures and devices.
Deleted: Ansible utilizes Secure Socket Shell (SSH) to interface with the network device command-line interface (CLI), allowing remote access to the network device and removing the physical presence of a person.

 

Ansible For Network Automation

The example we’re going to discuss here makes use of the cli_command Ansible module to send CLI commands to the test device, which is a Cisco 3560 Switch. The ansible network modules that are specific to a certain vendor start with the OS name, like ios_* or eos_*.

Ansible network automation runs on the control node, which is how it interacts with the Command Line Interface (CLI) of the network device via the SSH protocol or its APIs, if available. The same network management device does not require an agent for operation; command-line arguments and easily understood configuration files are sufficient.

The best approach to getting started with Ansible network automation is to acquire basic network device information. This includes details that configure network devices, such as the device’s IP address, username, and password. Once this information is obtained, it can be used to configure the control node and establish a connection with the network device. Additionally, it is important to ensure that the control node has the necessary network modules installed for the specific vendor of the device being managed. We are going to gather Address Resolution Protocol (ARP) table data.

 

Ansible File Structure and Directory

Ansible can be run with a minimal setup, but this can result in a wide range of constructs. Creating a directory structure that distinguishes configuration data will be necessary for network engineers to address this problem. Below is a sample output of an Ansible directory and file structure:

├── ansible1.cfg
├── group_vars
│   ├── IOS_sw.yml
├── host_vars
│   └── test_sw.yml
├── inventory.yml
└── sh_arp.yml

 

The Ansible configuration belongs to the ansible1.cfg file; this file is not very important because the default settings are probably the best option in this case. It can be seen in the INI format, which uses name = value syntax. For example, device fact gathering is disabled gathering, = explicit because it is explicitly designed for non-network equipment. The inventory file name is specified, and retrying will not be allowed, as seen below.

    1  [defaults]
    2  gathering = explicit
    3  inventory = inventory.yml
    4  retry_files_enabled = False

 

The directory group_vars contains variable definitions that apply to various groups. A YAML formatted file found in this directory has Internetwork Operating Systems (IOS) variables for switches.

Using IOS_switches.yml, we define the Ansible module network_cli and set the OS to ios, and provide the login credentials. The highly recommended secured configuration utilizes Ansible vaults or SSH keys, which provide an additional layer of security by keeping the credentials from being stored in plain-text format, but including the credentials in a variable file can be simpler, as demonstrated below.

     1  ---
     2  # IOS_switches variables
     3  ansible_connection: network_cli
     4  ansible_network_os: ios
     5  ansible_become: yes
     6  ansible_become_method: enable
     7  ansible_become_password: "foobar"
     8  
     9  ansible_user: tester
    10  ansible_ssh_pass: foobar

 

The inventory.yml file has the inventory of the devices together with their device groups in YAML format. Network devices can be put into various groups.

     1  ---
     2  all:
     3    children:
     4      IOS_switches:
     5        hosts:
     6          test_sw
     7      IOS_routers:
     8        hosts:
     9          router1
    10      access:
    11        hosts:
    12          test_sw
    13      core:
    14        hosts:
    15          router1

 

The Ansible playbook here is the sh_arp.yml file, which is in YAML format and controls Ansible’s execution of the command to display the ARP table in the output. Ansible playbooks can contain a variety of plays, each with many tasks.

In the example below, we play Get ARP data where the hosts are listed in the IOS_switches group. This playbook has two tasks, each defined by a different demarcation. In the current working directory, this file will be saved. These names are simple text strings that will be shown in the output. The ios_command on the Ansible automation platform is named cli_result.

The second task will send out the saved output based on the list of stdout_lines stored in the file cli_result.

     1  ---
     2  - name: Get ARP data
     3    hosts: IOS_switches
     4    tasks:
     5      - name: "Task 1: Get output of show arp on IOS"
     6        ios_command:
     7          commands: "show arp"
     8        register: cli_result
     9  
    10      - name: "Task 2: Display stdout_lines[0]"
    11        debug:
    12          msg: "{{ cli_result.stdout_lines[0] }}"

 

So when we run an Ansible script it can be seen as below;

     1     $ ansible-playbook sh_arp.yml
     2     
     3     PLAY [Get ARP data] ***************************************************
     4     
     5     TASK [Task 1: Get output of show arp on IOS] *****************************
     6     ok: [test_sw]
     7     
     8     TASK [Task 2: Display stdout_lines[0]] ***********************************
     9     ok: [test_sw] => {
    10         "msg": [
    11             "Protocol  Address     Age (min)  Hardware Addr   Type   Interface",
    12             "Internet  192.168.1.108      -   bcc4.933e.49c0  ARPA   Vlan1",
    13             "Internet  192.168.1.126      5   f894.c220.2177  ARPA   Vlan1",
    14             "Internet  192.168.1.133      1   88c2.55fb.9ce7  ARPA   Vlan1",
    15             "Internet  192.168.1.138      0   a860.b60a.7a3a  ARPA   Vlan1"
    16         ]
    17     }
    18     
    19     PLAY RECAP ***************************************************************
    20     test_sw                    : ok=2    changed=0    unreachable=0    failed=0   
    21    

 

Ansible’s True Strength

The strength of network automation using Ansible is not about the simplicity of one device, its true advantage is running a single command and having multiple devices executing it. It enables you to dynamically build configurations for many devices which can of course be stored locally for later use and also gives you the capability to check your network’s connections if they are properly implemented based on the design and are running smoothly.

Ansible can do a lot of things to streamline the network infrastructure employing automating tasks for network administrators using network automation tools. Network engineers can use the playbook configuration to learn about networking concepts that are readily available yet powerful and easy to learn.


Download our Free CCNA Study Guide PDF for complete notes on all the CCNA 200-301 exam topics in one book.

We recommend the Cisco CCNA Gold Bootcamp as your main CCNA training course. It’s the highest rated Cisco course online with an average rating of 4.8 from over 30,000 public reviews and is the gold standard in CCNA training:

cisco ccna gold bootcamp