Just a test to see if the migration to the new server is working.
Sub title: Winter is coming
DISCLAIMER: You can only trust a mad scientist so much!
Interesting times we are living in today, especially in the teknology industry! As you may know, if you read this blog, I am an automation evangelist. I have developed network automation applications for HPE Comware, Arista and Cumulus Linux. I always looked at the future with my “George Jetson” eyes and not my “Soylent Green” eyes. To me the future is bright, push button, and so much simpler because we are moving into a world of amazing automation.
I have been testifying, for quite a while, that if you are a network engineer, you need to depart from the command line and start picking up some python chops. You need to learn how to code, be familiar with the DevOps process, run around your office and say things like CICD, Kubernets, and salt-chef-puppet!
If you’re in a meeting, get a quizzical look on your face and ask “What about ZTP?” Congratulations! You’re now a member of Team Automation.
Now for the bad news…..
When I used to hear the word “automation” I would think of the simplicity it brings to day to day drudgery. Eliminating the small insignificant tasks that quite frankly drive me crazy. There is also a dark side to this. Whenever I hear the word automation, I think “humans don’t touch it”. Don’t get me wrong, someone has to invent the automation, but once that’s done….POOF… There goes a task that at one time required a human to touch it. Within the next 3 to 5 years I can image automation will be commonplace in customers data centers and large enterprise networks. They will quietly hum along and finding a network technician will be just about as hard as finding help at your local Home Depot on a Saturday morning.
Beyond that I see an even greater threat to your console cable wielding network engineer. A.I. Artificial Intelligence.
I look at the network automation practice as having five levels. As the levels get higher, we are bound to see AI getting inserted into the process.
You can clearly see that when we get to level five, we will all be seeking employment selling shoes or possibly in the construction business. If you include nanotechnology, robotics, and quantum computing into the mix we just might have to become robot phycologists (if they can think for themselves, they will have emotional hang ups just like us)!
Lately, I have been reading a lot about the future as seen through the eyes of Martin Ford. I am surprised to find he has a new read on just this subject called Architects of Intelligence….downloading now…Martin talks at great length how the influx of automation, robots (Yes, I have seen robots flipping burgers) and AI are going to shape our world. Jobs will be greatly impacted. Doctors, Lawyers, Scientists, Laborer’s. I don’t think there will be any job function not impacted by forthcoming teknology.
Is there any good news? Maybe, as far as the levels go, we are still fairly close to the bottom, still slogging through spanning-tree issues and route flapping. Most major enterprise networks have a Hodge-Podge of network management solutions and very little automation to speak of. So, for the moment we are relatively safe. This is no time to rest on your laurels!
There is an old hockey adage “Skate where the puck will be, not where it’s at” So it amazes me that today people are still trying to get the next vendor certification. CCIE, CISSP, VCP. I can tell you, with some confidence, by level 5 all that information will be inside the AI. I hope it won’t take too long to get that cert, it just may become obsolete by the time you do.
In closing, I would like to emphasize the need to re-invent yourself. There are a few vendors already bringing affordable AI solutions to the market. I know, AI has been around for a while but we are about to see an explosion in its use. As AI moves from being Reactive Machines all the way to Self-Awareness it will no doubt start replacing humans in many sectors. I for one will most likely be retired by then, living on my good looks and charm, no doubt (starving) but it’s you, dear reader, I am worried about.
Do yourself a favor and don’t quit your day job but make sure to stretch yourself. Learn all you can on these advanced subjects, don’t be the one who gets surprised by the events about to unfold and for heavens sake buy a warm coat……winter is coming!
Applications are king. Everything we do from a data center hardware perspective is in support of delivering the application to the end user and storing the outcome of those user interactions. Upon an initial release of an application, developers are hard at work on the next release. New features, bug fixes and streamlining interfaces drive the need to improve the application. Unfortunately, past development methodologies produced applications that had 1000’s of lines of code and the ability to deploy new versions happened every three to six months.
Deploying these huge applications in the data center was accomplished by spinning up a new Virtual Machine and loading the corresponding operating system (and necessary hardware drivers) and the application. With the introduction of CICD, Continuous Integration Continuous Delivery, a DevOps approach to designing and deploying applications meant that those 1000-line applications would need to be broken down into smaller “chunks” with explicit unit testing.
With containerization the smaller bits of code could be loaded into a container and that application of 1000 lines could now be deployed in 120 containers. Want 10 copies of that application load balanced? That would result in 1200 containers. Sounds difficult but these 1200 containers can be deployed by Kubernetes in a few lines of a deployment.yaml file. Want to scale up from there? A single command to Kubernetes API would result in more resources made available to the application, on the fly with no service interruption.
Now that we have the smaller parts of our application, we can create automated testing and automated deployment. Due to the power of DevOps and CiCD, Amazon pushes new software updates to its website every 11 seconds.
Applications are King, Containerized applications are Kingier.
I would have to say I’m your average mad scientist. I don’t have bubbling beakers full of brightly colored fluids and sparks from electrodes zipping around my lab but I do have a lot of switches, routers, virtual machines and applications currently under development. I am not a professional programmer and everything I know about application development comes from the Googler and one or two books on the subject du jour from Amazon.
As expected, the winds of change bring changes, I find myself fascinated by another attraction. Plexxi.
Before we get to what it is, let’s start with why?
OK, Time for a little thought experiment. I want you to spin up a new Virtual Machine, with a new storage target in your data center…I’ll wait……OK! I bet it only took about 5 or 10 minutes for your to do that…..what didn’t you do? Configure the network. Did your new VM wind up in the right port group? What happens if you need to migrate the VM to another EXSi server? Is the VLAN on the destination server switchport? NO?
Then let’s start the stopwatch and see how long it takes the network team to make those changes for you. What if it just happens when we spun up the VM?
What kind of sorcery is this?……It’s not sorcery, it’s HPE composable Fabric formerly known as Plexxi.
When I talk about this teknology I like to think of a house. A house has a strong foundation, Walls that divide rooms from one another and a roof to keep me dry. Let’s start with the foundation.
We start by removing all the layers of network architecture and build a full mesh layer two network. Actually less physical links than a spine/leaf with 4 spines and eight leafs. We only need the leafs. The forwarding tables of each switch are managed and programmed by the controller. Oh and one little small thing to point out is the full mesh is auto instantiated!
Next up, the walls. Think about a convention center. One week they have a huge group in attendance and then next week it’s 10 small companies. They need to be able to move the walls and reconfigure the space to meet the needs of the customer. If you have attended any of these events, you’ll know what I mean. Composable Fabric is just about the same thing. I start with the full mesh network and then I am able to define Affinities, giving me the ability to isolate workload traffic. I’m not talking about separate vlans, I talking about real isolation. moving walls! Oh, and yes, this can be done dynamically, Affinities can be deployed and torn back down many, many times, without a single word on a command line by a human.
And finally, the roof, in composable terms this is the application integration layer. The application layer allows us to integrate into things like OpenShift/Kubernetes, OpenStack and vCenter (to name a few). We can look for events happening in these system and modify the network configuration to support changes in these upper layer cloud management systems. If you vMotion a VM from one ESXi host to another, the network port connected to the destination ESXi host is automatically configured and you didn’t even need to talk to the guy over in the network department. This means that the network is responsive to what the guys or gals are doing in the software defined compute/storage world……finally!
So, you can build your data center network like my Dad built his, or you can step into the world of self provisioning, self healing, software defined networking.
I ask you, are you a Fred Flintstone or a George Jetson?
Want more?….check it out… Here
DISCLAIMER: I am a self-proclaimed, self-trained software hack, I barely know what I am doing! I’m fairly sure this is how you do it.
I started to write some code and when I looked up, a year had gone by…….I’m listening to Strawberry Fields Forever and wondering how a full year has slipped by without a post to the blog……So, in the words of Lennon and McCartney,let me take you down, ‘cause I’m going to.
It’s been quite a journey from being a network engineer to becoming a “developer” (I use the term loosely) and every day I discover its a journey with no foreseeable end. I’m am learning new things all the time and the more I know it just opens up new avenues to discover.
I started the year off puzzling over an interesting problem. I was working with Ansible and trying to automate Cumulus switches. Seemed like it was fairly straight forward. All you need is a YAML file with “ALL” the variables for your data center(loopbacks, fabric IP’s, Router ID’s) and a playbook and viola, you have yourself a functioning data center.
Not so fast you ZTPheads, sure, I no longer had to type the configuration into the switch, but I had to come up with all the variables in the all.yaml file. You’re basically editing a text file with no syntax checking! That’s not ZTP, you’re just moving the workload over to making the ALL file.
I was working on a process to automatically generate the ALL file and came up with a simple solution. Antigua. This app takes 10 variables and spawns the entire spine/leaf network all.yaml file. It then uses Jinja2 templates to generate the full switch configurations and upload the starup-config file into Arista’s Cloud Vision Portal. After that the config is applied to the switches in the spine/leaf and everything (eBGP fabric) is up and running in less than a minute.
Want to roll out a new spine/leaf pod in your data center? How about having it up and running in less than 1 minute? Can you do that? I can.
Later I was challenged to have the switches just self configure and I rewrote Antigua into “ISSAC” a special version of Antigua that ran directly on Arista switches. Basically, the switch boots, looks in its TFTP directory for a “key” file. If it’s there, it sends it to all it neighbors (via ISSAC’s neighbor database) and then learns it’s position (spine01) and self-configures. The only thing you have to do is TFTP a key file into any one of the switches TFTP directory. That’s It! Even I can do that…..Geesh!
After I got the mechanics down for Antigua, I started to think about other applications where I could reuse the teknology. I started looking at managing VXLAN tunnels and automatically generating “vxlan” configlets and loading them into Arista CVP. I came up with Subway.
Subway uses a mongo database and keeps track of all the changes to the VIN flood lists. It was a fun thing to write but needs a little more work. With the introduction of eVPN, theres not much left to do with the control plane. Definitely an application worth coming back to.
Longing for something I could really use on a day to day basis, I started looking at what it takes to MLAG a pair of Arista switches. Take a look, it’s like 16 commands per switch.
A couple of them are even reversed, I hope you don’t make a mistake, you’ll have fun trouble shooting what you did wrong.
I really had the process refined for generating configlets and stuffing them into CVP. So I automated the MLAG process with Jetlag.
Jetlag basically takes two IP addresses, the seed port of the two ports used for MLAG between the switches and then the port number of the LACP downlink. Very simple application. It generates a mlag configlet, saves it to CVP and applies it to the switches.
If you think about it, these three applications could really become a single app. They all basically do the same thing. Get user input, make a text file of the config, upload to CVP and apply it to the switches in the inventory. After finishing these up and showing them around, Antigua started to get a lot of attention. Still the only app that I know of that can do what it does. Gauntlet thrown!
I moved onto another challenge. A partner wanted to use HPE IMC to monitor his customer’s network. If there was a real time alarm on IMC, they wanted IMC to open an “incident” in Service Now. and have two-way communication between the two to track resolution of the incident. I put together an app call “SnowBridge”. snowBridge uses IMC’s and Service Nows API’s and sits in the middle running a continuous loop. It runs on the command line with no user interaction. This app got me thinking about how to divide up the tasks into smaller micro-services. More on this later.
With this effort out of the way I started working on a request to streamline Antigua. Antigua will generate a YAML file. It could be used with Arista, Comware or Ansible. It will upload to any of the three systems (working on Tower). The new request was to strip away the flask framework, make it run from the command line and just generate the config files and store them on the hard drive. Check…..easy…….done. It’s called AntiguaCLI.
I had another request to update an application that runs in a docker container and allows for using the API’s from Bigswitch. More of a proof of concept app, it allows for logging into Bigswitch Networks BSN controller and looking at a couple lists. I think I will automate the routing function of BSN. This little project re-kindled my love for playing with docker. The next project would take it to new heights.
So, HPE makes an application called OneView that manages the new Synergy compute platforms. Tracks uplinks sets, networks, storage volumes, server profiles, kind of a single pane of glass for managing these types of things. When someone adds a network or a link set, the rest of the network world (Outside of OneView) doesn’t have a clue it happened. However there is some integration for the state change message bus in IMC. IMC listens to One View’s State Change Message Bus and learsn of these events but if you’re not using that……, certainly there must be something to use to learn of these changes.
I looked at the hpOneView python library and decided I could make an application that did just that and called it “Spymongo”. The whole solution (three docker containers) can be used or just a portion of it. It all depends on what you want to do.
The first thing is to docker-compose build the spymongo and the mongo database containers. Once these two containers are running, the spymongo app automatically listens the OneView scmb and learns about all the changes being made. It starts looking for network changes and saves the document to the mongodb. You don’t have to use it in this fashion. You could take the app and make it do whatever you need. You could possibly use it without the database.
I use the database because I need just a little more functionality out of the app. With spymongo running, scmb events are automatically being stored in a mongo db. I wrote a “front-end” for the database in flask called “spyFront”.
spyFront allows for the verification of the database records. It also has a feature that lets me learn every network event that OneView knows about prior to running spymongo. This lets me have “parity” between the OneView database and spymongo’s. The two databases are synced and spymongo keeps them up to date by listening the the scmb.
I did explore adding vcenter support to spyFront. Currently, spymong looks at vcenter and downloads a list of virtual machines and their network connections. With spymongo running, anyone can make an application and mount the mongodb. They no longer need to deal with ssh keys to have secure communication with OneView. Just simply use the mongo database and go.
Throughout the year I have been on my favorite learning site Udemy. and I have been looking at new things to play with. Hey, for $10 bucks it’s the cheapest education you will find. I have taken a Puppet course, a CHEF class, Flask/API/Docker training and a super heavy course in Angular where I learned about the Single Page Application.
Just last week I started looking at what Darth was doing (mind blowing as usual) over at Kontrolissues. and it looks like a blast! I also started deep diving mesophere’s DC/OS. All of this is available on my private github. Just need to push it through the Open Source Review Board before it becomes available to the public.
I hope it’s not another year until I blog again, I will promise to quit being so “lazy” and keep you up to date on the going-ons of a half-crazed nerf herder.
By the way, the lyric “climb in the back with your head in the clouds” kinda has a new meaning for me!
I wonder if anyone will know this lyric is from “Lucy in the sky with diamonds and not Strawberry fields forever…..HA!
Sub title: Simplified Aristra Zero Touch switch deployment
DISCLAIMER: You can only trust a mad scientist so much!
Seems like I’m going a mile a minute here, but there is a great urgency to get this information out to as many people as possible, and as soon as possible. If you are building spine/leaf data centers with Arista switches, how would you like to provide a baseline configuration on a 4 spine and 8 leaf network and never touch one console cable? You can get started just by scanning the barcode on the outside of the box!
ZTP is the nirvana state that all of us who have been doing this for a while dream of (while we’re not dreaming of other things!). ZTP means you can pull the switch out of the box, plug in a power cable and connect the management port to the network and the switch will configure itself. It’s a neat trick that can save you a lot of keystrokes. There are several different ways of doing this and they are documented on the interwebs. No need to hash that out here. Let’s set up a simple lab and I’ll show you the way we do it here in the laboratory!
Above is a diagram of my lab. I am running 10x Arista vEOS switches in vagrant on a really big Windows 10 PC. All of them are set to zerothouch enable by default. This means if they can’t find a “startup-config file in flash, they will start broadcasting DHCP request out all ports.
You don’t need all 10, one or two will do, but I like to show off every now and then.
The ZTP server that we will implement will have a DHCP scope enabled and Option 67 as well to tell the switch who to “talk” to, to get is configuration, and possibly software as well.
First thing first! You will need to get my repo off of github at this location: https://github.com/xod442/aristaZTP
From a shell prompt on your linux workstation,
sudo git clone https://github.com/xod442/aristaZTP.git
You will see a newly created directory called aristaZTP.
I’m using the Ubuntu Mate distribution. It is probably one of the most “windows like” versions of linux and comes with “caja” a file explorer. Snap up a copy here: https://ubuntu-mate.org/download/
HIP TIP OF THE WEEK!
In Ubuntu’s command shell, to avoid typing sudo in front of just about every command you can “sudo –s” and once you enter the password, you will be at a “hashtag” prompt…..sudo no more!
Once you’re at the “#” prompt, type caja and spawn a very powerful file browser.
Now let me explain the different files, the README.md has some interesting tid bits and should be read at you leisure. There is a tftpboot directory, this is where we keep our csv variables and the configuration template. There is an interfaces file in my screenshot but these are not the droids you are looking for…….Finally, the setup.sh is a shell script that will configure the entire ZTP server from scratch. You just have to change a few things.
You’re looking at the first of three sections in the setup.sh file. Take a close look at what has a # in front of it. In the DHCP section the #apt-get install isc-dhcp-server is commented out. If you want to install it, and you do, get rid of the “#” in front of the command and it will change color.
Look a little more at the things you need to change.
Subnet 172.20.0.0 netmask 255.255.255.0. You might want to change this to match your own lab addressing. Take caution when working with multiple DHCP servers on the same network. Change the DHCP range and the ‘option tftp-server-name “172.20.0.1”;’ to match the eth0 address of your ZTP server. A quick ifconfig should reveal the address you will need.
Next the option for the boot file. Option bootfile-name “boot.py” This is the file that you want the switch to start processing when it boots. This could be the switches startup-config, but you would need to do static DHCP entries and have a boot file for every switch! No such shenanigans here! Our file has the name boot.py which means it’s a python script and when the switch downloads the boot.py file it will start configuring the switch for you.
Let’s look at the other sections of the setup.sh file.
There are two more sections in the script. One to setup the tftp server and the other sets up a ftp server but we don’t really need it for our demonstration, but what the heck, fire it up anyway!
PAY CLOSE ATTENTION to the directories listed in the tftp server sections. These must point to where you have the tftpboot directory saved. Pay attention! Change them to match your environment.
Once you made the necessary changes to the setup.sh file, run it # ./setup.sh…………..didn’t run? Try change the permissions of the file like this # chmod 775 setup.sh…….try it again.
Now the DHCP and TFTP should be up and running but you will need to CHMOD the dhcpd.leases file. It’s a pain in the butt and I have not figured out a way to not have to do this but it only needs done when you boot up the ZTP server.
OK, just a couple other things to do for successful booting of our switches. The one thing you absolutely need to know is the MAC address of all the switches. You will need this information and should be easily obtained without having to console into each switch. Barcode lables on the boxes, Perhaps they are listed on your PO?
Once we have the MAC addresses, we can pair it up with some repetitive information and just about anything you would like to see configured in the “base configuration”. I keep things like the real IP address I want the switch to have and the Cloud Vision Portal credentials. You can maintain this information in an Excel spreadsheet or you can use “switchdb” A flask application I wrote for just such things. You can find switchdb here: https://github.com/xod442/scriptsonly/tree/master/switchdb
Hint, Hint! install switchdb on the ZTP server…easy peazy!
Once we have all of our MAC addresses in the CSV file, you will need to store the CSV file in the tftpboot directory with the name of “varMatrix.csv”. It should look something like this.
The last piece of this puzzle is the template.txt file. It is used to create the switches configuration. In this file, everywhere we have a dollar sign “$” it “pairs” a variable in the CSV file.
You can modify this template file to add anything else that might be a common configuration for all switches. Don’t get too crazy, the next blog post will cover Ansible and we will really start deploying configurations then
NOTE: Once the switches boot with this template, they will be ready to import into Cloud Vision Portal and further configurations can be deployed there!
The real “magic” behind this ZTP process is the boot.py file. I had to do some interesting things to make this work but the process is fairly simple. Here’s the process.
Switch boots and gets DHCP and location of the boot.py file, downloads and executes it
boot.py copies over the varMatrix.csv file and the template.txt file to the switches flash.
boot.py opens both files for reading.
boot.py finds the MAC address of the local switch and compares it to the MAC field in the CSV.
If there is a match, the dollar sign variables in the template are replaced with the CSV variables
boot.py saves the result to the switches flash drive and the switch reloads
The switches will be ready to be managed after they complete their reload. There are a couple different directions we can go from here. We can import the switches into CVP check out this blog post for more information. http://techworldwookie.com/?p=205
Next up: Whipping these switches into shape with Ansible and Docker!
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.
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
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.
DANGER WILL ROBINSON!!!!
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.
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
The only thing we are missing is assigning an IP address…..(be quite you ZTPheads!) to the management interface.
interface management 1
ip address 10.132.0.8 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.132.0.1
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.
Console 2.0 a limited operators interface to IMC.
OK, sorry for the brief diversion from the python blog, but something came up and I wanted to share. We all know the power of API’s, I have been evangelizing this for quite some time now. Here is an example of API’s in action. I have a customer that uses IMC and likes it a lot. The main trouble he is having is he cannot lock down IMC to the point where the noob console operators cannot get into trouble. Things like putting a port in the down state and having it turn out to be an uplink port. So with some python code, HTML5, IMC API’s and containers…can’t forget those, I put together a solution. Originally this was implemented on a WAMP server. So if you have a Windows only policy, this solution will work for you as well (You will need my Win2008R2 OVA file…email me).
I give you Console 2.0…in a docker container. Lately, it seems I’m ending a lot of conversations with …”in a docker container” …….I’m kind of like that guy with a jalapeno on a stick!
This solution allows for the multiple users to find MAC or IP addresses, up/down front facing ports only, change vlans on interfaces and add voice VOIP configuration to switchports. I added a few other handy things to have and finally an option that will blast the voip port back to factory defaults.
This is available on my Dockerhub account at:
To get the docker image you will issue this command from a docker server: sudo docker pull xod442/console2
To get it to run:
sudo docker run -d -p 80:80 xod442/console2 /usr/sbin/apache2ctl -D FOREGROUND
Point a browser to the docker server’s IP address on port 80. Away you go!