cvs commit: src/sbin/ipfw ipfw.8 ipfw2.c src/sys/netinet in.h
ip_fw.h ip_fw2.c raw_ip.c
ru at FreeBSD.org
Fri Jun 11 07:21:46 GMT 2004
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
> 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. ;)
ru at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20040611/2f414b8e/attachment.bin
More information about the freebsd-ipfw