Is this limit to protect the routing engine? If so would it be possible
to direct the sampled headers to a tunnel PIC which could do the
encapsulation and forward them to some other device for post processing?
mark
On Wed, Nov 07, 2001 at 02:37:52PM -0800, Robert O'Hara wrote:
> Hi,
>
> The default maximum setting for sampling is 1000pps per
> active switch fabric. On the M160, because it has four switch
> fabs, the default is 4000pps. As Steve has noted in his earlier
> email, you can configure the router to provide more than 1000pps
> under the [edit forwarding-options] heirarchy, use the
> 'set sampling max-packets-per-second x', where x is the max number
> of packets per second you define. Juniper's recommended guideline
> to customers is to stick with the default of 1000pps/switch fabric.
> This has been tested and is certified.
>
> Also, while using the run-rate is useful in some circumstances,
> if you are truly trying to capture a representative sample
> of the flows that are running through the box, then a run-rate
> greater than '1' will skew your results.
>
>
> Thanks,
>
> Bob O'Hara
>
> Systems Engineer
> Juniper Networks
> Northeast Sales Region
>
> .........................................
> . email: rohara@juniper.net .
> .........................................
>
>
>
> -----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