Would be great if there was an intermediate daemon that could grab v9/ipfix and convert it to v5 at least for now :)
Craig Weinhold <[email protected]> wrote: Netflow v9 / IPFIX is not going to be added to flow-tools without a near-complete rewrite. The problem with the v5 paradigm is that everything is built around fixed length records with 7-tuple keys (src/dst ip, src/dst port, protocol, tos, and input interface) and simple data fields (bytes, packets, start time, end time, etc). Unfortunately, silk, flowd, and (I think) nfdump all continue with this paradigm. They may have added IPv6, but they basically toss out other v9/IPFIX fields. You see, V9 is open-ended with both its keys and its data fields. Think RADIUS vendor-supported attributes. The record length of each flow is not fixed, and the interpretation of flow data changes dramatically from device-to-device and config-to-config. For example, Cisco ASA firewalls use Netflow v9 for logging both blocked and allowed traffic, but you need to be able to see the extra fields to determine which. I think nfdump has some hacks to handle this. Or, consider a router sending duplicate flows (e.g., "ip flow ingress" and "ip flow egress" on multiple interfaces). With the old paradigm, you are on the hook for de-duping the flows. With Netflow v9, there's a "direction" field to tell if a flow is coming or going. This is REALLY handy for investigating QoS markings happening within the router since you can see incoming/outgoing QoS markings separately. Or, consider Cisco application recognition features like NBAR and Medianet, which can tie into netflow v9. Wouldn't it be nice if flows said "I'm g.711" or "I'm a video call from Bob to Sally." Anyway, if you just want to add IPv6 to the old paradigm, then silk, flowd, and nfdump are all options. I've tested flowd to 30 Mbps of raw flow data and 800 exporters (change DEFAULT_MAX_PEERS in flowd.h for more than 128), and it holds up fine. nfdump and silk seem to have more support. But what I really want is a v9 collector that doesn't simply drop IPFIX elements it doesn't understand. I want one that writes every field, and has a flexible parsing engine (a la wireshark protocol definitions) for getting at those fields. Anyone know of that? -Craig On Thu, 12 Apr 2012, Jaime Nebrera wrote: > Hi Michael, > > > I hate to say it, but if nobody adds v9/IPv6 to flow-tools really > > soon, I will have to switch too. We're deploying IPv6 in production, > > and not having flow data is unacceptable. > > > > I'm looking for: > > > > pure open source (BSD/GPL/MIT-style licenses) > > active user community > > command-line flow printing& filtering > > > > The two obvious replacements seem to be nfsen and SiLK. Anyone have any > > opinons one way or another? > > We are about to start such project very soon. > > I dont know if my first email went through to the list but the idea would be > to: > > * Netflow v5, v9, sFlow and IPFIX compatibility > * noSQL backend (provably Hypertable based) > * Web front end (RoR) > * For sure, all open source > > For sure, all open sourced and even supported commercially. This project > will go along the first one done for Snort that will be released to public > April 24th (more or less) > > -- > Jaime Nebrera - [email protected] > Consultor TI - ENEO Tecnologia SL > C/ Manufactura 2, Edificio Euro, Oficina 3N > Mairena del Aljarafe - 41927 - Sevilla > Telf.- 955 60 11 60 / 619 04 55 18 > > _______________________________________________ > Flow-tools mailing list > [email protected] > http://mailman.splintered.net/mailman/listinfo/flow-tools > _______________________________________________ Flow-tools mailing list [email protected] http://mailman.splintered.net/mailman/listinfo/flow-tools _______________________________________________ Flow-tools mailing list [email protected] http://mailman.splintered.net/mailman/listinfo/flow-tools
