Date: Thu, 4 Oct 2007 18:19:34 +0200 From: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> To: freebsd-net@freebsd.org Subject: Re: Racoon 0.7 on FreeBSD 6 with a lot of VPN tunnels Message-ID: <20071004161933.GA5406@zen.inc> In-Reply-To: <4704F388.5080506@xs4all.nl> References: <46FBB7BC.3010301@xs4all.nl> <4704F388.5080506@xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 04, 2007 at 04:07:04PM +0200, Seth Mos wrote: > Hello Yvan, Hi. > I have tested the suggested workaorund in pfkey.c by raising the ceiling > to 768kbytes from 128. > > I also raised the limit in the socketvar.h in FreeBSD 6 Stable from the > default 128kbytes to 768kbytes. > > Any higher values then 768kbytes result in a integer overflow and > prevents a build world of FreeBSD 6. Possible. I used to set up higher values a long time ago (with a fixed sbspace() macro in the kernel) but I noticed that some long are now ints. > The critical hit is around 120~130 active tunnels out of a configuration > of 390. After his critical ceiling the racoon keeps getting stuck in > sbwait after about 1 or 2 minutes after starting. I know we could get up to ~200-300 tunnels by "just" increasing the socket's buffer on old versions. > A good way to test this with less tunnels is sending reload signals to > the racoon processes which forces a lot of pfkey traffic. Which will > eventually trigger the truncated pfkey socket buffer problem. Don't worry, I know how to reproduce the problem :-) > The real problem is that racoon 0.6.7 and racoon 0.7 do not correctly > handle a truncated socket. Instead of retrying the operation they either > idle in sbwait and waiting for something that will never arrive or run > away on a buffer which does not exist anymore. I know 2 solutions: - Change the PFKey interface to avoid high number of messages. We did that for our appliances, but if this is perfect for our specific usage, this patch was not designed for general usage (we have specific buffer sizes, some structs in pfkeyv2.h have been changed, etc...). - Change the way racoon handles the PFKey messages: perhaps we could improve things by just filling an userland buffer (or a chain list, or something else) when we get such PFKey messages, so they would be removed quickly from the socket's buffer, then only parse our userland buffer/list once we know we got all the entries. I'll have a quick look to see if the second would be easy to implement, without significant drawbacks, of course. Yvan. -- NETASQ http://www.netasq.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071004161933.GA5406>