Any samples on how to define a private MIB containing some x objects? how do I register these MIBs and handle get requests to it?
You could start by reading something like Net-SNMP's tutorial about agent coding tutorials. But in the long run, if you need to write about MIBs you should probably also read either the SMIv2 RFCs (RFC2578 to get started) or a good book on SNMP and MIBs ("Understanding SNMP MIBs" is the classically referred to book).
Related
What online resource is the authority for the complete set of ASN.1 definitions for the SNMP data structures used to request and respond with information? I am interested in versions 2c and version 3.
In RFC 3416 Section 3, I have found most of the definitions needed to use version 2c. However, the document has no mention of something that I have found on other resources referred to as the "snmpv2 message". For example, this shows up in the SNMP Programmers Reference Wiki and in the blog post Simple? Network Management Protocol. It's the data structure that contains the community string, so it's role is essential, but I cannot find where the authoritative source (probably an RFC) with an ASN.1 definition.
Similarly, I cannot find any authoritative ASN.1 definitions of SNMPv3 data structures. I found an ASN file in a github repo's test suite, but I cannot find where this information was taken from.
I would appreciate any help locating these. I'm usually a pretty good Googler, but my usual strategies are not turning anything up beyond what I've already linked to.
SNMP v3 message format is defined in RFC3412 page 19 as section 6 as ASN.1.
SNMP v2c reuses most of v1 message format, except defining new message body (PDU). I think that's why in RFC 3416 you don't see all details, because it only mentions the new PDU definitions for simplicity.
You might want to dig ASN.1 documents out of SNMP RFCs:
Base data types, RFC2578
SNMP v2c message, RFC3416
SNMP v3 message, RFC3412
SNMP v3 USM, RFC3414
I want to implement SNMP-agent for PowerPC board using net-snmp.
Previously it was implemented using SMASH. SMASH has a parser
which could read MIB and generate C code (blank function imlementation)
How do I get started?
Try to look at mib2c tool from net-snmp. It will generate the snmp agent C code from the MIB. Then you have to only fulfill the return values to SNMP requests. Skeleton of responding to SNMP requests (get, set, get-next) are automatically done by generating.
Do you have a look to Writing a MIB module tutorial.
I took a different approach to this. In order to better integrate with my C++ ecosystem, and to obtain greater flexibility (particularly at scale), I:
Had a pre-build step parse the result of snmptranslate (that is, the MIB tree) into a bunch of C++ maps and other containers for use in code
Borrowed Net-SNMP's transport and PDU building functions
But serviced requests myself upon receipt, using my C++ maps and the data already available to my application
This made notification generation trivial (I just needed some variant types to generate varbinds, a bit of PDU construction and then left the rest to Net-SNMP's transport feature), although for requests I did then have to implement table walking myself (and GetNext/GetBulk/Set are not trivial unless you avoid all tables, or at least avoid composite-index tables).
The result is a fast, robust and scalable SNMP agent with expressive code that's easy to maintain and to extend.
You don't say you're using C++, but this does give an idea of how you can cherry-pick Net-SNMP functionality without necessarily buying into its entire ecosystem.
Do note that I have no idea how SNMPv3 would fit into this model; I cleverly left the company before it became my problem. :)
Mapping some OIDs to system commands is actually all I need
However, I could not find yet a resource which explain how to compose such thing.
Any idea?
There are books about SNMP and MIBs, such as the SNMP MIB Handbook. If you want to learn by example, read some RFCs that define MIBs, such as the Printer MIB.
I read SNMP MIB Handbook. I was a novice of the matter and it lead me inside MIBs very easly. VERY WELL ORGANIZED. Suggested!
I also bought Unserstanding SNMP MIBs, but I didn't read it. After a brief look seems to be very complete.
Good luck!
The Bible of MIBs is considered to be Understanding SNMP MIBs. If you're a book sort of person, that's the recommended reading. The RFCs for MIBS are well worth reading too (RFC2578 through 79) but don't give you a great feel for the corner and "how to" cases.
I know a little about SNMP, but not enough. I need to develop an application that can read standard SNMP MIBs and read/write the various properties. The network end is no problem, but the actual MIBs and exactly what they may contain is something of a black art to me.
I believe I should be able to use LIBSMI to 'parse' the MIBs, but I don't really understand what the output of the 'parser' is going to be, and how best to use it.
All suggestions welcome...
At the risk of throwing you in the deep end, you might want to take a look at net-snmp. The default installation contains a number of standard mibs with their associated implementation. It also contains a utility (mib2c) that will generate boilerplate code from your mib files.
Once you've read your way through a couple of mibs you should have no trouble familiarising yourself with the way that snmp does things.
Most standard MIB documents were defined in corresponding RFCs published at IETF.
http://www.ietf.org/
Please go to this site to find more details.
Muonics Mib Smithy User Guide provides a good overview of how to build a MIB, which can help you understand the necessary elements for parsing.
You should also look at the ASN.1 ITU specification X.690, because that is the language SNMP is defined in. It also helps if you scour the SNMP RFCs for any Bachus-Naur formatting in the SNMP RFCs. I'm going to suggest you start with RFC3642 and RFC2252.
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'.