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. > > 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.
