Hands-On Lab: Using Ansible for Network Device Automation

Lab Objective

Set up an Ansible inventory file listing two routers, write a playbook that configures an identical login banner on both simultaneously, execute it from a separate control node, and verify the change applied correctly to each device without installing any agent software on the routers themselves.

Lab Purpose

Guestshell, covered in the previous lab, runs automation locally on a single device. Ansible instead runs from a separate control node and manages many devices at once over standard SSH, requiring no agent or special software installed on the managed devices — a fundamentally different automation model suited to making the same change across a whole fleet of devices consistently.

Lab Topology

Ansible control node ---- SSH ---- R1: 192.168.60.1
                          SSH ---- R2: 192.168.61.1

Both routers already have SSH access
configured with a local username/password

Task 1: Create the Ansible Inventory File

Create an inventory file listing both routers with their connection details.

Task 2: Write a Playbook to Configure a Banner

Write a playbook using the ios_banner module to set an identical login banner on both devices.

Task 3: Run the Playbook

Execute the playbook against the inventory and observe the connection and configuration process for both routers.

Task 4: Verify the Banner on Both Routers

Confirm each router now displays the configured banner.

Task 5: Verify No Agent Software Was Installed

Confirm the routers required no special software beyond standard SSH access for this automation to work.

Solution and Verification

# inventory.ini (on the control node)

[routers]
R1 ansible_host=192.168.60.1
R2 ansible_host=192.168.61.1

[routers:vars]
ansible_network_os=ios
ansible_user=netadmin
ansible_password=NetAdmin2026
ansible_connection=network_cli

# banner-playbook.yml

- name: Configure login banner on all routers
  hosts: routers
  gather_facts: no
  tasks:
    - name: Set banner
      ios_banner:
        banner: login
        text: |
          Authorized access only.
          Automated via Ansible.
        state: present

ControlNode$ ansible-playbook -i inventory.ini banner-playbook.yml

PLAY [Configure login banner on all routers] ***

TASK [Set banner] **************************
changed: [R1]
changed: [R2]

PLAY RECAP **********************************
R1  : ok=1  changed=1  unreachable=0  failed=0
R2  : ok=1  changed=1  unreachable=0  failed=0
-- Both routers configured in a single
-- playbook run, over standard SSH --
-- Ansible connected using the same
-- network_cli mechanism a human engineer
-- would use interactively

R1# show running-config | begin banner

banner login ^C
Authorized access only.
Automated via Ansible.
^C

R2# show running-config | begin banner

banner login ^C
Authorized access only.
Automated via Ansible.
^C
-- Identical banner confirmed present on
-- both devices

R1# show processes | include ansible
-- (no output -- nothing related to Ansible
--  is running on the router itself, since
--  Ansible operates entirely from the
--  control node using standard SSH, unlike
--  Guestshell's on-box container approach
--  from the previous lab)

Key Takeaway

Ansible's agentless architecture means the routers themselves need nothing beyond the SSH access they likely already have configured for normal administration — all the automation logic and execution happens on the control node, connecting out to each device exactly as a human administrator would over SSH, making it straightforward to apply consistent configuration across a large fleet without any special software footprint on the managed devices, in direct contrast to Guestshell's approach of running code locally on each individual device.