Configuration Compliance for Ansible Automation

Leveraged SolarWinds Compliance Policy Reports to standardize configurations across the Network. This Includes the Data Center, Campus, Management, etc. As a result I worked on IP Device Tracking (IPDT), Dynamic Host Configuration Protocol (DHCP) Snooping, Virtual Local Area Network (VLAN) configurations, and more. This also involved me working on both Cisco and Nexus OS.

Devices Involved:

Cisco Catalyst 3850 Series Switches‍

Cisco Catalyst 9300 Series Switches‍

Cisco Catalyst 9500 Series Switches

Cisco Nexus 9000 Series Switches

Cisco Catalyst 9800 Series Wireless Controllers

Cisco Industrial Ethernet 4000 Series Switches

Cisco 4331 Integrated Services Router

‍

We would like to automate aspects of the Network using Ansible, but prior to that we must standardize the configuration across the campus. Before completing this project our configuration had "drifted" from a known state. In emergencies, problems sometimes get fixed manually, or haphazardly, and that's dangerous - it leads to unpredictability when one system in a crowd behaves differently than others - and this problem gets increasingly more problematic as infrastructure sizes grow.

‍

‍

A significant part of Ansible is ad hoc commands which uses the /usr/bin/ansible command-line tool to automate a single task on one or more managed nodes. ad hoc commands are quick and easy.

ad hoc commands are great for tasks you repeat rarely. For example, if you want to power off all the machines in your lab for Christmas vacation, you could execute a quick one-liner in Ansible without writing a playbook. An ad hoc command looks like this:

‍

$ ansible [pattern] -m [module] -a "[module options]"

‍

If there is configuration drift these ad hoc complands will not work across all devices. For example an adhoc compand may depoy on servers 1 and 3 for example. But if server 2 configuration has drifted it may result in a deployment failure.