Olla, On Mon, 2006-30-01 at 15:33 +0100, KOVACS Krisztian wrote: > On Monday 30 January 2006 14.14, jamal wrote: [..] > We implemented partial ISAKMP SA synchronization in racoon. That way the > cookies, the shared secrets, etc. were synchronized to the slaves, so that > after failing over the new master could even do a phase2 exchange using the > previously negotiated shared secret. In this case a PF_KEY interface is a > good thing because that way you can have racoon > > a) set up the desired event parameters for the SAs (no need to use the > sysctl-controlled global default setting) > > b) do the IPSEC SA synchronization as well, utilizing the already existing > framework for master-slave communication (which is necessary for ISAKMP SA > synchronization anyway). >
Unfortunately this would also mean dependency on racoon. Is there any other way to do it without having to change racoon? example the phase1 scripts or racoonctl? It seems to me that the only useful runtime parameter really - dont know how you would extract this without changing racoon - is peer/local cookies, no? From that one should be able to generate the SAs. > > true although i am still curious if it may be worth the complexity of > > having a single timer - the only reason i can see for aggregation is for > > perfomance reasons. > > Exactly, that's what I was trying to say. Although if you have a lot of > SAs the memory needed by an additional timer_list may be significant (about > 48 bytes per SA on 64 bit architectures if my memory serves me well). > So about 40M for every 100K rules - Dont care really these days for that kind of RAM as long as performance is not impacted. > BTW, did anyone do any testing with such a high amount of SAs in place? I > would be seriously interested in the results, especially if some user-space > KM is involved as well. I only have some limited (lab environment) > experience with racoon, which is unable to handle more than a couple > hundred SAs when running on Linux. I am planning to go to at least 100K SAs ;-> I am also quiet curious. So far i have stopped at about 100. > > The trick of padding the replay values on the backup node could still be > > used in addition to the timer but only a small padding is needed. > > In any case, this mechanism is still needed/valuable. > > Indeed, but this value depends on whether or not the user-space is clever > enough to use it. Let's suppose it will be. :) I do in the code i am testing with at the moment. I havent been testing a lot of corner cases - and so far havent needed any padding; but will let you know how it goes. In any case, lets agree we need it. Whoever feels brave enough to do without could. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
