[SNMP4J] Basic Question about implementing SNMP Tables

Frank Fock fock at agentpp.com
Mon Dec 17 13:11:14 CET 2007


Hi,

As I wrote in my previous email, INDEX column *must*
be not-accessible in SMIv2. The reason is to avoid
redundancy. As you correctly mentioned, the column
object instance and its index suffix would otherwise
contain redundant information.

SNMP4J does it not check such a correlation, since
it is an exception case (and not allowed for "new"
MIBs) and since it can be easily implemented by the
instrumentation.

Best regards,
Frank

inliner683 at gmx.de wrote:
> 
> Yes I know that, but I really thought the OIDs for a row and the date in this
> row in the index columns must be identical, see below.
> 
>>>  I thought the OIDs should be deduced from
>>> the index column? This doesn't fit in my understanding of indexing tables in SNMP. Here you can provide
>>> arbitrary OIDs which will be valid and the index column seems to be of no importance.
>>>
> 
>    
>> Why do you think there is a relationship between the column index and 
>> the instance ID? 
> 
> Because every example that I read, there was a relationship. Consider the example
> with retrieving tcpConnState column (all other columns are index-columns):
> 
> 
> tcpConnState	tcpConnLocalAddress 	tcpConnLocaPort 	tcpConnRemAddress 	tcpConnRemPort
> ------------	------------		------------		------------		------------
> established(5)	127.0.0.1		6000			127.0.0.1		1042
> closeWait(8)	192.168.1.78		1156			192.168.4.144		80
>  
> Quote:
> "To get the value of the column tcpConnState for the last row, you have to query with the OID tcpConnState.192.168.1.78.1156.192.168.4.144.80 where 192.168.1.78 is the value of tcpConnLocalAddress for the last row, 1156 is the value of tcpConnLocalPort for the last row 192.168.4.144 is the value of tcpConnRemAddress for the last row 80 is the value of tcpConnRemPort for the last row."
> 
> So here is definitely a relationship between OID an data in the table. The OID is clearly constructed from the data
> in the index columns.
> 
> Now in terms of SNMP4J I could implement the above table and create the two rows with two
> arbitrary OIDs 1 and 2 and the suggested OID tcpConnState.192.168.1.78.1156.192.168.4.144.80 would be invalid (and
> igore all the index columns totally). And that is what I do not understand. Why would they be called index columns
> if they are not used to identify the rows but instead a OID provided by the SNMP4J API?
> 
> Do I have a basic misunderstanding of SNMP tables here (I admit that I am relatively new to SNMP)?

-- 
AGENT++
http://www.agentpp.com
http://www.mibexplorer.com
http://www.mibdesigner.com




More information about the SNMP4J mailing list