Network Maintenance

Let's create two network maintenance workflows: a device configuration audit workflow, and a firmware upload + system reboot workflow.

Device Configuration Audit

A prevalent use case for network automation is maintenance after the environment is set up. This workflow operates as follows:

Assumption: For each device on the network, there is a saved "golden config" against which the device's configuration can be checked. These golden configs must be actual configurations that were pulled from the devices themselves and not configurations generated from templates. This requirement exists because certain aspects of the running-configuration can't be predicted in advance (e.g. password ciphertext), and thus aren't suitable for being parametrized in a template.
Pull the running-configuration of the device and store it in a temporary file.
Calculate the temporary file's checksum and compare this checksum with that of the device's stored golden config file.
If the checksums do not match, push the golden config as the running-config of the device, restoring the device to a known acceptable state.

Concepts

stat module: this module generates a checksum from a file's contents.
set_fact module: this module allows variables to be set dynamically during playbook execution.
aoscx_backup_config : this module allows configs to be copied to a TFTP server.
Conditional: this component allows tasks to execute conditionally (i.e. only under certain circumstances).
Block: this component allows tasks to be grouped together logically. Blocks are often used in conjunction with conditionals.
Tag: this feature allows specific tagged parts of a playbook to be executed selectively.

Workflow

As a preliminary step that is a prerequisite to the "actual" workflow, we first save the device's current running-config as the golden config. We copy the device's running-config to a TFTP server with the aoscx_backup_config module. Documentation for this module is linked above in the Concepts.

---
- hosts: all
  collections:
    - arubanetworks.aoscx
  tasks:
    - name: Copy Running Config to TFTP server as Golden Config
      aoscx_backup_config:
        config_name: 'running-config'
        remote_output_file_tftp_path: 'tftp://192.168.1.2/golden_config.cli'
        config_type: 'cli'
        vrf: 'mgmt'

To begin our audit workflow, create a new Ansible playbook. Write a play and task to retrieve the current running-config from the device through TFTP and save it to a temporary file, again with the aoscx_backup_config module.

---
- hosts: all
  collections:
    - arubanetworks.aoscx
  tasks:
    - name: Copy Running Config to TFTP server as Temporary Config
      aoscx_backup_config:
        config_name: 'running-config'
        remote_output_file_tftp_path: 'tftp://192.168.1.2/temporary_config.cli'
        config_type: 'cli'
        vrf: 'mgmt'

Add tasks to generate the checksums of the golden config file and the temporary file. To generate the checksums, we use the stat module, whose documentation is linked above. Then store the calculated checksum values in variables using the set_fact module. The documentation for this module is also linked above.

---
- hosts: all
  collections:
    - arubanetworks.aoscx
  tasks:
    - name: Copy Running Config to TFTP server as Temporary Config
      aoscx_backup_config:
        config_name: 'running-config'
        remote_output_file_tftp_path: 'tftp://192.168.1.2/temporary_config.cli'
        config_type: 'cli'
        vrf: 'mgmt'
  
    - name: Get checksum of stored GOLDEN config
      stat:
        path : "/var/lib/golden_config"
        checksum_algorithm: sha256
      register: golden

    - name: Get checksum of pulled RUNNING config
      stat:
         path : "/var/lib/tftpboot/temporary_config.cli"
         checksum_algorithm: sha256
      register: running

    - set_fact:
        golden_sha: "{{ golden.stat.checksum }}"
        running_sha: "{{ running.stat.checksum }}"

Lastly, add a task that calls the aoscx_upload_config module. Add a "when" clause to this task so that it pushes the previously saved golden config if and only if the checksum comparison indicates that the compared files do not match.

---
- hosts: all
  collections:
    - arubanetworks.aoscx
  tasks:
    - name: Copy Running Config to TFTP server as Temporary Config
      aoscx_backup_config:
        config_name: 'running-config'
        remote_output_file_tftp_path: 'tftp://192.168.1.2/temporary_config.cli'
        config_type: 'cli'
        vrf: 'mgmt'
  
    - name: Get checksum of stored GOLDEN config
      stat:
        path : "/var/lib/golden_config.cli"
        checksum_algorithm: sha256
      register: golden

    - name: Get checksum of pulled RUNNING config
      stat:
         path : "/var/lib/tftpboot/temporary_config.cli"
         checksum_algorithm: sha256
      register: running

    - set_fact:
        golden_sha: "{{ golden.stat.checksum }}"
        running_sha: "{{ running.stat.checksum }}"

    - name: Restore Stored Golden Config to Running through TFTP
      aoscx_upload_config:
        config_name: 'running-config'
        remote_config_file_tftp_path: 'tftp://192.168.1.2/switch_config.conf'
        vrf: 'mgmt'
      when:  golden_sha != running_sha

Once you've validated the operation of this workflow, you can get creative and expand its logic to allow for more complex use cases. For example, you could alter this workflow so that it only checks the state of the devices and doesn't push any configurations. You can check out an enhanced version of this workflow in our Github repo to see how we use blocks and tags: aoscx_deploy_ospf_fabric.yml.

Upload Firmware and Reboot with New Image

Another routine Day N operation would be updating the firmware on a device and rebooting it with the new image. This workflow operates as follows:

Assumption: A compatible firmware file is stored locally on the Ansible control machine.
Upload the new firmware as the primary image.
Boot the device with the new primary partition.

Concepts

aoscx_upload_firmware module: This module uploads a firmware image from either the local machine or a remote HTTP server to the switch.
aoscx_boot_firmware: This module reboots the switch to the selected partition.

Workflow

Create a new Ansible playbook. Write a play containing two tasks: the first to upload the firmware to the desired partition using the aoscx_upload_firmware module, and the second to reboot the switch to the desired partition using the aoscx_boot_firmware module. Use the pages linked in Concepts for reference if necessary.

---
- hosts: all
  collections:
    - arubanetworks.aoscx
  tasks:
    - name: Upload firmware to primary through local file
      aoscx_upload_firmware:
        partition_name: 'primary'
        firmware_file_path: '/var/lib/tftpboot/GL_10_04_0001.swi'

    - name: Boot to primary
      aoscx_boot_firmware:
        partition_name: 'primary'