Moving Towards Automated Changes
Let's take a look at the things we need to consider when moving towards making automated changes.
We'll cover the following
Tactical changes are often one-time in nature and have a variable footprint. Sometimes, there is a need to deploy a new feature that has configuration elements on every device on the network. For example, a QoS policy or Netflow collection. Other changes might be limited to multiple touchpoints on one or two devices. Ansible playbooks are flexible enough to handle changes of any size or scope. Start accumulating various one-time playbooks that can be cloned as reusable templates of known working code. Quickly write new playbooks based on working code in the repository. A full history of the changes these playbooks make is now available in the change control history section.
The network automation engine is given a level of authorization to change network configurations based on the playbooks being written. Be sure that everyone is ready before proceeding.
Orchestration
Before starting to write any YAML, think of the primary goals. For example, what is the organization trying to achieve with tactical playbooks? What are the requirements for the change? Which devices are impacted? Is there a specific order of operation in which to execute the commands? Is there any output that should be gathered before, during, or after the change to validate the state of the network? How can success be measured?
Ansible executes playbooks serially, providing granular control and the ability to orchestrate changes across the enterprise network.
Think of the steps involved in provisioning a simple VLAN on the network:
For the Distribution layer:
- New VLAN
- STP root for new VLAN
- New SVI for VLAN
- Add VLAN to port-channel facing access switch
For the Access layer:
- New VLAN
- Add VLAN to port-channel facing distribution layer
- Configure physical interfaces as access ports on the new VLAN
Ansible translates this intent into a fully orchestrated modular playbook that can be refactored in the future for all new Access Layer VLANs.
Network modules
Moving beyond running IOS commands through the ios_command
module, a different Ansible
module, ios_config
, with its own unique syntax, will be introduced. The modules are similar. However, ios_config
is intended to configure the device with configuration, or privileged EXEC level
commands, while ios_command
is typically reserved for running non-privileged show commands.
Get hands-on with 1400+ tech skills courses.