Hi Savitha, Gert, Regarding IPv6 accounting using a PCAP program: | > http://sf.net/projects/yaps-pcap/ | | I took a look at your project at the above URL. Looks | good. But the catch here is that it is a packet | sniffer. An accounting tool essentially uses packet | sniffers generally libpcap but does something more | than that (using SNMP MIBS, or something like that). | The advantage of this is it can be used for large | enterprises/networks and the most important point is | if the network is migrated to gigabit Ethernet or | something packet sniffers would'nt work as they don't | follow a standard. Well, scaling is the problem we had at AS12859 also, when we upgraded from an STM1 to multiple dark fibers carrying GigE. Allthough today's hardware is indeed capable of examining line rate gigabit traffic, it's not optimal and kind of difficult to get the traffic to a single measuring point when you have multiple exitpoints. This is actually exactly why I wrote YANA (Yet Another Netflow Analyser) two weeks ago. What this does is extend the way YAPS works (accounting IPv4 addresses using pcap), to support IPv4 accounting per interface per cflow source; This way, one can answer questions like "What is the top10 speaker at the DE-CIX shared medium (fa0/2 @ cis1.de-cix) ?" or "From AS-BIT, who talks the most to AS3356 at AMS-IX (ge-0/1/0.100 @ jun1.ams-ix); Not to plug this software, but it seems natural to respond to your scaling issue. It's well under control using (statistical) flow management.o Back to IPv6. Gert seems interrested, and at least so am I. What I need is to change the source code a bit to use a new hashing library which I wrote for YANA. It is able to hash IPv6 addresses too and should be just as fast on both endian platforms, taking only memory for the IPv6 addresses that actually use resources. Gert (or others), would you be interrested in per-prefix (ie, per /48 or per /64) statistics, or per-host (/128) stats ? I am interrested in all three of them, but implementing it takes careful consideration. The /128 approach can be aggregated into accounting per /64 or other size, of course using potentially a lot more memory .. at 48 bytes per counter, if somebody started sending traffic to your /32, you'd quickly end up exhausting available primary storage on the measuring box. One method I could think of, is only initializing a new counter for a /128 which you've actually seen *outbound* traffic on. This way, random junk and portscanning will not explode your counter counts that much. It still remains difficult though, due to the numbers of (potentially) active IPv6 addresses ... Another is timestamping. We could make counters disappear after N seconds of idletime; this way noise can be eliminated and all idle IPv6 (and IPv4) addresses are eliminated... hmm, thinking aloud on this forum may help. Any other thoughts on this (YAPS and YANA) approach ? Does anybody want to help test (even develop?) this software ? -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------