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
>