> | | +--udpEthInLinkTable(3) > | | | | > | | | +--udpEthInLinkEntry(1) > | | | | Index: udpEthInLinkTable
????? > | | +--udpEthOutLinkTable(4) > | | | > | | +--udpEthOutLinkEntry(1) > | | | Index: udpEthOutLinkTable ????? That looks Just Plain Wrong. A table should be implemented by (one or more) column objects. Typically (though not universally) column objects of the same table. But you can't index a table by itself. I think you need to look again at your MIB definitions. > I was under the impression that a table leaf (e.g. udpInLinkID) in row > "rowNumber" has an OID as follows: > > udpEth.udpEthInLinkTable.udpInLinkID.rowNumber.0 No. Firstly, you're missing the "udpEthInLinkEntry" object. Secondly, if the table is indexed purely by "rowNumber" then the OID wouldn't have that trailing .0. This is the instance subidentifier for *scalar* objects, where it acts as the equivalent of "rowNumber" in a table. You wouldn't have both of them. I suggest you re-read whatever SNMP reference material you are using, and perhaps consider getting something else. > So why does snmpwalk (and HP OpenView NNM ) report the extra appended .0's > as follows?: No idea. The MIB dump above looks bogus, but this output is really down to the code that you're written to implement the MIB. Without a little more detail about what code you've actually got, it's impossible to tell why the output is warped in this way. Dave > CAUTION - This message may contain privileged and confidential information > intended only for the use of the addressee named above. If you are not the > intended recipient of this message you are hereby notified that any use, > dissemination, distribution or reproduction of this message is prohibited. > If you have received this message in error please notify Cirrus immediately. > Any views expressed in this message are those of the individual sender and > may not necessarily reflect the views of Cirrus. Cirrus cannot accept > liability for any virus damage caused by this message. This message does not contain privileged or confidential information, and is intended for the use of anyone who may find it of assistance. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is fine by me, as long as it falls within the commonly understood limits of "fair use" and "common decency". If you have received this message in error, just delete it. Please do not notify the University of Liverpool, the Department of Computer Science or the sender - we're really not interested in the slightest. Any views expressed in this message are those of the individual sender and do not necessarily reflect the views of the University of Liverpool, most of which has never even *heard* of SNMP, let alone have any view on these topics. If this or any other email message results in virus damage, then you should really take this up with the suppliers of your virus protection software and/or those responsible for maintaining this. And if you don't have any such protection (including mechanisms for keeping this up to date) then any residual sympathy goes flying out of the window. Such an attitude today can only be described as "wilful stupidity". ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
