Oh, yeah, that would be a nice to have!

A quick Arista Spine/Leaf to play with
Part One: Get off the bench
DISCLAIMER: You can only trust a mad scientist so much!
It came to me while I was thinking about something else. I just showed you how to get switches loaded into Arista’s Cloud Vision portal, but you might not have any switches to play with.
You have Vagrant installed, if not Vagrant Up!
You have Oracle VirtualBox installed OVB
You have the box file from Arista
Arista vEOS-lab-6.16.6M-virtualbox.box
The finished product should look like this.
If you are familiar with vagrant, have I got a file for you!
Click this to download.
OK, move the vagrantfile into the directory …just make something up…and change to that dir.
Rename the file if you’re using linux to Vagrantfile (Capital V)
Make sure you add the box file to vagrant
Vagrant box add vEOS4166M vEOS-lab-4.16.6M-virtualbox.box

Then, at the command line just type vagrant up.

Each VM need 1536 of RAM!

The four switch lab will boot up inside Oracle Virtualbox.
Log into the switches with admin/admin

Now you have a lab that’s ready for a BGP configuration!

NOTE!!! You will need to go into the VM setting in Oracle and change the Management interface (#1) to Bridged mode.

It will show that it is set to NAT and that won’t work.

Beginner’s guide to the Universe and Cloud Vision Portal

Part One: Get that switch in the game!

DISCLAIMER: You can only trust a mad scientist so much! 

Note for all the fans: I have not posted in quite a while. I was doing some soul searching and I cut the soles off of my shoes, learned to play the flute and lived in a tree. It took a while but I finally realized that life was not worth living if I couldn’t blog and look at facebook. So, I’m back!….and the crowd went wild!

OK, so you have heard the latest word on the street that HPE will start reselling Arista Networks. Yes, it’s true. That means we get to start experimenting with new things here in the laboratory. You might be of the mindset that a switch is a switch but Arista switches take it a bit further.

Arista keeps the “state” of the switch in something called SysDB. It’s a database that keeps all the state information of all the processes. If the OSFP process hangs, you simple restart it and it loads the last know state form the SysDB, which greatly reduces network outages.

Now if you kick it up a notch, all the Arista switches share the state information with Arista Cloud Vision Portal (CVP). CVP uses something called NetDB to keep the state of the entire network! CVP now gives us a single place where we can apply “API’s”, yes, I said it! API….you knew I wouldn’t go a whole blog post without mentioning it! The API’s allow the entire configuration of the network to be manipulated and automated any way you want it. I did a little pimping out of the log in screen, this is what it looks like.


Let’s login and start working with CVP. Here is what waits for you upon successful authentication.


As Jeff Probst would say, “First things first!” There are a number of things to click on and look around, but in order to do anything substantial we need to add some switches to CVP. CVP uses a concept of configlets, small portions of a config file that get applied to hierarchical containers (not Docker) and as you go down the tree, additional configlets are combined to make the final configuration. Let’s take a closer look. I will log into a vEOS switch running in Oracle Virtualbox (didn’t think I wouldn’t mention that either???). Here is spine01.


This switch is fully configured. Even so, it was missing some key information. Now pay attention! You are going to miss the most important part. CVP will not be able to manage any switch without the correct credentials. This means the credz that you use to log into CVP must be on the switch as well…….all you ZTP heads don’t blow a cork just yet, we’ll get to that in another blog, stay tuned….so, just for now, we will add the username to the switch, manually.

HOLD THE PHONE!!!!!!……I just added the username and it was the exact same commands as a Cisco switch! Yes, you are correct! You do not need to learn a new cli, for the most part it is exactly like Cisco.

Configuring the switch

Conf t (don’t need the “t”)
username cvpadmin privilege 15 role network-admin secret mypassword
CTL-Z (I’m old school)
Wri me (Told you…write to memory)

Now we have the credentials saved to the configuration, its VERY important that these are the same as the ones used to log into CVP.  We also need to tell the switch that it will be managed by……..wait for it………APIs!!

Conf  (Not using the ”t” this time because I’m lazy)
Management api http-commands
Cors allowed-origin all
No shut
Wri me

The only thing we are missing is assigning an IP address…..(be quite you ZTPheads!) to the management interface.

interface management 1
ip address
ip route
Write me

Looking good. You can consider that this will be the very basic configuration needed by CVP to manage the device. We will build a configlet to ensure that as well.

Adding the switch to CVP

It’s been all fun and games up to this point, but here I got burned pretty badly. Let’s be honest, there was nothing pretty about it. There are a couple of ways to get a running switch into CVP. You can add them one at a time or by using the bulk import method. We’ll look at both options but first we are going to guarantee that all of the devices we import will have a minimum configlet applied.

Log into CVP and look at the main screen (pictured above) and click on the Configlets button. Your list will be empty if you’re just starting out. Look at the top right of the screen and you will see a plus “+” sign with a down arrow….click on it and select configlets.

At the bottom of the page click on Save.

Now we need to apply the configlet to the uppermost container in our tree and I know I will have to have a discussion about containers right about now!



It’s a far flung organization we have over here a wookieware so we approached the container tree with a little foresight into what will happen and what could happen. Security it always a concern so we wanted to have a container just for security ALC’s otherwise known as access control lists and yes, I do know my ACL from a hole in the ground, but I digress. Here is what our tree looks like.


We created a top level container called Wookieware. After that we have our security container called Sector 5, this could be some geographic designation but it is just a place where the security folks can add a configlet of an ACL and have it trickle down to the lower levels where the switches will inherit them. Moving down the tree we have our data center container dc1 and after that the different pod containers. Finally a little further division of the switch role. Spine or leaf.

It’s important to note that configlets can be deployed in any container. The top level will have Motd, Triple-A, and basic routing. The switches will have configlets that pertain to just local configurations like IP address of interfaces, Autonomous system numbers, loopback IP addresses and hostnames.

The implied idea is that as we move down the tree the switch picks up the configlet in each container (and software image) and by the time we arrive at the switch most of the configuration is complete. So take a little time here and build out what you want your tree to look like.


But what about the switches!

Let’s go back to the main menu and look at the Inventory. At the top left you will see grid. Click on it and it will give you shortcuts to where you want to go.


Choose Inventory and it will take you to your CVP inventory page. From here (your list should be empty if you’re just starting out) look at the top right and click on the plus “+” sign.

We can add switches one at a time…BORING!!…..but let’s have a look. The add device radio button is on Add Device. In the Host Name / IP box we will but the IP address of the switch and navigate down to the container we want to place our switch. At this point you need to have a long think about what you are doing. If your switch is fully configured then I wouldn’t recommend adding it to the spot whare you want it. Perhaps it’s better to have a container for all new switches and import to that first. Then make sure you have the necessary configlets you desire. It’s up to you. Think!

I don’t like to think a lot so for the purposes of this blog I will choose the final container x-spines and click on the add button next to the Host Name /IP address.


Now watch out! Here’s is where it gets a little funky, don’t know if this is browser related but as long as the screen says connecting it will not add to the inventory when you select the save button at the bottom of the screen.


Look at the top right of the screen again and locate the refresh icon. Click it. Click it. Click it. Keep clicking on it until the switch says connected.


The switch in now in the inventory and is inheriting any configlets you have in your container tree. Click on the Save button at the bottom of the screen to return to the inventory home page.


Bulk importing switches

The same result can be obtained by using Import Device function. From the inventory home screen click on the plus “+” sign at the top right of your screen and this time we will choose the Import Device function. If you look just below the validate button you will see a link to download a sample CSV file. Download it and we will quickly fill it out.


Open up the Excel CSV file and look at the information we need. Below is a sample of the one I used to populate my system.


The same thing applies to the bulk loader. Keep refreshing your screen until you see all the switches Connected Then hit the Save button at the bottom of your screen.

Next up…Part Two….working with configlets.

If your new to Arista then look at this: Arista Warrior. It’s a bit dated but still an excellent resource.