On 02/06/2016 13:53, Brian Candler wrote: > So it seems to me that this should be REV in the middle block of code, > and FWD in the last block of code.
Hmm, thinking about this a bit more: maybe it's just that "in" and "out" are named the wrong way round. The values stored in the nfdump records are: table->packets table->bytes table->out_packets // Extension EX_OUT_PKG_4/8 table->out_bytes // Extension EX_OUT_BYTES_4/8 However, in standard unidirectional flows, the counters relate to traffic from src to dst. So I'd consider the base netflow packets/bytes to be "out"; and the extension values, which contains the reverse counts, to be "in". We could swap the names "in" and "out", or to be less ambiguous rename them to "forward" and "reverse". For example, the extension would become table->in_packets and EX_IN_PKG_4/8, or table->rev_packets and EX_REV_PKG_4/8; and the labels "ibytes" / "obytes", "ipps" / "opps" etc would be swapped or change to "fbytes" / "rbytes", "fpps" / "rpps" etc. This works (and does not change any existing stored data) as long as we're only considering: * standard unidirectional flows * ASA NSEL bi-directional flows using NF_F_FWD_FLOW_DELTA_BYTES and NF_F_REV_FLOW_DELTA_BYTES But we would also have to consider: * Netflow V9 bi-directional flows with NF9_IN_BYTES and NF9_OUT_BYTES * bi-directional flows synthesised by nfdump/nfstat * anything else which uses EX_OUT_* (ipfix, nfexport, others?) and I'm not sure whether those need to be changed for consistency. In particular, does NF9_IN_BYTES refer to traffic from src to dst, or dst to src? Regards, Brian. ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Nfdump-discuss mailing list Nfdump-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfdump-discuss