On Wed, 2010-11-24 at 10:48 +0100, Joerg Kurlbaum wrote: > Package: linux-2.6 > Version: 2.6.32-27 > Severity: normal > Tags: squeeze > > When using the squeeze kernel (2.6.32 on amd64), the performance for > IPSec tunnels that also need SNAT is very bad. > > I'm using OpenSWAN with shorewall (but that doesn't really matter, i think) > > I have several tunnels configured to do FIRST SNAT to a certain IP when > packets come from our LAN that should go into the tunnel. > > Using this configuration the performance on the tunnel is about 300 Kb/s > when copying large files. > A test configuration without SNAT is capable of about 10 MB/s, with the > same settings for IPSec. That's terrible! > While transferring data over the tunnel, the number of software interrupts > raises (up to 100% in top) and slows down all other (non-IPSec) connections. I doubt that there is a higher *number* of software interrupts. It is simply that network protocol processing is done in software interrupt handlers, and this takes more time. > The machine hardware used, is more than capable for the IPSec traffic > (quad-core XEON CPU). > > I had reported this problem to the shorewall developers and they couldn't > reproduce, but used different linux kernels. > > As a test i installed another linux kernel (2.6.36) and the problem was gone. > I used the config from the Debian kernel (2.6.32) and just answered to new > configuration questions. > > The relevant thread on the shorewall list is here (more information): > http://sourceforge.net/mailarchive/forum.php?thread_name=20101015103504.GJ4773%40kropotkin.neuland-bfi.de&forum_name=shorewall-users > > Since the 2.6.32 kernel is the long term supported kernel for the next > debian release, the problem described briefly above should be known to the > developers. Right. > I think the problem raises only for special configurations. Some combination > of NIC and Kernel. It might be, but I don't see any obviously related changes in bnx2 between versions 2.6.32 and 2.6.36. > We haven't had this problem before (even with slower hardware) and are not having > it with the new 2.6.36 kernel. Could you test some of the intermediate Debian kernel versions from <http://snapshot.debian.org/package/linux-2.6/>, to help me work out when and how this got fixed? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Description: This is a digitally signed message part