> I'm wondering if there is a point to doing it this way actually. Perhaps it
> would be better to work on why I want to do it this way first.
>
> When a SNMP query is sent to a device, such as
> 1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1 (where it is not complete), how does it
> get the sub-oids? Does the device determine all the sub-id's it has or does
> intermapper substitute values and see what gets a reply?
Great question, and that makes me realize that it's worth explaining how
InterMapper does sub-oids and derived variables. Let me explain a little about
SNMP tables, and then tell how InterMapper does its magic:
In most SNMP table definitions, the index (or indexes) of a row are defined
with "ACCESS not-accessible". This means that there's no SNMP query that can
retrieve the index: instead, the index value is implicit in the OID itself. To
get values from the table, InterMapper "walks" the table by requesting
successive values until it reaches the end of the table. Each response contains
two items:
a) The requested value, and
b) The OID for the value that was returned.
InterMapper then examines the OID to "derive" the index value(s) for use in the
on-demand table. Here's a specific example from RFC-1213, MIB-II tcpConnTable
that illustrates this common case:
The tcpConnTable describes TCP connections that are in place. The table
conceptually has five columns: local IP address and port, the remote IP address
and port, and the connection state. The first four values are indexes; only the
connection state is really stored in the table. When InterMapper issues a
request for the first "tcpConnState" in the tcpConnTable, the response contains
the value (the tcpConnState) and the OID for that value.
I used the SNMP/Table Viewer probe to view the tcpConnTable on a local device.
It returned this information:
Connection state Local Adrs Local Port Remote Adrs Remote
Port
established 192.168.1.2 23 192.168.1.71 49372
The SNMP query for this returns the tcpConnState value of "5" (which means
'established'); the OID that comes back is:
1.3.6.1.2.1.6.13.1.5.192.168.1.2.23.192.168.1.71.49372
If you stare at the OID above, you can see that it's a straightforward process
for InterMapper to examine the suffix of the OID after tcpConnState (everything
after "1.3.6.1.2.1.6.13.1.5") to derive the local address and port (192.168.1.2
& 23) and the remote address and port (192.168.1.71 & 49372) and display them
in the Table view.
On-demand tables within InterMapper probes handle this automatically. The
tcpConnTable definition in the SNMP/Table Viewer probe looks like this:
tcpConnTable, .1, TABLE, "TCP Connections
that are in place in ${deviceaddress}"
tcpConnTable/tcpConnState, tcpConnState, DEFAULT, "Connection
state"
tcpConnTable/tcpConnLocalAddress, tcpConnState[0:4], DEFAULT, "Local Adrs"
tcpConnTable/tcpConnLocalPort, tcpConnState[4:1], DEFAULT, "Local Port"
tcpConnTable/tcpConnRemAddress, tcpConnState[5:4], DEFAULT, "Remote Adrs"
tcpConnTable/tcpConnRemPort, tcpConnState[9:1], DEFAULT, "Remote Port"
Here's how to interpret this:
- The first line above defines the name of the table, and the legend shown at
the top of the window.
- The second line defines tcpConnState, and its column heading. InterMapper
substitutes the real OID ("1.3.6.1.2.1.6.13.1.5") in the requests.
- The third line defines the tcpConnLocalAddress, which is derived from the
tcpConnState by taking the four sub-ids immediately following tcpConnState.
InterMapper actually requests tcpConnState, but sets the value for this column
from the four sub-ids of the OID that comes back.
- The fourth line defines tcpConnLocalPort, which is a single sub-id at offset
4 from the end of tcpConnState's OID
- The fifth line defines tcpConnRemAddress, which is 4 sub-id's at offset 5
from the end of tcpConnState's OID
- The sixth line defines tcpConnRemPort, which is a single sub-id at offset 9
from the end of tcpConnState's OID
The MIB Viewer builder tool handles all this table work automatically. It
creates the table definition, automatically detects the index entries, and
figures out the sub-ids required. (NB: The MIB Viewer tool does not currently
handle multi-sub-id values, such as the local and remote addresses in this
example. However, these are rare and easily fixed by editing the generated
probe file by hand.) You can try it at this address:
http://bit.ly/InterMapperMIBViewer
Please get back to me if you have further questions. Thanks.
Rich Brown [email protected]
Dartware, LLC http://www.intermapper.com
66-7 Benning Street Telephone: 603-643-9600
West Lebanon, NH 03784-3407 Fax: 603-643-2289
.+-j·!÷¬Ûiÿü0Âf¢ªÜ+Þr¿{^®f©¥êíjY8ÒX¬µÖ«·«yÊ&ý:.˱Êâmë צj)m íz³¦«M©d¡÷åË]j»pj·¢
