[c-nsp] NetFlow for Bandwidth Billing

[Phil Mayers]

Bill Nash wrote:
> 
> Also, if you enable src/dst AS tagging on your flows (implies flow 
> generation from a bgp speaking device, caveat emptor for load hits), you 

Interesting factoid that is not well documented AFAIK - some hardware 
e.g. 6500 can add the destination AS for free but NOT the source AS - 
the latter has to be looked up in software when the flow is passed to 
the CPU. With large routing tables and lots of flows, hilarity ensues.

>>> My main concern is to understand the implications of using NetFlow for
>>> bandwidth
>>> billing, and if there are any major reasons "not" to do it this way.
>>>
> 
> There are a lot of benefits to flow based accounting, provided a good 
> architecture that can handle the volume of data. It's very easy for 
> netflow to run away from you, especially if you're dealing with duplicate 
> flows.

A rather more pertinent concern is missing flows altogether. In 
platforms with limited space and/or networks with a lot of flows, you 
can just miss flows, and that of course means you under-bill. You will 
want to monitor for this and have a plan in place (e.g. count bytes, 
subtract counted flows, divide the remaining portion pro rata)

> 
> Other things you can do with netflow: 

Great list. I'll add:

Processing flows with outif=0 (which indicate all of: output null0, acl 
denies, RPF fails or destination ARP fails - all of which are 
symptomatic of security issues if numbers are large).

Counting destination IPs per (srcip,dstport) - very effective with port 
25. Spambots show up like a supernova.