• Integrating Salt and Arista ZTP Server for Zero Touch Automation of EOS

Print Friendly, PDF & Email

Zero Touch Provisioning

The term ZTP or Zero Touch Provisioning is a feature often heard, which EOS has offered since the early days. During the initial boot, if a startup-configuration file is not found in the /mnt/flash/startup-configuration directory, the EOS device will automatically boot into ZTP mode. The switch will obtain an IP address from a DHCP server including DHCP options 66 and 67. Next the switch will ask the ZTP server or a server designated within option 66/67  for a bootstrap file. In this post we will use the Arista ZTP server which can be found here. 

This process is depicted in the following picture:

The ZTP server requires a few files to make it work correctly which are listed bellow:

The “112233445566” is the serial number which is how the ZTP server is able to distinguish between each switch that is being provisioned. The definition file includes patterns which can match certain actions based on attributes such as interface state.

The “startup-config” is the configuration which will be sent to the switch upon startup. The definition file is unique in the case for salt, since it will require an agent. We are able to copy the agent from the ZTP server and start the Salt-Minion daemon upon boot time.  

Salt can create all of these files dynamically including the directory based off of this information. Once the switch boots with a very basic configuration (i.e. configuration for interfaces, hostname ,and management port) it will then accept the Salt-Key for the Minion and Salt will use Salt Reactors to configure Vlans, Syslog, etc.  

Salt States

A Salt State is a desired state for a given Minion. We previously covered Salt in a EOS central article which can be found here. A given Salt State, will take a host name and serial number and produce multiple templates to create the files necessary for ZTP to occur.

Here is our state file:

There is a lot of info in a State file. If you recall with the ZTP server, we need a few files to make a zero touch provision possible. This state creates the directory and necessary files based off of input that can come from Salt gGrains, YAML files, JSON files or even external Git repo’s. Here we are going to use YAML that is embedded into the Salt State without requiring much additional logic for simplicity. In the case of multiple switches, you can use the same method with load_yaml and JINJA to an external YAML file and loop over the information. 

We begin with a nested dictionary within JINJA2. We then call the file module to create directories and files. We can see where we are passing in JINJA2 variables for example: {{ yaml_src.switches.leaf4a.systemmac }} will render to 112233445566 once the state is ran.

Executing States are very simple within Salt, simply by running the Salt ‘salt-master’ state.apply. In this case the Salt-master is the ZTP server. 

If we check the ztp directory where nodes are typically stored, we should see a listing of files for ZTP:

We can see that each file was created for the switch to boot properly. 

Booting the Device

Booting our device for the first time, it should come up in zero touch provisioning mode. It will check for an IP address from the DHCP server. We can inspect the logs on the DHCP server to see the incoming requests for the bootstrap file:

As we can see from the DHCP server logs, the switch is requesting multiple files from the server including its startup-configuration file to its Salt daemon. Once the switch downloads all the necessary files and executes the bootstrap file it will reboot.

Accepting the New Switch and Managing with Salt.

Once the switch is online, the first thing the Salt daemon will try to do is negotiate a secure connection with the Salt master. We can check the Salt master to see if leaf4a is negotiating a secure connection.

This is typically where we would accept the switch and let Salt manage the devices as a minion. Here is where we can have salt manage our device once its brought online. We have mentioned states to push configuration.

Salt also has what is called a reactor. A reactor is simply a way to trigger a state once a certain action is taking. If we recall from our previous Salt article, Salt information is constantly syncing information from the minions to master over the high speed zeroMQ bus. When a device comes online the salt bus see’s it and we can react to these new devices coming online. We are going to simply use a reactor once the device comes online and add Vlans to the device if the hostname includes the string “leaf”. We can add any sort of configuration to a device once it comes online: Vlans, Syslog, NTP, etc. Here is an example of the Salt master configuration where the reactors are kept:

Looking at the reactor statement this will use the salt tags that are constantly synchronized between the Master and Minions. Any minions that are accepted and begin with “leaf” will run the reactor called leafvlanztp.sls.

We can see the state runs locally:

Salt uses the typical python way of going through directories. If we look at /srv/salt/states/leaf/vlans.sls we will see a state file that adds Vlans:

Once the Minion/switch is accepted we can look at the debug through the master:

We can then see in the debug that the state was successfully rendered on the master:

If we log into the switch we can see that vlans 300 and 400 have been added:



Get every new post on this blog delivered to your Inbox.

Join other followers: