I use SNMP SETs and I’m not afraid to admit it.

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.

Understanding ifIndex

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 (.1.3.6.1.2.1.2.1.0) – Which is the total number of Interfaces
  • ifIndex ( .1.3.6.1.2.1.2.2.1.1. * ) – Which acts as a primary key for all the other interface group stats.
  • ifDescr (.1.3.6.1.2.1.2.2.1.2.* ) – Which is the name of the interface
  • ifType (.1.3.6.1.2.1.2.2.1.3.* ) – Which describes the type of the interface
  • ifMTU ( .1.3.6.1.2.1.2.2.1.4.*) – Which shows the current MTU size configured on the interface
  • ifSpeed (.1.3.6.1.2.1.2.2.1.5.*) – Which shows the current speed of the interface
  • ifPhysicalAddress (.1.3.6.1.2.1.2.2.1.6.*) – Which shows the mac address of the interface
  • ifAdminStatus (.1.3.6.1.2.1.2.2.1.7.*) – Which shows the current admin status of the port
  • ifOperStatus (.1.3.6.1.2.1.2.2.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 ( .1.3.6.1.2.1.31.1.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

Screen Shot 2015 12 10 at 10 33 12 PM

The ifAlias value for the corresponding ifIndex looks like this

Screen Shot 2015 12 10 at 10 34 30 PM

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.

Screen Shot 2015 12 10 at 10 52 41 PM

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.

Screen Shot 2015 12 10 at 10 58 57 PM

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. 🙂

Advertisements

Juniper EX4200T- Management Observations

So I’ve had been spending some time playing around with a juniper EX4200T from a management standpoint.

This post is just a place to put some observations and questions. Hopefully, some Junos Peeps will be able to shed a little light on some of these questions.

First, as both a criticism and a defence; Juniper does not use SNMP as their primary interface. I get that SNMP has it’s problems, but it’s what we have and if you want to bring Juniper into a network where there is already a network management system in place, I would think that they should at least do the minimum to improve their SNMP support to at least meet the bar.

I have to say; as an operationally focused network engineer, it does disturb me that I can’t even set the sys location from a simple SNMP set command.   

ifIndex

One of the first things I noticed about the Juniper box is that the seem to have some strangeness, at least compared to other vendors, around the number of interfaces. Specifically, I’ve got a 48 port switch with more than twice that many interfaces.  Upon a closer look, it seems that the Juniper switches, or at the very least the EX 4200t, seems to have two index values for every physical port.

Juniper SNMP Interfaces

 

One of the interesting questions that come up here is ” What ifIndex value do I poll?”.  I’d like to get interface stats on this device, but do I poll the ethernet port, or the prop virtual port?  And if both return the same values; Why would I chose one over the other?  

Anyone have a good explanation of WHY they went this direction? @steve did suggest to think of this like a sub interface in Cisco terms.  I’ve been trying to figure this out, but the most common reason I’ve used a sub-interface has been to create dot1q routing on a stick configurations.  I don’t see how that applies here?

 

MIB Walking 

Another strange thing is that it seems that the EX4200 cannot return all the interfaces when reading the ifTable by SNMP.  It may be that this is an issue with my MIB browser, but it’s definitely a pain in the butt.  

Junos-peeps: Anyone have a MIB browser that works here? Suggestions on code? Possibly a bug?

 

VLAN 0

One of the other things I noticed is that the default VLAN of the EX4200 is 0. Huh? VLAN 0? All of the interfaces on the switch belong to VLAN 0 initially.  I did find this article  from the Juniper website says that ” Some attached devices may not accept 802.1q-tagged frames, and therefore can reside only in VLAN 0.” 

Coming from a Cisco and HP background, I’ve always seen the native VLAN initially on a interface listed as VLAN 1.    Anyone able to explain this to me?

VLAN-Range: Anyone able to explain this to me? Now I checked the Juniper documentation .  But I wasn’t able to find an article which explained what exactly the function is for. 

 

If anyone has comments, I’d love to learn here. I freely admit I haven’t had time to get far enough into this to understand the benefits and I do bring the baggage of history to my perspective on this.  If someone has made the jump to Junos, I’d love to hear from you! 

 

@netmanchris