cvs commit: src/sbin/ipfw ipfw.8 ipfw2.c src/sys/netinet in.h ip_fw.h ip_fw2.c raw_ip.c

[Ruslan Ermilov]

On Fri, Jun 11, 2004 at 01:51:10AM +0200, Max Laier wrote:
> On Thursday 10 June 2004 23:40, Ruslan Ermilov wrote:
[...]
> > One nice difference (and I don't believe PF or IPFilter can do
> > this) is this optional 32-bit tag value with no special meaning.
> > For example, we have several thousands of client IPs, and each
> > client is allowed (through a Web form) to limit bandwidth to
> > some discrete values (0, 64, 128, 256, 512, and "unlimited") in
> > Kbps to/from Ukrainian and foreign networks.  We have this all
> > implemented using less than ten IPFW tables:
> 
> hmmm ... I don't really see the benefit in packing the information into 
> one table. You could as well have different tables for that (with pf only 
> memory limits the number of tables allowed).
> 
Imagine if I had 1000 possible values for rate limiting, I'd have to
use 1000 tables then.  Also, the lookup code caches last query so if
your ruleset does say hundred lookups:

pipe 1 ip from table(0,1) to any
pipe 2 ip from table(0,2) to any
...
pipe 100 ip from table(0,100) to any

and the entry in a table has the value 100, no radix.c code will ever
be called for 99 times.  If it were 100 different tables, this would
not work.

> But it's cool that we 
> inspire eachother and still diverge a bit to find the best solutions for 
> our respective users.
> 
Yes, sure.  ;)

> Btw, I find it very helpful that pf refers to a table by a name and not a 
> number. Why did you choose to use numbers?
> 
This is in spirit of the current IPFW syntax: no names for rules,
rulesets, pipes, hence no names for tables.  ;)


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20040611/2f414b8e/attachment.bin