Hi, On Monday 30 January 2006 14.14, jamal wrote: [...] > > To put it simple: I don't think PF_KEY is worth the hassle unless > > someone comes up with an open source software utilizing that interface. > > I agree. And if you look at something like sasyncd, it is obvious you > dont need it if what you want to achieve is failover. Infact you dont > need racoon in some cases at all (example this could be done for manual > setup as well). > > In the case you do use racoon, the question is ISAKMP SAs; how do you > fail those over? i.e how do you keep racoon-master and racoon-slave > synced - one idea could be to make sure the cookies are synced. I know > in your work you were doing something with racoon - was there anything > of this sort that you did?
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). > > > How expensive are timers these days? Lets handwave a moderately large > > > number of SAs (100K). With this we would have 200K timers as opposed > > > to 100K if we aggregated them. > > > > Of course we could aggregate these timers, this is just a leftover > > from the very first patch. However, this would mean that a more > > fine-grained timing would be necessary for that timer instead of the > > current precision of one second. > > I thought about this after i typed my last email. The more fine grained > the timer, the better the failover time. The SA expiry timers dont need > anything more than 1 sec granularity (infact anything lower than 60 > seconds will be considered strange) > > > Which is of course not a problem, just makes the patch a bit more > > intrusive. > > 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). 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. > > One more thing: whether or not this timer is necessary really depends > > on how the sync daemon uses these events. The most simple trick of > > simply adding a large-enough constant to the sequence numbers of > > outgoing packets after failover does not take advantage of this > > feature. Of course if someone comes up with a more exact way of > > handling failover cases, then those additional update messages could be > > useful. > > The timer allows for more exact values. IOW, if you use the timer and > you dont loose any events you can _guarantee_ exact numbers; with > padding the replay it becomes: > a) if you make it small more of how lucky you are in choosing a good > padding or > b) dropping a substantial amount of packets if you use brute force and > make it large. > > 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. :) -- Regards, Krisztian Kovacs - 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
