$ snmpget cisco.ora.com public .1.3.6.1.2.1.1.6.0 system.sysLocation.0 = ""
TIP: All the Unix commands presented in this chapter come from the Net-SNMP agent package (formerly the UCD-SNMP project), a freely available Unix and Windows NT agent. Chapter 5, "Network-Management Software" provides a URL from which you can download the package. The commands in this package are summarized in Appendix C, "Net-SNMP Tools".Several things are going on in this example. First, we're running a command on a Unix host. The command is called snmpget. Its main job is to facilitate the gathering of management data using a get request. We've given it three arguments on the command line: the name of the device we would like to query (cisco.ora.com), the read-only community string (public), and the OID we would like gathered (.1.3.6.1.2.1.1.6.0). If we look back at Table 2-5 we see that 1.3.6.1.2.1.1 is the system group, but there are two more integers at the end of the OID: .6 and .0. The .6 is actually the MIB variable that we wish to query; its human-readable name is sysLocation. In this case, we would like to see what the system location is set to on the Cisco router. As you can see by the response (system.sysLocation.0 = ""), the system location on this router currently is not set to anything. Also note that the response from snmpget is in variable binding format, OID=value. There is one more thing to look at. Why does the MIB variable have a .0 tacked on the end? In SNMP, MIB objects are defined by the convention x.y, where x is the actual OID of the managed object (in our example, 1.3.6.1.2.1.1.6 ) and y is the instance identifier. For scalar objects (that is, objects that aren't defined as a row in a table) y is always 0. In the case of a table, the instance identifier lets you select a specific row of the table; 1 is the first row, 2 is the second row, etc. For example, consider the ifTable object we looked at earlier in this chapter. When looking up values in the ifTable, we would use a nonzero instance identifier to select a particular row in the table (in this case, a particular network interface).
TIP: Graphical NMS applications, which include most commercial packages, do not use command-line programs to retrieve management information. We use these commands to give you a feel for how the retrieval commands work and what they typically return. The information a graphical NMS retrieves and its retrieval process are identical to these command-line programs; the NMS just lets you formulate queries and displays the results using a more convenient GUI.The getcommand is useful for retrieving a single MIB object at a time. Trying to manage anything in this manner can be a waste of time, though. This is where the get-next command comes in. It allows you to retrieve more than one object from a device, over a period of time.
The get-next sequence returns seven MIB variables. Each of these objects is part of the system group as it's defined in RFC 1213. We see a system object ID, the amount of time the system has been up, the contact person, etc. Given that you've just looked up some object, how does get-next figure out which object to look up next? get-next is based on the concept of the lexicographic ordering of the MIB's object tree. This order is made much simpler because every node in the tree is assigned a number. To understand what this means, let's start at the root of the tree and walk down to the system node. To get to the system group (OID 1.3.6.1.2.1.1), we start at the root of the object tree and work our way down. Figure 2-6 shows the logical progression from the root of the tree all the way to the system group. At each node in the tree, we visit the lowest-numbered branch. Thus, when we're at the root node, we start by visiting ccitt. This node has no nodes underneath it, so we move to the iso node. Since iso does have a child we move to that node, org. The process continues until we reach the system node. Since each branch is made up of ascending integers (ccitt(0) iso(1) join(2), for example), the agent has no problem traversing this tree structure all the way down to the system(1) group. If we were to continue this walk, we'd proceed to system.1 (system.sysLocation), system.2, and the other objects in the system group. Next, we'd go to interfaces(2), and so on.$snmpwalk cisco.ora.com public system system.sysDescr.0 = "Cisco Internetwork Operating System Software ..IOS (tm) 2500 Software (C2500-I-L), Version 11.2(5), RELEASE SOFTWARE (fc1)..Copyright (c) 1986-1997 by cisco Systems, Inc... Compiled Mon 31-Mar-97 19:53 by ckralik" system.sysObjectID.0 = OID: enterprises.9.1.19 system.sysUpTime.0 = Timeticks: (27210723) 3 days, 3:35:07.23 system.sysContact.0 = "" system.sysName.0 = "cisco.ora.com" system.sysLocation.0 = "" system.sysServices.0 = 6
Since get-bulk is an SNMPv2 command, you have to tell snmpgetbulk to use an SNMPv2 PDU with the -v2c option. The nonrepeaters and max-repetitions are set with the -B 1 3 option. This sets nonrepeaters to 1 and max-repetitions to 3. Notice that the command returned seven variable bindings: one for sysDescr and three each for ifInOctets and ifOutOctets.$ snmpbulkget -v2c -B 1 3 linux.ora.com public sysDescr ifInOctets ifOutOctets system.sysDescr.0 = "Linux linux 2.2.5-15 #3 Thu May 27 19:33:18 EDT 1999 i686" interfaces.ifTable.ifEntry.ifInOctets.1 = 70840 interfaces.ifTable.ifEntry.ifOutOctets.1 = 70840 interfaces.ifTable.ifEntry.ifInOctets.2 = 143548020 interfaces.ifTable.ifEntry.ifOutOctets.2 = 111725152 interfaces.ifTable.ifEntry.ifInOctets.3 = 0 interfaces.ifTable.ifEntry.ifOutOctets.3 = 0
The first command is the familiar get command, which displays the current value of sysLocation. In one of the previous examples we saw that it was undefined; this is still the case. The second command is snmpset. For this command, we supply the hostname, the read-write community string (private), and the variable we want to set (system.sysLocation.0), together with its new value (s "Atlanta, GA"). The s tells snmpset that we want to set the value of sysLocation to a string; and "Atlanta, GA" is the new value itself. How do we know that sysLocation requires a string value? The definition of sysLocation in RFC 1213 looks like this:$ snmpget cisco.ora.com public system.sysLocation.0 system.sysLocation.0 = "" $ snmpset cisco.ora.com private system.sysLocation.0 s "Atlanta, GA" system.sysLocation.0 = "Atlanta, GA" $ snmpget cisco.ora.com public system.sysLocation.0 system.sysLocation.0 = "Atlanta, GA"
The SYNTAX for sysLocation is DisplayString (SIZE (0..255)), which means that it's a string with a maximum length of 255 characters. The snmpset command succeeds and reports the new value of sysLocation. But just to confirm, we run a final snmpget, which tells us that the set actually took effect. It is possible to set more than one object at a time, but if any of the sets fail, they all fail (i.e., no values are changed). This behavior is intended.sysLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The physical location of this node (e.g., 'telephone closet, 3rd floor')." ::= { system 6 }
SNMPv1 Error Message | Description |
---|---|
noError(0) |
There was no problem performing the request. |
tooBig(1) |
The response to your request was too big to fit into one response. |
noSuchName(2) |
An agent was asked to get or set an OID that it can't find; i.e., the OID doesn't exist. |
badValue(3) |
A read-write or write-only object was set to an inconsistent value. |
readOnly(4) |
This error is generally not used. The noSuchName error is equivalent to this one. |
genErr(5) |
This is a catch-all error. If an error occurs for which none of the previous messages is appropriate, a genError is issued. |
The SNMPv1 error messages are not very robust. In an attempt to fix this problem, SNMPv2 defines additional error responses that are valid for get, set, get-next, and get-bulk operations, provided that both the agent and NMS support SNMPv2. These responses are listed in Table 2-7.
SNMPv2 Error Message | Description |
---|---|
noAccess(6) |
A set to an inaccessible variable was attempted. This typically occurs when the variable has an ACCESS type of not-accessible. |
wrongType(7) |
An object was set to a type that is different from its definition. This error will occur if you try to set an object that is of type INTEGER to a string, for example. |
wrongLength(8) |
An object's value was set to something other than what it calls for. For instance, a string can be defined to have a maximum character size. This error occurs if you try to set a string object to a value that exceeds its maximum length. |
wrongEncoding(9) |
A set operation was attempted using the wrong encoding for the object being set. |
wrongValue(10) |
A variable was set to a value it doesn't understand. This can occur when a read-write is defined as an enumeration, and you try to set it to a value that is not one of the enumerated types. |
noCreation(11) |
You tried to set a nonexistent variable or create a variable that doesn't exist in the MIB. |
inconsistentValue |
A MIB variable is in an inconsistent state, and is not accepting any set requests. |
resourceUnavailable(13) |
No system resources are available to perform a set. |
commitFailed(14) |
This is a catch-all error for set failures. |
undoFailed(15) |
A set failed and the agent was unable to roll back all the previous sets up until the point of failure. |
authorizationError(16) |
An SNMP command could not be authenticated; in other words, someone has supplied an incorrect community string. |
notWritable(17) |
A variable will not accept a set, even though it is supposed to. |
inconsistentName(18) |
You attempted to set a variable, but that attempt failed because the variable was in some kind of inconsistent state. |
In Chapter 1, "What Is SNMP?" we mentioned that RFC 1697 is the RDBMS MIB. One of traps defined by this MIB is rdbmsOutOfSpace :
The enterprise is rdbmsTraps and the specific trap number is 2. This trap has one variable binding, rdbmsSrvInfoDiskOutOfSpaces. If we look elsewhere in the MIB, we will find that this variable is a scalar object. Its definition is:rdbmsOutOfSpace TRAP-TYPE ENTERPRISE rdbmsTraps VARIABLES { rdbmsSrvInfoDiskOutOfSpaces } DESCRIPTION "An rdbmsOutOfSpace trap signifies that one of the database servers managed by this agent has been unable to allocate space for one of the databases managed by this agent. Care should be taken to avoid flooding the network with these traps." ::= 2
The DESCRIPTION for this object indicates why the note about taking care to avoid flooding the network (in the DESCRIPTION text for the TRAP-TYPE) is so important. Every time the RDBMS is unable to allocate space for the database, the agent will send a trap. A busy (and full) database could end up sending this trap thousands of times a day. Some commercial RDBMS vendors, such as Oracle, provide an SNMP agent with their database engines. Agents such as these typically have functionality above and beyond that found in the RDBMS MIB.rdbmsSrvInfoDiskOutOfSpaces OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times the server has been unable to obtain disk space that it wanted, since server startup. This would be inspected by an agent on receipt of an rdbmsOutOfSpace trap." ::= { rdbmsSrvInfoEntry 9 }
The list of bindings is called OBJECTS rather than VARIABLES, but little else has changed. The first object is the specific interface (ifIndex) that transitioned from the linkDown condition to some other condition. The OID for this trap is 1.3.6.1.6.3.1.1.5.3, or iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTraps.linkDown.linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and transitioned into some other state (but not into the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 3 }
Copyright © 2002 O'Reilly & Associates. All rights reserved.