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). Regards, Peter Nørlund
