Subject: On the performance of ipfilter
To: None <email@example.com>
From: David Howland <firstname.lastname@example.org>
Date: 04/05/2005 19:08:13
I have an awful pesky problem with IPFilter (I think). First, some
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
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
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.