Thanks for reply, Dave.
My problem is a little bit different - when no packet counter is sent by
the router, master_record structure has shifted byte counter in packet
counter place. No sampling at all.
So, I did temporary workaround with filling packet data counter even when
there is no data sent for it. FillElement does the work. Diff below.
collector-5:/usr/src# diff -wau nfdump-1.6.6.orig/bin/netflow_v9.c
nfdump-1.6.6/bin/netflow_v9.c
--- nfdump-1.6.6.orig/bin/netflow_v9.c 2012-01-08 22:00:59.000000000
+0100
+++ nfdump-1.6.6/bin/netflow_v9.c 2012-10-02 11:33:17.000000000 +0200
@@ -605,13 +605,13 @@
* This record is expected in the output stream. If not available
* in the template, assume empty 4 bytes value
*/
- if ( input_template[NF9_IN_PACKETS].length ) {
+ //if ( input_template[NF9_IN_PACKETS].length ) {
table->packet_offset = offset;
FillElement( table, NF9_IN_PACKETS, &offset);
// fix: always have 64byte counters if (
input_template[NF9_IN_PACKETS].length == 8 )
SetFlag(table->flags, FLAG_PKG_64);
- } else
- table->packet_offset = 0;
+ //} else
+ // table->packet_offset = 0;
/* byte record
* This record is expected in the output stream. If not available
--
Regards,
Jakub Słociński
2012/10/1 Dave hartzell <[email protected]>
> Jakub-
>
> I too have noticed this, with Netflow v9 export from the CRS. But I
> don't think it is platform specific....
>
> I collect at 1:1500 on the CRS. When I force nfcapd to ignore the
> sample rate exported by the router (using the -S 1 switch) the sampled
> values are correct, as output by nfdump. I then later apply the math
> (x 1500) and get the correct values in the post-processed data.
>
> We're not the first to notice this, and it would be really nice if we
> could track this down and fix it.
>
> See:
> http://sourceforge.net/tracker/?func=detail&atid=683752&aid=3427615&group_id=119350
>
> for a similar issue, I commented on this bug at the bottom of the thread.
>
> Dave
>
>
> On Mon, Oct 1, 2012 at 6:14 AM, Jakub Słociński <[email protected]> wrote:
>
> >
> > So, in summary:
> > a) data seems to be gathered in a proper way
> > b) summary counters from nfcapd works well (those put into syslog each
> > rotation)
> > c) all other displayed data have crappy bytes/pkts couters.
> >
> > How can I check if data is stored properly and this is only presentation
> > layer bug? Data counters are 64bit long.
> > BTW. setup_translation_table fills proper elements (NF9_IN_BYTES).
>
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Nfdump-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
