In this hands-on lab we move from theory into practice. By the end of this lesson you will have Ansible installed, a working config file, a host inventory file pointing at real lab devices, and two working playbooks – one that pushes a login banner to every router simultaneously and one that pulls interface data back from the whole estate.
We start with installation. Rather than installing Ansible globally and risking conflicts with your system packages, we install it into a Python virtual environment using pip. This is the right approach for any tooling you want to keep isolated and repeatable across different projects.
Once installed we build out the three core components that every Ansible setup needs:
The ansible.cfg file controls how Ansible behaves. In a lab environment this includes disabling host key checking so SSH connections do not stall waiting for key confirmation, and adding legacy cipher support for older Cisco devices that do not negotiate the same SSH algorithms as modern equipment. Both of these are common stumbling blocks when you first try to run Ansible against real network kit.
The hosts file, also called the inventory, is where you define all the devices Ansible can connect to. We build an inventory with four routers and three switches grouped by device type, with management IP addresses, credentials, connection port and connection type all defined per group. You will see how grouping works in practice – you can target a single device by hostname, an entire group like routers, or everything in the inventory using the all flag. We also cover how to create sub-groups, so you could for example target only UK sites without touching devices in other regions.
The playbook is the set of instructions Ansible executes against your inventory. We walk through the structure of a YAML playbook in detail – the name field, the hosts field that ties back to your inventory groups, and why gather_facts is almost always set to no when working with network devices. Leaving gather_facts enabled causes Ansible to attempt an SNMP-style data collection from every device before running any tasks, which adds significant time and is rarely useful for network automation work.
Our first playbook uses the ios_config module to push a login banner to all four routers in a single run. We verify the change by SSHing directly into one of the devices and confirming the banner is present. We then run the same playbook a second time to demonstrate idempotency – a core Ansible principle where running the same playbook repeatedly does not make unnecessary changes. If the banner is already there, Ansible skips it. This behaviour is critical when you are running playbooks against production devices where you cannot afford unintended changes.
The second playbook demonstrates read operations – using the ios_command module to run show ip interface brief across all routers, register the output and display it back in the terminal. This is the foundation of any monitoring or reporting automation.
All config files, host files and playbooks used in this lesson are available on the GitHub repo lab 1 linked below. You will need to update the IP addresses to match your own lab environment before running them.