Re: [Opensnmp-users] Opensnmp-usersOpenSnmp v NetSnmp

[Brendan S. <Brendan@BrendanSimon.com>]

Thanks again Wes.  I will probably choose Net-SNMP of OpenSNMP for the 
following reasons.

    * SNMPv2c & SNMPv1 - some large organisations have a large install
      base of v1/2 monitoring software.
    * Larger install base => critical bugs are noticed and fixed earlier.
    * New python interface in 5.4 release :)

I would liked to have chosen OpenSNMP because it sounds like it has been 
engineered from the ground up to be more modular, etc, with proper use 
of C++ :)  I understand it is not as mature as net-snmp, but 
unfortunately it lacks a few features and is not a very active project.  
I hope you can get some proposals and funding together to take OpenSNMP 
to the next level to be as functionally complete as net-snmp.

I have some net-policy questions but I'll ask on the appropriate mailing 
list.

Thanks again.
Brendan.


Wes Hardaker wrote:
>>>>>> "BS" == Brendan Simon <Brendan@BrendanSimon.com> writes:
>>>>>>             
>
> BS> This implies that net-snmp is not fully compliant with the SNMPv3 
> BS> standards architecture.  Is there any documentation for net-snmp that 
> BS> states where it does not comply?  Maybe it's only in the threading ???
>
> The SNMPv3 architecture describes how to make a SNMP engine modular
> according to the pieces that are described in RFC4311.  That
> architecture is just "one" way to do it and is not "the" way to do
> it.  SNMPv3 in Net-SNMP is completely compliant with the wire
> protocol, but doesn't exactly mirror the "example" internal
> architecture described by RFC4311.  Specifically, the dispatcher and
> the message processing are not quite as separated as that document
> describes.  The security modules, however, actually are.  But there is
> no downside to the implementation with respect to supporting the
> protocol.
>
> The OpenSNMP stack, on the other hand, was actually created to *test*
> the architecture described in RFC4311 to make sure the RFCs weren't
> missing anything important (the work was done during the time the
> standards were being prepared and it was a double check on the
> standards documents).
>
>   
>>> OpenSNMP isn't heavily used, but we do use it ourselves in the
>>> net-policy project (also a sourceforge project) for the management end
>>> and it functions very well there.
>>>
>>>       
> BS> To what extent?
> BS> Are all SNMPv3 functions available, or does net-snmp provide more?
>
> All SNMPv3 functions are available.  However, Net-SNMP has more
> transports (tcp, for one) available for it too...  Both support IPv4
> and IPv6 though.
>
> Net-SNMP has a few more experimental SNMPv3 plugins though (the
> kerberos security model, etc).
>
> Also, by the way, OpenSNMP only supports SNMPv3.  It does not support
> SNMPv2c or SNMPv1.
>
> BS> In general I see the move to C++ as a good thing, from a software 
> BS> engineering viewpoint, if used appropriately :)
>
>   
>>> C++ has its ups and dows, just like C!  I think it worked really well
>>> for the OpenSNMP project, but we did a lot of advanced design that
>>> made it work well.
>>>       
>
> BS> In what way do believe it works well, and presumably better that net-snmp?
>
> It works well because we use a number of class hierarchy features that
> allow easier reuse.  Net-SNMP is filled with function pointers, which
> works really well, but many people have a harder time understanding
> than passing objects around instead.  Both work perfectly well,
> actually, and I'd even suspect that Net-SNMP might be faster but again
> no speed tests have been done.
>
> BS> I'm curious to know why the agent has been a lower priority.  Maybe the 
> BS> demands of something like net-policy (eg. multi-threaded client 
> BS> application) was the catalyst and motivation, and that net-snmp was more 
> BS> than adequate as an agent?
>
> Net-SNMP's agent is very very well tested and we simply haven't had
> the funding to make OpenSNMP's agent as robust.  It's not that we
> didn't want to, it entirely has to do with what we had funding to work
> on.  We have needed the client side code more lately, so it's received
> more attention.  It's as simple as that.
>
> BS> I understand that they are independent projects, but I guess I'm 
> BS> interested in the motivation for writing OpenSNMP rather than 
> BS> using/modifying Net-SNMP.  Whas it to:
>
> BS> * improve functionality?
> BS> * improve performance?
> BS> * improve robustness?
> BS> * learn to use C++?
>
> None of the above.  The goal was to produce a different package which
> was written from the ground up to test the SNMPv3 specifications.  The
> same project was responsible for putting in the SNMPv3 code into
> net-snmp as well, actually (there were two phases to the project; the
> first was to retrofit an older package and the second was to do a
> study from the ground up testing the specification itself).
>
> BS> Was net-policy the motivation or just the catalyst for OpenSNMP?
> BS> What other motivations have I missed?
>
> Net-Policy was actually a different project that came around after
> OpenSNMP.  We simple used OpenSNMP as the SNMP stack within the
> management framework of Net-Policy (which is one of the reasons, as I
> said above, why OpenSNMP's management side code has gotten more attention).
>