Hi I am trying to understand SNMP trap mechanism, I referred http://docstore.mik.ua/orelly/networking_2ndEd/snmp/ch02_06.htm#enettdg-CHP-2-TABLE-8.html and I understood that there are two types Generic and enterprise, Now In My Java code, I want to capture description from specific OID,
// variable binding for Enterprise Specific objects, Severity (should be defined in MIB file)
pdu.add(new VariableBinding(new OID(trapOid), new OctetString("Major")));
Here, Instead of "Major", what should I specify to get the severity for that specific OID?
Any help would be higly appreciated
In general, the severity is not an attribute of an SNMP trap.
Usually the custom severity mapping is defined in vendor specific MIB file as variable binding of specific trap. Here is an example:
sysLogMessageSeverity OBJECT-TYPE
SYNTAX INTEGER {
emergency (0), --system is unusable
alert (1), --action must be taken immediately
critical (2), --critical conditions
error (3), --error conditions
warning (4), --warning conditions
notice (5), --normal but significant condition
informational (6), --informational messages
debug (7) --debug-level messages
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Severity level of the message"
::= { sysLogMibObjects 5 }
Please also note that most of modern NMSs allow the user to assign custom severity to any received SNMP traps based on user-defined rules.
The most widely used tool to do that is NetDecision TrapVision. Find out more at: http://netmechanica.com/products/?prod_id=1003
i used two ways before:
1. adding a severity variable to MIB and including it in any sent trap.
2. classifying events causing traps to Critical, Major, ... and assigning an enterprise trap id range to each type like: traps with ids in range (1,100) are Critical, traps with ids in range (101,200) are Major and...
Related
With a friend we are currently working on a library to create and read SNMPv3 packet.
The idea is "only" to create the content of the packet and it will be sent independently.
I know that many libraries exist for that but not in the language that we need. Our major problem now is to specify the content of the different packets. Which part is mandatory? Which part comes in which type of request?
With some examples available on Wireshark's website and the RFCs we can have a beginning of an idea but as it is a protocol, we need to be very clear and sure of what is required in each type of request (get-request, set-request, get-bulk, trap, etc.).
Is there a way to know exactly how each type of packet is created or the only information sources are the RFCs?
First, I want to offer some clarification about the terminology. A UDP packet encodes an SNMP "message". The format of the message varies with the SNMP version, but in all cases, it contains a single PDU. I think when you say "packet", you really mean "PDU".
As for your question, there's no better source than the RFCs, and they are actually easier to read than you think, as long as you know which parts to read (that's the tricky part).
RFC 3416 specifies everything to do with PDUs, including the format (p. 8), a comprehensive list of PDU types (pp. 7-8), and an explanation of how each PDU is used (under section 4.2, starting on p. 10).
The format of all PDUs is the same (though the BulkPDU replaces error-status and error-index with two integer fields of different meanings):
PDU ::= SEQUENCE {
request-id INTEGER (-214783648..214783647),
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2), -- for proxy compatibility
badValue(3), -- for proxy compatibility
readOnly(4), -- for proxy compatibility
genErr(5),
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnavailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18)
},
error-index -- sometimes ignored
INTEGER (0..max-bindings),
variable-bindings -- values are sometimes ignored
VarBindList
}
I am developing an SNMP (2c) agent for a sensor product. I'm just learning about SNMP and MIB formats and struggling to represent a particular value that could be unknown.
For example, I've defined a temperature OBJECT-TYPE as an Integer32 but sometimes the value is not available or unknown. If I respond with a null value, the SNMP manager times out*. I would prefer to use a null value when the temperature value is unknown or not available, instead of agreeing upon some specific value to mean the same thing.
This leads me to the following questions:
Does SNMP v2c/MIB support a data type that is analogous to a nullable integer?
If so, what is the proper way to denote this in the MIB?
* I am using MG-SOFT's MIB Browser to get values as a testing method. If the value is null, it times out (even though the agent responded). If the value is an integer, it works as expected. I am using nSoftware IP*Works! SNMP library to develop the agent.
Posting from comment:
You should not be doing this. OID values should always be singular they should not be dynamically changed, if someone will use a mibfile for this it will be incorrect and misleading for the person who is implementing communication protocol for this sensor. The correct way to do it is to have 2 OIDs one with the value and another with the status of the sensor.
In experimenting, I've had some success dynamically changing the SNMP agent object type:
int? temperature = ReadTemperature();
snmpAgent.Objects[i].Value = temperature.ToString();
snmpAgent.Objects[i].ObjectType = temperature.HasValue ? SNMPObjectTypes.otInteger : SNMPObjectTypes.otNull;
When performing a GetRequest with a MIB browser, it appears to handle both cases. Even though the MIB doesn't specify that the particular OID can be null, just SYNTAX Integer32, it seems to work. Various SNMP managers will probably behave differently.
(This example is specific to IPWorks SNMP Agent.)
Conditions:
CA Console spectrum server receives SNMP traps (events), MIB definition file loaded to CA system.
Problem:
In events list I don't see color severity and I see only OIDs, but not fields names described by MIB file.
Does anyone have any suggestions about that?
Problem is resolved. Problem was not in MIB file, but in SNMP trap sender: it was sent trap ID incorrect and of course CA spectrim don't recognize event.
I Used library Lextm.SharpSnmpLib. Function Messenger.SendTrapV2 has parameter called "enterprise". But you must don't provide enterpriseOID to this parameter, you need to provide TRAP ID (!!!). It's non sense, but it working!
When implementing my own scripts, is it the best practice to exit with different exit codes for different failure scenarios? Or should I just return exit code 1 for failure and 0 for success providing the reason on stderr?
Providing a descriptive error message to stderr is fine and well for interactive users, but if you expect your scripts to be used by other scripts/programs, you should have distinctive error codes for different failures, so the calling script could make an informed decision on how to handle the failure.
If the calling program does not wish to handle different failures differently it could always check the return code against > 0 - but don't assume this is the case.
There are some recommendations, see wikipedia, but not normative, except the one of 0 iff success:
http://en.wikipedia.org/wiki/Exit_status#POSIX
*In Unix and other POSIX-compatible systems, the wait system call sets a status value of type int packed as a bitfield with various types of child termination information. If the child terminated by exiting (as determined by the WIFEXITED macro; the usual alternative being that it died from an uncaught signal), SUS specifies that the low-order 8 bits of the exit status can be retrieved from the status value using the WEXITSTATUS macro in wait.h;[6][7] when using the POSIX waitid system call (added with POSIX-2001), the range of the status is no longer limited and can be in the full integer range.
POSIX-compatible systems typically use a convention of zero for success and non zero for error.[8] Some conventions have developed as to the relative meanings of various error codes; for example GNU recommend that codes with the high bit set be reserved for serious errors,[3] and FreeBSD have documented an extensive set of preferred interpretations.[9] Meanings for 15 status codes 64 through 78 are defined in sysexits.h. These historically derive from sendmail and other message transfer agents, but they have since found use in many other programs.[10]*
I am looking for some advice on SNMP MIB trap organization or best practices. I haven't found any material describing real world usage and expectations.
I have only briefly worked with SNMP in the past, and mostly just get/set, I have never had to deal with traps before.
Let me explain...
I recently joined a company and needed to look at their MIB, but the traps in it are not what I expected.
For each trap that raises an alarm condition (eg. ‘over X threshold’ - severity critical, id 100) has a completely separate trap for a clear (‘over X threshold clear’- severity clear, id 134). Each one of the traps has an arbitrary ‘trap-id’ assigned to it with no meaning or relationship information encoded in it. The only way one knows that trap 134 clears trap 100 is to look at the textual name of the trap. This just doesn’t seem right.
For example, the fan failure trap is as follows (edited for brevity):
fooTrapFanFailure NOTIFICATION-TYPE
OBJECTS {StampID, SerialNumber, Name, TrapID, Severity}
DESCRIPTION "Fan failure, trap-id 105, severity major"
::= { fooTraps 8 }
fooTrapFanFailureClear NOTIFICATION-TYPE
OBJECTS {StampID, SerialNumber, Name, TrapID, Severity}
DESCRIPTION "Fan failure clear, trap-id 132, severity informational"
::= { fooTraps 11 }
The only way I know that 132 is a clear for 105 is to manually read the MIB or programmatically scan the MIB and build a table based on the trap name. This case is even more goofy as the Clear trap shows up with an ‘informational’ severity.
I expected when an ‘over X threshold’ trap-id 100 is raised, it would be sent with its severity set to say ‘critical’ and when it clears, the very same trap-id 100 would be sent with a severity of ‘clear’.
Or it would be even better if there was just one generic alarm trap which contains the trap-id and severity, instead of the my 65 or so unique traps.
So, in short, the question is:
Is this 'two trap, one to raise and one to clear' normal?
It's not normal but it's OK. I can see why they might have done it that way, it is easy to assign colors in HP OV NNM based on OID (don't know the exact version but it worked in the year 2000). Or else you might have to parse the packet to display colors on the Manager/Management station.
Generally it is good idea to use trap status as part of the trap binding.
I use my Mib files with the SNMPc.
My file has only one trap EventOccured and all other logic (correlation) made by SNMPc filters. I use Severity='CL' to clear traps.
So don't understand what for you need a Severity var in the "fooTrapFanFailureClear" trap?