Previous | Table of Contents | Next |
In the first GetRequest (Frame 1 of Trace 7.8b), the OID given for sysDescr is {1.3.6.1.2.1.1.1.0}. This OID consists of the prefix {1.3.6.1.2.1.1.1} and an instance (.0). Recall that an instance of .0 indicates a scalar object, that is, one that occurs only once. (Columnar objects may have multiple instances, requiring a suffix of .2, .3, .4, and so on. In these cases, the suffix identifies the specific instance of interest.) In Frame 3, you can see that the GetResponse returns:
Value = /usr3/wf/wf.rel/v5.75/wf.pj/proto.ss/ace_test.p/.
So far, so good.
Figure 7-8. Invalid Object Identifier (OID)
Now, as an experiment, the network administrator issues another GetRequest (Frame 4), which returns an error (Frame 5). The details show why this problem occurred. The GetRequest contains an invalid OID {1.3.6.1.3.1.1.1.1}, otherwise known as sysDescr.1. Since this is a scalar, not a tabular, object the ASN.1 syntax is invalid. The response returned in Frame 5 indicates this error: No such name. Thus, the agent provided a proper response for an OID that was not within its MIB.
Trace 7.8a. Handling an invalid object identifier (summary)
Sniffer Network Analyzer data 16-Nov at 17:43:32, file 7-15.ENC, Pg 1 SUMMARY Delta T Destination Source Summary 1 Router Manager 146 SNMP Get sysDescr 2 0.0488 Router SGI 020C5D ARP R PA=[XXX.YYY.3.146] HA=080069020C5D PRO=IP 3 0.0031 Manager 146 Router SNMP GetReply sysDescr = /usr3/wf/wf.rel/v5.75 /wf.pj/proto.ss /ace_test.p/ 4 7.2153 Router Manager 146 SNMP Get sysDescr 5 0.0421 Manager 146 Router SNMP GetReply No such name sysDescr
Trace 7.8b. Handling an invalid object identifier (details)
-------------------------------- Frame 1 -------------------------------- SNMP: ----- Simple Network Management Protocol (Version 1) ----- SNMP: SNMP: Version = 0 SNMP: Community = xyzsnmp SNMP: Command = Get request SNMP: Request ID = 13227000 SNMP: Error status = 0 (No error) SNMP: Error index = 0 SNMP: SNMP: Object = {1.3.6.1.2.1.1.1.0} (sysDescr.0) SNMP: Value = NULL SNMP: -------------------------------- Frame 3 -------------------------------- SNMP: ----- Simple Network Management Protocol (Version 1) ----- SNMP: SNMP: Version = 0 SNMP: Community = xyzsnmp SNMP: Command = Get response SNMP: Request ID = 13227000 SNMP: Error status = 0 (No error) SNMP: Error index = 0 SNMP: SNMP: Object = {1.3.6.1.2.1.1.1.0} (sysDescr.0) SNMP: Value = /usr3/wf/wf.rel/v5.75/wf.pj/proto.ss/ace_test.p/ SNMP: -------------------------------- Frame 4 -------------------------------- SNMP: ----- Simple Network Management Protocol (Version 1) ----- SNMP: SNMP: Version = 0 SNMP: Community = xyzsnmp SNMP: Command = Get request SNMP: Request ID = 1094416166 SNMP: Error status = 0 (No error) SNMP: Error index = 0 SNMP: SNMP: Object = {1.3.6.1.2.1.1.1.1} (sysDescr.1) SNMP: Value = NULL SNMP: -------------------------------- Frame 5 -------------------------------- SNMP: ----- Simple Network Management Protocol (Version 1) ----- SNMP: SNMP: Version = 0 SNMP: Community = xyzsnmp SNMP: Command = Get response SNMP: Request ID = 1094416166 SNMP: Error status = 2 (No such name) SNMP: Error index = 1 SNMP: SNMP: Object = {1.3.6.1.2.1.1.1.1} (sysDescr.1) SNMP: Value = NULL SNMP:
One of the significant enhancements to distributed network management has been the Remote Monitoring MIB (RMON). Both Ethernet and token ring versions of RMON are available (as discussed in Sections 3.4 and 3.5). RMON extends the reach of the network manager to remote LAN segments located anywhere on that internetwork. The RMON agent can be a simple device that connects to a local LAN segment and gathers statistics on that segments performance. RMON agents can also be built into internetworking devices such as bridges, routers, and intelligent hubs. The RMON manager could be a software application running on the network management console. This example shows sample statistics that this Ethernet RMON agent can tabulate for the manager (see Figure 7-9).
Figure 7-9. Retrieving remote information using the RMON MIB
The Ethernet RMON MIB contains nine groups (review Figure 3-12). The first group maintains a table of statistics, measured on the agents segment. The second group contains historical information about significant network events. In Trace 7.9a, the manager wishes to retrieve the statistics table and check its values. Frames 86 and 88 transmit the Managers GetNextRequests, and Frames 87 and 89 contain the RMON agents responses. Note that only one instance of the etherStatsTable exists, as all of the OIDs in the GetResponse messages (Frames 87 and 89) end with the suffix .1.
The details of the agents response show the statistics that are maintained (see Trace 7.9b). Of particular interest are the number of errored frames (fragments, jabbers, and collisions), which are counted by objects {1.3.6.1.2.1.16.1.1.1.11}, 12, and 13, respectively. Both Frames 87 and 89 reveal values of 21,389 fragments, 4 jabbers, and 163 collisions, respectively, for those objects. (Review the Statistics group of Figure 3-12, the RMON Ethernet MIB.)
Next, the manager issues a Set command followed by a Get for confirmation to store configuration entries in the History Control table {1.3.6.1.2.1.16.2.1}. This table contains various parameters that control the periodic sampling of statistics. The sampled values are stored in the Ether History table {1.3.6.1.2.1.16.2.2}. A two-step process stores the configuration entries. In the first step (Frames 90 and 91), the manager picks a random instance number between 1 and 65535 (52021 in this case), and issues a Set to the historyControlStatus object {1.3.6.1.2.1.16.2.1.1.7.52021} with Value = 2 (createRequest). The instance number (52021) identifies the table and prevents another manager from creating the same table with the same instance. This SetRequest succeeded, as the GetResponse (Frame 91) was returned with Error Status = 0 (No error).
Previous | Table of Contents | Next |