From owner-freebsd-questions@FreeBSD.ORG Mon Apr 12 10:45:40 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A1216A4CE for ; Mon, 12 Apr 2004 10:45:40 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 118F743D39 for ; Mon, 12 Apr 2004 10:45:40 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id ECA191A0; Mon, 12 Apr 2004 11:45:36 -0600 (CST) Date: Mon, 12 Apr 2004 11:45:36 -0600 From: Tillman Hodgson To: FreeBSD Questions Message-ID: <20040412174536.GB56037@seekingfire.com> References: <20040412143042.GA67287@happy-idiot-talk.infracaninophile.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040412143042.GA67287@happy-idiot-talk.infracaninophile.co.uk> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.6i Subject: IPsec performance impact [was: Re: OS X and FreeBSD: What could be a good setup] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 17:45:40 -0000 On Mon, Apr 12, 2004 at 03:30:42PM +0100, Matthew Seaman wrote: > If you're that worried about WEP not being secure enough, you could > wrap the NFS connections in ipsec instead. It might have a bit of a > performance impact though. I'm a big fan of running IPsec over wireless connections. But I was shocked but the performance impact IPsec has. I collected some numbers netperf recently, shown below. Notes: * Athena (the household server) is a Celeron 900 wiith 256MB of RAM and a 'bge' gigE NIC running -STABLE * Caliban is a UltraSPARC 360 with 384MB of RAM and a 4-port 'hme' NIC running -CURRENT * Coyote is a Celeron 400 with 128MB of RAM and a 'rl' NIC * In my case racoon sets up 3des for me -- note that this isn't a CPU friendly scheme, though it is very likely to be compatible with other platforms * I run a seperate VLAN for IPsec traffic, so all IPsec traffic numbers include an assumed that they were also VLAN'ed * The IPsec'd IP of a host has it's own name in DNS, simply it's regular name prefixed with "sec". * I ran netserver (from netperf) on Athena and tested it for UDP_STREAM (a nice NFS-like test) over both the IPsec VLAN and the regular unencrypted link (non-VLAN'ed) Results: [root@caliban /usr/local/netperf]# ./netperf -t UDP_STREAM -H secathena Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 715 0 5.27 42080 10.01 713 5.25 [root@caliban /usr/local/netperf]# ./netperf -t UDP_STREAM -H athena Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 13004 13160 95.81 42080 10.01 12778 94.14 [root@coyote /usr/local/netperf]# ./netperf -t UDP_STREAM -H athen Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.00 10452 0 77.02 42080 10.00 10452 77.02 [root@coyote /usr/local/netperf]# ./netperf -t UDP_STREAM -H secathena Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.00 1789 0 13.18 42080 10.00 1789 13.18 During the tests the clients were CPU-bound. To put it bluntly, the performance impact is non-trivial. That's to be expected, and at the slower speeds of wireless networks it's more likely that more modern CPUs will be able to keep up. I wouldn't want to play a high-bitrate video file over an IPsec connection, though, as the video app and IPsec will starve each other of CPU cycles. -T -- The mere sense of living is joy enough. Emily Dickinson