Recall that .1.3.6.1.4.1 is .iso.org.dod.internet.private.enterprises, and 9 is Cisco's private enterprise number. Therefore, the previous command is walking the entire Cisco subtree, which is very large; we've deleted most of its output. The output you see isn't very readable because we haven't yet installed the Cisco MIBs, so the snmpwalk command has no way of providing human-readable object names. We just have to guess what these objects are. This problem is easy to solve. Copy the Cisco MIBs[79] to the main Net-SNMP repository (/usr/local/share/snmp/mibs) and use the -m ALL command-line option. With this option, snmpwalk parses all the files in the MIB repository. As a result we get the object IDs in string (human-readable) form, and we can walk the cisco subtree by name rather than specifying its complete numeric object ID (.1.3.6.1.4.1.9):$ snmpwalk cisco.ora.com public .1.3.6.1.4.1.9 enterprises.9.2.1.1.0 = "..System Bootstrap, Version 11.2(17)GS2, [htseng 180] EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)..Copyright (c) 1999 by Cisco Systems, Inc..." enterprises.9.2.1.2.0 = "reload" enterprises.9.2.1.3.0 = "cisco" enterprises.9.2.1.4.0 = "ora.com" enterprises.9.2.1.5.0 = IpAddress: 127.45.23.1 enterprises.9.2.1.6.0 = IpAddress: 0.0.0.0 enterprises.9.2.1.8.0 = 131890952 enterprises.9.2.1.9.0 = 456 enterprises.9.2.1.10.0 = 500 enterprises.9.2.1.11.0 = 17767568 enterprises.9.2.1.12.0 = 0 enterprises.9.2.1.13.0 = 0 enterprises.9.2.1.14.0 = 104 enterprises.9.2.1.15.0 = 600 ...
[79] You can find many Cisco MIBs at ftp://ftp.cisco.com/pub/mibs/.
Now let's trim the output by adding the -Os option, which omits the initial part of each OID:$ snmpwalk -m ALL cisco.ora.com public cisco enterprises.cisco.local.lcpu.1.0 = "..System Bootstrap, Version 11.2(17)GS2, [htseng 180] EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)..Copyright (c) 1999 by Cisco Systems, Inc..." enterprises.cisco.local.lcpu.2.0 = "reload" enterprises.cisco.local.lcpu.3.0 = "cisco" enterprises.cisco.local.lcpu.4.0 = "ora.com" enterprises.cisco.local.lcpu.5.0 = IpAddress: 127.45.23.1 enterprises.cisco.local.lcpu.6.0 = IpAddress: 0.0.0.0 enterprises.cisco.local.lcpu.8.0 = 131888844 enterprises.cisco.local.lcpu.9.0 = 456 enterprises.cisco.local.lcpu.10.0 = 500 enterprises.cisco.local.lcpu.11.0 = 17767568 enterprises.cisco.local.lcpu.12.0 = 0 enterprises.cisco.local.lcpu.13.0 = 0 enterprises.cisco.local.lcpu.14.0 = 104 enterprises.cisco.local.lcpu.15.0 = 600 ...
This output is a little easier to read, since it cuts off the redundant part of each OID. Let's take this command one step further:$ snmpwalk -m ALL -Os cisco.ora.com public cisco lcpu.1.0 = "..System Bootstrap, Version 11.2(17)GS2, [htseng 180] EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)..Copyright (c) 1999 by Cisco Systems, Inc..." lcpu.2.0 = "reload" lcpu.3.0 = "cisco" lcpu.4.0 = "ora.com" lcpu.5.0 = IpAddress: 127.45.23.1 lcpu.6.0 = IpAddress: 0.0.0.0 lcpu.8.0 = 131888844 lcpu.9.0 = 456 lcpu.10.0 = 500 lcpu.11.0 = 17767568 lcpu.12.0 = 0 lcpu.13.0 = 0 lcpu.14.0 = 104 lcpu.15.0 = 600 ...
This command walks the system subtree. Since the system group falls under mib-2, there is no need to use -m ALL; mib-2 is one of the MIBs the Net-SNMP tools load automatically. Adding S to the -O option instructs the command to prefix each line of output with the name of the MIB file; we see that each line begins with RFC1213-MIB, which is the name of the file that defines mib-2.$ snmpwalk -OsS cisco.ora.com public system RFC1213-MIB::sysDescr.0 = "Cisco Internetwork Operating System Software ..IOS (tm) GS Software (GSR-K4P-M), Version 12.0(15)S, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)..TAC Support: http://www.cisco.com/cgi-bin/ibld/view.pl?i=support.. Copyright (c) 1986-2001 by Cisco Systems, Inc..." RFC1213-MIB::sysObjectID.0 = OID: DTRConcentratorMIB::catProd.182 EXPRESSION-MIB::sysUpTimeInstance = Timeticks: (344626986) 39 days, 21:17:49.86 RFC1213-MIB::sysContact.0 = "O'Reilly Data Center" RFC1213-MIB::sysName.0 = "cisco.ora.com" RFC1213-MIB::sysLocation.0 = "Atlanta, GA" RFC1213-MIB::sysServices.0 = 6 RFC1213-MIB::system.8.0 = Timeticks: (0) 0:00:00.00
snmpget options hostname community objectID...
-v 2c is required because get-bulk is defined by SNMP Version 2. There is one command-specific option, -B nonrep rep. nonrep is the number of scalar objects that this command will return; rep is the number of instances of each nonscalar object that the command will return. If you omit this option the default values of nonrep and rep, 1 and 100, respectively, will be used.snmpbulkget -v 2c options hostname community objectID
snmpbulkwalk -v 2c options hostname community objectID
You can provide any number of objectID/type/value triples; the command will execute set operations for all the objects you give it. type is a single-character abbreviation that indicates the datatype of the object you're setting. Table C-2 lists the valid types.snmpset options hostname community objectID type value...
Abbreviation | Type |
---|---|
a | IP address |
b[80] | Bits |
d | Decimal string |
D | Double |
F | Float |
i | Integer |
I | Signed int64 |
n | Null |
o | Object ID |
s | String |
t | Time ticks |
u | Unsigned integer |
U | Unsigned int64 |
x | Hexadecimal string |
[80]While the manpages show this as a valid datatype, the help output from the command does not.
For Version 1, the following trap parameters are required:snmptrap options hostname community trap parameters...
This command is discussed in detail in Chapter 10, "Traps". Each object ID/type/value triplet specifies a variable binding to be included with the trap; you may include any number of variable bindings. Note that the agent and the uptime are not optional; however, if you provide an empty string ("") as a placeholder they default to the IP address of the system sending the trap and the system's current uptime. The parameters are simpler for Version 2 traps, largely because traps (now called notifications) are full-fledged MIB objects in their own right. The following parameters are required:enterprise-oid agent trap-type specific-type uptime objectID type value...
snmptrap -v 2c options hostname community uptime trapoid objectID type value...
snmpdelta requires you to specify the OID of an integer-valued scalar object -- it can't monitor tables. For example, if you want to want to watch the octets arriving on an interface, you can't just specify ifInOctets; you must specify the interface number in addition to the object name (e.g., ifInOctets.3). By default, snmpdelta polls the given object every second. Table C-3 lists some of the snmpdelta-specific options. There are many problems with the documentation for this command, but if you stick to the options listed below you should be on firm ground.snmpdelta options hostname community objectID...
The -Cu option tells the command to consult the Net-SNMP private MIB. The Host Resources MIB is used by default.snmpdf -Cu options... hostname community
There are no options specific to snmpgetnext.snmpgetnext options... hostname community objectID...
snmpstatus options... hostname community
The objectID must be the ID of a table (e.g., ifTable), not of an object within a table. Table C-4 lists some of the snmptable-specific options.snmptable options... hostname community objectID
filename must be either snmp.conf or snmpd.conf.snmpconf filename
snmptranslate does not perform queries against any device, so it doesn't need the hostname or community parameters. Its sole purpose is to read MIB files and produce output about specific objects. Before looking at examples, it's worth noting that snmptranslate's interpretations of the -O options are, to be kind, interesting. To speak more plainly, they're just plain wrong. The following examples show what actually happens when you use these options -- we'll leave the rationalization to you. We expect these problems to be fixed in some later version of Net-SNMP. Let's say you want to know the enterprise OID for Cisco Systems. The following command does the trick:snmptranslate options objectID
This tells us that Cisco's enterprise OID is .1.3.6.1.4.9. Note the use of the -IR option, which tells snmptranslate to do a random-access search for an object named cisco. If you leave this option out, snmptranslate will fail because it will try to locate cisco under the mib-2 tree. Let's say you want to take .1.3.6.1.4.1.9 and convert it to its full symbolic name. That's easy:$ snmptranslate -m ALL -IR -Of cisco .1.3.6.1.4.1.9
In this case, -IR isn't needed because we're not performing a random-access search. -Ofn ensures that we print the full object ID, in symbolic (text) form. Here's what happens if we use -Of by itself:$ snmptranslate -m ALL -Ofn .1.3.6.1.4.1.9 .iso.org.dod.internet.private.enterprises.cisco
As we said earlier, this is not how you'd expect -Ofn and -Of to behave. If you're writing scripts, you shouldn't count on this behavior staying the same in future versions. Now, let's say you want to know a little bit more information about a particular object. The-Td option displays the object's definition as it appears in the MIB file:$ snmptranslate -m ALL -Of .1.3.6.1.4.1.9 enterprises.cisco
-Td can save you a lot of work poking through MIB files to find an appropriate definition, particularly when combined with -IR. Furthermore, the last line shows you the entire object ID in both numeric and string forms, not just the object's parent. Note that the other Net-SNMP commands have an unrelated -T option; don't get confused. -T is meaningless for this command, because snmptranslate only looks up a local file and doesn't need to access the network. The -Tp option prints an entire OID tree. The best way to understand this is to see it:$ snmptranslate -Td system.sysLocation .1.3.6.1.2.1.1.6 sysLocation OBJECT-TYPE -- FROM SNMPv2-MIB, RFC1213-MIB -- TEXTUAL CONVENTION DisplayString SYNTAX OCTET STRING (0..255) DISPLAY-HINT "255a" MAX-ACCESS read-write STATUS current DESCRIPTION "The physical location of this node (e.g., 'telephone closet, 3rd floor'). If the location is unknown, the value is the zero-length string." ::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) 6 }
We displayed the system subtree because it's fairly short. From this output it's relatively easy to see all the objects underneath system, together with their types and textual conventions. This is a great way to see what objects are defined in a MIB, as well as their relationships to other objects. The output can be voluminous, but it's still a convenient way to get a map and figure out what objects are likely to be useful.$ snmptranslate -Tp system +--system(1) | +-- -R-- String sysDescr(1) | Textual Convention: DisplayString | Size: 0..255 +-- -R-- ObjID sysObjectID(2) +-- -R-- TimeTicks sysUpTime(3) +-- -RW- String sysContact(4) | Textual Convention: DisplayString | Size: 0..255 +-- -RW- String sysName(5) | Textual Convention: DisplayString | Size: 0..255 +-- -RW- String sysLocation(6) | Textual Convention: DisplayString | Size: 0..255 +-- -R-- Integer sysServices(7) +-- -R-- TimeTicks sysORLastChange(8) | Textual Convention: TimeStamp | +--sysORTable(9) | +--sysOREntry(1) | +-- ---- Integer sysORIndex(1) +-- -R-- ObjID sysORID(2) +-- -R-- String sysORDescr(3) | Textual Convention: DisplayString | Size: 0..255 +-- -R-- TimeTicks sysORUpTime(4) Textual Convention: TimeStamp
Copyright © 2002 O'Reilly & Associates. All rights reserved.