Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Jan 2000 11:38:33 -0800 (PST)
From:      "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
To:        patrick@mindstep.com (Patrick Bihan-Faou)
Cc:        luigi@info.iet.unipi.it (Luigi Rizzo), freebsd-current@FreeBSD.ORG
Subject:   Re: ipfw optimizations
Message-ID:  <200001071938.LAA12079@gndrsh.dnsmgr.net>
In-Reply-To: <007d01bf5942$a0216540$c80aa8c0@local.mindstep.com> from Patrick Bihan-Faou at "Jan 7, 2000 02:08:47 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi,
> 
> > > One of the things I would do to optimize ipfw is:
> > > - instead of keeping one list with all the rules, split the list (the
> > >   internal one) by interface and by direction (one list for ed1
> incoming,
> > >   one list for ed1 outgoing, etc.).
> >
> > I often do this manually in long rule sets by using things like
> >
> > ipfw add 1000 skipto 10000 from any to any via de0
> > ipfw add 1001 skipto 20000 from any to any via de1
> > ...
> > ipfw add 10000 skipto 15000 from any to any in via de0
> > #process outbound on de0 rules here
> > ipfw add 15000 blah blah # processing inbound on de0 rules here
> 
> [...]
> 
> > Anotherwords, don't burden the ipfw with code that can easily be done
> > by an intellegent user, and some more examples/documentation...
> 
> Yep, and there happens to be a rule that you would like to be tested in
> every case, but you don't want to test it at the begining (before the
> switch) but sometime in the middle. With your scheme (which is the only
> reasonable one currently), you have to duplicate that rule for every branch.
> This is fine, but if now you need to modify the rule somewhat, don't forget
> to modify it everywhere. This can rapidly become a maintenance nightmare.

Thats what m4 is for :-)  I don't normally write direct rule sets as a
simple list of ipfw commands, but as a combination of sh script that is
actually written by an m4 input file.  I never write the same line twice,
and even lines that are similar either end up being a m4 macro, or
a shell function for more complicated ones with lots of arguments.

> 
> What I was proposing is that the per-interface switch be done implicitely by
> ipfw. So if you do:
> 
> ipfw add allow ip from joe to bob via de0
> ipfw add allow ip from arthur to joe in recv de0
> ipfw add allow ip from john to any
> 
> You get the proper rule tree generated:
(Which also happes to be very far from optimal rule set with meaningless
rules being run)
> 
> -> ed0 RX:
>     allow ip from joe to bob
More than likely from joe to bob is only either a RX or TX packet,
infact unless your using multiple IP addresses on ed0 by definition
of routing it would have to be one or the other, otherwise this
box should never see that packet as it is not routing it.

>     allow ip from arhur to joe
>     allow ip from john to any

> 
> -> ed0 TX:
>     allow ip from joe to bob
>     allow ip from john to any
> 
> -> ed1 (TX or RX)
>     allow ip from john to any
The ``from john'' rule probably only applies to one of the 3
interfaces, unless john happens to be multiple routed.

> 
> 
> By the way, in terms of optimization you will save:
> 
> - 2 * number of interfaces rules (the skiptos) that have to be tested for
> most packets

And your scheme could easily end up with 100's of rules that don't even
make since for that interface/that direction.  Attempting to build these
lists with intelegence has been tried in the past, and I have yet to
see one that doesn't produce far more rules than are actually needed.

> - 2 tests for each rule after (you don't need to retest the interface nor
> the direction, it has been.
> 
> 
> If you go further in that logic and implement a per protocol switch, you
> reduce the number of test even more.

The ipfw dispatch command I mentioned in other email would be an
effecient optimization... what I see here would probably be far
from optimal as explained above.
> 
> 
> To answer a previous question about the number of interfaces, I use FreeBSD
> as a gateway with 2 ethernet interfaces and 3 tunnel interfaces (ipsec) to
> remote locations. I guess that most cases where you really worry about ipfw
> is in gateways where a minimum of 2 interfaces seems reasonable.

We use it here with 4 to 8 ethenets per box... and larger rule sets run
into the 300 to 400 range in count.

> 
> Again, I am not saying that you can not implement a similar behaviour with
> ipfw as it is now, I am just saying that if you want to optimize it, you
> want to reduce the number of test you perform for each rule. What I am
> proposing is one way of doing it (and as a side effect, it makes managing a
> tree like set of rule easier).

Having to managed systems that do it both ways (basically your trying to
go to a Cisco acess-list model) I can say that ipfw actually produces a
smaller set of rules (or at least for what we are doing it does.)  And
a rule set that is easier to figure out what is going on.  What we do
with about 12 rules in ipfw takes me 12 rules per interface on a cisco,
and your scheme would duplicate it to that same 12*interface set, but
run it no faster.  (Yes, I use m4 to write the cisco rule set too so
it's not that big a deal except when your on the router itself trying
to figure out what is going wrong :-()

How about this for a start/stab at syntax for a dispatch command:

ipfw add dispatch interface de0=10000,de1=20000,ed0=30000
# Note we fall pass the above rule if no interface match
ipfw add dispatch direction input=2000,output=3000

# I don't know that we could ever fall past this rule, perhaps a
# host originated packet could? Or if output or input was left off.

ipfw add dispatch protocol tcp=5000,udp=7000,ospf=50000,2=60000
# Fall pass this rule if protocol does not match any in list

We actually do that now using skipto rules, but this should reduce
the number of comparisons that would need done, and take advantage
of things being in registers instead of reloaded from memory as
it steps over the rules due to subroutine calls/etc.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)               rgrimes@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001071938.LAA12079>