ipfw prefix-list support request

Luigi Rizzo rizzo at icir.org
Tue May 18 00:07:11 PDT 2004

On Tue, May 18, 2004 at 05:25:33AM +0200, Max Laier wrote:
> I'll try to describe a bit how it is handled in pf, to give you some more 
> hints in case you are going to look at the code ...

good, thanks.

> pf uses the existing radix-tree implementation for the tables. This provides 
> lookups in O(32) for IPv4 and O(128) for IPv6 which means it's a constant 
> time lookup. Unfortunately, the radix code has some locking requirements that 
> add overhead but it's sure worth looking at.

well, good luck :) it's not just the locking requirements, it's
the space used for each entry and the very complicated API to
use it that scares me -- basically requiring a lot of extra
work to format arguments.

If anything, a good output from this kind of project would be
a reimplementation of a forwarding table...

> >  + remember that ipfw(2) accepts one line at a time -- so there will be
> >    times when the configuration is inconsistent e.g. you might have rules
> >    pointing to a non-existing list. Make sure the handling of these cases
> >    is not terribly expensive.
> I have no clue how to address this, but I find it a rather gross way of 
> dealing with a ruleSET ...

well this was for backward compatibility. The way ipfw2/dummynet handle
this is the same way in whihc one should handle pluggable hardware --
invalidate pointers on departures, flag arrivals so that the code
can (lazily) try to update an invalid reference after an arrival.
A generation-id of some kind would make the mechanism very simple.


More information about the freebsd-ipfw mailing list