Re: [j-nsp] cflowd / JunOS 5.1

From: Przemyslaw Karwasiecki (karwas@ifxcorp.com)
Date: Tue Feb 12 2002 - 10:30:14 EST


All,

I have a problem I was alredy reporting to this group,
but unfortunatelly got no answers.

I am using Junos with:
 SAMPLED release 5.0R1.4 built by builder on 2001-08-14 22:55:55 UTC

I am collecting flows on OC3 POS interface with 1:100 sampling with
runlenghth 0.

I don't understand how it is possible that majority of flow data,
send by juniper to my cflowd, contains number of packets >1.

I know from experience, when I sampled the same traffic on cisco
box, with ratio 1:1, that majority of my flows contains no more
then 10 packets.

But juniper is supposed to sample 1:100 packets, so i understand,
that it should never (or very rarely) see all packets which belongs
to typical flow. I expected that netflow output from juniper will
contain majority of flows with packet count == 1, becuase of
1:100 ratio.

How it can happen, that even when i am sampling only 1 packet in 100
I still see all packets which belongs to a single flow????

Thanks for clarification,

Przemek

On Sun, 2002-02-10 at 10:10, Simon Leinen wrote:
> Arif,
>
> > 2- cfdcollect complains about missing flows and gives strange flow
> > loss ratios. It doesn't matter what the sampling rate is, cfdcollect
> > catches only 29 flows (strangely even on different platforms; alpha,
> > i686). I've tried 500 pps, 1000 pps, 2000 pps sampling rates on an
> > STM- 1 interface (run-length=0). Always 29 flows are
> > cached. Interface has 40000 pps traffic average. (I'm collecting
> > version 5 flows).cfdcollect syslog mess. is as fallows;
>
> >> [I] missed 1927 of 1956 flows from (null) engine 1075322028
> >> agg_method 0 (-7.64681e+53% loss)
>
> I read that JunOS 5.1 (at least some versions of it) have a problem
> where all Netflow packets *except for the first one* are sent out with
> an erroneous value in the "Netflow version" field of the header. The
> field should be 0x05 in all headers (since the packets should conform
> to Netflow version 5 format), but in fact it has some other value
> (0xd5?) in all packets except the first.
>
> Until this bug is fixed, you should be able to work around this
> problem by patching cfdcollect to ignore the version field and assume
> that the version is always 5.
>
> Hope this helps,
> --
> Simon Leinen simon@babar.switch.ch
> SWITCH http://www.switch.ch/misc/leinen/
>
> Computers hate being anthropomorphized.
>



This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:39 EDT