Subject: Re: ipfilter performance with 'count' rules on NetBSD-1.4/i386
To: Martin Husemann <email@example.com>
From: Bill Sommerfeld <firstname.lastname@example.org>
Date: 09/15/1999 10:13:06
> > So you just need a trickier one. You need some kind of meta term like
> > ``... count 192.67/16'', that will recursively expand it bit by bit,
> > creating the obvious binary tree.
> But if it's that regular you should be able to process this whole set of
> rules in O(1), not even wasting space for a binary tree. So the question is:
> is this just the first time or a corne case, not likeley to appear again?
Indeed; this is the sort of thing which should take O(1) bpf rules and
maybe O(N) space (or possibly less, if you're clever and the active
address space is sparse).
Another approach which may scale better to large numbers of counted
addresses may be to use BPF to capture packet headers of interest and
throw them at a userland daemon for processing; that may not have the
needed performace, though clearly the "one ipf rule per address"
approach doesn't either.
Prototyping this with tcpdump piped to a perl script would likely give
you an upper bound on how many packets you'd lose when the system's