On Sun, 2 Nov 2014 16:58:13 +0100 Peter Nørlund <[email protected]> wrote:
> Hi, > > I have been working on adding SNMP support to BIRD through AgentX for > a while, but unfortunately I haven't had the necessary spare time the > last many month, so it is far from done. > > Lately we've experiencing scalability issues with out SNMP collector > at work, and I stumbled upon sFlow, which seemed a lot smarter and > simpler in may ways. > > This leads me to the question - if I were to add notifications and > statistical counters to protocols in BIRD, which way would then be the > preferred way for the community? And which counters/notifications do > you want? > > I can think of the following solutions, each with their advantages and > disadvantages: > > 1. AgentX > 2. SMUX > 3. Raw SNMP > 4. sFlow with BIRD specific structure > 5. sFlow with standard application structures. > 6. IPFIX with enterprise fields > 7. IPFIX with MIB variables > > Now, solution 1, 2, and 3 were part of my original solution. > The actual SNMP protocol is abstracted away and each protocol > implementation can export MIB variables and send notifications to the > SNMP protocols (AgentX being the only one for now). But SNMP is > actually rather complex, despite its original goals of being simple, > and it actually requires more CPU power than the other solutions. > > Solution 4 is probably the simplest solution of all. In fact, compared > to SNMP, sFlow is mindbogglingly simple. But sFlow collectors would > need to be modified to understand the data. > > Solution 5 would probably be supported by sFlow collectors, but we > would be somewhat limited to which counters we could export. > > Solution 6 I really like. Although IPFIX was originally designed to be > a standardized version of NetFlow, exporting network flow information, > it is increasingly moving into the domain of SNMP of sFlow with just > statistical counters - at least from the perspective of IETF. And > where sFlow requires that the sFlow collector knows the data > structure, IPFIX can be self-explanatory thanks to RFC 5102. The cool > thing is that IPFIX in this case really isn't that much more complex > than sFlow (although it certainly is from the perspective of the > collector). If the IPFIX collector doesn't utilize RFC 5102 to its > fullest, the collector would have to be modified just like the sFlow > collectors. > > Solution 7 is based on an upcoming IETF specification for exporting > MIB variables through IPFIX > (https://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-07). > Considering it is incomplete, it is probably not a viable > solution right now - and it adds the complexity of the other SNMP > solutions. > > As for what to monitor, it obviously depends on the solution. With > sFlow/IPFIX I was thinking a generic BIRD specific set of counters, > counting updates and withdrawals, and showing the uptime, status, and > name of each protocol, etc. (basically "show protocols all") > > Regarding the enterprise fields, my work place has an IANA enterprise > number, but so does CZ.NIC, and considering future extensions, it > would probably be best to use that of CZ.NIC if possible. > > Anyway, I would love to get input from other users out there, so that > the solution benefits most (note that one solution excludes the > other). Correction - I meant to say that implementing one solution does NOT exclude another from being implemented also. > > Regards, > Peter Nørlund >
