The Cumulux VX image comes completely unconfigured (save for the DHCP client configuration on the management port eth0). It has three switch ports, that is, swp1, swp2, and swp3. Let's query one of those interfaces to see whether there is any existing configuration. We can use a simple playbook called switch-query.yaml to query swp1:
---
- name: query switch
hosts: mastery-switch1
tasks:
- name: query swp1 interface
nclu:
commands:
- show interface swp1
register: interface
- name: print interface status
debug:
var: interface
If we run this (exactly as we have run other playbooks), then we will see something like the following:
This confirms our initial statement about the VM image—we can see that the switch port is not configured. It is very easy to turn this VM into a simple layer 2 switch with Ansible and the nclu module. The following playbook, called switch-l2-configure.yaml, does exactly this:
---
- name: configure switch
hosts: mastery-switch1
tasks:
- name: bring up ports swp[1-3]
nclu:
template: |
{% for interface in range(1,4) %}
add interface swp{{interface}}
add bridge bridge ports swp{{interface}}
{% endfor %}
commit: true
- name: query swp1 interface
nclu:
commands:
- show interface swp1
register: interface
- name: print interface status
debug:
var: interface
Notice how we are using some clever inline Jinja2 templating to run a for loop across the three interfaces, saving the need to create repetitive and cumbersome code. These commands bring up the three switch interfaces and add them to the default layer 2 bridge.
Finally, the commit: true line applies these configurations immediately to the switch. Now, if we run this, we will see a different status for swp1:
As we can see, the swp1 interface is now up and part of the bridge, ready to switch traffic. Note that the task to configure the ports was marked as changed, since the configuration was applied for the first time here. What happens if we run the playbook again without performing any other steps on the switch? Let's see:
This time, the state of this task is ok, meaning that the nclu module did not detect any changes being applied to the switch. In this way, playbooks that automate the configuration of our Cumulus Linux switch are idempotent and result in a consistent state, even when they're run multiple times. This also means that if the configuration of the switch drifts (for example, due to user intervention), it is very easy to see that something has changed. Unfortunately, the nclu module doesn't currently support the check mode of ansible-playbook, but nonetheless, it still provides a powerful way to configure and manage your switches.
Automating Cumulux Linux with Ansible really is as simple as that – further examples are beyond the scope of this book, as they would entail more advanced usage of the nclu command. Hopefully, however, by means of these simple examples, it can be seen that the automation of network infrastructure with Ansible is now no more difficult than automating anything else.