Date: Tue, 29 Nov 2011 16:59:02 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Eugene Grosbein <eugen@grosbein.net> Cc: "Mikhail T." <mi@aldan.algebra.com>, net@freebsd.org Subject: Re: natd slow, eats up an entire CPU... Message-ID: <20111129153427.K94374@sola.nimnet.asn.au> In-Reply-To: <20111128172204.GA28718@rdtc.ru> References: <201111272043.pARKh9rZ047643@narawntapu.narawntapu> <20111128052758.GA23803@rdtc.ru> <4ED3C114.3070200@aldan.algebra.com> <20111128172204.GA28718@rdtc.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Nov 2011 00:22:04 +0700, Eugene Grosbein wrote: > Cc: eivind@dimaga.com, cm@linktel.net, archie@whistle.com, > brian@awfulhak.org, suutari@iki.fi, net@freebsd.org, > Eugene Grosbein <eugen@grosbein.net> I've trimmed ccs except net@, feel free to re-add if desired. > On Mon, Nov 28, 2011 at 12:12:52PM -0500, Mikhail T. wrote: > > > >Do not use natd, use ipfw nat instead - it uses the same libalias > > >but completely in kernel and avoids gigantic natd overhead. > > I guess, I'll have to research this new method... But I don't recall this > > being a problem with FreeBSD-7.x -- are there some known regressions in > > natd from 8.x? I'm not sure, I recall seeing another problem apparently similar not long ago (100% on one CPU for natd) but can't find it now, and am not sure it turned out to be a natd problem or a config issue. Anyway, if you update to ipfw nat and the issue goes away, you'd know soon enough. > I do not know since there is no reason in using natd with 8.2-STABLE > where it supports nearly all natd's features including multiple > NAT instances and shared translation tables. Yes. There are still a couple of issues regarding rc.firewall 'simple' and the /etc/rc.d scripts to do with natd vs ipfw nat, especially where both are enabled, that I offered patches for in these: http://lists.freebsd.org/pipermail/freebsd-ipfw/2011-January/004500.html http://lists.freebsd.org/pipermail/freebsd-ipfw/2011-January/004509.html but due to health, relocation and slackness issues, never followed up in the correct manner re PRs. I see there've been no subsequent changes to these scripts on cvsweb, so you (Mikhail) could apply these for your basis of the rc.firewall 'simple' ruleset, but it's likely enough to be sure to remove natd_enable from rc.conf when adding firewall_nat_enable, and using the ipfw nat syntax for open and client as an example. If you find the ipfw nat section of ipfw(8) a little sparse, you can still use natd(8) as a reference, modulo the slight changes in terms. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111129153427.K94374>