On Thu, 11 Dec 2014 10:47:40 -0800 Wes Hardaker <[email protected]> wrote:
> > [catching up on past mail in mailing lists leaves me very behind in > this discussion... Sorry about the delay.] > > > [...] I didn't feel comfortable > > integrating Net-SNMP into the daemon, so I started out with a pure > > BIRD-based solution with an internal library used by the individual > > protocols. > > I strongly suggest you don't consider trying to implement an AgentX > subagent by itself. There are a number of agentx toolkits you can use > instead (Net-SNMP being just one). Getting things right in a subagent > is not easy (contrary to what the "S" in SNMP stands for; the protocol > is simple but the implementation is not). Doing it from scratch will > likely end up in an infinite data loop and other annoying things. > I agree that SNMP is not as simple as it ought to be. The protocols are relatively simple (especially AgentX), but with the way MIBs are designed used with conceptual tables and all, creating an easy to use API which also scales is challenging. It seems that the better the API become, the more complex the underlying implementation becomes. Even NET-SNMP, with 20 years of experience, haven't managed to make SNMP a pleasant thing to work with. > > [... actually above the other ...] > > Considering the single-threaded nature of BIRD [...] > > And there's the rub. Routing is *the* thing that bird must do and > must prioritize for. So the SNMP traffic needs to be handled last. I > suspect there is ways of doing that, though, such as checking first > for any non-SNMP traffic and handling it first and then *check again* > rather than jumping to the held SNMP traffic. EG, wait for a truly > dead time where there is no routing traffic to deal with first and > the *only* traffic is SNMP based. Yes, that might be a wise thing to do if possible. > > Then, implement the SNMP agent/mib code in such a way that it won't > ever take long to fulfill a request. If you have long-queries that > are hard to answer quickly, then either don't answer them or break > them up into smaller chunks of processing where you can keep checking > for incoming important packets again while doing the processing. EG, > the Net-SNMP agent does support a notion of asynchronous support that > lets you return control before you've finished getting the data that > was requested. > > > I revised my initial mile stone to just support notifications > > That's a good plan anyway :-) > I guess that simplest, least demanding way to actually achieve support for notifications, is to do SNMPv2 notifications directly (no AgentX/SMUX), which I guess is better than nothing. There probably wouldn't be SNMPv3 support (needs crypto), and you would have to specify the notification receivers in the BIRD configuration (as opposed to through the SNMP agent). I am very interested to hear which other SNMP libraries, you are thinking about. I know of one for C++ and a couple for other languages, but when it comes to C everyone seems to point at NET-SNMP. IPFIX, at least in theory, sounded like a much nicer way to export information, as it is less intrusive and less demanding, and I've had a working version of BIRD with IPFIX running on one of my routers for a couple of weeks, but I have had a hard time finding good 3rd party collectors which could do anything but standard NetFlow stuff. I tried one commercial product (Scrutinizer from Plixer), but I failed to get it to work. So right now, I am working on a generic IPFIX metric collector, so we can at least monitor BIRD at my work place, but the whole idea was to implement standard protocols which existing tools could leverage. This is also one of the reasons why I haven't submitted a patch for it yet, though it is publicly available at http://git.ordbogen.com/mother/bird/tree/ipfix. sFlow might have been a better choice as it actually distinguish between flows and counters, although sFlow lacks the self-descriptive nature of IPFIX.
