Posted Thu, 01 Jan 2015 16:00:00 GMT by

Trying to create an on-demand table. My current working table is:
 

Code:
   
   occ,            .1,                                          TABLE,         "occtab"
   occ/adrp,         1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1[1:4],                     DEFAULT,         "ADRP"
   occ/asrc,         1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1[0:1],                     DEFAULT,         "ASRC"
   occ/mac,         1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1,                        DEFAULT,         "MAC"
   occ/status,         1.3.6.1.4.1.1595.13.10.2.2.2.11.1.5,                        STRING,         "Status"



An example of a full oid:


1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1.20056.3.1.2.3

The asrc for this oid would be "20056". The adrp would be "3.1.2.3".

The 'adrp' is actually in the format "Chassis card"."Node"."Node card"."Port number"

Chassis card: 3
Chassis port: 1
Node card: 2
Port number: 3

What I want to do is break the tables in the probe down so it displays it per node card and port. So only the last two digits in the oid (eg; 2.3) with the associated asrc, mac and status.

I was hoping there was a wildcard I could use, for example 1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1.*.3.1

Obviously this doesn't work.

I am currently attempting to get the value of the asrc and put it into the oid as follows:

 

Code:

    occ2,            .1,                                                   TABLE,            "occtab"
   occ2/asrc,         1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1[0:1],                     DEFAULT,         "OCC ASRC"
   occ2/adrp,         1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1.($asrc).1.1[1:2],               DEFAULT,         "OCC ADRP"



But it only retrieves only one row.

Posted Thu, 17 Dec 2015 16:00:00 GMT by

What makes this complicated is I want to create a new table where the main source is the 'chassis card and port'. But since the asrc is before this in the OID, its making it hard. The arsc can also be nonconsecutive, meaning the following OID's can (and do) occur.
 

Code:

Chassis Card      Chassis Port      Node card   Node Port   ASRC   MAC         Status   
1                    1                    1                    1   10141   xx:xx:xx:xx:xx:xx      up
1                    1                    1                    1   10142   xx:xx:xx:xx:xx:xx      up
1                    1                    2                    3   10124   xx:xx:xx:xx:xx:xx      up
1                    1                    2                    4   10122   xx:xx:xx:xx:xx:xx      up
1                    1                    2                    7   10138   xx:xx:xx:xx:xx:xx      down
1                    1                    2                    8   10139   xx:xx:xx:xx:xx:xx      up
1                    1                    2                    8   10140   xx:xx:xx:xx:xx:xx      up
1                    1                    3                    1   10223   xx:xx:xx:xx:xx:xx      up
1                    1                    4                    5   10157   xx:xx:xx:xx:xx:xx      up
1                    1                    4                    5   10158   xx:xx:xx:xx:xx:xx      down
1                    2                    4                    7   10215   xx:xx:xx:xx:xx:xx      down
1                    2                    4                    8   10216   xx:xx:xx:xx:xx:xx      down
2                    3                    1                    3   10101   xx:xx:xx:xx:xx:xx      up
2                    3                    1                    3   20038   xx:xx:xx:xx:xx:xx      up
2                    3                    1                    4   10102   xx:xx:xx:xx:xx:xx      up
2                    3                    1                    4   20040   xx:xx:xx:xx:xx:xx      up
2                    3                    1                    5   10181   xx:xx:xx:xx:xx:xx      up
3                    1                    2                    1   20049   xx:xx:xx:xx:xx:xx      up
3                    1                    2                    2   10335   xx:xx:xx:xx:xx:xx      up
3                    1                    3                    2   10310   xx:xx:xx:xx:xx:xx      down
3                    1                    3                    8   10320   xx:xx:xx:xx:xx:xx      up
3                    1                    3                    8   20048   xx:xx:xx:xx:xx:xx      up
3                    1                    4                    1   10261   xx:xx:xx:xx:xx:xx      up
3                    1                    4                    1   20039   xx:xx:xx:xx:xx:xx      up
3                    1                    4                    2   10265   xx:xx:xx:xx:xx:xx      up
 



This means I need to specify the asrc part of the oid to extract the chassis and node details. But currently the probe will order it via the asrc because that's what comes first.

I hope that makes sense..

I've been playing with an alternitive to a wildcard

 

Code:

    occ2,            .1,                                                   TABLE,            "occtab"
   occ2/asrc2,         1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1[0:1],                     DEFAULT,         "ASRC"
   occ2/vtp,         1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1[3:2],                     DEFAULT,         "Node Port"
   occ2/drop2,         1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1.($asrc2).1.1.,               DEFAULT,         "Drop"



but as of yet havent had much sucess because it queries the asrc first. It also only returns one row.

The 'drop2' will be obvious to you that it doesn't work. If you have any info on how to insert values from one variable to another

Posted Thu, 17 Dec 2015 16:00:00 GMT by

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?

Posted Thu, 17 Dec 2015 16:00:00 GMT by

You can easily separate out the columns for the Chassis Card, Chassis Port, Node Card, and Port Number with the following:

occ/ccard, 1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1[1:1], DEFAULT, "Chassis Card"
occ/cport, 1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1[2:1], DEFAULT, "Chassis Port"
occ/ncard, 1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1[3:1], DEFAULT, "Node Card"
occ/pnum, 1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1[4:1], DEFAULT, "Port Number"
occ/asrc, 1.3.6.1.4.1.1595.13.10.2.2.2.11.1.1[0:1], DEFAULT, "ASRC"

This changes your original definition of adrp from [1:4] (starting at position 1, for four values) to individual values

Also, if you can get a MIB file from your vendor, you might try using the MIB Viewer probe creator at:

http://bit.ly/InterMapperMIBViewer

Posted Thu, 17 Dec 2015 16:00:00 GMT by

InterMapper doesn't really impose any order on the queries: the order of the columns in the table view comes from their order in the list. If you want to put arsc at the end, it should work fine.

Do you have the MIB that you want to query for this device? That would help me understand better the data structures supported by the device.

Posted Thu, 17 Dec 2015 16:00:00 GMT by

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

submitted by Rich Brown

You must be signed in to post in this forum.