On 24 nov 2006, at 13.12, Brian Candler wrote:
...
Time(s)  Num flows
-------  ---------
   10      606
   20      976
   30     1286
   40     1384
   50     1768
   60     1946
   70     1946 ..

And there it stops, never reaching 2000 (in+out).

But I find the following in /var/log/messages:

Nov 24 11:12:45 gw isakmpd[32720]: pf_key_v2_set_spi: UPDATE: No such process
Nov 24 11:12:45 gw last message repeated 26 times

1946 + 27*2 = 2000, so that's where the missing flows have gone. For some reason some of them are not known; maybe some earlier messages to the kernel
were silently dropped?

This particular part of the IKE implementation works something like the following:

1. start a negotiation (here: start 1000 negotiations simultaneously)
2. each negotiation starts by reserving a SPI value (for every proposal) in the kernel, the SPI is a 32-bit number but has to be unique. If you do debug logging, you'll see a number of "GETSPI" calls here.
3. isakmpd starts to send out IKE packets to the other host(s)
4. the other side responds, and assuming everything is ok one proposal (per negotiation) is selected 5. the selected SPI (or "larval" SA state) on the local system is updated with the keying material, timeouts etc - i.e the "real" SA is finalized

This continues until all negotiations are complete -- however there is a limit on how long this "larval" SA lives in the kernel... as you may guess it's 60 seconds. (The idea being if a negotiation has not completed in 60 seconds something has probably failed.)

Since the hosts seems to be a bit slow in running IKE negotiations, you hit the 60 second limit before all negotiations are complete, all remaining "larval" SAs are dropped and when isakmpd tries to "update" them into real SAs this of course fails. ("No such process" approx means "no SA found" here.)

/H

PS
When I tried between two ~700Mhz P-III machines a while back, setting up 4096 (or was it 8k) SAs was no problem. Another developer had a scenario setting up 40960 SAs over loopback on his laptop -- mainly a test of kernel memory usage, but he did not hit the 60s larval-SA time limit there either.

Reply via email to