Accelerate Network Automation with Aggregate Resources

One of the major networking features in Red Hat Ansible Engine 2.4 was the addition of aggregate resources to the networking modules. The Ansible networking team recently talked about this at the Ask an Expert webinar in November.

What are Aggregate Resources?

Simply put, aggregate resources are a better way to iterate (or loop) without the need to execute each task one by one. That is, you can now “aggregate” a collection as a single task instead of a collection of discrete loops.

Loop Method

Aggregate Method

Based on feedback from customers, partners and community members, this post provides more examples and more detail of this important new feature. The simplest way to showcase this is to compare the old way and the new way, and highlight the differences between each.

For this scenario we assume a network operator wants to configure 500 VLANs on a Arista EOS device. We can use the eos_vlan Ansible module to easily accomplish this. Refer to the following Ansible Playbook snippet.

Ansible 2.3 and older

The vlan_id parameter is where the actual 802.1q VLAN number is specified. The name parameter is a description that helps identify what this VLAN is for (i.e. printers, laptops, etc). Finally, the state parameter describes what the intended or expected state should be, which can be present, absent, active or suspend.

    - eos_vlan:
        vlan_id: "{{ item.vlan_id }}"
        name: "{{ item.name | default('VLAN' + item.vlan_id|string) }}"
        state: "{{ item.state | default('active') }}"
      with_items:
        - { vlan_id: 1, name: default }
        - { vlan_id: 2, name: Vl2 }
        - { vlan_id: 3, state: suspend }

View the full playbook: oldway.yml

Prior to integrating the aggregate resources feature, with_items was used as a loop and passed this criteria for multiple VLANs. Loops are very useful within Ansible, however in this particular example loops can have serious performance impacts. To highlight the execution time differences, we can use the Linux time command.

sean@rhel7 ~]$ time ansible-playbook oldway.yml

This particular playbook with just the one task took 18 minutes and 52 seconds to run over 500 VLANs. Ansible still provides parallelism across many different network switches, but this is far too slow for many large scale production environments!

Red Hat Ansible Engine 2.4 and newer

The new aggregate method allows us to pass the entire list of VLAN information without looping. The exact same list of VLANs shown in oldway.yml can be reused easily. Simply moving every line of the VLAN data from the task level to the module level (two spaces in) under the aggregate section (replacing with_items previously). Instead of looping each VLAN one at a time, we can send all the information at once. Keep in mind this example is only showing the first three VLANs, the full example contains 500 VLANs. This is what the updated task in the playbook looks like:

   - eos_vlan:
        state: active
        aggregate:
          - { vlan_id: 1, name: default }
          - { vlan_id: 2, name: Vl2 }
          - { vlan_id: 3, state: suspend }

The modified task with aggregate resources is also timed to compare:

sean@rhel7 ~]$ time ansible-playbook newway.yml

View the full playbook: newway.yml

This took 10 seconds to complete, which is significantly faster than the previous ~19 minute method. Another advantage is that you will also see all VLANs as either changed or OK at the task level (referring to Ansible’s ability to keep track of state) rather than VLAN by VLAN as with the loop method.

The Purge Ability

In conjunction with the aggregate feature, there is a purge parameter. The purge knob is defined as “Purge VLANs not defined in the aggregate parameter.” This means that VLANs not defined in the aggregate will be removed from the switch. So when the aggregate in this example is used all other VLANs will be deleted.

 - eos_vlan:
        state: active
        purge: yes
        aggregate:
          - { vlan_id: 1, name: default }
          - { vlan_id: 2, name: Vl2 }
          - { vlan_id: 3, state: suspend }

View the full playbook: purge.yml

When it is not used, it only enforced that the VLANs exist in the state the aggregate sends them. What are potential use-cases for each?

Going Further

Where else can I use aggregate? Other Arista examples include those such as the eos_user module and the eos_vrf module. Users and VRFs can be handled in a single aggregate rather than a collection of looped tasks. Instead of sending configuration user by user, or VRF by VRF with a loop it is now possible to use the aggregate. This will speed up configurations and give an alternative to using os_config modules with Jinja templating.

Ansible network modules that are capable of the aggregate feature are listed on their respective module documentation page. The aggregate keyword will appear under the parameter heading in the Options table. Click here for a complete list of modules.

All scenarios in this blog post are stored in a GitHub repo in our network automation community.

Follow the aggregate resources repository here.

To become a member of the growing community email us with your GitHub ID.

Have more questions? Join our next regularly scheduled Ask an Expert: Networking Webinar.