Test and Deploy Network Automation Safely

Series overview | Previous: Trigger Ansible Playbooks from Cisco Syslog Events

Part 5 of 5: In Part 5, we validate the complete workflow in a lab, confirm that only approved devices trigger changes, document rollback, and establish the safeguards required before a production pilot.

Safety note: Use an isolated lab, replace every example value, protect all credentials, maintain console access, and back up configurations before allowing automated changes.

Testing

Now, you need to populate the three files with MAC address data. Below are examples demonstrating the correct format for each file to ensure proper processing. Be sure to format the MAC addresses according to your switch vendor’s specifications. The example shown follows Cisco’s standard format.

/etc/ansible/Wireless.txt
mac address only
d04f.58

/etc/ansible/OUIs.txt
mac address oui, vlan, description
0002.c1,620,Ansible_IED

/etc/ansible/DeviceMacs.txt
mac address, vlan, description
744d.bd7e.9f88,20,Ansible_HPPrint

Configure a lab switch to use 802.1X on one test port, send informational syslog messages to the Ubuntu server, and use nonproduction VLANs. A failed 802.1X event should be stored in MySQL, matched against the MAC lists, and passed to the appropriate Ansible playbook.

Validation Checklist

Confirm UFW permits SSH only from approved management networks and syslog only from switch-management networks.
Run sudo rsyslogd -N1 before restarting rsyslog.
Run ansible-playbook --syntax-check against each playbook.
Use --check where supported and inspect the rendered commands before allowing changes.
Verify that an unmatched MAC address cannot trigger a configuration change.
Confirm a failed job is visible in the service, Ansible, and device logs.

Rollback

To stop automated changes immediately, disable the processing service while leaving syslog collection available:

sudo systemctl disable --now monitor_logs.service

Restore affected switch interfaces from your approved baseline or configuration backup. Do not rely on the automation workflow itself as the only rollback mechanism.

Conclusion

This solution may look extensive, but it saved our team significant time during a complete switch refresh. Known devices could be connected without manually rebuilding every port, while unmatched events remained outside the automated workflow.

The most important lesson is to automate gradually: begin with logging, validate event parsing, render the proposed configuration, require human review, and only then permit narrowly scoped changes. That approach delivers real operational value without turning a helpful automation server into an uncontrolled production risk.

Expected Result

At the end of this part, you have test evidence, a known-good baseline, a documented stop procedure, and a narrowly scoped plan for production deployment.

Troubleshooting

If the wrong playbook is selected, stop the worker immediately and inspect the raw event, MAC lists, and conditional order.
If a switch command fails, compare the rendered configuration with the syntax supported by that exact platform and IOS/IOS XE release.
Do not expand the pilot until failed jobs, unmatched devices, and rollback have all been tested deliberately.