On Mon, 03 Nov 2014 09:44:14 +0800 k simon <[email protected]> wrote:
> > Netflow or Ipfix implemention in userspace is not scaleable, it will > be good for implementing a wrapper in Bird for invoke ipt_netflow on > Linux and ng_netflow on FreeBSD. But ng_netflow is limited for V9. > > Simon Agree. Implementing Netflow/IPFIX/sFlow in user space would be quite a challenge. But that was not my intent, and it wasn't by accident that I did not mention Netflow. Netflow is (at least in v5) only designed to export IP flows for accounting, forensics, monitoring of the traffic, etc, so Netflow is not really suited when it comes to monitoring the state of BIRD. In sFlow there is a clear separation of flows (dubbed packet flow samples) and counters (dubbed counter samples), and specific structures exists to allow exporting IF-MIB and EtherLike-MIB. An sFlow implementation in BIRD would only send out counter samples (using a sFlow data structure particular for BIRD). In IPFIX there are only flows, but flows can be of arbitrary types. The most common flow key in IPFIX I bet is the 5-tuple <ip src, ip dst, ip proto, src port, dst port> which maps nicely to Netflow, but the flow key could simple be an interface index (supplementing IF-MIB), or only the IPv4 protocol (supplementing IP-MIB). This is the primary difference between Netflow and IPFIX, I think. Some of the recommended flows in IPFIX are actually just counters and statistics of the IPFIX device itself, meaning that only one flow of that type would ever exist in the stream. In the case of BIRD, the flow key could simply be a BIRD protocol name, and you would have as many flows as you have BIRD protocols running. All fields would be enterprise specific, but also self explanatory with a little help from RFC 5102, allowing a data collector who understands it, to interpret the data without prior knowledge of the BIRD-specific enterprise fields (unlike in sFlow). I'll admit that I did expect this kind of response to the IPFIX idea, which is the very reason I didn't just jump into doing the IPFIX solution right away. But I am confident that it is the intention of the IETF to let IPFIX be used in that manner. One of the primary goals of the upcoming "Exporting MIB Variables using IPFIX Protocol" specification is: "to allow SNMP push data from SNMP-only devices to be more easily integrated into IPFIX based collection infrastructures" And judging from the IETF mailing list, I'm not completely off. But I may be an early adopter. Too early maybe? Regards, Peter Nørlund
