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
can be extended through sampling, but at a loss of accuracy. You can
still get accurate enough data for billing if you sample at around 1/3
or 1/4, which means you can sample at a rate of between 21Mb/s and
28Mb/s. This is obviously inadequate. On the Cisco 7206 at PAIX we
were moving around 100Mb/s through it was running NetFlow on all
interfaces without problems. I'm not sure what the upper limit of
NetFlow switching is on that platform, but its vastly higher than
Juniper can offer.
NetFlow is not without its flaws, but it has a lot of very nice
properties. It allows us to gather very detailed data on the usage of
our network. Even if we don't use all the data all the time, we still
have access to it. Of course, it does require quite a bit of
processing to deal with all the records coming out of a busy router,
but its nothing a single lower end machine can't handle.
Juniper's recommendation is that we use a new 4.3 feature called
"Destination Class Usage" or "DCU". If you haven't seen it, this is a
fairly clever scheme that sorts outgoing traffic on an interface into
buckets based on rules, which can include BGP communities for the
destination route. These buckets are then queriable by SNMP. The
problems with this are several:
1) the traffic is only measured in one direction.
2) you are limited to 16 different buckets per interface.
3) the measurements are all taken with respect to a single
interface.
Obviously #1 is the most important problem with DCU. DCU needs to
become CBU (Class Based Usage), or it is of significantly limited
use. #2 will become an issue as our network grows. We'd are quite
conceivably going to be in 16 different countries or at least 16
different billable regions in the future. #3 isn't much of a problem
as long as we have Juniper routers everywhere. With NetFlow however,
we get flow records for all traffic transiting a router, and we can
separate customers if they share a router interface, for example.
To top it all off, in order to even get DCU we need to upgrade to 4.3,
and all of our routers are on 4.2 currently. We have also found a bug
(ID 13037) in 4.3 concerning SNMP and DCU. If you delete an interface
under 4.3 much of the DCU information is not longer available via
SNMP. So even if we were going to deploy something with DCU in one
direction and raw usage in the other direction, we'd have to wait for
a fixed version of 4.3. Given this relatively obvious SNMP/DCU
problem, I get the feeling that DCU wasn't tested very much before it
was released.
What I'd like to know is, how does Juniper expect that customers will
do variable billing? Is the expectation that people will just use DCU
in one direction and guess at the other direction? Is Juniper
expecting that customers that really care about accurate billing data
will buy a transparent analyzer product? How are other Juniper
customers dealing with variable billing?
I'd also like to know if Juniper's NetFlow implementation will ever
get any faster. Using NetFlow to track down problems and gather data
is very helpful, but with the 7Mb/s limitation the situations in which
it is applicable are severely limited.
shiva balasubramanian
iAsiaWorks
650-401- 3127 (work)
650-759 2498 (cell)
----- Original Message -----
From: Said Ouissal <souissal@conxion.net>
To: Greg Ketell <gketell@juniper.net>; <rkuhljr@uol.com.br>;
<juniper-nsp@puck.nether.net>
Sent: Wednesday, March 28, 2001 8:21 AM
Subject: RE: Netflow question
> Assuming that you use at least code 4.2, as there is an issue with earlier
> code which halts the sampling process after some time and skyrockets CPU.
>
> Said.
>
> At 17:19 28-3-01, Greg Ketell wrote:
> >The netflow statistics on the 7500 is gathered when you enable netflow
> >switching. You get information on every packet through the router. On
> >the GSR on on the M-series routers there is a statistical sampling done
> >and then the information about those sampled packets is put into
> >netflow-format and exported.
> >
> >On the M-series you can use filters to define what packets are sampled
> >(syn/fin only, http only, packets from nn.nn.nn.nn only, etc), what ratio
> >of packets you want to sample (grab every 1/N packets) and how long a
> >"train" of packets to sample (1/N + X). But the router has throttles
> >built in all over the place such that if you define sampling that would
> >kill the router it will drop the information rather than dropping the
router.
> >
> >GK
>
>
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:41 EDT