I am writing a MIB and a SNMP agent. I seem to be confused by an apparent conflict between DISPLAY-HINT and UNITS. Is it better for a NMS to have a DISPLAY-HINT, or knowledge of the UNITS?
The background for this question is as follows: One object in the MIB is mPowerVoltage:
FixedDiv10 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d-1"
STATUS current
DESCRIPTION "Fixed point, one decimal"
SYNTAX Integer32
mPowerVoltage OBJECT-TYPE
SYNTAX FixedDiv10
UNITS "V/10"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Power Voltage in desiVolts"
::= { mPowerEntry 2 } -- an entry in a table with integer index
Actual transfer "on the wire" of the value I understand, for instance 10.8 V is transferred as 108 in an Integer32. And this is my motivation to set UNITS as "V/10" and describe the object as Power Voltage in desiVolts. However, when I use snmpget I get:
snmpget -c public -v 1 -m -MY-MIB 192.168.1.3 mPowerVoltage.1
MY-MIB::mPowerVoltage.1 = INTEGER: 10.8 V/10
which is indeed what I specified, but is clearly wrong.
But I can hardly change the UNITS to "V"? Hence the question, should I remove the DISPLAY-HINT, or should I remove the UNITS?
Baard
As I understand it, they're two diferent things, so neither takes precidence.
DISPLAY-HINT tells the caller how to place the decimal point - so in your example it prints out an "on-the-wire" value of 108 as 10.8.
UNITS is just a bit of text that gets appended after the number, exactly as you typed it. In this case you should definitely change the units to "V" because you've told the caller to display the number in V by dividing it by 10.
It does seem a bit inconsistent that one is part of the textual convention, while the other is part of the object definition, however.
Related
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.)
When I do an snmpwalk for oid 1.3.6.1.2.1.2.2.1.10.1 I get a Counter32 integer value as the result. [1] states that 1.3.6.1.2.1.2.2.1.10 gives total number of octets received on the interface, including framing characters.
Does anybody knows for which time frame snmp gives this integer value because what I get is a pretty large value.
[1] http://www.oid-info.com/get/1.3.6.1.2.1.2.2.1.10
Thank you.
In RFC 202 you can find the mapping of MIB objects to their corresponding item in IEEE 802.12,
https://www.rfc-editor.org/rfc/rfc2020#page-12
That means, SNMP only exposes those values directly from the network adapters, without any processing at SNMP layer. Thus, when you see a value for ifInOctets, it is very likely to be an accumulated value since the last reset of this adapter (may or may not be related to device reset).
I am debugging some snmp code for an integer overflow problem. Basically we use an integer to store disk/raid capacity in KB. However when a disk/raid of more than 2TB is used, it'll overflow.
I read from some internet forums that snmp v2c support integer64 or unsigned64. In my test it'll still just send the lower 32 bits even though I have set the type to integer64 or unsigned64.
Here is how I did it:
a standalone program will obtain the capacity and write the data to a file. example lines for raid capacity
my-sub-oid
Counter64
7813857280
/etc/snmp/snmpd.conf has a clause to pass thru the oids:
pass_persist mymiboid /path/to/snmpagent
in the mysnmpagent source, read the oidmap into oid/type/value structure from the file, and print to stdout.
printf("%s\n", it->first.c_str());
printf("%s\n", it->second.type.c_str());
printf("%s\n", it->second.value.c_str());
fflush(stdout);
use snmpget to get the sub-oid, and it returns:
mysuboid = Counter32: 3518889984
I use tcpdump and the last segment of the value portion is:
41 0500 d1be 0000
41 should be the tag, 05 should be the length, and the value is only carrying the lower 32-bit of the capacity. (note 7813857280 is 0x1.d1.be.00.00)
I do find that using string type would send correct value (in octetstring format). But I want to know if there is a way to use 64-bit integer in snmp v2c.
I am running NET-SNMP 5.4.2.1 though.
thanks a lot.
Update:
Found the following from snmpd.conf regarding pass (and probably also pass_persist) in net-snmp doc page. I guess it's forcing the Counter64 to Counter32.
Note:
The SMIv2 type counter64 and SNMPv2 noSuchObject exception are not supported.
You are supposed to use two Unsigned32 for lower and upper bytes of your large number.
Counter64 is not meant to be used for large numbers this way.
For reference : 17 Common MIB Design Errors (last one)
SNMP SMIv2 defines a new type Counter64,
https://www.rfc-editor.org/rfc/rfc2578#page-24
which is in fact unsigned 64 bit integer. So if your data fall into the range, using Counter64 is proper.
"In my test it'll still just send the lower 32 bits even though I have set the type to integer64 or unsigned64" sounds like a problem, but unless you show more details (like showing some code) on how you tested it out and received the result, nobody might help further.
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?
I am new to snmp, and I am trying to figure out what OID's I should get/trap to see if my printers, switches (and servers) is running? I do not need to know the details - just a simple test. I have successfully med get, getbulk, (and walk) request from a device, both from bash and iReasoning MIB browser.
Edit:
Maybe the
.1.3.6.1.2.1.1.3.0
Name/OID: sysUpTime.0; Value (TimeTicks): 194 hours 43 seconds (69844352)
is used for just that!? What happens when something is wrong? -will this be reset immediately? -or will it just stop counting? or is it just the time since last power on?
Printers
You should use the Printer MIBv2 to monitior printer error status for jams...
hrPrinterDetectedErrorState reports printer errors such as low toner, jams, etc... the RFC contains details on what specific codes mean
hrDeviceStatus will reveal the big picture ability of the printer to handle tasks. For more info, see Printer MIBv2, Section 2.2.13.2
sysUpTime.0 is an OID that reports the time a system's SNMP stack has been up (reference RFC 1213: MIB-II). If this value is returned and incrementing, it's a 99% safe bet that a printer is up. Most people use sysUpTime to detect whether the device has rebooted for some reason; if that happens, you'll see a sudden decrease in sysUpTime.0, unless your last value was around 248 days (where a 32-bit counter would roll).
Ethernet Switches
Checking the basic health of ethernet switches is usually done with checks to sysDescr.0 or sysUpTime.0; the problem with this heuristic comes if you care about the up/down status of particular links... at that point, you need to check values from ifOperStatus, which is indexed by ifIndex and uses interface names from ifName. See the following examples...
[mpenning#Hotcoffee ~]$ ## Walk ifName correlated to ifIndex
[mpenning#Hotcoffee ~]$ snmpwalk -v 2c -c Public 172.25.116.6 .1.3.6.1.2.1.31.1.1.1.1
iso.3.6.1.2.1.31.1.1.1.1.1 = STRING: "Fa0/0"
iso.3.6.1.2.1.31.1.1.1.1.2 = STRING: "Nu0"
[mpenning#Hotcoffee ~]$ ## Walk ifOperStatus (up==1)
[mpenning#Hotcoffee ~]$ snmpwalk -v 2c -c Public 172.25.116.6 .1.3.6.1.2.1.2.2.1.8
iso.3.6.1.2.1.2.2.1.8.1 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.2 = INTEGER: 1
[mpenning#Hotcoffee ~]$
Thus we know from the example that both interface "Fa0/0" (index: 1) and "Nu0" (index: 2) have an ifOperStatus of "up"; the index value is the last integer returned in the OID of the results.
Scripting
I assume you will use bash for your monitoring scripts; if so, check out Net-SNMP for your SNMP manager