Even though managing Arista switches is pretty great, sometimes performing things like software upgrades can be tedious and boring, especially when there are a lot of switches to upgrade at a time. Here at WAN Dynamics, we like to solve tedious problems with automation so to for this particular challenge.
We created an Ansible playbook which is used to help automate upgrades but also have some guardrails in place to ensure a smooth and successful upgrade of your Arista switches.
There are a few things this playbook does before performing the EOS upgrade:
- First it checks to see if the switch already at the desired EOS version? No need to upgrade a switch which is already running the version we want.
- Next, is there enough space on switch to transfer over the EOS file? If there is not enough space on the devices, we may as well not try to transfer the file without making room.
- Then, does the MD5 sum of the transferred EOS file match the MD5 sum from Arista? This is to make sure the image we staged on the switch for deployment is not corrupt.
After the upgrade has completed Ansible will finish up by the running eos_facts module against the switch to verify that it is now at the desired version of EOS.
Here is a simple topology where there are two spines and 2 leaf switches:
If all connections are dual-homed via MLAG we should be able to upgrade one switch from each MLAG pair causing minimal if any disruption. In this case we will upgrade vEOS-Lab-3-C and vEOS-Lab-5-E at the same time.
For this I have created a group named “arista_upgrade” in the inventory file. Since we want to upgrade vEOS-Lab-3-C and vEOS-Lab-5-E we will edit the “my-inventory” file so that both switches are in the group.
This is just an easy way to control which switches are being upgraded when running the playbook.
Some of the variables used to ensure the upgrade will go well are stored in the arista.yml file in group_vars.
swi_url - is the location of where to download the EOS image from.
target_version - is the version of code that we will be upgrading to.
eos_mem_required - is how many MB free we will need on flash to transfer the EOS image.
eos_md5 - is the MD5 sum for the image, you can get this from Arista when downloading your new image.
target_file - is the file name of the new EOS image.
For the purposes of this lab, a special modification that was made is that the name of the switch was added to the /etc/hosts file on the host running the playbook so that Ansible can resolve the hostname when checking to see if the switch is back up and running from the EOS upgrade. You may have the hosts in DNS with a search domain which would provide the same result.
The following portion of the configuration will make it so that the playbook will pause and wait for the switch while it is rebooting, once Ansible can connect to the switch on port 22 it will move on to the next task in the playbook.
Ok lets run the playbook!
Great it looks like the upgrade worked, both switches are now at the proper EOS version:
Well that was fun, lets run the playbook again and see if the EOS image is transferred or if the switches reboot.
The EOS image transfer and reboot tasks will only be performed if the variable “target_version” does not equal ansible_net_version. (ansible fact)
Here is the eos_upgrade.yml playbook:
If you would like to review the playbook it is available here:
https://bitbucket.org/wandynamics/arista_eos_upgrade/src/master/
Thanks for reading! Please send any questions, comments or other to info@wandynamics.com.