Ir maybe we had to create the full 4094 VLANs available
Do you remember back in CCNA school when we learned all sorts of great things that we very rarely followed. One of the favourites was that we are supposed to put meaningful descriptions on all of our interfaces so we know what the other side is connected to.
How many people actually follow that advice?
Yeah, I never do it either. There’s always just too many things on the list that need to get done and it seems like that extra 5 seconds it would take me to update the description to the interface just doesn’t seem like it’s worth the effort. Of course, then I later check the port and end up knocking out my XYZ services and cause myself an outage.
This is where a little python and a decent NMS can help to solve a problem.
Before we get into the code. We need to understand a little about ifIndex values and how they relate to the physical interfaces of the devices. If you’re REALLY interested, you can do some reading in RFC 2863. But in a nutshell, each interface on a device, whether physical or logical has a specific numeric value assigned to it which is the last digit in the interface statistics that can be seen through the SNMP interfaces. This is commonly known as interfaces group stats.
There are a bunch of different tables in the interface group stats that are used to store specific kinds of information or statistics for the interfaces such as
- ifNumber (.22.214.171.124.126.96.36.199.0) – Which is the total number of Interfaces
- ifIndex ( .188.8.131.52.184.108.40.206.1.1. * ) – Which acts as a primary key for all the other interface group stats.
- ifDescr (.220.127.116.11.18.104.22.168.1.2.* ) – Which is the name of the interface
- ifType (.22.214.171.124.126.96.36.199.1.3.* ) – Which describes the type of the interface
- ifMTU ( .188.8.131.52.184.108.40.206.1.4.*) – Which shows the current MTU size configured on the interface
- ifSpeed (.220.127.116.11.18.104.22.168.1.5.*) – Which shows the current speed of the interface
- ifPhysicalAddress (.22.214.171.124.126.96.36.199.1.6.*) – Which shows the mac address of the interface
- ifAdminStatus (.188.8.131.52.184.108.40.206.1.7.*) – Which shows the current admin status of the port
- ifOperStatus (.220.127.116.11.18.104.22.168.1.8.*) – Which shows the current operational status
There’s a bunch more which you can see here if you’re interested, but one that I found particularly fun was the ifAlias ( .22.214.171.124.126.96.36.199.1.1.18.* ) which actually corresponds to the description command in your friendly neighbourhood network operating system
So when your interface is configured like this
The ifAlias value for the corresponding ifIndex looks like this
The Fun Begins
The interesting part about the ifAlias value is that it’s actually a SET-able value through the SNMP interface. That means that if you have a simple piece of python code like the following
It will allow you to run a little command like this >>> set_interface_description(‘10.101.0.221’, ‘1’, ‘Changed This’ ) which will result in the following.
So this is cool, right? We’ve just programatically changed a single interface description on a interface. We could stop here and you would be left with a
“So what? Why would I go to the trouble of doing that. It’s harder than just typing in the description manually!”
But wait! There’s more…
The really cool part about automating something so simple is that now we have a building block that we can do something with. For those of you who might have seen the HPE Intelligent Management Centre, you may already be aware that the topology map does this really cool thing where it actually creates a table of all of the links within a given custom view and automatically creates link-names for them.
You’ll notice that the auto-generated Link-Name actually tells me who’s connected to both sides of that link. You’ll also notice that I have the left and right nodes ( with the IP address ), as well as the left and right interfaces. And “yes”, there is an API for this where it’s all represented in a nice little JSON string which can be easily parsed in your favourite IDE.
Time vs ROI
The reason we don’t label interfaces is that most people feel it’s just not worth the effort to keep them up to date. Things change too often and it’s just too easy to say “it’s not that important” and move on before changing that description. I’m with you. I’m as guilty as everyone else on this. But with the help of a little code, a good NMS, the entire process is now automated.
I can proudly say that, for now at least, my lab is 100% accurate as far as interface descriptions go. And because the whole thing is totally automated, I simply re-run the script overtime I make some changes.
So for those of you who weren’t aware. Yes, there is someone who actually uses SNMP SETs in the world. 🙂
About this time last year, I wrote this post. It’s time to revisit again and plan for 2016.
How did I do?
In 2015, I planned to work on skills in four major areas; python, data science, virtualization, and then just keep up on networking. In general, I think I did good in all areas, with the breakaway really being in the python area. I made a concerted effort this to year to seek out project after project that would allow me to explore different aspects of python, and force me to grow in as many areas as possible. Attending Interop sessions led by such trailblazers as Jason Edelman, Jeremy Schulman, and Matt Oswalt definitely gave me ideas and inspiration to explore new areas, push boundaries, and have really helped me to grow as a coder/developer not to mention really helped me to cement some opinions on the future of networking in general.
I did manage to get through a bunch of the R courses in Cousera and they were great. I’d love to say that I’m going to return and finish the specialization (I’m two courses shorts) but if I”m honest, I’m probably going to move towards the Data Science aspects of Python and get into Anaconda and Pandas more in 2016. Nothing like combining two growth areas into one to really push the growth.
More so this year that others, having great conversations over beers, Moscow Mules, and many a sugery umbrella drink helped me expand my knowledge and firm up some of the thoughts I’ve been having for the last couple of years. No need to name drop, but you all know who you are and I’d like to say thanks for all of the conversations and laughs. As much as I love the tech, it’s the people that always help to drive me forward.
If I’m keeping score, I think that 2015 was a good year.
Plans Plans Plans
Now comes time to publicly declare what I want to accomplish in 2016. This is always the scary part as I know I’m now publicly accountable for any grandiose designs I throw into the ether. 🙂
Practice to Application:
I’ve got a bit of a lab at home. If things go as planned, at the end of the year, I will be able to factory reset *almost* the entire lab and have it come back from the dead in a completely automated fashion. The plan here is to use a combination of python, jinja2, IMC, Ansible, and whatever other pieces I need to duck tape together to make this work by the end of the year. Just because I like to make my life harder than it has to be, I’m planning on building out the topology using vendor independent methodologies, meaning that I want to be able to place a Cisco, HP, or Juniper box into any position in my lab access/distribution/core/dmz/wan/etc… and use a YAML file to dynamically build the required configurations on demand.
Yeah… I know…. But it’s good to set goals right?
OpenSwitch is also another area which I will definitely be exploring during 2016. The project is still very new and definitely has some places, mostly in the documentation area, where there’s room to make a difference. I’ve been really lucky to be able to work at a place where I have direct access to some of the projects core developers and I’m hoping I can share the fruits of that access in more blogs posts, pull requests to enhance the documentation, as well as some interoperability testing with some of the usual-suspect network kit that I already have in my lab. Right now, I’m thinking OSPF, BGP, Spanning-Tree as an unambitious start, and moving from there to using the declarative interface and REST interfaces to see how I can incorporate it into project one.
Thoughts on 2015
2015 was a good year. As an industry, I think we’ve made some great gains in general. The whole “Is SDN really a thing?” conversations seem to be over and we’ve moved on to “ I don’t care what you call it, what does it do for me?” conversations are starting to really get interesting. The projects with value are starting to separate themselves from the science fair exhibits and it looks like parts of the networking profession are finally past the out-right denial and have reached the bargaining stage ( “ Can someone else write the scripts for me? Please? )
I’ve been able to make forward momentum in all the areas I wanted to and I’m generally where I thought I was going to be at the start of the year.
Looking forward to 2016!
First, disclaimer: I’m an HP employee. HP’s a major contributor to the OpenSwitch project. Just thought you should know in case you think that affects my opinion here.
If you need more info on the OpenSwitch project, you can check out the first post in this series here.
Getting our hands dirty
This section comes down into three steps, if you don’t follow these steps, you won’t succeed. I’m not going to go into details on these steps as I’m assuming you can figure this out if you found this blog. 🙂
– Install Virtual Box
– Install Vagrant
– Install Docker Toolbox
I’m running OpenSwitch on a Windows box in this case as the documentation covers the ‘IX build. I’m running on this natively on OSX which also means that I’ve got to install the docker toolbox plugin to get docker containesr to work. I’m also assuming that you’ve already installed Virtual Box and Vagrant for the following section.
Installing Vagrant Plugin
From a terminal window, run the vagrant plugin install vagrant-reload command from the CLI. This should show the following output.
Installing the OpenSwitch Dev Environment
For this section, I’m assuming you have already downloaded the vagrant files from here into your working directory.
Running the Docker Toolbox Plugin
Run the Docker QuickStart Terminal application and wait for the virtual box image to come to a running state. You should be able to see the following
From the terminal, navigate to where you have unzipped the OpenSwitch vagrant files that you downloaded from here. Run vagrant up command from the CLI. At this point some magic happens ( read more on Vagrant here if you’ve never worked with this tool before. Magic is obviously not magic, but I just don’t feel like explaining the whole process in this post. )
On a OSX box, you’re not running as root so you may end up with the following window
If you hit this, don’t worry, just SUDO it!
Accessing the OpenSwitch
From the same terminal window issue the sudo vagrant ssh command to be able to access the shell (CLI) of the OpenSwitch.
If you are successful, you should see the following output. Notice the shell has changed to vagrant@switch
Accessing the network interface
From the vagrant@switch prompt, issue the sudo vtysh command and you will now have access to an industry standard hierarchical CLI like we all know and love!
My thoughts so far
Getting this up and running has been relatively painless. There were a couple of small things to get it running that were particular to OSX which was not covered on the OpenSwitch quick start guide. Nothing that a little patience and google didn’t help me cover in a few minutes though. The install experience was pretty easy. The guides were pretty accurate and the getting this up and running should be something most of us can follow without much trouble.
OpenSwitch doesn’t have what I would call a robust network stack at this point in time, but we’re still really early in this world. Now that I’ve got it up and running, I’m looking forward to starting to look at the alternate interfaces such as OVSDB and REST as described here.
Anyone else got this up and running yet? Thoughts? Let me know in the comments below!