SNMP OID: THOSE RANDOM NUMBERS ACTUALLY MEAN SOMETHING!
I’ve been playing with a new monitoring platform this week, because wow do I know how to have fun on a weekend. No wonder they call me The Party Monster. Round the way I’m known as The Good Fun Cool Guy, on account of all the good fun cool stuff I do. They call me Charley Dickens, because I know how to have the best of times.
Anyway, this has made me finally dig in properly to how SNMP works. I’ve often seen SNMP servers refer to numbers like this when they’re polling something, and I’ve always just assumed that it was a random string of nonsense:
1.3.6.1.2.1.2.2.1.7
That full number is called an OID, or Object ID. Today I got curious to know if there actually is meaning behind it.
It turns out that these numbers refer to a hierarchy within a MIB, or Management Information Base. And it’s so consistent that by the end of this post you’re going to be able to read an OID by sight, and have a fair idea of what it does. That’s pretty neat considering that right now it probably just looks like a cat walked over the keyboard!
This blog post uses Junos to show you how OIDs work, but I’m sure that your vendor of choice will have similar commands, so even if you’re not a Junos user you should still get tons of value out of this post. Let’s take a closer look.
THE OBJECT ID HIERARCHY
In Junos you can use the command “show snmp mib get” on each number to see what it actually means.
Take a look at this screenshot from a Juniper router I’ve made friends with recently. You can see that I’m running this command over and over, on different parts of the “tree” for a couple of different OIDs. The word “tree” clues us into the fact that OIDs are hierarchical.
The top section of this output on the right explores each individual part of OID 1.3.6.1.2.1.138 (apart from the very top part, which for some reason doesn’t work!), while the bottom bit explores 1.3.6.1.4.1.2636. In these examples there’s a trailing dot at the start – but as I found out mere moments before publishing this post, you don’t have to type this!
To see this hierarchy in action, let’s follow the journey of the OID we mentioned at the start of this post: 1.3.6.1.2.1.2.2.1.7.
THE TOP OF THE TREE
Let’s start with that beginning bit that says 1.3.6.
The 1 at the start means that this part of the top level of the tree is managed by the ISO – the International Organization for Standardization. As networks folks, we’re pretty much always going to see a 1 at the start of our OIDs.
The ISO can create MIBs that follow their own international standard. They also have the power to let other organisations create their own MIBs. These other organisations are all filed under their own part of the tree called “identified-organisation”.
With that in mind, “1.0” is ISO’s own standards, and “1.3” is another “identified-organisation”. Again, we’re pretty much always going to see 1.3 in our OIDs.
So that’s the 1.3 bit explained. How about 1.3.6?
The .6 refers to the DoD, or US Department of Defense. Here we see a bit of internet history, from back in the ARPANET days! So, 1.3.6 means “ISO > Identified Organisation > Department of Defense”.
There’s only one sub-tree of the DoD that we care about: 1.3.6.1 means “internet”. On the right you can see the first three commands from that screenshot above, and it lines up real nice.
Remembering that the full OID we’re trying to read is 1.3.6.1.2.1.2.2.1.7, we now know what the first four digits mean! Let’s keep going.
MGMT
Here are some numbers that can potentially follow 1.3.6.1:
- Directory
- MGMT
- Experimental
- Private
We’ve highlighted 2 because it’s the next number in our example OID.
MGMT is not a terribly intuitive name for what it really does: it basically means that the OIDs in this part of the tree are defined standards that you will find in use on any vendor. In other words, it’s in this part of the tree that you’ll find the OID for things like whether an interface is up, whether an OSPF adjacency has flapped, stuff that could happen on any vendor’s device.
This is how monitoring platforms are able to quickly start monitoring certain aspects of a device regardless of what vendor it is: if that vendor is using standard OIDs, then the monitoring platform will know exactly what it needs to do in order to extract the right information.
There’s only one number you’re going to see in the 1.3.6.1.2 hierarchy: the number 1 means mib_2, which means MIB version 2. This is the MIB format everyone uses nowadays, and it’s defined in RFC2578.
So, again remembering that our full OID is 1.3.6.1.2.1.2.2.1.7, we can now read the first bit: the section in red of 1.3.6.1.2.1.2.2.1.7 means “ISO > identified-organisation > DoD > Internet > MGMT > MIB version 2”. Congratulations: you’re 50% smarter than you were five minutes ago!
SYSTEM, INTERFACES, IP AND MORE
The next number in the tree is going to tell us the broad thing we’re monitoring. There’s tons of stuff that has its own number, and again Junos tells us what they are. Notice below that 1 means “system”, 2 means “interfaces”, and so on. (Notice that 3 doesn’t have any meaning.) I’ve highlighted in red the one for the OID we’re exploring:
root@PE-1> show snmp mib get 1.3.6.1.2.1.1 system No such object root@PE-1> show snmp mib get 1.3.6.1.2.1.2 interfaces No such object root@PE-1> show snmp mib get 1.3.6.1.2.1.3 mib_2.3 No such object root@PE-1> show snmp mib get 1.3.6.1.2.1.4 ip No such object root@PE-1> show snmp mib get 1.3.6.1.2.1.5 icmp No such object root@PE-1> show snmp mib get 1.3.6.1.2.1.6 tcp No such object root@PE-1> show snmp mib get 1.3.6.1.2.1.138 isisMIB No such object
You can see I skipped right to 138 there at the bottom to show you that there’s tons of sub-objects you can monitor. In fact, it was the hunt for IS-IS information that led me down this rabbit-hole in the first place.
(And yes, it WAS a great deal of fun telling the sales engineer at this new monitoring platform that it’s pronounced ai ess ai ess, and not… you know, ISIS.)
Once again remembering the full OID of 1.3.6.1.2.1.2.2.1.7, we now know everything up to the red part!
- 1 = ISO
- 3 = identified-organisation
- 6 = Department of Defense (DoD)
- 1 = internet
- 2 = MGMT
- 1 = MIB Version 2
- 2 = Interfaces
From here things start to get very specific, so only a true monster brain would memorise deeper into the tree – but just to complete the journey:
root@PE-1> show snmp mib get 1.3.6.1.2.1.2.2 ifTable No such object root@PE-1> show snmp mib get 1.3.6.1.2.1.2.2.1 ifEntry No such object root@PE-1> show snmp mib get 1.3.6.1.2.1.2.2.1.7 ifAdminStatus No such instance
So it turns out that this object shows us the “admin status” of an interface.
Now let’s see how we actually use this object.
WALKING THE MIB
Now we’ve got our object, we’re going to do something called “walking the MIB”. No, this is isn’t the latest dance craze to hit Gen Z’s favourite private-data stealer Tik-Tok: it’s the name we give to investigating what information is available to us within a certain MIB.
Check this out:
root@PE-1> show snmp mib walk 1.3.6.1.2.1.2.2.1.7 ifAdminStatus.1 = 1 ifAdminStatus.4 = 1 ifAdminStatus.5 = 1 ifAdminStatus.6 = 1 {snip} ifAdminStatus.536 = 1 ifAdminStatus.544 = 1 ifAdminStatus.545 = 1 ifAdminStatus.546 = 1
We’ve just told our router “show me everything you can report on for this OID”. In return, we get lots of numbers. I’ve highlighted one object that has “536” in it.
In this case, “536” refers to the unique SNMP ID of a certain interface this box. You know how you’ve always looked at the “show interfaces” output and wondered why it shows you the SNMP ifIndex? This is exactly the reason!
root@PE-1> show interfaces | match 536 Logical interface ge-0/0/0.0 (Index 330) (SNMP ifIndex 536)
The 1 in “ifAdminStatus.536 = 1” means that this interface is administratively up. It might not be physically up, but it’s not been admin-down’d, and that’s what matters here.
But wait: how did I know that this is what the “1” means?
Put a pin in that question for now. In a moment I’m going to show you a section on the Juniper website – and in the official RFCs – that shows you how to find out what various status codes mean for every object you might come across.
For now, let’s take a look at a slightly different OID.
PRIVATE
Let’s go back up the tree a bit, and look at this OID: 1.3.6.1.4.1.2636.
You saw a moment ago that the 2 in 1.3.6.1.2 means MGMT.
By contrast, the 4 in 1.3.6.1.4 means Private. This is the part of the tree that is given to vendors to do what they like.
The 1 at the end of 1.3.6.1.4.1 means “Enterprises”. There’s nothing else in this branch of the tree other than Enterprises, so I’d guess this number 1 was made with plans to expand, but the expansion wasn’t needed.
(I’m currently in the process of applying to become the owner of number 2, which I will assign to “cool people”. I will put only myself in this group, and none of you are allowed to join me, because I am cool and you are all nerds. Get rekked!!)
From here, each vendor has their own number. You can probably guess that 2636 means Juniper:
root@PE-1> show snmp mib get 1.3.6.1.4.1.2636 juniperMIB No such object
This means that if you see an OID beginning with 1.3.6.1.4.1.2636, it’s going to be something specific to Juniper. Here’s a list of other vendors.
Juniper have made branches of their own hierarchy. Here’s just a small handful of them:
root@PE-1> show snmp mib get 1.3.6.1.4.1.2636.1 jnxProducts No such object root@PE-1> show snmp mib get 1.3.6.1.4.1.2636.2 jnxServices No such object root@PE-1> show snmp mib get 1.3.6.1.4.1.2636.3 jnxMibs No such object root@PE-1> show snmp mib get 1.3.6.1.4.1.2636.4 jnxTraps No such object
From here you can drill down into a whole variety of stuff that’s specific to Juniper devices.
FINDING SPECIFIC OIDs, SO YOU CAN MONITOR ANYTHING
Let’s imagine that you, like I, decide you want to monitor IS-IS adjacencies on a device. How would you go about finding the OID for it?
The answer will be different for each vendor, and it can take a bit of patience sometimes, because you’re going to see multiple objects that on the surface seem to do the same thing, but only one of them will do what you actually want it to do.
Let me show you an example with Juniper, so you can see what to look out for.
If you Google for “Juniper SNMP MIB explorer” then you’ll come to this page that does what it says on the tin. It looks like this:
If you click on Navigate, like we’ve done below, then you can browse the entire SNMP tree to your heart’s content. This is a nice way to learn how OIDs work in general, and get a feeling for the things that are possible.
Notice in the screenshot above on the right that the navigation starts us at 1.3.6.1.4.1.2636 in the tree, which we’ve already learned is the Juniper specific branch of the tree.
You can check this OID number on the right against where it’s showing we are in the tree on the left. Thanks to what you’ve learned, you know for sure we’re correctly in the “ISO / Org / DoD / Internet” section, which is the 1.3.6.1 bit at the start. This is where we see the MGMT and Private hierarchies.
Notice as well that Juniper knows some other enterprise MIBs that belong to the MEF (Metro Ethernet Foundation), among others. We could also go to the MGMT hierarchy to browse vendor-neutral stuff.
Going back to the main page, let’s instead click Search, where you can – you guessed it – search!
I’m looking for the MIB for ISIS adjacencies, so let’s start by doing a search for ISIS. You can see below that we get 254 results.
By complete chance, the very first entry gives us something that looks promising: notice above that the first result is for an object is called “IsisAdjState”.
Let’s click it:
You can see above that the description seems to suggest that this is exactly what we want.
But wait: Do you see the “Access” line? It says “accessible-for-notify”.
This isn’t very intuitive, but this is SNMP’s way of saying that this object is used for notifications – what SNMP calls a trap, which is when a box actively sends a message to the SNMP server. In this case, this isn’t the object we want. We want to be able to poll the box and get the info, which is a different object to the one that the box sends as a notification.
Do you remember that RFC we mentioned earlier that defines MIB version 2? Section 7.3 explains the five possible states you can have in the Access section. I’ve taken a screenshot, which if you look very very carefully you might just spot to the right of this text. Can you see it? If not, look closer.
Basically these five states go from “you can’t look at this at at all” to “you can build your own universe with it”. When it comes to polling the device for info, generally “read-only” is the one we want.
So, it looks like this isn’t the object for us. Let’s keep surfing the information superhighway.
Going back to our search results, I hit “CTRL-F” on the page and search for “adj”. After a bit of browsing, I find one called “isisISAdjState”. I’m sure I speak for all of us when I say thank you to the architects of this scheme for the fact that these two objects have almost identical names. Not at all confusing. Thanks pals!
Let’s take a look:
This looks more promising! We see an object with read-only access, and it’s got a description that’s looking oh so fine.
Make a note of the numbers in the Syntax section above. We’ll use this info in a moment.
Great! So, our OID is 1.3.6.1.2.1.138.1.6.1.1.2. We’re getting there. Now, let’s “walk the MIB”, if you know what I mean. Nudge nudge wink wink.
HOW TO REFERENCE A SPECIFIC INTERFACE IN AN OID
Back on Junos, let’s confirm that this is indeed the object we want:
root@PE-1> show snmp mib get 1.3.6.1.2.1.138.1.6.1.1.2 isisISAdjState No such instance
Lovely stuff. Now we want to see what interfaces match this object. To do that, let’s walk this specific part of the tree:
root@PE-1> show snmp mib walk 1.3.6.1.2.1.138.1.6.1.1.2 isisISAdjState.536.1 = 3
What’s going on here? Well, thanks to our exploring earlier you now know what the 536 means: it’s the SNMP reference that identifies interface ge-0/0/0.0 on this box.
I actually couldn’t find documentation confirming what the .1 means in “isisISAdjState.536.1”, but my guess is that some objects might have multiple sub-objects, but this one only has the one sub-object.
What about the value of 3 that this object apparently has? The “Syntax” bit of the MIB info a moment ago tells us the answer to this: 3 means that the adjacency is up.
You may wonder where Juniper got this info about the different numbers which reflect the different interface adjacency states. In the screenshot of the correct OID above, you might have noticed that Juniper links to the “ISIS-MIB”. This is an edited version of RFC4444, which is the RFC that defines the MIB for IS-IS.
Each protocol in the MGMT hierarchy should have some kind of standards doc that defines all the objects for that protocol, whether it be an RFC or an IEEE doc or something else. These docs will list these values and their meaning. Here’s the IS-IS MIB RFC, and here’s Juniper’s edited version of it.
Here’s the bit we want: a status of 3 means that the adjacency is up:
There we are! We now know that this box has one single IS-IS adjacency on ge-0/0/0.0, and it’s up. Or, in SNMP speak, “.1.3.6.1.2.1.138.1.6.1.1.2.536.1 = 3“. Lol.
You should only need to put “1.3.6.1.2.1.138.1.6.1.1.2” into your monitoring system of choice. Your SNMP box will then walk the MIB (nudge nudge wink wink) to find all interfaces, and it will use the interface index to tell your monitoring platform what interfaces are hosting what adjacencies.
But as you can see, you can also reference a specific interface if you know its SNMP index. And you can test it all out yourself on your Junos device to make sure you are indeed looking at what you think you’re looking at.
ONE FINAL FACT
If you just type “show snmp mib walk 1” then you’ll find out every single object that Junos knows about. Which is a bit overwhelming! But when you do, it doesn’t give you the numerical OID – instead it gives you the name for the OID. Long story short, there’s a knowledge base article here that shows you how to get the numerical OID for any named object so you can put into your SNMP monitoring system. Good to know!
THAT’S IT!
SNMP OIDs are definitely one of those things that seem scary, and that aren’t often well explained. It’s easy to get nervous by them. We always feel anxious and unconfident when we’re dealing with something we don’t really understand. Hopefully this post has helped you get a little bit closer to that confidence and understanding.
Hey there: thanks for reading this post! If you’re on Mastodon, follow me to find out when I make new posts. (2024 edit: I’m also on BlueSky nowadays too. I was once on Twitter, but I’ve given up on it, on account of… well, I don’t need to finish that sentence, do I.)
If you enjoyed reading this post, a great way to support my work is to share it on your favourite social media page of choice. And leave a comment if you’ve got any fun SNMP stories to share.
And if you fancy some more learning, take a look through my other posts. I’ve got plenty of cool new networking knowledge for you on this website, especially covering Juniper tech and service provider goodness.
It’s all free for you, although I’ll never say no to a donation. This website is 100% a non-profit endeavour, in fact it costs me money to run. I don’t mind that one bit, but it would be cool if I could break even on the web hosting, and the licenses I buy to bring you this sweet sweet content.
Thanks again for reading, and see you next time!
