Hi Matt, How's life?
Responses below primarily for jnpr-nsp folks since you and I have talked
about this a bit already.
At 12:49 PM 3/28/2001 -0800, Matt Ranney wrote:
>"shiva" <shiva@iasiaworks.com> writes:
>
> > OK, here's the situation, as described by our developer building a billing
> > app:
> > We want to do variable billing. Its hard to do that on the Juniper
> > platform.
> >
> > First of all, Juniper's NetFlow implementation can only handle 7000
> > packets per second. Our average packet size in the US is around
> > 130bytes, which translates to a sampling rate of around 7Mb/s. This
>[...]
>
>Since I wrote that originally missive, allow me to summarize:
>
>NetFlow on the Juniper platform does indeed work for statistical
>sampling of no more than 7000pps.
That is 7000 sampled packets per second. So if you do 1/1 sampling it is
true 7000pps. But if you SAMPLE using 1/N where N>1 then it is N*7000.
> It is not suited for billing.
It wasn't ever designed for per-packet billing. The original intention was
for network planning purposes. If you sample syn/fin you know where every
flow is going so can design your network optimally.
Although if you did syn/fin sampling to get relative percentages for
traffic destinations and then used the per-interface in/out statistics you
could come up with reasonable billing. Then it becomes selling to convince
the customers that it *is* reasonable billing. Yes, this is hard.
>If you want more accurate numbers, see if DCU can do what you want.
>DCU is handled by the IP2, and doesn't degrade performance at all.
To be clear, neither does sampling, even if you sample "too much"
traffic. The throttles in place protect the main function of the router,
which is routing so you continue to get full throughput.
So, unlike our friendly spin-meister implied, Sampling is not deadly to the
IP2. (;->)
GK
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:41 EDT