Subject: Re: On the performance of ipfilter
To: David Howland <metalliqaz@fastmail.fm>
From: Gene ENonymous <yancm@sdf.lonestar.org>
List: tech-kern
Date: 04/05/2005 21:48:06
Hi David,

I am not an expert by any means, but I run almost your exact same set up!

My hardware is a P3-300 w/512M and I have no issues at all. Basically
I get the same ping times from my nat box as I do from machines inside...
I'm also running 2.0_stable...

I'll ask the obvious: what rules are you using? I'd like to see your
ipf.conf and your ipnat.conf...

I'm kinda busy, but I would urge you to join both the mailing lists I've
cc'd this message to. ipf has a web archive too.

Best regards,
gene



On Tue, April 5, 2005 6:08 pm, David Howland said:
> I have an awful pesky problem with IPFilter (I think).  First, some
> background:
>
> I use NetBSD in my home as a kind of "household server".  We have mostly
> Windows based desktop and laptop clients, and the NetBSD machine hooks
> up to the cable modem and performs IPF/NAT/http/mail duties.  The
> machine is PIII 500MHz, 512MB, should be plenty for what it does.  It
> has two NICs, both 3Com 3C905B.  It doesn't run X, and besides the basic
> stuff like cron and inetd, all it runs is ssh, apache, smb, ntp,
> sendmail, dhcpd, dnsmasq.  The only time it ever hits the swap is when I
> recompile the OS.
>
> I have these pesky problems with the machine getting laggy or dropping
> packets.  The problem is difficult to fix.  I now believe that the
> problem is with ipfilter.  I'll explain:
>
> Internet access is not "smooth" like it is when using a cheap-o hardware
> router, one of those home Linksys wireless jobs.  Packet loss is a
> problem, and pings spike.  I have eliminated the following causes:
>
> cable modem: plugged directly into a PC, problem disappears
> cable: replaced
> NIC: moved to different slot, replaced with new card of different type
> OS version: problem persists after upgrade to latest 2.0_STABLE
>
> I performed a simple experiment to find the problem:
>
> The PC has two NICs, "outside" and "inside", it acts as a gateway
> between the outside world and our house, with NAT.  From one of the
> client PCs (192.168.0.2) I ping three locations.  The "inside" adapter
> (192.168.0.1), the "outside" adapter (65.x.x.x), and the cable modem
> (hardwired to 192.168.100.1).  All three pings go at the same time.  I
> set them to ping forever until I stop it.  In windows, the ping tool
> actually shows a "request timed out" message when a ping doesn't come
> back, so I can just sit back and watch the three windows for these
> timeouts.  There is no other traffic, except perhaps the occasional
> keep-alive packets from instant messenger.
>
> The pings to the "inside" and "outside" adapter never show anything but
> <1ms ping time and never drop packets.  The cable modem ping is less
> than desirable.  Whats worse is that I can cause packet loss to occur.
> I have a cron script run every 5 minutes for MRTG.  When this happens,
> it _always_ drops some packets (even when nice'd).  This is not the only
> time when packets are dropped, and I have a hunch that other times are
> due to other processes going on processor.
>
> It can't be the driver, the "inside" adapter never flinches.  It
> probably isn't option GATEWAY, because the "outside" adapter never
> flinches.  However, to go outside the box to the cable modem, it has to
> go through ipf/ipnat.
>
> So, it seems to me that there is perhaps some performance problem with
> IPFilter in the kernel?  I lack the know-how to perform any other tests
> to confirm this.  How is it that userland processes can be allowed to
> trip up the in-kernel packet forwarding?  All I have to do is start a
> big make (eg build.sh distribution) and response time goes to hell.  I
> am surprised to find that this kind of thing hasn't been reported by
> anyone else.
>
> I use a slimmed-down kernel.  Problem persists with GENERIC kernel (plus
> option GATEWAY).  Problem persists with and without ALTQ.
>
> Later this week, I am going to replace the entire machine with a
> different one in a last ditch effort to fix it.  If that works, I'll say
> so on the mailing list.
>
> So, sorry for the long email.  Any experts here on IPFilter or
> networking in general that have suggestions?  Thanks in advance for any
> help.  Please CC my email, I'm not subscribed to the list.
>
> Thanks,
> -d
>