From: Brian B. <bbu...@qu...> - 2004-04-22 15:08:26
|
>>>the test machines are virtual machines, and the host is really loaded, so >>>i'm wondering if the SA takeover doesn't use more ressources, that can't >>>be given by the host. >>>maybe that's a performance problem between racoon and the kernel ? >>> >>> >>> >>> >>36 seconds should be plenty of time, so I wouldn't think this would be a >>problem even if the host is heavily loaded. >> >> > >i think of a performance problem at t2, when the old SAs are removed; not >between t1 and t2; for example, the kernel might need a bit more >ressources to update the SAD, and these ressources can't be allowed quickly >because of heavy load; that would be strange anyway ... > > > Sorry, you're right about that. I think the question is what does the kernel do when it is trying to send using an SA and discovers that it is expired? I would have assumed it would delete the old SA and look for the new one when sending, but I wouldn't think this would take so long. It should just delete the old one and then do single hash lookup for the new SA. I'm not sure if that is in fact what it is doing (ie. I have not looked at the code close enough) though so don't take my word for this. I do think it is probably a kernel issue though. Does anyone disagree? >>>in case that can help, here's the setup + the logs; everything seems >>>normal except that racoons logs 2 times that the same SA is expired (see >>>T2) >>> >>> >>> >>> >>The two expires are because there are two different IPsec SAs, one for >>each direction. >> >> > >no, that's for the same SAs (see T1's log too); >that may be normal though (one log at the soft limit, and another identical log at the hard limit) > > Sorry, I misinterpreted which two you were referring to. Yes, it is normal to have two expires, one for the soft lifetime and one for the hard lifetime. The debug logs of racoon don't indicate which one it received, but T1 is the soft and T2 is the hard. Brian |