Date: Wed, 26 Oct 2011 11:39:19 -0700 From: Julian Elischer <julian@freebsd.org> To: Karim <fodillemlinkarim@gmail.com> Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw rule processing performances Message-ID: <4EA853D7.4010305@freebsd.org> In-Reply-To: <4EA85168.5020103@gmail.com> References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> <CAHu1Y71Lf8=x3=S8cf__aT2fxyv6eX_EBqZvybgzwi9Q%2BSfzRQ@mail.gmail.com> <4EA85168.5020103@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/26/11 11:28 AM, Karim wrote:
> 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?
read up on all the things you can do with tablearg.. sometimes a
single table can replace dozens of rules.
>
> Regards,
>
> Karim.
> _______________________________________________
> 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"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EA853D7.4010305>