Efficient use of Dummynet pipes in IPFW

[Brett Glass]

At 03:40 AM 9/19/2005, John-Mark Gurney wrote:
 
>What's awkward about:
>#define PIPE_FOO 1
>#define PIPE_BAR 2
>
>add pipe PIPE_FOO config bw 64kbit/sec
>/* ... etc ... */

I've done that, and unfortunately it does not solve the problem
I'm describing.

The awkward and inefficient part comes when you have nontrivial 
criteria for passing the packets into the pipe. Due to the limited 
semantics of IPFW's "language," you must manually generate inverses 
of rules. This is tricky and error-prone and replaces each single 
rule with multiple rules, creating lots of overhead. And when you 
surround the rules with other rules (both manually and automatically 
generated), you can run into BASIC-like numbering problems.

In the end, even with a preprocessor you wind up generating a rule 
set that's huge, complex, inefficient, spaghetti-like, and very 
difficult to read and maintain.

To put it another way: this isn't the sort of situation that 
lends itself to the use of a preprocessor because the preprocessor
can't solve the underlying problem: the constraints of the 
language it is generating.

If the goal is to keep IPFW's language straightforward, simple,
and readable (important for firewalls, since the results of
messing up can be a catatonic machine and angry users), it's
best to give it the semantics it needs to do what's necessary.
The ability to negate an entire IPFW rule rather than just
the individual conditions in it (that is, do a "short circuit
NAND" of all the conditions in it) would be a big help, not only 
in this situation but in others. But the "resume" option would 
be even more efficient in many cases.

--Brett Glass