Important Notice: Our web hosting provider recently started charging us for additional visits, which was unexpected. In response, we're seeking donations. Depending on the situation, we may explore different monetization options for our Community and Expert Contributors. It's crucial to provide more returns for their expertise and offer more Expert Validated Answers or AI Validated Answers. Learn more about our hosting issue here.

Do we really have to support SNMPv2 in order to work with new RFCs like 2233 resp. are we stuck with the old RFC 1213 when supporting only SNMPv1 ?

RESP RFCs SNMPv2 stuck support
0
Posted

Do we really have to support SNMPv2 in order to work with new RFCs like 2233 resp. are we stuck with the old RFC 1213 when supporting only SNMPv1 ?

0

The format of MIB modules is independent of the protocol except for objects that have data type of Counter64. This type is not supported in the SNMPv1 protocol. So you can implement RFC 2233 using the SNMPv1 protocol, except for the Counter64 objects. RFC 2089 provides you with information about implementing a bi-lingual agent. If your tools support MIBs only in SMIv1 format, you can convert them from the SMIv2 format to the SMIv1 format with MOSY and SMICng. (I would suggest that you get a license for SMICng from SNMPinfo at http://www.snmpinfo.com ) David T. Perkins 2.30.04.03 2.30.04.03.01 You can use mosy to convert MIBs. However, mosy is not doing a very good job in keeping things readable. It will also simply abort if it encounters things like Counter64 object types in SMIv2 MIB modules. Mosy is freely available. There is a free embeddable SMI parser library package called libsmi which includes a program called smidump. The smidump utility can output SMI MIB modules in various fo

What is your question?

*Sadly, we had to bring back ads too. Hopefully more targeted.

Experts123