ippool Questions (Was Re: Large ipf Rule Sets - ...)

Hi Darren,

I looked in the manpages (sec. 5 and 8)and am intrigued with
the posibilities.

Is there further documentation somewhere for ippool and ippool.conf?

How large can pools be? Can they be multi-line, 10's, 100's of lines?

If a rule such as:
pass in from pool/100 to any
is encountered and pool 100 is empty, what happens?
What if there is no pool 100 defined?
[yeah I could just try it, but I'm trying to understand a bit
first...I hate rebooting my machine]

In the man page ippool(5) it says:
POOL TYPES
Two storage formats are provided: hash tables and tree
structure. The hash table is intended for use with objects
all containing the same netmask or a few different sized
netmasks of non-overlapping address space and the tree
is designed for being able to support exceptions to a
covering mask, in addition to normal searching as you would
do with a table. It is not possible to use the tree
data storage type with group-map configuration entries.
-------
What does: "the tree is designed for being able to support
exceptions to a covering mask..." mean?

Is there more description of: the group-map command
and the call command which invokes either fr_srcgrpmap or fr_dstgrpmap
somewhere?

Again, I can probably hack my way through these, but any advance
understanding would be helpful.

I think you are right though, ippools will be (much) more efficient
than what I am currently doing / trying to do.

Thanks,
gene



>> I have been using ipf to block some large swaths of unwelcome
>> address ranges for a while now.
>>
>> My current (working) rule sets consist of about 85,000 mostly
>> symmetric input and output rules for ~170,000 rules total.
>
> Would using ippool to define address pools for use in rules
> allow you to have fewer rules?
>
>> This appears to occupy about 85MB of kernel memory, which is
>> where ipf memory resides under NetBSD.
>>
>> Question 1: The ascii files for these rules only occupy about 12-13MB.
>> Is
>> the 85MB number reflective of some sort of allocation error?
>> (I would expect the in memory storage to be smaller since binary
>> coding can be used?)
>
> Unfortunately it's not like that. For example, the kernel objects
> used to store interface names provides for upto 16 characters, even
> if they're only 4 bytes long and there are upto 7 of these per rule
> and...
>
>> Question 2: If I flush the rulesets, I do not seem to get this
>> kernel memory back. How can I determine if this is a NetBSD kernel issue
>> or an ipf issue?
>
> Hmm? If you flush and then load again, does it use another 80MB
> of memory or does the memory use seem to become capped?
>
> Darren
>