Hi Craig, I believe nprobe running as collector should do all this through Netflow v9 templates
Is the one we will use for our project Jaime Nebrera Enviado / Sent iPhone El 12/04/2012, a las 18:58, Craig Weinhold <[email protected]> escribió: > 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
