You are correct, there is a documentation bug in the same paragraph of
seemingly all software config documents, not just JUNOS 5. The
paragraph from which you included the quote contradicts itself w/
reference to the run-length parameter. It should read "...the software
samples the next three packets..."
-- steve
> -----Original Message-----
> From: Przemyslaw Karwasiecki [mailto:karwas@ifxcorp.com]
> Sent: Wednesday, November 07, 2001 4:28 PM
> To: Stephen Gill; juniper-nsp@puck.nether.net
> Subject: RE: [j-nsp] cflowd sampling
>
> Steve,
>
> Thanks for your response.
> I did some more experiments and I believe that I found an error in
> an example in JunOS documentation:
>
> http://www.juniper.net/techpubs/software/junos50/swconfig50-
> interfaces/html/sampling-config3.html
>
>
> In the example: (yanked from documentation)
>
> For example, if you set a rate of 100 to trigger sampling on
> 1 out of every 100 packets and set the run length to be 3,
> the software samples the next two packets that are marked
> for sampling as well, giving an effective sample rate
> of 3 percent.
>
> documentation claim that setting 'run-length' to value 3 will
> sample 3 packets out of 100.
>
> But I believe that router will actually sample 4 packets out of 100.
> One plus 3 additional.
>
> To prove that I set up sampling with following parameters:
> rate 100
> run-length 0
>
> and my cflowd is showing approximately 1% of bandwidth shown on
interfaces.
>
> When I was trying to do the same with run-length set to 1,
> cflowd was reporting approx. 2% of bandwidth.
>
> Also, for the purpose of bandwidth analyzing, I believe it should be
> better
> to sample packet from all population of packets, instead SYN/ACKs
only.
> SYN/ACK are very short, and statistically doesn't represent well
actual
> bandwidth.
> On the other hand, sampling SYN/ACK only, can have an advantage of
> catching
> all TCP flows for more complete source/destination analysis, but
without
> any meaningful bandwidth.
>
> Please comment.
>
> Thanks,
>
> Przemek
>
> -----Original Message-----
> From: Stephen Gill [mailto:gillsr@yahoo.com]
> Sent: Wednesday, November 07, 2001 4:39 PM
> To: 'Przemyslaw Karwasiecki'; juniper-nsp@puck.nether.net
> Subject: RE: [j-nsp] cflowd sampling
>
>
> Unfortunately you are limited by a 100-Mbps bus b/n the RE and PFE
> (fxp1). For this reason, the number of packets that you can sample is
> limited, thus the need for telling the router what you really want to
> classify as interesting. You can be as granular as you would like
when
> doing so, such as by sampling syn/fin packets, etc... Keep in mind
that
> there is a built in rate-limiting mechanism of 7000pps no matter how
> much you may try to sample.
>
> It will be difficult to measure a full flow (including ack packets) if
> you cannot sample ALL traffic. As long as you stay within the built in
> limitations of pps you can sample based on filters.
>
> According to the docs on the 'run-length' flag: "Set the number of
> samples following the initial trigger event, thus allowing you to
sample
> adjacent packets to those already being sampled." IE. A run-length
of
> 0 will not sample any other packets in addition to the first one -
this
> is the behavior you have noticed.
>
> You may also wish to visit the juniper-nsp archives for previous posts
> on netflow here: http://puck.nether.net/lists/juniper-nsp/
>
> Juniper has posted a relevant Whitepaper on accounting that you may
find
> useful here: http://www.juniper.net/techcenter/techpapers/200010.pdf
>
> Cheers,
> -- steve
>
>
> > -----Original Message-----
> > From: Przemyslaw Karwasiecki [mailto:karwas@ifxcorp.com]
> > Sent: Wednesday, November 07, 2001 10:46 AM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] cflowd sampling
> >
> > All,
> >
> > I am looking for some more detail descriptions how traffic sampling
> > really work.
> >
> > I have just setup cflowd with 'rate 100' 'and run-length 1',
> > and the results given by cfdnexthops are far different from
> > what I would expect. Specifically traffic reported by this utility
> > is approximately 2% of traffic which is actually send over each
> > of the next hops.
> > Because of rate ratio and run-length, I would expect to see 1%
> > of traffic to be reported.
> >
> > Also, cflowd is actually meant to work on flow data, and I don't
> > understand how you can identify full flows, from SYN/ACK to FIN
> > just by looking at every 100ths packet. Or I am missing something.
> >
> > Any help, pointers, suggestions, explanations will be greatly
> appreciated.
> >
> > TIA,
> >
> > Przemek
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:37 EDT