Ansible / GNS3 Labbing – Configure and verify Hosts in Inventory file, explore Ansible Modules, install GIT in Ubuntu, and wrap up for tonight!

It LIVES! The Ansible Automation lab is back! Time to Automate some switch configs!

Upon getting the switches configured with their IPs, I got right into the Ansible Inventory File to set both the [all:vars] to set the user/pass/os/connection, and all my different switches in their very similar to my previous lab and I got them pinging right off the bat:

^^^ Ansible seems to want to throw that Purple Python 2.x message without a lot of research I did before to correct this, however I am just happy to have the lab back, and this demonstrates that my “Ansible Inventory File” is working as intended with the “Host Groups” as when I ping coreSW from Ansible SW1 and SW2 ping!

That is as far as I’ve actually ever gotten with Ansible, so from here it may get rocky!

I did perform an SSH to each individual Switch to make sure it was working, and I noticed a message that I believe actually shows that its maybe required (for noobs like me) to allow Ansible to SSH to these hosts again:

I ran through this with all 5 switches saving along the way, then found, well… I am not really sure what to do setting up Ansible from scratch – However I tested a server command from previous Ansible labbing that I did not post here and it gave some surprising results:

A few of the command modifiers shown here and there meaning in full are:

  • -m – This defines calling out a module at the specific path
  • raw – This tells Ansible this command will be run from the Bash Shell or run “dirty”
  • -a – This tells the Ansible to run the action against the specified hosts
  • allSW – This finally is all of my switches Host Group in the Inventory File

Now I had no expectation for this to work, but it appears to have returned the Switch Name / System Time / Uptime (2hrs 11mins) / # of users connected / The CPU averages!!!

The interesting thing is Ansible Playbooks / Plays are YAML Files executed via Python Scripting, however this is using a local “uptime” file in the usr/bin folder shown here:

Whereas the actual PlayBooks / Modules are buried much deeper into the “Other Locations”:


Into the Modules Directory we go into the Network Directory, and look at all the vendors:

ASA / Aruba / CheckPoint / CLI / IOS / FortiOS / IOSXR / NSO / F5 / RESTCONF – Its amazing!

What I am focused on with my humble little Cisco IOS GNS3 Topology is the IOS Folder:

The amazing thing is these come with Ansible when you install it, I am not a huge fan of Ansible seeming to use Python 2.7 as I’ve only been learning Python 3, but I will wing it!

Being that I have Visual Studio Code on my Ubuntu machine, I can open these scripts to review what they do in VSC, to try to understand the logic of how Ansible automates:

It just keeps getting better with the Ansible Automation pre-canned modules, as they not only are a huge free collection of Python / YAML examples to work with, but at the top as highlighted it shows notes as to what it does / IOS it was tested against / other misc notes.

Then as we go down the script, it is basically a template that you can just fill in with your own information, its so easy I can probably even learn to lab it up here pretty soon 🙂

This is one Python script in the IOS Module Directory, and looking at the preview of the entire contents on that right hand side, this thing is gigantic! Just reading through this example is a refresher of YAML formatting with some Python mixed in at the end!

That is amazing, mind = blown kind of stuff right there, I thought it was impressive an Ubuntu Host file could show me the CPU averages of a switch in GNS3 (which is also quite surprising) this is absolutely crazy how there are templates with explanations that could not hardly be clearer on their use cases!


To do some gnarly Automation, I will have to create a YAML Playbook file, and before I start creating files that I want to keep around via Version Control – I better create and GIT my main repository I keep on GitHub first by creating a global username / email, then making a directory and cloning the GitHub repo to that folder and avoid initializing a new repo:

Seriously always use 2-FA or MFA when available on everything, I use it on this website / my discord channel / Cisco login / everything! Always practice good security everywhere!

As much as I’d like to say I know all GIT syntax off my head, I’d rather share this:

Really awesome GIT Cheat Sheet, I have some reading / further studying for GIT, but for now I will take what I can… GIT 🙂

So I can now set my Visual Studio Code to use this as my Version Control repo to save / track files locally on my Ubuntu machine and create a YAML file to get started:

I am finding that to construct my own Play I am going to need to do some exploration of modules and their formatting / variables, for example pulling examples from this file:

Which given there are a TON of examples within both IOS and CLI, I am honestly not really sure at this time how to slap a YAML file / Ansible Play together for IOS devices, and being that it is getting late I am going to punch the study clock for the night to review some Ansible videos and come back to create and run some Ansible Plays in future labbing!

The next Ansible lab I will at least attempt to write / run an Ansible play of my own!

From experience I know if I start something at 11:15pm, and I hit a snag in the lab, I will be up half the night working at it or thinking about it in bed – So I will book mark it here.

I think I might put theory on the back burner for a bit to get this lab really running and get some automation dirt under my developer finger nails, until next time!!! 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s