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
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
