Hi Gregor, let me briefly summarize your (good!) point: dealing with large networks - where multiple sensors, dynamic routing, etc. come into play - requires a kind of spanning-tree method to consolidate collected data.
This is a point on which i'm spending more and more thoughts recently. While i'm still analyzing the way to go, i think a 2-stages SQL approach may result in a quick and effective solution, actually. In a 1st stage data are collected and tagged (as in your example, tags should be solely based on the sFlow/NetFlow agent who has produced the sample). In a 2nd stage, data are consolidated by stripping their tag; this will produce duplicates. Duplicates will be discarded by the SQL engine: we are obtaining our (trivial ?) spanning-tree method and will happily get a consistent picture of the network. On Fri, Jun 02, 2006 at 07:59:26AM +0200, Gregor Heuer wrote: > bunch of sensors involved. Another problem is that after the data is > inserted in the database, there is no information about the sample rate, > so data from a sensor wich samples every packet is treated as having the > same accuracy as a sensor which samples only one in a zillion packets. This issue is easily solved by the 'sfacctd_renormalize': samples are renormalized as they are collected and before being pushed to the DB, allowing to get data from multiple agents even at different sampling rates. This is ACTUALLY not supported on the NetFlow side. I know NetFlow v9 can be sampled and encloses sampling insights in the datagram but i've been unable to get it working myself (perhaps because of the Cisco platforms/IOSs i have available). Though, i would be happy to implement this feature on the NetFlow side aswell. If anyone reading can deal with sampled NetFlow, s/he can help by sending me (privately) a tcpdump savefile of a few sampled NetFlow datagrams (in a way that i can replay them locally). Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
