[c-nsp] NetFlow for Bandwidth Billing

[Adam Powers]

As a general statement, I believe NetFlow is an incredibly useful traffic
accounting technology ­ its application as a bandwidth billing mechanism is
proven. A few comments and things to consider based on my experience working
with NetFlow...

1. Find a collector that supports NetFlow deduplication. One of the biggest
challenge you run into with NetFlow is duplicate NetFlow records exported
from multiple routers. You¹ll want to be careful not to double count yet
catch everything sent/received by the logical IP block you¹re monitoring.

2. Monitor cache utilization; dropped flows leads to under reporting of
traffic volume. Fortunately this is in the customer¹s favor so not usually
an issue. Some level of product loss should be built into your billing
strategy anyway.

3. Understand NetFlow v1/5/7¹s limitations regarding multicast traffic. Also
remember that NetFlow monitors IP only.

4. Verify that your cache timers are compatible with the collector¹s
measurement intervals. Else you¹ll get a nasty sawtooth effect that
customers won¹t like.

5. Make sure you have a mechanism for detecting NetFlow outages. This is
more to protect you than the customer as they won¹t mind at all if your
missing traffic for a few hours.

6. Be aware of how ACLs and Null0 routed flows are reported. To bill or not
to bill for dropped flows and if you don¹t bill, how do you differentiate
dropped/not dropped?



On 5/2/07 9:36 AM, "TCIS List Acct" <listacct at tulsaconnect.com> wrote:

> 
> 
> 
> Adrian Chadd wrote:
>> > On Wed, May 02, 2007, TCIS List Acct wrote:
>> >
>>>> >>> 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.
>> >
>> > Its probably not going to be a big deal for a single-POP colocation
>> provider,
>> > but consider your network topology when deploying Netflow. You don't want
>> to
>> > double/triple account flows and you have to assume some traffic will be
>> asymmetric
>> > and thus show up as two flows - each router seeing one direction of the
>> traffic.
> 
> Yes, we will have that situation (asymmetric flows) where data comes in one
> link
> and out another, which is why we want to use a NetFlow analyzer that is smart
> enough to deal with such a situation/aggregate the data in an intelligent way.
> We are willing to buy a commercial product if that is what it takes, provided
> the pricing is reasonable.  Several open source products have been suggested
> as
> well, such as http://www.pmacct.net/
> 
> 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.
> 
> --Mike
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 



-- 

Adam  Powers
Chief Technology Officer
Lancope, Inc.
c. 678.725.1028
e. adam at lancope.com