Due to the limitations of sampling pps for Netflow (RE<->PFE) and the
fact that the firewall filters are not stateful it will be difficult to
grab information for entire flows. There is some room for improvement
and development here. Perhaps as the features and functionality of DCU
increase (more buckets, bi-directional flows), it will be more suitable
to what you are looking for.
It would be nice to have the best of both worlds: bandwidth v. tcp
flows. Perhaps you can have both as long as you are within the pps
sampling limitations.
-- 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