Hi Brian,
Many thanks for your detailed analysis. I appreciate that very much.
As I have no ASA equipment available, I have to rely on packet samples
from users and their feedback respectively. Doing the implementation
to the best of my knowledge, bugs show up.
In this case I would like to ask the other ASA users to participate on
Brian's proposal and the renaming of forward/reverse, and if this fits
with everybody's understanding, as I have to rely on that.
It also gets more ad more complicated, to fit the plain v1/v5/v7/v9/IPFIX flows
and ASA records under a common umbrella and maybe it's worth to think about
an update of the record format to separate flows and events more cleanly.
I'd appreciate your comments.
Cheers
- Peter
On 03.06.16 05:35, Brian Candler wrote:
> 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
>
--
Be nice to your netflow data. Use NfSen and nfdump :)
------------------------------------------------------------------------------
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
