Subject: On the performance of ipfilter
To: None <tech-kern@netbsd.org>
From: David Howland <metalliqaz@fastmail.fm>
List: tech-kern
Date: 04/05/2005 19:08:13
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