Hi Brian, Justin, we were doing some calculation about the error you could have trying to protect at the same time the RE (not having more than 1 Kpps to the RE). I wanted to have less that 5 % error because the sampling, and I realize this could be obtain with more flexible sampling.
I know it could sound too conservative, but I think it is enough for us. My result could be sumarized with this table: Total traffic incoming | sampling recommended x < 300 Mbps | 200 300 Mbps < x < 3 Gbps | 2.000 3 Gbps < x < 30 Gbps | 20.000 30 Gbps < x < 300 Gbps | 200.000 Regards, Ignacio. 2008/8/31 Alexander Tarkhov <[EMAIL PROTECTED]> > Hi Brian, Justin! > > This sampling story can be implemented in two different ways on M/T-series. > One way of configuring the sampling output stanza is to utilize RE > resources for exporting flows. That is the default (and free) approach > when one of the daemons on RE - sampled - is doing the job of > aggregating flows and sending them out via UDP. > > The other way of doing this is using services PIC (or some variant of > it) with JFlow license installed for this purpose. > > The limitations of these two options are quite different, the intended > purpose of the two approaches is also different. That might be a > reason why there is no consensus here. You are probably asking about > RE-based sampling on M/T-series or MX. Please clarify if this is > correct, so that we don't mix these things. > > -Alex > > On Fri, Aug 29, 2008 at 6:55 AM, Brian Spade <[EMAIL PROTECTED]> wrote: > > I'd be interested to learn this as well. Also, how can you monitor the > > router properly to know whether sampling is affecting performance > (counters, > > ram, cpu, etc.) > > > > /b > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp