Date: Wed, 26 Oct 2011 14:28:56 -0400 From: Karim <fodillemlinkarim@gmail.com> To: freebsd-ipfw@freebsd.org Subject: Re: ipfw rule processing performances Message-ID: <4EA85168.5020103@gmail.com> In-Reply-To: <CAHu1Y71Lf8=x3=S8cf__aT2fxyv6eX_EBqZvybgzwi9Q%2BSfzRQ@mail.gmail.com> References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> <CAHu1Y71Lf8=x3=S8cf__aT2fxyv6eX_EBqZvybgzwi9Q%2BSfzRQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11-10-25 11:30 PM, Michael Sierchio wrote:
> On Tue, Oct 25, 2011 at 6:43 PM, Julian Elischer<julian@freebsd.org> wrote:
>
>> I find that the structure of teh ruleset has a huge affect on the cpu usage.
>>
>> for example I immediately split incoming and outgoing packets apart and send
>> them to different groups of rules.
>> I also have different groups of rules for internal and external rules.
>> so my rulesets usually start with:
>>
>> skipto 1000 all from any to any in recv ${OUTSIDE_INTERFACE}
>> skipto 2000 all from any to any in recv ${INSIDE_INTERFACE}
>> skipto 3000 all from any to any out xmit ${OUTSIDE_INTERFACE}
>> skipto 4000 all from any to any out xmit ${INSIDE_INTERFACE}
>> allow all from any to any via lo0
>> drop all from any to any
>>
>> I also try use tables whenever possible.
> I've found the same to be true, and use a scheme similar to what
> Julian describes - I have rules grouped based on interface and
> direction. Having larger tables and fewer table lookups is faster, in
> my experience - such that I have a big block list (~20,000 nets) and a
> small whitelist (~20 nets) ...
>
> - M
> _______________________________________________
> freebsd-ipfw@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
Hi,
Thanks to everyone who contributed I will try to digest all the
information and see how I can improve my ruleset. Couple of points I've
identified so far:
1) As Luigi's article points out route lookups are expensive due to
locking (I am using verrervpath ...)
2) ipfw_nat performance impact is an unknown at the moment (?)
3) Using mbuf tags (IPFW_TAG) is costly (so is ALTQ due to pf_tags and
FORWARD_IP due to m_tag). In other words policy based routing is costly.
4) Its preferable to split incoming and outgoing packets apart as early
as possible in the ruleset
Anything else I'm missing?
Regards,
Karim.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EA85168.5020103>