[Openswan dev] Small optimisation for lots of interfaces

[David McCullough]

Jivin Paul Wouters lays it down ...
> 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.

2 seconds in case you missed it in the other email.

> 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 have to agree on the doc.

> > | > 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.

Ok, we have a 'C' based tool that we originally wrote to run on our
small footprint devices as we could accomodate a full shell+tools.

It's and older freeswan implementation of whatthe shell scripts do,
and I mean,  it does what the shell scripts do only in 'C'.  There
are a couple of small optimisations in there to help,  but it is
effectively just a 'C' pattern/text parser.

Now we have started looking at OpenSwan and our devices are bigger and
have MMU's,  we were just going to run with the scripts and make them do
what we need and ditching the 'C' version.

So if a 'C' implementation of the scripts is something  that might be
cosidered an improvement,  we would definately be happy to put it out
there.  It needs updating to the current openswan ifmond.conf options
though.  It's not beautiful,  but it is self contained.

> > 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.

A combination of both,  we test the limits but we also have customers
setting up rather large numbers of tunnels as well.

Cheers,
Davidm

-- 
David McCullough, davidm at cyberguard.com.au, Custom Embedded Solutions + Security
Ph:+61 734352815 Fx:+61 738913630 http://www.uCdot.org http://www.cyberguard.com