As part of a recent automation POC project at work, I was tasked with doing a demo of how Ansible could be used to configure a standard configuration to some WAN routers. In setting up the demo, I have used some IOSv virtual routers running 15.4 code a and control Ansible server built on Ubuntu server 16.0 LTS, all running on top of my laptop inside VMWare Workstation.
To demonstrate the concepts I setup 8 edge routers plugged into 2 separate service providers to mimic what we have in production.
To simulate the MPLS clouds, I used another virtual router with multiple VRFs and multiple BGP ASes using the local-as feature to mimic the 2 provider peerings.
My Playbook structure consists of the following layout, where I breakout each part of the configuration into separate roles as is best practice in most production setups of Ansible.
One of the key requirements of the POC was modifying a standards QOS policy applied to the routers. Each circuit has different bandwidth settings and hence different shaper settings for the WAN interface. I achieved this by modifying the Jinja template under the QOS role to take the interface bandwidth and multiply it by 3 places as Cisco uses different measurements under the interface bandwidth setting and QOS shaper setting. One is kilobits/sec, the other is set in bits/sec.
The qosbw variable refers back to a value in the host_vars folder where a yaml data file exists for each WAN router.
The WAN deployment playbook configures various different aspects of the router configuration, including interfaces, host names , syslog, ntp, routing protocols and vrf definitions.
An interesting task in the run book is the application of public keys from the control server to the routers to facilitate running “raw” commands against the devices to quickly check configuration status post checks. This is required to get Ansible in ad-hoc mode commands to work against the routers as an SSH trust is needed for this to work. As part of the public key task, a write to memory is also required on the router in order for the router to save the Ansible server’s public key to its non volatile memory. After this is configured on the router, you can then issue quick mode commands against the device without the need to run a whole playbook.
This is a very handy feature to check quickly the status of a config on many different devices without the need to log into each router separately.
There is also two playbooks that check BGP and save the running config to various folders on the control server.
The BGP playbook first shows the output of two commands, displays them to the screen and then saves the result of standard out to a file and pops it in a local directory on the Ansible control server.
The Save running playbook does something similar and saves the results to a file in a local directory also for later reference. By setting a terminal length of 0 and then issuing a show run, we get a clean snapshot. Passing this to a register directive we can then do a copy of the content of standard out and send it to a file using the dest keyword as seen below:
Finally we can see the resulting files saved in the directories on the Ansible Server, designated by their host names.
And doing a cat of the contents we have a record of the routers configuration:
Next up I will be looking at Ansible Tower….stay tuned!