Guten Tag Paolo Lucente, am Mittwoch, 9. Mai 2007 um 00:46 schrieben Sie:
> Daniel, don't know where you are getting such informations. Can you > please provide any docs supporting what you are saying? Even sFlow, > which intuitively should be the less reliable, can do the job by > playing a bit around the error: > http://www.inmon.com/pdf/sFlowBilling.pdf I see it in my network. I see 30Mbit avg. throu AS3320 (german telekom) but i am sure that it cant be correct i have more then 30Mbit. I upload a file to a server which have 10MB and sFlow shows me 17MB. I use a sample rate of 512 on my core-routers (only packetes importent for me) I know AMSIX use it too with a sample rate of 8196 (or so) and this graph looks exactly what my mrtg/snmp graph say. I think u have always a differents between 4-6 percent. I dont know any german ISP which use flow based accounting. Maybe the reason is that the router is under heavy cpu load. I use (and other ISPs) flow samples only for debugging and ddos detection/prevention what realy good works. Let me do some checks when my new routers come and see what he say when i use a sample rate of 8196 (or so) maybe then it will be fine. > NetFlow is then a de-facto industry standard deployed in a lot of > billing solutions today. It could be said that a solution based on > NetFlow needs a bit of thinking (ie. needs tuning, could generate > huge amounts of data, wastes CPU cycles of the network devices, > etc.) but that's it: it can't be said that it doesn't fit the job > because it's not accurate. I know a german link where someone explain that net.flow is not accurate enough. When i see that flow based accounting works fine u can be sure i will migrate all my customers to ip based accounting. -- Mit freundlichen Grüßen Daniel mailto:[EMAIL PROTECTED] _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
