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
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:37 EDT