I have a situation where I'm trying to do some MIB-processing on a pre-existing, non-translated SNMP walk in the cloud. I have a set of translated PySMI MIB json files, but I'm unsure how to match the correct MIB with OIDs within the walk.
I saw in this post that PySNMP was unable to automatically detect a MIB but that it was being worked on. I tried to create a simple implementation myself using regex, but I cannot find the correlation between a MIB's module identity and the OIDs that I am retrieving from the SNMP walk.
I've seen the MIB index that can be generated from PySMI, which seemed promising, but I'm not sure how I can use that to find the human-readable version of an OID from a collection of MIB files.
What am I missing? Thanks!
A way to deal with this would be to build the OID->MIB index by running PySMI-based script (or just vanilla mibdump tool) over your entire MIB collection. Actually, such index can be found here.
Once you have this OID->MIB mapping, you could run the OIDs your snmpwalk script receives, match them (or their prefixes) against the OID->MIB map and load up the required MIBs.
Unfortunately, this relatively simple process has not been built into pysnmp yet, but it should not be hard to implement within your script.
I am trying to make a snmp trap receiver, that can capture all the incoming snmp trap from UDP 162 port and translate them into meaningful alarms. The image I attached is a sample trap that I captured using wireshark.
My script can capture and parse all different parts of the packet, but I got stuck in the variable binding section. Im not sure how I can re-present this section into some user friendly information (that I can show in the user interface). How do I know these sequences are sending something alarming or just some general information regarding the agent node? are these sequences independent information each or together they are forming one piece of information?
As with any incoming data, it is important to know what kind of info you are getting. The variable bindings of an SNMP trap is basically a hierarchical piece of data. Every object or element represents it's own data. If you take the first element (1.3.6.1.2.1.1.3.0) you will find that this contains the sysUpTime (see link), which is pretty general.
Most of the other elements seem to start with 1.3.6.1.4.1.4421 which appears to be object from a specific vendor; Santera systems (see link). You might want to try and contact them in order to obtain their MIB (Management Information Base), which should have details on what kind of data is shown in these fields.
It might be possible to find info like this online, have a look at the XML-files on this link.
Most of the examples provided for sending SNMP traps are simple ones like the one below.
snmptrap -v 1 -c public host TRAP-TEST-MIB::demotraps localhost 6 17 '' \
SNMPv2-MIB::sysLocation.0 s "Just here"
Take any MIB file, they contain many complex object groups, for example, systemGroup contains sysLocation, sysName, etc.
Could someone help in bringing out examples to show the way how to send snmp traps which includes such OBJECT-GROUPS. Adding one more question here, Does SNMPTRAPD support internationalization?
It is really bad practice to define the SNMP notification (trap or inform) the way that it contains the entire OBJECT GROUP or even worse the entire SNMP table. The reason is that you don't really need all these variables anyway. The other reason is that the packet/PDU is limited by MTU size. So it is possible that you'll not be able to send the data within single UDP packet due to its size.
The proper scenario would be to have few varbinds and you could also initiate some polling cycle to find out what happens if you need more details when you receive such trap.
SNMPTRAPD and NET-SNMP library in general do not support internationalization (UNICODE). The library is limited to ASCII charset only.
There are commercial products on the market including NetDecision TrapVision and some other that fully support UTF-8 internationalization.
I'm still quite new to SNMP and I was wondering how I would go about getting an entire branch of a MIB with as few queries as possible.
My approach:
Use GETBULK messages to get pow(2,tries) entries at a time and then stop when I get an object that don't match as a child of the object specified by my OID
Why do I need it:
I'm trying to get a variant sized branch of the MIB, the ipRouteTable part to be specific.
Do you know SNMP has a WALK operation where you can visit all objects in turn? Net-SNMP has such a utility,
http://net-snmp.sourceforge.net/docs/man/snmpwalk.html
I'm querying a bunch of information from cisco switches using SNMP. For instance, I'm pulling information on neighbors detected using CDP by doing an snmpwalk on .1.3.6.1.4.1.9.9.23
Can I use this OID across different cisco models? What pitfalls should I be aware of? To me, I'm a little uneasy about using numeric OIDs - it seems like I should be using a MIB database or something and using the named OIDs, in order to gain cross-device compatibility, but perhaps I'm just imagining the need for that.
Once a MIB has been published it won't move to a new OID. Doing so would break network management tools and cause support calls, which nobody wants. To continue your example, the CDP MIB has been published at Cisco's SNMP Object Navigator.
For general code cleanliness it would be good to define the OIDs in a central place, especially since you don't want to duplicate the full OID for every single table you need to access.
The place you need to be most careful is a unique MIB in a product which Cisco recently acquired. The OID will change, if nothing else to move it into their own Enterprise OID space, but the MIB may also change to conform to Cisco's SNMP practices.
It is very consistent.
Monitoring tools depend on the consistency and the MIBs produced by Cicso rarely change old values and usually only implement new ones.
Check out the Cisco OID look up tool.
Notice how it doesn't ask you what product the look up is for.
-mw
The OIDs can vary with hardware but also with firmware version for the same hardware as, over time, the architecture of the management functions can change and require new MIBs. It is worth checking whether any of the OIDs you intend to use are in deprecated MIBs, or become so in the life of the application, as this indicates not only that the MIB could one day be unsupported but also that there is likely to be improved, richer data or access to data. It is also good practice to test management apps against a sample upgraded device as part of the routine testing of firmware updates before widespread deployment.
An example of a change of OID due to a MIB being deprecated is at
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a0080094aa6.shtml
"This document shows how to copy a
configuration file to and from a Cisco
device with the CISCO-CONFIG-COPY-MIB.
If you start from Cisco IOSĀ® software
release 12.0, or on some devices as
early as release 11.2P, Cisco has
implemented a new means of Simple
Network Management Protocol (SNMP)
configuration management with the new
CISCO-CONFIG-COPY-MIB. This MIB
replaces the deprecated configuration
section of the OLD-CISCO-SYSTEM-MIB. "
I would avoid putting in numeric OIDs and instead use 'OID names' and leave that hard work (of translating) to whatever SNMP API you are using.
If that is not possible, then it is okay to use OIDs as they should not change per the SNMP MIB guidelines. Unless the device itself changes but that requires a new MIB anyway which can't reuse old OIDs.
This is obvious, but be sure to look at the attributes of the SNMP MIB variable. Be sure not to query variables that have a status of 'obsolete'.
Jay..
In some cases, using the names instead of the numerical representations can be a serious performance hit due to the need to read and parse the MIB files to get the numerical representations of the OIDs that the lower level libraries need.
For instance, say your using a program to collect something every minute, then loading the MIBs over and over is very inefficient.
As stated by others, once published, the name to numerical mapping will never change, so the fact that you're hard-coding stuff into your programs is not really a problem.
If you have access to command line SNMP tools, check out 'snmptranslate' for a nice tool to get back and forth from text to numerical OIDs.
I think that is a common misconception (about MIB reload each time you resolve a name).
Most of the SNMP APIs (such as AdventNet, CMU) load the MIBS at startup and after that there is no 'overhead' of loading MIBs everytime you ask for a 'translation' from name to oid and vice versa. What's more, some of them cache the results and at that point, there is no difference between name lookups and directly coding the OID.
This is a bit similar to specifying an "IP Address" versus a 'hostname'.