[Openswan dev] Small optimisation for lots of interfaces
Paul Wouters
paul at xelerance.com
Wed Nov 23 19:07:10 CET 2005
On Wed, 23 Nov 2005, D. Hugh Redelmeier wrote:
> | It seems the ifconfig is the slow part (all kernel time too).
>
> You've certainly demonstrated that.
What is the speed of 'ip addr' on that same machine? I wonder if this
is due to 'ifconfig' being a legacy command on Linux. It might get
translated internally into the appropriate 'ip' command.
We have been slowly moving away from commands like 'ifconfig' and 'netstat'
in favour of the highly obscure, badly documented, but years old 'ip' command.
> | > I'd actually expect some of the code in Pluto for discovering
> | > interfaces to be a worse problem when there are a lot of interfaces.
> |
> | Absolutely, I am sure it does.
And it doesn't work properly on BSD either, but hopefully that has been fixed
now. (Though I"m running into weird linking errors with respect to "_assert"
now that I first need to resolve.
> | I would be interested in others experiences with large tunnel counts
> | using OpenSwan. I have run over 1000 simple tunnels between two hosts
> | using freeswan (ie., single SA for all tunnels), but pluto seems to get
> | unstable with much over 200 truly independant tunnels. Has any one else
> | has this experience ?
We have benchmarked openswan about a year and a half ago, and it worked
with over a thousand tunnels.
> This was a conscious choice. "Premture optimization is the root of all
> evil." But when optimization is needed, it is time to do it.
:)
> The most infamous performance problem is in the startup scripts: n**2
> in the number of connections. Henry was going to fix the sh/awk/etc
> script to make it linear but did not get done. There are
> work-arounds. One is a C-based startup program that does not suffer
> from this.
But has not been updated to completely replace the scripts, though we
want to get rid of the scripts.
> BTW, I'd be interested in a thumbnail description of a deployment that
> uses so many tunnels.
I think they are testing, but in general an l2tpd setup for Windows/MacOSX
roadwarriors would do this.
Paul
More information about the Dev
mailing list