Arista Zero Touch Provisioning (ZTP)

Zero Touch Provisioning is a way for Arista switches to get a configuration file via DHCP options and configure itself with no interaction from an admin. All there is to do is connect up the switch and IP/config will be applied to the switch.
ZTP will only run when there is no startup-config file, so first boot of new device, or deletion of the startup-config file.

DHCP Options

Arista ZTP uses DHCP options 66 and 67. I have used a Checkpoint firewall as the DHCP server. This configuration can be found in a previous post.
DHCP option 66 and 67 direct devices to download configuration.
– Option 66: provides a TFTP address. This would be the URL – tftp://10.10.10.10
– Option 67: provides the path to the file. This could be the URI – test.cfg
DHCP returned options create: tftp://10.10.10.10/test.cfg
Option 67 can also be alone to return a full path using FTP or HTTP. Instead of using just a file name, an entire path can be given such as HTTP://172.17.2.10/test.cfg or FTP://172.17.2.10/testing_configs/test.cfg

TFTP Server Configuration & ZTP Download

Without the TFTP configuration or if the Arista switch is unable to reach the TFTP server, it will display error messages in the console. The Arista switch will continue to try to reach the TFTP server.

With a TFTP server configured and a file named test.cfg. The Arista switch has downloaded the config and reboots

Multiple ZTP Switch Provisioning

The current ZTP config can only deal with a single Arista switch at a time due to the IP being hard set. There is another option for ZTP, which is to use a script over a configuration file.

In theory, the Arista switch should be able to execute a python or bash script that it is provided. It does this based on the #! line at the top of the file. If there isn’t a #! line, then the file is treated as a startup config file.

In this example, I will demonstrate a python file being downloaded and providing basic IP and hostname assignment. The idea of the script is to determine if a switch is a spine or a leaf.
The logic for this is a spine will always see the LLDP neighbour ports as Eth1, Eth2, Eth3 or Eth4 depending on the spine number the Eth port will change.
The leaf number will always be connecting to Eth1, Eth2, Eth3, Eth4, – Eth40. These ports will be the same. So the script will look at LLDP of Eth1 neighbour for the destination port.

I had major issues getting this work successfully in a lab with Python. The script works as expected in the lab when run manually, but running the Python script in ZTP after it has downloaded results in a failure. I tried HTTP and TFTP, no difference.
I have corrected this by using a .cfg file and AEM to run the script after ZTP. The details can be found at the end of this post.

The Script is below, and the results of the script when run manually are below the script.

To run the script manually, I will copy the file to each Arista switch and run the script from the bash shell. ZTP will be cancelled in order for me to do this.

Each switch has a startup-config file that was created. It contains the basic config, below is an example from leaf4.

ZTP Fix Using AEM

The ZTP python script did fail to run when it was executed through the ZTP provisioning. I have come up with a work-around using AEM. This method requires an extra reload of the switch and an extra file to be downloaded. The steps are;

  • ZTP performs DHCP
  • ZTP downloads config-ztp-fix.cfg
  • ZTP performs reload
  • AEM ZTP1 runs on startup; downloads ZTP1.py, runs ZTP1.py, and reloads after 1 minute wait
  • After reboot, the switch has the correct hostname and IP set in the way that the ZTP python script.

I have used a .cfg file for ZTP as this will work correctly and place that config into the startup-config file. The full config-ztp-fix.cfg is below.

Now that the device has performed the ZTP configuration the next step of downloading and running the python script that will assign the correct hostname and IP address. the AEM to run the script is also removed to be sure that it does not keep running and overwrite the startup on each reload.

Leave a Comment

Your email address will not be published. Required fields are marked *