Looking at possibilities for an implementation of usage-based billing, it seems that the same techniques and tools always come up. I'm looking for some feedback from the list on experiences with these tools and techniques as well as alternatives that may not be listed here.
+Techniques
--Flow data (Netflow, SFlow, etc) analysis to determine 95th percentile traffic levels
--SNMP polling of interface counters to determine 95th percentile traffic levels
Granted, there are many interpretations of how to calculate "95th percentile traffic levels" that may differ from provider to provider. Assume that we have established the method that we will use.
+Tools
--RTG
--MRTG
--Cacti
--solarwinds Orion
--Various, expensive PM tools such as Netcool Proviso, JDSU NetComplete, InfoVista tools, etc
--flow-tools and FlowScan combo
--Arbor Networks Peakflow
Any follow up to this thread, either on or off list, or pointers to previous threads with good information would be appreciated! My search didn't turn up any, but that doesn't mean that they don't exist!
Thanks!
Regards,
Mauricio Rodriguez
Manager of IP/Data Engineering, FPL FiberNet
Email: Mauricio.Rodriguez@fpl.com<mailto:Mauricio_Rodriguez@fpl.com>
Rodriguez, Mauricio said the following, On 3/5/2009 2:02 PM:
Looking at possibilities for an implementation of usage-based billing, it seems that the same techniques and tools always come up. I'm looking for some feedback from the list on experiences with these tools and techniques as well as alternatives that may not be listed here.
+Techniques
--Flow data (Netflow, SFlow, etc) analysis to determine 95th percentile traffic levels
--SNMP polling of interface counters to determine 95th percentile traffic levels
I've been using pmacctd for several years with good success. It is designed for actual usage accounting (for instance, GB per month per IP/subnet) rather then 95th percentile.
The beauty of pmacctd is that it simply puts the data into an SQL database. Once the data is stored, you can write any SQL queries as required for reporting.
Wim
I need to look into this in the near future as well. The problems I'm aware of are:
1) we have customers on policed ports, and the interface snmp counters count packets before service-policy. It doesn't seem right to bill for packets we dropped :)...so this isn't useful data for billing purposes.
2) our customer agg gear (cisco 3550s) don't do netflow. Our bigger switches the agg gear uplinks to does (6509 sup720-3bxls), but can't handle export of full netflow, so we run sampled. It's still useful for abuse tracking, but billing based on it would require some large assumptions and multipliers...unlikely to be of use.
The remaining option I'm aware of is to use monitor sessions to send a copy of our traffic to a system/device which would then either generate "full" netflow data or just distill the traffic into data xfered per IP/network. What are people using for this on the several hundred mbit/s to a few gigabits/s or more range?
Are there other ways?
I use netacct - can grab data per cidr block and dumps data into
mysql. I wrote scripts from there to graph in rrdtool, bill on total
usage, or bill on 95th percentile.
http://netacct-mysql.gabrovo.com/
-Jack Carrozzo
Once upon a time, Jon Lewis <jlewis@lewis.org> said:
1) we have customers on policed ports, and the interface snmp counters
count packets before service-policy. It doesn't seem right to bill for
packets we dropped :)...so this isn't useful data for billing purposes.
Not sure how you are policing, but I belive both Juniper and Cisco have
MIBs that show the policed traffic. For example, when we used Cisco CAR
to limit traffic on some ports, I set up Cricket to monitor both the
base port and the CAR stats (so we could see how much traffic was
actually passed).
I haven't got around to doing it for Juniper firewall policers, but I
pretty sure the info is in a MIB.
I'd like to add:
--flow-tools and FlowViewer ( http://ensight.eos.nasa.gov/FlowViewer )
Keeps max, mean, and 95th pct. for up to three years for any predefined
customer (defined by a flow-tool filter and stored in RRDtool). Can group
customers for visual comparison.
Joe
Looking at possibilities for an implementation of usage-based billing,
[...]
+Techniques
--SNMP polling of interface counters to determine 95th percentile traffic levels
+Tools
--RTG
--MRTG
--Cacti
You can be pretty sure that there are probably a lot of billing systems based loosely around the tools mentioned here, and that in their particular environments they are robust enough to be successful.
If you go down this route, or a similar route, you need to remember that you MUST update the default RRD storage behaviours so that the most granular data is not aggregated until four or five months after the billing month, otherwise you will find that the averaging causes different results to fall out of your scripts when you look into customer queries on their bill !
Best wishes
Andy
I just checked a few 3550s and 3560s, and I don't see any evidence that they support CISCO-CLASS-BASED-QOS-MIB. Walking .1.3.6.1.4.1.9.9.166, I get nothing. On our 6500s, walking .1.3.6.1.4.1.9.9.166, I do get lots of data, but I don't see anything obvious in it that tells me which numbers go with which interfaces.
Is anyone actually making use of CISCO-CLASS-BASED-QOS-MIB on 3550s to graph/bill traffic passed after per-interface policing service policies are applied?