[j-nsp] recommended Netflow sampling rates?

Justin M. Streiner streiner at cluebyfour.org
Sun Aug 31 18:50:51 EDT 2008


On Mon, 1 Sep 2008, Ignacio Vazquez wrote:

> 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.

Right now I'm running at 1:100 sample rate, with a 4 packet run length, so 
I guess the sample rate is effectively 4:100.  I haven't looked at any of 
my Netflow data yet...

jms

> 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 <karabass at gmail.com>
>
>> 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 <bitkraft at gmail.com> 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


More information about the juniper-nsp mailing list