Arista VXLAN 3 – Automating Adding New Spine and Leaf Switches

I have been over the automatic creation of the VXLAN topology in the previous post. However, this stopped at the creation of the topology only. If in the future I wanted to add a new spine or leaf switch, this could be done, but the other switches wouldn’t be aware as they would also need to be rebuilt.
So in this post, I will address a method to boot up new switches and have the existing fabric become aware that there is an additional leaf or spine.

The scripts used for this post can be found here on my GitHub.

The process is quite simple and does require some manual intervention. It is not like the boot up and forget automation as the topology creation is.
– Process to boot up new switch is the same, ZTP and python scripts running from AEM to create VXLAN config.
– I have added XMPP configuration and all switches in the fabric will join a switch group (chat group)
– Before any boot up, the device username is added to the XMPP server
– Once boot up has finished, all switches will get issued with the command to run a python script that will recreate their VXLAN configuration and save it.
– All new spine and leaf switches are now known about over the fabric.

The base topology will be the switches as in the previous VXLAN posts.

Lab Prep

Ubuntu Server running; DHCP, TFTP and XMPP Servers

Creating the DHCP Server

Install the DHCP Server

Configure the DHCP server with option 66 and 67

Bind the DHCP server to an interface. In my case, it will be ens3. Use the command ip a to locate the interface to be used.

Restart the DHCP Server and confirm it is running.

Creating TFTP Server

Install the server

Check the server is running

Configure the TFTP Server. The options important to me are;
– Add in a user specified directory /tftp
– Setting the user to connect to the /tftp server when connecting, using the --secure option
– Adding the option to create files/directories on the TFTP server. --create option

Change the TFTP directory owner and group to the tftp user

Restart and check the server status

Installing and configuring XMPP

This is a repeat of when I configure XMPP on Ubuntu in a previous post. All switches have been added to the XMPP server.

I have also used the same GAJIM client. The installation and configuration for the has been described in a previous post.

Not all switches are contacts in GAJIM client. This is because all switches are automatically joining the VXLAN switch-group (chat group) and so do not need to be individual contacts. I can reach them through the chat group without manually adding new switch contacts.

Automation Scripts

There are four files in total to get this running. Three are similar to the previous VXLAN 2 automation post. The new file is a python script that is very similar to the VXLAN config creation script. All the files can be found on GitHub.

In these scripts there is additional configuration for XMPP, this is pretty much lifted from the XMPP post

  1. config-ztp-fix.cfg

2. ZTP1.py

3. AEM_VXLAN_DeviceReady.py

4. newSpineLeaf.py

Adding Leaf5

Before adding a new switch, the switch XMPP user must be added to the XMPP server. I have explained this in my XMPP configuration post, so a quick summary is that the commands are to be run as the root or ejabberd users.

5 leaf switches and 2 spine switches added
Only Spine2 and Leaf 5 are contacts, rest are in the chat group

The current state of the VXLAN network is correct. BGP is working, and the switches have learnt about each other’s VTEP. Below is an example output from Spine1 and Leaf3 to demonstrate.

Now that the users are added to the server, the new leaf switch can be turned on. This will go through the process of discovering what its hostname is and LLDP neighbours are From the hostname and LLDP neighbour details, the correct VXLAN configuration will be applied. At this point the new switch won’t have any BGP neighbours and be cut off from the rest of the fabric.

Leaf5 added to the group chat automatically
Leaf5 responding to commands

Leaf5 is cut off from the rest of the VXLAN fabric. The only functioning interface is the management.

To fix the fact that the new switch is not yet part of the fabric, a manual command will be run from XMPP to all switches in the VXLAN chat group, even the new leaf. This command is to run the python script newSpineLeaf.py This will take seconds to execute and each switch in the fabric will have the correct config, allowing the new leaf5 to function correctly.

Now that the switches have reconfigured themselves, Leaf5 now has BGP neighbours, prefixes and knows about the remote VTEPs

Adding Spine3

Adding a new spine switch will behave in the same way as adding a Leaf5 did.

Add the new switch user to the XMPP server

Cable and start the switch Spine3

Once that has booted up and is responding to commands sent via XMPP chat, all that is left is top run the newSpineLeaf.py script to add it to the fabric correctly.

Now that all switches are responding, time to run the newSpineLeaf.py script.

Below is BGP config taken from Leaf4 to show that ECMP is running and is going via the three spine switches for connectivity to the VTEPs.

Leave a Comment

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