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>