I share your pain, but a userspace packet sniffer is probably the way to go. As for masq, sniffing works on a per interface basis, so you just sniff the internal interface and you're done. I don't think context switches would be a problem if i's going to be the only thing the router does. We have a similar situation (not yet, but getting there) but for us it could be neatly handled if we could just attach packet filters to interfaces but that's not possible. Note that on 2.4+ routes can be assigned "realms" and any packet gets an incoming realm and an outgoing realm. There is realm accounting which counts bytes and packets between any pair of realms. You can also match on realms in iptables. Maybe that could be useful to reduce the number of cases (assuming you don't need every pair but can aggregate things)? The problem is that you must add the routes using the new iproute tools which can be a pain if they're automatically generated in any way. Hope this helps, On Sun, Jan 04, 2004 at 03:31:18PM +0100, Maciej Zenczykowski wrote: > Hi, > > I've divided IP's viewed by a router into approx 300 categories, with > approx 8000 source-dest pairs (not all of the 300*300 pairs are possible). > I'd like to perform tracking of #bytes and #packets being > routed/sent/received in these pairs. Obviously this needs around 120kB > data worth of counters (8 bytes per #bytes and 3 bytes per #packets). > > For small numbers this could be done with ipchains/iptables and the > built-in counters. However this seems to be very unwieldly and likely > very time-consuming in my case (especially since 256 of the 277 categories > are just 192.168.5.* and can thus be determined much faster then a linear > chain lookup). Is there a kernel-space way to do this? Is there a > user-space utility to do this? All I need is #bytes and #packets with a > way to dump and load the current state (to save and restore state over > reboot) (doesn't need to be atomic, small errors can be ignored). This > router is a Pentium 100 - thus performance _is_ a vital issue... > > How should I go about achieving this? I currently have a partial solution > which uses around 2000 ipchains in tree-like formation, highly unwieldy > and very slow to load up, even though it does work decently in practice, > however this provides logging for a mere 1000 cases :) > [I'm sticking with ipchains as I've yet to find a good reason to move > forward :) but I will if the need arrises] > > I've been thinking of writing a userspace packet sniffer (just need the > source/dest ip address and packet size) however I don't know how this will > work with masquerading and I'm worried about the number of context > switches this would cause. Should this be implemented as a netfilter > module? > > Cheers, > MaZe. > > > - > : send the line "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > (... have gone from d-i being barely usable even by its developers > anywhere, to being about 20% done. Sweet. And the last 80% usually takes > 20% of the time, too, right?) -- Anthony Towns, debian-devel-announce
Attachment:
pgp00138.pgp
Description: PGP signature
