On Wed, 5 Nov 2014 19:18:32 +0100 Peter Nørlund <[email protected]> wrote:
> On Wed, 5 Nov 2014 12:10:04 +0100 > Ondrej Zajicek <[email protected]> wrote: > > > On Sun, Nov 02, 2014 at 04:58:13PM +0100, Peter Nørlund 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? > > > > Hi > > > > > > If i understand this correctly, there are several interwoven issues: > > > > 1) SNMP-like interface (pull-based) or just stream of counters > > (push-based) > > > > 1.1) Which variant of SNMP-based interface (AgentX, SMUX, raw > > SNMP, ...) > > > > 1.2) Which variant of stream-based interface (sFlow, IPFIX, ...) > > > > 2) What data/counters to export and how to represent it (standard > > MIB, BIRD specific) > > > > Exactly > > > > > My comments to these questions: > > > > 1) I think that it could be useful to have both kinds of interfaces. > > SNMP-based interfaces could support traps and be compatible with > > SNMP tools while stream-based interfaces are simple enough to be > > easily integrated with other data-gathering tools. > > > > 1.1) I have no clue of advantages and prevalence of these. Having > > raw SNMP would be nice to be self-contained, but that is probably > > not so important. > > SMUX has the disadvantage of being from SNMPv1 days, meaning that it > doesn't support 64-bit counters. I guessed that some people would like > the idea of standalone SNMP, but this would mean that we would have to > also handle the security-side of SNMP, which in the AgentX/SMUX design > is handled by an SNMP daemon. The default transport for AgentX is > UNIX sockets, which doesn't seem to be fully supported by the BIRD > socket API. TCP is the alternative transport though, and in some cases > TCP is the only viable one (some servers have an inbuilt SNMP daemon > embedded in the firmware). > > > > > 1.2) Generally i would prefer self-explanatory streams (IPFIX with > > RFC 5102), but i have no experience with sFlow or IPFIX. > > Me too. IPFIX can run on SCTP, TCP, and UDP, but SCTP is apparently > the preferred transport. But I guess this is for flows that require a > reliable connection. sFlow is by design just semi-random sampling and > statistical counters, so here UDP is always sufficient. Oh, and in case people are confused by the RFC 5102... What I meant to type was RFC 5610 (Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements). RFC 5102 is just a description of all the original standard information elements in IPFIX (Which would not need additional type information, since an IPFIX collector is expected to known the data types). > > > > > 2) This is an interesting question. We already have several > > statistical counters in BIRD, but we could extend or modify it to > > cover some standard or well-established MIBs. Could you point me to > > some statistical data specifications (like SNMP MIBs or their > > relevant parts) that are relevant for BIRD? What is supported by > > other routing sofware/hardware? > > > > Relevant MIBS for BGP: > - BGP4-MIB (RFC 4723) [Cisco, Juniper, Quagga, XORP] > - BGP4-MIB-V2 (Expired draft) [Juniper with enterprise ids] > > Note that BGP4-MIB doesn't support IPv6 or multiple peers with the > same address. Juniper tried to standardize their BGP4-MIB-V2 but it > expired July 2014. It supports IPv6 and multiple instances. > > > Relevant MIBS for OSPF: > - OSPF-MIB (RFC 4750) [Cisco, Quagga] > - OSPFv3-MIB (RFC 5643) [Cisco, Juniper, Quagga] > > I haven't checked the OSPF MIBS in detail > > > Relevant MIBS for RIP: > - RIPv2-MIB (RFC 1724) [Cisco, Quagga] > > > Relevant MIBS for BFD: > - BFD-MIB (RFC 7331) [Cisco] > > > > > In short, i would prefer both your solution 1-3 and 6. > > > > So I guess SNMP still makes sense. Question is then how to implement > it. Considering the single-threaded nature of BIRD and the fact that > it is often a critical application, 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. Through the library, a protocol can register a MIB area > and send notifications. A special set of SNMP protocols would then > serve as backends to the library. These SNMP protocols could then be > AgentX, SMUX, raw SNMP, etc.. But due to the complexity of SNMP and > the hard job of making it easy to use (Just ask the Net-SNMP guys), I > revised my initial mile stone to just support notifications (and > later fell in love with the simple, non-intrusive nature of sFlow and > IPFIX). > > As I could understand from Ondrej Filip's presentation today at > RIPE69, the focus in the near future is to stabilize and test BIRD, > and all the cutting edge stuff will happen in BIRD 2.x, so I suspect > adding SNMP this time around would be unwise. >
