From : Martin Ansdell-Smith <www@ansdell.demon.co.uk>
Subj : few SNMP MIB variables
-------------------------------------------------------------------------------
MIBs we've met
This page mentions briefly a few SNMP MIB variables and other
indicators that provide useful information about the functioning or
malfunctioning of a network. Of course, in reality, all MIB variables
are useful in some circumstances but, as with all things, we each have
our preferred subsets due to the type of networks we see or the way we
approach maintaining or fixing networks. I mention OIDs I have used
and found helpful as predictors, informers or diagnostics. In
particular I give information on how I have collected information for
some of the more obscure stats I have collected with [1]mrtg and
cricket.
Caveats
What I put here I have found to be useful but I might have mis-spelt
something vital or just be wrong. Read the [2]disclaimer and check
things out for yourself.
Even if I got it right it might work on the hardware and software
versions I used but not on yours so check things out for yourself.
Not all MIB variables on all versions of all software and hardware
from all manufacturers contain the correct information. Before you
rely on it check it out for yourself. Check it again when you change
things, or when some else does.
All MIB variable counters (and variables in most programming
languages) have a limited range. They will wrap eventually. They might
wrap in minutes or even seconds. This matters. Check out for yourself
what this means in your network for the variables you are monitoring.
Remember that as loadings change, so does the time to wrap.
All stats collection consumes resources; storing the information uses
more; accessing the information yet more. Statistics collection that
seriously impedes live data flows or badly inaccurate statistics may
be worse than no statistics at all, though you cannot expect
perfection. Check out that you have appropriate resources available to
avoid distorting the real traffic flows or presenting faulty data.
Finally: be prepared to give a reasonable justification for the
statistics you present. Check out for yourself that the information
you collect and present is relevant and accurate enough for the
purpose.
MIB-II Based Variables of Interest
MIB-II lives at 1.3.6.1.2.1, see the [3]note below if you are not sure
of the significance of this or how to use mrtg or CMU SNMP tools to
look at the information. Most of MIB-II is relevant, most is obvious
in its use so I'll just mention a few less common variables.
Type Code Description
.1.3 sysUpTime should increment
.2.2.1.11 ifInUcastPkts inbound unicast pkts
.2.2.1.12 ifInNUcastPkts inbound nonunicast pkts
.4.12 ipOutNoRoutes !=0 => routing problems
.6.13 tcpConnTable can process, e.g. for current
Oracle sessions
.11.4 snmpInBadCommunityNames !=0 may be a security issue
.16.1.1.1.13 etherStatsCollisions value irrelevant but big
increase might indicate problem.
Zero on full-duplex links.
.16.1.1.1.12 etherStatsJabbers should be very low
.16.1.1.1.6 etherStatsBroadcastPkts
.16.1.1.1.7 etherStatsMulticastPkts
Proprietary MIBs
Hewlett Packard (HP)
LaserJet printers (LaserJet 5 (MIO 6) and above but not the
ColorLaserJet 5 Enhanced and maybe others) with a JetDirect card
(EEPROM A.05.05 and up, I think), can provide useful information
including the total number of pages printed, available at
1.3.6.1.2.1.43.10.2.1.4.1.1 (some people have had success with the
proprietary MIB 1.3.6.1.4.1.11.2.3.1 but I have not yet).
Cisco
The majority of these that I use (dozens, perhaps hundreds) are used
to gather static information such as names assigned to ports, software
versions, cards and modules fitted in chassis (serial number, type,
software, firmware) and I have not detailed those here (though I could
publish the scripts with OIDs if anyone was interested). Some,
however, are useful for real-time data capture. Full details of all
supported MIBs and copies of all the MIBs themselves (as v1, v2, SMI
and OID lists) are available from ftp.cisco.com.
* Router (IOS) CPU Utilization, from the local variables system
group in OLD-CISCO-CPU-MIB.my (or OLD-CISCO-SYS-MIB.my):
+ 1.3.6.1.4.1.9.2.1.56.0 gives avgBusyPer: CPU busy percentage
over the last 5s period in the scheduler
+ 1.3.6.1.4.1.9.2.1.57.0 gives avgBusy1: exponentially-decayed
moving average of CPU busy percentage over a 60s period
+ 1.3.6.1.4.1.9.2.1.58.0 gives avgBusy5: exponentially-decayed
moving average of CPU busy percentage over a 300s period
I find the last two the most useful to give a feel for
utilization. On most routers the two stay together but will
deviate when the load is peaky and the router is very busy, I
find. These are gauges so do not average the readings over the
monitoring period. For example, use the gauge option with [4]mrtg.
* Router (IOS) Free Memory 1.3.6.1.4.1.9.2.1.8.0 from
OLD-CISCO-MEMORY-MIB is the obvious variable but this is not
always, in my limited experience, entirely reliable and is
officially obsolete from IOS 11.1. In the ciscoMemoryPoolTable in
CISCO-MEMORY-POOL-MIB-V1SMI.my there are instances for used, free
and largest contiguous free block of memory for each of the memory
pools found on the router. These values are similar to the ones
seen with sh mem at the router console.
For example, on a 2500 series router there are only two memory
pools, proc (pool 1) and i/o (pool 2). The number and names of the
pools can be seen by an snmpwalk on 1.3.6.1.4.1.9.9.48.1.1.1.2. In
this example, the amount of free memory in each pool can be seen
from
+ 1.3.6.1.4.1.9.9.48.1.1.1.6.1 (enterprises.9.9.48.1.1.1.6.1)
gives pool 1 (proc) memory free and
+ 1.3.6.1.4.1.9.9.48.1.1.1.6.2 gives pool 2 (i/o) memory free.
Similarly,
+ 1.3.6.1.4.1.9.9.48.1.1.1.7.1 gives proc largest contiguous
block free
+ 1.3.6.1.4.1.9.9.48.1.1.1.7.2 gives i/o largest contiguous
block free
+ 1.3.6.1.4.1.9.9.48.1.1.1.5.1 gives proc memory used
+ 1.3.6.1.4.1.9.9.48.1.1.1.5.2 gives i/o memory used
A comparison of sh mem and the OIDs listed here for two sample
routers can be seen [5]here.
The number of pools depends on the device type. All support
processor memory pools and may have other predefined pools and
also dynamic pools. Some devices allow pools to be called on by
other pools that have run out of memory. The [6]MIB gives the
details. When I last looked it pre-defined five memory pools:
1. processor memory
2. i/o memory
3. pci memory
4. fast memory
5. multibus memory
* Traffic rate on an interface by Protocol. For example,
+ IP
locIfipInPkts 1.3.6.1.4.1.9.2.2.1.1.42
locIfipOutPkts 1.3.6.1.4.1.9.2.2.1.1.43
locIfipInOctets 1.3.6.1.4.1.9.2.2.1.1.44
locIfipOutOctets 1.3.6.1.4.1.9.2.2.1.1.45
+ IPX (Novell)
locIfnovellInPkts 1.3.6.1.4.1.9.2.2.1.1.62
locIfnovellOutPkts 1.3.6.1.4.1.9.2.2.1.1.63
locIfnovellInOctets 1.3.6.1.4.1.9.2.2.1.1.64
locIfnovellOutOctets 1.3.6.1.4.1.9.2.2.1.1.65
+ Bridged
locIfbridgedInPkts 1.3.6.1.4.1.9.2.2.1.1.74
locIfbridgedOutPkts 1.3.6.1.4.1.9.2.2.1.1.75
locIfbridgedInOctets 1.3.6.1.4.1.9.2.2.1.1.76
locIfbridgedOutOctets 1.3.6.1.4.1.9.2.2.1.1.77
+ Others (e.g. XNS, CLNS, Appletalk): look in the
OLD-CISCO-INTERFACES-MIB for full details
* Configuration file moves. I prefer to do this using Expect but it
can be done using an SNMP set. Permissions need to be set on the
router. The old way used the now deprecated "writeNet" object in
the OLD-CISCO-SYSTEM-MIB by setting writeNet.<tftphost> to the
octetstring value of <tftpfile>. The recommended MIB is
CISCO-CONFIG-COPY-MIB. Full instructions for use are in the MIB.
Catalyst 5x0x switches support the CISCO-STACK-MIB which also
gives tftp facilities for moving configs and software to and from
switch modules.
Specifying and Accessing MIB variables
SNMP (Simple Network Management) Management Information Base (MIB)
variables are referenced by an OID (Object identifier), a sequence of
digits and dots. This specifies the position of the variable in the
MIB tree. Almost all the MIB variables you see commercially will start
with 1.3.6.1 (iso.org.dod.internet) and will then either take the
proprietary limb of the tree (.4.1: private.enterprise) the standard
limb (2.1: mgmt.mib). There are lots of books that explain this well;
My own preference is for Stalling for the explanations and
RMON2/SNMPv3 coverage, Feit for the examples from lots of the standard
MIBs.
After the MIB variable number there has to be an instance defined.
This will usually be 0 (zero) where there can only be one (the Cisco
Router CPU utilization variable above is an example of this),
otherwise it will often be the SNMP index of the interface, for
example. Having mentioned the SNMP index of interfaces do be aware
that these can change if modules are added or taken away from a
chassis, if VLAN configurations change or sub-interfaces are defined,
for example. There may also be non-obvious interfaces such as console
ports. On some equipment the indexes may not be consecutive.
Some software packages try to ease the burden of having to type in
lots of numbers and provide mnemonics for some parts of the tree or
assume that you are starting at somewhere other than the root of the
tree. Read the man and other information that comes with the products.
An example would be getting the current value for avgBusy1 from a
Cisco router. In mrtg the specified OID would be
1.3.6.1.4.1.9.2.1.57.0, with CMU SNMP-Utilities snmpget the OID would
be .1.3.6.1.4.1.9.2.1.57.0 as, without the leading dot it, by default,
assumes the OID is in the standard tree (i.e. without the leading dot
all the CMU SNMP utilities prefix 1.3.6.2.1. to the specified OID).
mrtg now supports the loading of MIBs at run-time, as well as
pre-defined OIDs. This greatly simplifies using unusual OIDs (look at
the documentation on the loadMIBs global configuration file entry).
This page is maintained by Martin Ansdell-Smith (e-mail:
www@ansdell.demon.co.uk)
using GNU Emacs and RCS on SuSE Linux 6.4.
Last modified $Date: 2000/06/13 16:36:41 $.
Vova
