Re: SNMP Data Collection on ifIndex > 2^31
David Hustace <[email protected]> Mon, 29 Oct 2018 20:16:16 -0500
| Newsgroups | gmane.network.opennms.general |
|---|---|
| Message-ID | <[email protected]> |
> On Oct 29, 2018, at 19:41, Ian MacDonald <[email protected]> wrote: > > The CPE access interfaces however have much higher ifIndex numbers (seen in snmpwalk immediately below) which appear as negative integers as the ifIndex From the RFC it seems index values are to be non-negative so I'm assuming that's making the underlying protocol library (SNMP4J) very unhappy and the manager (OpenNMS) is calling "no joy". RFC 1212 If the INDEX clause is not present, and the object type corresponds to a non-columnar object, then instances of the object are identified SNMP Working Group [Page 8] RFC 1212 Concise MIB Definitions March 1991 by appending a sub-identifier of zero to the name of that object. Further, note that if the MIB module does not contain a textual description of how instance identification information is derived for columnar objects, then the INDEX clause must be present. To define the instance identification information, determine which object value(s) will unambiguously distinguish a conceptual row. The syntax of those objects indicate how to form the instance-identifier: (1) integer-valued: a single sub-identifier taking the integer value (this works only for non-negative integers); _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-discuss mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-discuss
signature.asc
(application/pgp-signature, 873 B)
-----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEM8HVsB3Payb01u1DmyrG1LpC+MIFAlvXsOEACgkQmyrG1LpC +MInHw/+IqgxMeeamJFpnY46H4rzIWpI7ORgiIAuKSZ4HWyEEHLakaEVQH7h7saM m9Wyot5xeVB1z8Qo68eR1VTJg5z0pZGKQra/Z3LoXopwq81xSbBdsELCrIWlQNTZ LMoRwYsdPVvZIltRq5kWcHg5sXGj+RiQepmjOHayxwwAJ6G887NSkmdc1FPVTM55 0/S2Y6vYO9fY0R6nVm+IURYt9ED//3WQzk5tNApUfMcNtiyze3nkqQKfpx0e42JN xJ5yTRgAmWM6Oz3WFQDI763jCUERhgN46nHA8ZTWaa++ehNN2wI1IIzJXAtO48EA UtciNkgTzo380UZdeTg7u4D7uHy6yGjJ0byRUWXloj06DKxyGDRBL3WRLMpfRQKw 3/Uhq5reNsAU/MnFpsnleOO4CK4gToeSzEP3Swz+lTpuzwmvbBAMv8BsbGnrHQxH MGJFrgrtxCNcrgMc20QRDr5gIqP92KgEmd9tPDz/npP3Mi7WYSEIbCNRJ6HRvJdT fmenuKW089AMMOuuVxhY8fgfQK2B2OylBNFHWumy17oFSKIXiKhg7j8x58KkeGBk m5FZ/t+IfJvFUi2qU9mnkz9dfa32UaQHDP/747PUYrGuuUjMuXAezBZFFtEBIes1 ZFbcmI5QsRY5zc00zSY2pEmgEgKDwPfttap1wzMdUzleHg5k+Xo= =X8Eu -----END PGP SIGNATURE-----