25.05.06 @ 03:26 Andre Oppermann wrote:
Does this accept the packet and untag it at the same time? Wouldn't
it make more sense to have [tag|untag] as its own operators like
[allow|deny]?
Yes, it does (but example is impractical - we don't need tagging or
untagging when packet is finally denied). We thought about making
[tag|untag] as its own actions like [allow|deny], but decided to
implement it as modifiers instead, for two primary reasons:
1) Speed. It is faster to match packet with body of only one rule than
to do it once more for the same packet in the next rule, only to take
action on it.
2) Flexibility. We can use modifiers tag/untag with any possible
actions, e.g. allow, netgraph, skipto, pipe, ... - not only
[allow|deny]. Imagine you have to insert additional tagging rule for
any such action looking absolutely the same? And then consider speed of
matching. Thus, it is even *looks* more beautiful to write:
ipfw add 100 netgraph 300 tag 200 ip from host1 to host2
for tagging packet with tag 200 and then sending it to netgraph, than
to write something like:
ipfw add 100 tag 200 ip from host1 to host2
ipfw add 101 netgraph 300 ip from host1 to host2 tagged 200
Sorry, "tagged 200" is unnecessary there (or one can imagine, e.g. "tagged
400"
on both rules - tagging already tagged by another tag).
I understand your rationale. OTOH I think it's a logical blunder and
allows
some quite confusing rule sets. What I always liked about ipfw was the
simple
Umm, perhaps it should be documented more clearly in man page?..
and obvious logic in the statements. Over time it becomes more and more
over-
loaded with more stuff and also more stuff breaking the beautiful
simplicity
and clarity the original ipfw design had. ipfw rules used to read like
normal
sentences and were really simple to write and understand. But then I'm
just ranting...
Yes, I'll agree about beautiful clear syntax of ipfw, I also like it very
much.
But it is still clear when all that new overloading features are not used
To be honest I would prefer to fix the rule evaluation performance
problem of ipfw rather than to clutter the original beautiful rule syntax
logic.
Another $0.02 about logic - altq in ipfw also does its work in addition to
main
action instead of separate action keyword. Tag functionality in pf (from
which
idea and keywords are borrowed) also made as addition, not separate action.
So IMHO these ipfw tags follow the same unified style.
--
WBR, Vadim Goncharov
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
