[c-nsp] NetFlow for Bandwidth Billing

[Bill Nash]

Sounds like you're in the 'small' scale, with some room to grow for 
'medium'. 

Check out:
http://www.networkuptime.com/tools/netflow/

If you're talking billing, you're probably interested in 95th percentile. 
Flavio will do that out of the box, but I don't like the front end. Stager 
is hackable as hell. I've used softflowd for all kinds of things, even as 
a stand-in for tcpdump. Your requirements will obviously vary from mine, 
but that's at least a start.

- billn


On Wed, 2 May 2007, TCIS List Acct wrote:

> 
> 
> Bill Nash wrote:
> 
> > Scope and scale are the two big factors when dealing with netflow
> > accounting.
> > 
> > You will need full IP address accounting for your customers, ie knowing
> > which customers have been issued which address space.
> 
> Got that part covered.
> 
> > You will need an understanding of how many flows per second a given customer
> > generates.
> 
> Not sure on that one.  In general, we aren't pushing much more than 80,000pps
> out our transit links at any given time, and traffic on the Ethernet side is
> still under gigabit speeds most of the time (excluding backup traffic).  What
> specific metrics do I need to consider regarding flows?  I know there are flow
> expiry knobs, etc in the config..
> 
> > You will need to determine how and where it's possible to aggregate flows
> > together, based on the level of detail you need. This can be done at the
> > router level[1] or at the analyzer level[2]. Router sourced flow aggregation
> > may not work in a colocation environment if you're issuing single ip's to
> > different customers in the same subnet. Others may have more expertise in
> > this area than I. I couldn't figure out a good way to do it, and it was
> > easier (for me) to do on the analyzer side.
> 
> Since we only care about accounting for bandwidth that passes in/out of our
> borders, we planned to do NetFlow on our Cisco 7206VXR/NPE400 (soon to be -G1
> or -G2, or 6509 with Sup720/3BXL) core routers.  We have some legacy customers
> on /32's on the same /24, but most are on their own small subnets.
> 
> > [1] Depending on scale and architecture, this may not be healthy for your
> > router.
> > 
> > [2] Depending on flow volume and analyzer design, this may require some CPU
> > horsepower.
> 
> We can throw whatever sized hardware is needed on the NetFlow Analyzer side of
> things.
> 
> > As for completeness, I've not run into many cases where the flow volume
> > wasn't accurate. The netflow capable platform I worked with was c6509 (as
> > recently as last year), rocking a Perl analyzer that tossed about ~18k flows
> > a minute through Mysql, to the tune of about 400 million flows per day,
> > including LAN chatter, on about 8 gigs of egress capacity.
> 
> We are nowhere near that on egress capacity, maybe 200-300Mbit at present.
> 
> > There is no netflow solution that's perfect for every network, so you'll
> > want to do some legwork. Despite my experience, I can't personally recommend
> > any particular toolset, since I've always rolled my own. (No, I don't
> > currently have a flow analyzer that I can release.)
> 
> Our main concern is bytes in/out for billing purposes.  Nothing fancy, but we
> will be sending NetFlow streams from 3-4 different core routers which the
> NetFlow Analyzer must aggregate and consolidate into a single report per-IP or
> per-subnet, depending on the customer.
> 
> --Mike
> 
>