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. 🙂
This is one of those posts inspired by people asking me “Hey! How did you do that Zoom thing while you were presenting?” I’m not sure how I feel about them not asking me about the actual content, but hey, sometimes that’s how things go. Hopefully, sharing these tricks will help people pick up a small skill which can make your presentations more accessible for your audience.
Zoom Zoom Zoom
We’ve all been in a situation where you are stuck with an older projector, or just plain don’t have enough screen real-estate to get everything on the screen you need to. The classic eye-chart. ( By the way,
Note: if you are going to call it an eye-chart, why did you include it in the presentation in the first place? Call it out as reference material for future review, don’t make people wonder why you put something in the presentation that you intentionally made it difficult for them to see! #rantover
I’ve started incorporating more and more live demo’s into my presentations, and many of those are showing code examples. Not the easiest thing to see in on a projector. Thankfully, there’s a nice accessibility feature within OSX and Windows that can help your audience with assimilating the information you’re trying to explain, which after all is the whole point of delivering a presentation, right? What’s the message you want to give them and what do you want to leave them understanding at the end.
Note: I’m writing this in an airport on the way to ONUG, so the windows section will get posted in a future update as I’ve only got my MacBook open at the moment. 🙂
To configure the zooming functions on OSX, it’s pretty easy. Just head over to the settings > accessibility > zoom and turn it on. I particularly like option Zoom follows the keyboard focus which allows the zoom short-cut keys to focus in on exactly where your cursor is currently located.
Once you’ve turned on this setting To zoom in, press Command (⌘)-Option (⌥)-Equal Sign (=). To zoom out, press Command (⌘)-Option (⌥)-Minus Sign (-).
Here’s a quick video example of this in action. As you can see, you can zoom in and focus on any area of the screen that you want to draw attention to.
This is a placeholder that I will update in the extremely near future. I do present from both OS’s so it’s nice that both have a very similar feature with almost identical hotkeys.
Love your audience
Remember at the end of the day, although you may feel like you’re the man because you’re at the front of the room, the most important person in any presentation is each and every individual member of the audience. Anything that we can to to help them understand and consume the message/information that we’re trying to deliver is always going to be welcome.
This is part four in a series of using python and the RESTful API to automate the configuration of the HP IMC network management station. Like with all things, it’s easier to learn something when you’re able to find a good reason to use those skills. I decided to extend my python skills by figuring out how to use python to configure my NMS using the RESTful API.
If you’re interested, check out the other posts in this series
Adding Custom Views
In this post, we’re going to use the RESTful API to programatically add a custom view, and then add devices to that custom view. For those of you who don’t know, a custom view is simply a logical grouping of devices. In IMC custom views also form the basis of the topology maps. In fact, a custom view and a topology map are essentially the same object internally, The difference is just whether you chose to look at it as a list of devices in the normal interface or chose to look at it in the typical topology/visio format which we all know and might-not-love.
Why might we want to add a custom view programatically you ask? While, the answer to that might be simply that we’re lazy and it’s easier and faster. Or it might be that you don’t want to have to look through all the different devices, or, as in my case, that you simply want an excuse to extend your python skills. Whatever you’re reasons are, custom views are something that just don’t get used enough in my opinion.
Custom views are a great way to be able to zoom in on the status of a specific branch, a geographic area, maybe a logical grouping of devices that support a specific application? It really doesn’t matter and the best part is that a single device can exist in multiple custom views at the same time, so there’s really no limit to how you put these views together. It all depends on what makes sense to you.
This code is a little bit more complicated than some of the other examples we’ve looked at. We’re actually going to be using multiple functions together, but the logic should be pretty easy to follow. I’m sure there are better ways to do this, but this seems to work for me. I’m sure I’ll be back here in a year going “Why did I write it that way!?!?!?!?!?” but for now, I hope it’s simple enough for someone else to follow and possibly get inspired.
The main function is really just calling the other functions which we will break down below
Step 1 – Create the Custom View
In this code, we’re going to simply use this small function that I created to gather the name of the custom view ( the view_name variable ) and then use that to create the JSON payload ( the payload variable ). The other part of the JSON payload is the autoAddDevType variable which is hard-coded to 0. This could be used to have the system automatically add new devices of a given type, but I”m in interested in doing the automation myself here. The last part of this code will be used as the input for another function, which is the return of the view name. You can see in the main function in the the view_name = create_new_view() line.
Step 2 – Get Custom Views
For the next part, we are going to need to figure out what Id was assigned to this new view, to do this we’re going to have to go through a couple of steps. The first one is to ask the NMS to send us a list of all the known custom views. The following function will request the list, which will be returned as a JSON array, and then convert it over into a python list of dictionaries so we can work with it natively as a python object. You can see this in the main function in the view_list = get_custom_views() line
Now that we have the view_list which is the list of all the views, we’re going to have to find the ID for the new view that we just created. We do that by by using the get_view_id() function using the view_name as the input. Essentially, this will look through each of the views in the view_list that was returned above and let us know when the ‘name’ value is equal to the view_name value that we captured above. Once it’s equal, we then return the ‘symbolId’ which is the internal unique numeric value assigned to this particular custom view. This is the number we’re going to use to identify the view that that we want to add devices to. Make sense? Now that we’ve got this number, we’re going to assign it to the object view_id for use later on.
Note: I actually could have added the devices directly to the view in the original add_custom_view code code above, but then I’d have to write the modify function later if I ever wanted to change or add new devices to the view. I’m trying to follow the DRY ( Don’t Repeat Yourself ) advice here so I just write the modify here and I can then leverage it later without having to re-write the code.
Step 3 – Generate the Device List
We’re not going to spend too much time on this part as I’m essentially re-using the code from the Changing Device Categories blog. It’s pretty straight forward. I’m using some user-put to gather a list of devices that we want to add to this specific view and then capture it in the dev_list object. What’s cool about doing it this way is that the returned list will search through all the IP addresses assigned to your devices, not just the managed address which might come up in the NMS interface where you would normally perform this step. There are ways around that as well, but that’s another blog.
Step 4 – Add Devices to Existing Custom View
This last step is where things come together. We’re going to run the add_device_to_view(dev_list, view_id) function which is using the dev_list generated in step 3 and the view_id that we captured at the end of step 2 as the inputs. Essentially, we’re just saying here “ add all the devices I want to the view I just created “.
Wrapping it Up
So this is just an example of how you can tie a few pieces of code together to help automate something that might otherwise take you a lot of manual labour. In this case, just a bunch of mouse clicks and depending on the fact that you were able to manually identify all the devices you wanted to add to a specific view. Personally, I’d rather leave the hard work to the computers and move on to something that requires my brain.
In the first couple of posts in this series, we created some operators, then we added some devices. In this post we’re going to look at something a little more complicated. In this post, we’re going to link a couple of different python functions together to meet the requirement which is to change a device from one category to another.
A bit about Device Categories
For those of you haven’t used HP’s Intelligent Management Centre before, the system automatically categorizes any discovered device, usually based upon SNMP sysobjectid. What this means is that when you run an auto discovery, the majority of your infrastructure will be properly classified right out of the box.
This works great for devices which are SNMP enabled, as well as some other devices like ESX machines ( Virtual Devices ) which use SOAP as the management protocol, but it fails pretty miserably when dealing with devices which don’t support anything more than PING. IMC’s default behaviour is to put anything which doesn’t respond to SNMP in the Desktop Category.
IP Phones aren’t smart
I’ve had customers who decided to discover all of their expensive IP phones and suddenly found out that none of them were classified properly. The problem with IP phones is that they are usually pretty stupid devices. Low memory, weak CPUs. Most of the processing/thinking is done by the PBX. I’ve never seen an IP phone that supports SNMP.
In this case we have two choices
- Manually change each IP phone from the Desktop category into the Voice category one device at a time.
- Use the RESTful API and a bit of code to do it wihile we go have a coffee
So the first thing we need to do is to identify the IP phones from the rest of the devices in the Desktop category. Thankfully, this is where having a well designed network can come in REALLY handy. Most Voice networks are designed so that the IP phones are automatically put into a voice vlan. This means that all phones SHOULD be in the same layer 3 network range.
The first piece of code we need to write is a simple piece of code which will allow the user to identify which of the categories they want to filter by. Although this might sound strange, we actually need to make sure that we only grab the DESKTOP devices in a specific subnet range. Imagine if you accidentally move the router or switch for this subnet into the voice category too. Really sucks leaving when you lose your router, right?
In this piece of code, we’re simply creating a dictionary which creates the link between the categoryId, which is the number IMC internally uses to identify the defined categories and the labels we humans use to identify them. In a nutshell, this simply prints out the available categories. Why you ask? Because the human running this script needs to known which categories they want to filter by.
This next performs two different functions
- Filters all known devices by the categories listed above
- Filters all known devices by an IP range.
Combining the two of them we’re able to easily fine all of the devices that have been classified in the Desktop Category in the L3 subnet of the IP phones and return that as a dictionary which contains, among other things, the device IDs which we’ll need in the next step.
Putting it all together
So the last piece of code is where the magic actually happens.
First we assign the output of the filtering function above into the variable called dev_list. Essentially, this is a list of devices which meet the search criteria of the filtering function.
In our case, this means the list will consists of all the IP phones in the specific subnet that we filtered.
From there, we use the items in dev_list as input into a for loop which changes them into the new category. ( see how we use the same print_category function from above? )
Wrapping it up
Hopefully this is a fairly useful example of how putting a few basic python functions together can help to substantially cut down on the amount of time it takes to perform what’s really a simple task. That’s the whole point of automation right?
As I continue learning, I can already see there a bunch of ways to improve this code, but hopefully having a simple working example will help people who are a couple of steps behind me on this journey take another step forward.
If you’re ahead of me on this journey and have suggestions, please feel free to comment!