Part Two: Get that switch in the game!
DISCLAIMER: You can only trust a mad scientist so much!
Thanks for hanging in there with me on this long blog post. We are going to go a little deep in building the configets for our spine leaf network using Arista Cloud Vision Portal (CVP). The CVP server ships as an OVA and with a couple of clicks we can have it up and running on our ESXi host. You’re going to need about 10 Gig of RAM to get this going. At a bare minimum I have had it running with 7 Gig, but I do not recommend it. The first step is to login with the cvpadmin user and run the setup script. You will be prompted to change the “Root” password, no weak stuff here….I tried.
After we accomplish this we need to run the setup script. I selected “s” for standalone mode. Answer the prompts according to your own environment.
Select “r” and “a” for apply and watch the boot process. I had a lot of issues with the nic coming up with the correct address. If this happens to you, quit the script with a “q” and login as “root”, remember, you just set the password for the root user. Once the network connectivity issues are resolved run the standalone script once more. It will take about 15 minuets for the CVP server to boot.
Look in /etc/sysconfig/network-scripts/ifcfg-eth0 for any mis-configurations. I had issues with the NTP server as well so I just used the “IP” address instead of the DNS name. All good, let’s move on. Point your favorite web browser to the address of the CVP server and you should be greeted with the login screen.
We are going to login to CVP with the “cvpadmin” user. At the first login attempt you will use cvpadmin as the userid and cvpadmin for the password as well. You will be prompted to change the password for cvpadmin.
CVP Main Menu
If you read part one of this blog post you should be a little familiar with navigating around CVP. The main menu is your starting point. Let’s verify our containers are just the way we want them using the Network Provisioning page. Arrange them to your liking. We will start with at least one of our switches are in the inventory. We’ll use it’s configuration to build our configlets.
Each container in the tree can host a particular part of the overall switch configuration, a configlet. As we traverse down the tree to the switch we pick up configlets and stitch them together to make up the overall configuration.
In the blog we will create all the configlets for our two spine/two leaf network.
If we take a closer look at our switch that we have added to the inventory, we see it is yellow and if we hover on the image we will get a pop-up that tells us the devices configuration is out of sync. This means that the configuration of the switch does not match what are configlets “think” it should be.
The process starts by “right-clicking” the device and selecting “manage-configet” from the network provisioning screen.
On this screen you will select “validate” from the bottom of the page and CVP will pull the configuration from the switch and compare it to what the configurations look like from cascading through the network provision tree.
Seems we have some differences between the two! If you see items marked in red in the running configuration window to the right, this indicates that you do not have a configlet for that part of the configuration and you will need to create it.
In the running configuration window, highlight the entire configuration and paste it into an Excel spreadsheet. It’s a little weird, but believe me, it makes it easier to see what’s going on.
OK, at this point we are going to start rearranging some of the configuration statements. We will group them into common items that can be found on all switches and unique items that only are available on the switch, things like router-id, loopback address, etc, etc.
Once we get our configuration statements arranged the way you want them, go back the CVP screen and let’s add a new configlet. Pull down the plus “+” sign menu and select Configlets.
Give the configlet a title and copy and paste the configuration statements from the excel SS into the configlet editor. Save.
Here we have copied out the rest of the unique information for the other switches to help build the configlets for all the devices in our network. Obviously, this won’t scale but it is a good way to learn what configlets are and help you keep track of what is going on as you’re just starting out.
Looking good, I think we can move on! Configlets done!
Assigning configlets to containers
We need to assign the common configlets to a top level container. From the network provision screen right-click on your top most container and manage configlets. Select the common configlets and assign them to this container.
Now, right-click on the switch and assign the configlets to the individual switch.
The unique configlets will be at the left and you will need to place a check mark on which ones you want to add. Don’t worry if the common configlets show up on the right. They are supposed to. Select validate from the bottom of the screen.
The main goal of this exercise is to get the red indicators in the running configuration window to no longer appear. You either make another configlet or remove the configuration from the switch.
It is possible to use the Reconcile at the bottom of the screen and this will clean up the remaining red items as well. I don’t really recommend this, it is up to you.
For me it is difficult to tell if these will be common across all switches or not. I just keep making configets until all the red is gone. As shown in the following image.
Now once we save the validation screen we will see back in the network provision screen that something new has appeared. A small letter “T” in a yellow circle tells us that we have tasks that need to be pushed.
At the top left corner of the screen get to the short cut menu and navigate to the tasks page and have a look.
On the far right of the following image, we see the tasks are pending.
Just above the tasks pending notification there is a small circle icon with an arrowhead inside. Click on this to start deploying the task(s). At this point they are only staged.
If the deployment is successful you can look at the network provision screen and see the color of the switch icon has changed to purple.
Now to finish this up we will add the other three switches and with any luck we will automatically configure the switches common elements.
Don’t forget to add the unique configlets to the new switches and deploy the new tasks
We have now completed this blog post on configlets and how to use them to configure our network devices. If we add more switches to other containers we will have to repeat this process. One of the benefits of doing our configurations in this format, is we can add ACL’s to the sector 5 container and we don’t need to be too worried about what configlets are in the others.
Next up, we will look at writing a API script to log into CVP and back these configlets up! Stay Tuned.