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.
Related
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.
Can anyone tell me why NMS implementations parse and save MIB items in a database?
I know one of the reasons is when they receive a trap and want to analyze it, then they use the parsed MIB. What else they do with parsed MIB?
For example, when the NMS sends a SNMP GET request to an agent, the programmer must specify which OIDs are being requested?
Does the the parsed MIB have a another purpose or do we parse MIBs only for analyzing SNMP traps?
You are on the right track - you parse the MIB at all in order to make it human-readable. That is for both traps (informs) and polled values. But if you parse it out to a text file, that's a huge amount of data to read/grep through to find out the description, message, possible values, related OIDs, etc.
Added to this is that there isn't just one MIB. There are dozens or hundreds that an NMS may be interested in. Since, on a host, you only add the MIBs that you want that host to respond to, the NMS has to have a copy of every MIB that ever device it is monitoring may have on IT so that it can understand the response the host returns.
So you parse each MIB and store it in a db to make it faster to search and to have everything all in one place. That could be so that you can find the messages associated with varbinds, or what all the possible enumerations are, etc.
Just to be clear, parsing the MIB isn't the same as doing an SNMPWalk on a host. SNMPWalk just gives you the current response to each OID in sequence.
I'm new to SNMP. We have maybe 20000+ devices to listen SNMP traps. It is very hard to add to all trap receivers. Is there a way adding a trap receiver(destination) to a trap sender with SNMP-set request or something like that?
That would depend on your devices.
One of the drawbacks (and advantages) of SNMP is that as an equipment vendor, you are in charge of what your device allows users to do over SNMP.
Each of the devices implements an SNMP Agent, which publishes a MIB, whose contents vary between makes and models. If a vendor decides to include a variable in their MIB where a manager (that's you) can set the trap destination, this will be easy for you. As long as you have a current list of the addresses and community strings of all your devices, it's easy enough to loop through the list with a shell script and do snmpset.
If the MIB doesn't include a trap destination variable, you're going to have to find another way.
If your 20k devices are heterogenous (ie they implement different MIB sets), they you have fun times ahead, figuring out which ones can be managed entirely over SNMP and which will require other access to set the trap destination.
So, start by gathering the MIBs implemented by your devices, and by reading them (try a MIB browser) you should be able to answer the question yourself.
I am investigating SCTP and whether its useful for sending BULK SMS BUSSINESS in any way.So far my efforts have gone vain.I am not from telecom background.
So have faced some challeges to get acquainted.Perhaps any point of advice to use SCTP or ANY other part of SS7 leading to enhacement of the process of sending BULK SMS is highly appreciated.Many thanks for reading this
SCTP in itself will get you nowhere - you need one of the user adaption layers (e.g. M3UA, SUA) - and then the rest of the stack (e.g. in case of M3UA: SCCP, TCAP, MAP). This however will only be useful if you are an mobile operator and have a mobile operator license from your countries telco regulator - as no other operator will have much to do with you without this.
Closest you might get is SMPP interface from a Mobile operator - but these are usually not easily provided. So you are left with working with some other provider which already has arrangements in place with the operators in your country. Though it is theoretically possible that one of them might require you to use SCTP - it will not be to carry SS7 (i.e. MAP).
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'.