On Mon, 22 Dec 2014 07:14:30 -0800
Wes Hardaker <[email protected]> wrote:

> Err, um, rant-off I guess :-)

Hehe, just to be clear, NET-SNMP is by far the best SNMP implementation
I've seen so far. I think the the problem lies in the design (and
usage) of the SMI, which probably can't be made truly pleasant (unless
you put an obscene level of abstraction on top of it, which will
undoubtedly have its costs in performance).

> Notifications are much more likely to be implemented correctly if you
> do them yourself.  If all you care about is notifications, I doubt
> you want or need the overhead of AgentX (please don't use SMUX; it's
> a dead protocol).

I never truly intended to implement SMUX, but I threw all ideas into
the air. At my work, we would like to get notifications from BIRD when
connections go up and down, and we would like to monitor the number of
updates etc.. We can achieve this in several ways, but I prefer to do
it in the way that benefits the community the most. If for some weird
reason the majority of the community used SMUX, I would have gone that
way.

> In terms of libraries, the base net-snmp library is not as large as a
> full agent and you can send v1/v2c/v3 notifications with it (and there
> are configuration options that can help you reduced the code print
> size for small devices).  But it wouldn't be that hard or bad to roll
> your own SNMP trap either (unlike rolling your own agent).

I think I'll add "raw" SNMP notifications to BGP over IPv4 and see what
people think.

> As far as other choices, Net-SNMP is the most popular on the C side, I
> agree.  I can't point you to many other things as I'm much more
> familiar with Net-SNMP than anything else myself.
> 
> > IPFIX, at least in theory, sounded like a much nicer way to export
> > information [...]
> 
> Yeah, it's a better way to go.  But there is a lot less support for
> using it out there with open tools, I agree.  It's a newer kid on the
> block.
> 
> You could also send netconf notifications too, but there isn't much
> integrated support for that too on the receiving side.  There are
> tools you can use, but it's not likely to be the norm.  If you want
> the norm for receiving data then snmp is definitely it.  Netconf is
> being to be used more and more for configuration, but that'd be a
> large project in itself to get working within bird.
> 

So many options, yet so little time :-)

Reply via email to