In this section we'll show some examples that fetch the values of variables from an SNMP agent. The software used to query the agent is called snmpi and is from the ISODE system. Both are described briefly in [Rose 1994].
We'll query a router for two simple variables from the UDP group :
sun % snmpi - a gateway -c secret snmpi> get udpInDatagrams.0 udpNoPorts.0 udpInDatagrams.0=616168 udpNoPorts.0=33 snmpi> quit
The -a option identifies the agent we want to communicate with, and the -c option specifies the SNMP community. It is a password supplied by the client ( snmpi in this case) and if the server (the agent in the system gateway ) recognizes the community name , it honors the manager's request. An agent could allow clients within one community read-only access to its variables, and clients in another community read-write access.
The program outputs its snmpi> prompt, and we can type commands such as get, which translates into an SNMP get-request message. When we're done, we type quit. (In all further examples we'll remove this final quit command.)
Figure 25.15 shows the two lines of tcpdump output for this example.
The request for the two variables is sent in a single UDP datagram, and the response is also a single UDP datagram.
We show the variables as their respective object identifiers, because that is what's sent in the SNMP messages. We had to specify the instance of the two variables as 0. Notice also that the name of the variable (its object identifier) is always returned in the response. We'll see below that this is required for the get- next operator to work.
The operation of the get-next operator is based on the lexicographic ordering of the MIB. We start the following example by asking for the next object identifier after udp (without specifying any instance, since this is not a leaf object). This returns the first object in the UDP group. We then ask for the next entry after this one, and the second entry is returned. We repeat this one more time to get the third entry:
sun % snmpi -a gateway -c secret snmpi> next udp udpInDatagrams.0=616318 snmpi> next udpInDatagrams.0 udpNoPorts.0=33 snmpi> next udpNoPorts.0 udpInErrors.0=0
This example shows why a get-next operator must return the name of the variable: we ask the agent for the next variable, and the agent returns its name and value.
Using the get-next operator in this fashion, one could imagine a manager with a loop that starts at the beginning of the MIB and queries the agent for every variable that the agent maintains. Another use of this operator is to iterate through tables.
We can reiterate the column-row ordering of tables using our simple query program to step through the entire UDP listener table. We start by asking for the next variable after udpTable. Since this is not a leaf object we can't specify an instance, but the get-next operator still returns the next object in the table. We then work our way through the table, with the agent returning the next variable, in column-row order:
sun % snmpi -a gateway -c secret snmpi> next udpTable udpLocalAddress.0.0.0.0.67=0.0.0.0 snmpi> next udpLocalAddress.0.0.0.0.67 udpLocalAddress.0.0.0.0.161=0.0.0.0 snmpi> next udpLocalAddress.0.0.0.0.161 udpLocalAddress.0.0.0.0.520=0.0.0.0 snmpi> next udpLocalAddress.0.0.0.0.520 udpLocalPort.0.0.0.0.67=67 snmpi> next udpLocalPort.0.0.0.0.67 udpLocalPort.0.0.0.0.161=161 snmpi> next udpLocalPort.0.0.0.0.161 udpLocalPort.0.0.0.0.520=520 snmpi> next udpLocalPort.0.0.0.0.520 snmpInPkts.0=59 we're finished with the UDP listener table
We see that the order returned corresponds to Figure 25.14.
How does a manager know when it reaches the end of a table? Since the response to the get-next operator contains the name of the next entry in the MIB after the table, the manager can tell when the name changes. In our example the last entry in the UDP listener table is followed by the variable snmpInPkts.