From: ythhaj k. <ka3...@go...> - 2007-07-12 21:20:28
|
Hello Let me begin by first saying that my IPsec network actually does work. I get encrypted traffic flowing nicely once everything is up and running, which the issue I'm here to ask for advice on. I'm using tunnel mode between a bunch of gateway devices. There are two kinds, ones that protect servers and ones that protect clients; they come in equal numbers. The only communication that is allowed is between server and client, this is enforced by both network routing and more importantly by the racoon configuration. If I only have a few devices and write ipsec.conf to define a few tunnels then racoon is ready to process traffic immediately after being run. That is, if I begin pinging from a server to a client at the same time as I run racoon on both gateways I immediately see ISAKMP main mode followed by quick mode and the ESP protected pings follow quickly. The IPsec gateway devices are fairly slow embedded boards so the negotiation takes approx 2 to 3 seconds. Details are: 266MHz PowerPC, 128MB ram, compressed OS image flash storage, linux kernel 2.6.21, debian based distribution with ipsec-tools 0.6.6. The problem is when I have a lot of tunnels defined in my ipsec.conf, say 250. In this case it takes about 30s between running racoon and first seeing the ISAKMP packets. The system just appears to have frozen during this time. When the ISAKMP packets do appear, everything runs as quickly as before, taking 2 or 3 seconds to complete the negotiation. If I run racoon and then wait for 30s before trying to ping across the network the negotiation happens immediately. If I reduce the number of defined tunnels there is an exponential decay in this delay time. I have run racoon in debug mode and generated a 25MB log file!!!! A tiny part of which I will include at the end of this email. As far as I can tell racoon seems to check every possible tunnel vs every other possible tunnel. It does this more than once in slightly different ways. The output from these checks is what takes up most of the 25MB. The start time in debug mode (not foreground mode, log file dumped to ramdisk file) was about 3m17s. So my question is how do I remove this 30s 'freeze' time from racoon starting up? I have tried manually overwriting the ipsec-tools files with the ones from the debian 0.6.7 ppc version but I had library clashes (this trick worked with other binaries so I thought it was at least worth a try). I can ask our system suppliers to rebuild the OS image with 0.6.7 or later but I'd like to know if that will solve this problem before we commit to the extra contract cost. Is there anything which can speed this up (ram vs speed tradeoff)? Is there any way to turn off this checking of multiple tunnels? Is there more information I can supply to help anyone solve this problem? Cheers RF Edited section of debug output follows, edited section of ipsec.conf appears afterwards: 2007-05-24 00:02:23: INFO: @(#)ipsec-tools 0.6.6 ( http://ipsec-tools.sourceforge.net) 2007-05-24 00:02:23: INFO: @(#)This product linked OpenSSL 0.9.8c 05 Sep 2006 (http://www.openssl.org/) 2007-05-24 00:02:23: DEBUG: call pfkey_send_register for AH 2007-05-24 00:02:23: DEBUG: call pfkey_send_register for ESP 2007-05-24 00:02:23: DEBUG: call pfkey_send_register for IPCOMP 2007-05-24 00:02:23: DEBUG: reading config file /etc/racoon/racoon.conf 2007-05-24 00:02:23: DEBUG: DN: C=**edited** 2007-05-24 00:02:23: DEBUG: DN: O=**edited** 2007-05-24 00:02:23: DEBUG: DN: OU=**edited** 2007-05-24 00:02:23: DEBUG: DN: CN=**edited** 2007-05-24 00:02:23: DEBUG: Parsed DN: C=**edited**, O=**edited**, OU=**edited**, CN=**edited** 2007-05-24 00:02:23: DEBUG2: lifetime = edited 2007-05-24 00:02:23: DEBUG2: lifebyte = edited 2007-05-24 00:02:23: DEBUG2: encklen=edited 2007-05-24 00:02:23: DEBUG2: p:1 t:1 2007-05-24 00:02:23: DEBUG2: 7(7) 2007-05-24 00:02:23: DEBUG2: edited 2007-05-24 00:02:23: DEBUG2: edited 2007-05-24 00:02:23: DEBUG2: edited 2007-05-24 00:02:23: DEBUG2: 2007-05-24 00:02:23: DEBUG: compression algorithm can not be checked because sadb message doesn't support it. 2007-05-24 00:02:23: DEBUG2: parse successed. 2007-05-24 00:02:23: DEBUG: open /var/run/racoon/racoon.sock as racoon management. 2007-05-24 00:02:23: DEBUG: my interface: 127.0.0.1 (lo) 2007-05-24 00:02:23: DEBUG: my interface: 172.17.1.1 (eth1) 2007-05-24 00:02:23: DEBUG: my interface: 172.16.1.254 (eth0) 2007-05-24 00:02:23: DEBUG: configuring default isakmp port. 2007-05-24 00:02:23: DEBUG: 3 addrs are configured successfully 2007-05-24 00:02:23: INFO: 172.16.1.254[500] used as isakmp port (fd=6) 2007-05-24 00:02:23: INFO: 172.16.1.254[500] used for NAT-T 2007-05-24 00:02:23: INFO: 172.17.1.1[500] used as isakmp port (fd=7) 2007-05-24 00:02:23: INFO: 172.17.1.1[500] used for NAT-T 2007-05-24 00:02:23: INFO: 127.0.0.1[500] used as isakmp port (fd=8) 2007-05-24 00:02:23: INFO: 127.0.0.1[500] used for NAT-T 2007-05-24 00:02:23: DEBUG: get pfkey X_SPDDUMP message 2007-05-24 00:02:23: DEBUG: get pfkey X_SPDDUMP message 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.2.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c3f0: 172.18.1.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: get pfkey X_SPDDUMP message 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.3.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c3f0: 172.18.1.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.3.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c630: 172.18.2.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: get pfkey X_SPDDUMP message 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.4.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c3f0: 172.18.1.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.4.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c630: 172.18.2.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.4.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c870: 172.18.3.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: get pfkey X_SPDDUMP message 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.5.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c3f0: 172.18.1.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.5.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c630: 172.18.2.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.5.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c870: 172.18.3.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.5.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008cab0: 172.18.4.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: get pfkey X_SPDDUMP message 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.6.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c3f0: 172.18.1.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.6.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c630: 172.18.2.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.6.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008c870: 172.18.3.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.6.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008cab0: 172.18.4.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: sub:0x7fa3d9f8: 172.18.6.0/24[0] 172.16.1.0/24[0] proto=any dir=in 2007-05-24 00:02:23: DEBUG: db :0x1008ccf0: 172.18.5.0/24[0] 172.16.1.0/24[0] proto=any dir=in repeated many times from 172.18.6.x (above) through to 172.18.254.x then repeated again in slightly different ways, seeming to compare each possible tunnel with each other possible tunnel again and again. =========================================================== ipsec.conf #!/usr/sbin/setkey -f # Flush the SAD and SPD flush; spdflush; spdadd 172.16.1.0/24 172.18.1.0/24 any -P out ipsec esp/tunnel/172.17.1.1-172.17.1.2/require; spdadd 172.18.1.0/24 172.16.1.0/24 any -P in ipsec esp/tunnel/172.17.1.2-172.17.1.1/require; spdadd 172.16.1.0/24 172.18.2.0/24 any -P out ipsec esp/tunnel/172.17.1.1-172.17.2.2/require; spdadd 172.18.2.0/24 172.16.1.0/24 any -P in ipsec esp/tunnel/172.17.2.2-172.17.1.1/require; # many more definitions summarised by: spdadd 172.16.1.0/24 172.18.x.0/24 any -P out ipsec esp/tunnel/172.17.1.1-172.17.x.2/require; spdadd 172.18.x.0/24 172.16.1.0/24 any -P in ipsec esp/tunnel/172.17.x.2-172.17.1.1/require; # and finally this tunnel: spdadd 172.16.1.0/24 172.18.254.0/24 any -P out ipsec esp/tunnel/172.17.1.1-172.17.254.2/require; spdadd 172.18.254.0/24 172.16.1.0/24 any -P in ipsec esp/tunnel/172.17.254.2-172.17.1.1/require; |
From: Joy L. <la...@au...> - 2007-07-13 15:57:54
|
On Thu, 2007-07-12 at 22:20 +0100, ythhaj khkci wrote: > Hello > > Let me begin by first saying that my IPsec network actually does work. > I get encrypted traffic flowing nicely once everything is up and > running, which the issue I'm here to ask for advice on. > > I'm using tunnel mode between a bunch of gateway devices. There are > two kinds, ones that protect servers and ones that protect clients; > they come in equal numbers. The only communication that is allowed is > between server and client, this is enforced by both network routing > and more importantly by the racoon configuration. > > If I only have a few devices and write ipsec.conf to define a few > tunnels then racoon is ready to process traffic immediately after > being run. That is, if I begin pinging from a server to a client at > the same time as I run racoon on both gateways I immediately see > ISAKMP main mode followed by quick mode and the ESP protected pings > follow quickly. The IPsec gateway devices are fairly slow embedded > boards so the negotiation takes approx 2 to 3 seconds. Details are: > 266MHz PowerPC, 128MB ram, compressed OS image flash storage, linux > kernel 2.6.21, debian based distribution with ipsec-tools 0.6.6. > > The problem is when I have a lot of tunnels defined in my ipsec.conf, > say 250. In this case it takes about 30s between running racoon and > first seeing the ISAKMP packets. The system just appears to have > frozen during this time. > When the ISAKMP packets do appear, everything runs as quickly as > before, taking 2 or 3 seconds to complete the negotiation. If I run > racoon and then wait for 30s before trying to ping across the network > the negotiation happens immediately. > If I reduce the number of defined tunnels there is an exponential > decay in this delay time. > > I have run racoon in debug mode and generated a 25MB log file!!!! A > tiny part of which I will include at the end of this email. As far as > I can tell racoon seems to check every possible tunnel vs every other > possible tunnel. It does this more than once in slightly different > ways. The output from these checks is what takes up most of the 25MB. > The start time in debug mode (not foreground mode, log file dumped to > ramdisk file) was about 3m17s. First, your policy is added into the kernel's SPD. When you start racoon, the kernel will send to racoon all its SPD entries. racoon also keeps an spd database of sorts in its userspace. For each SPD entry it receives from the kernel, racoon searches its database first to see if it already exists before adding it. I think this is perhaps what you are seeing those first 30 seconds... Regards, Joy |
From: ythhaj k. <ka3...@go...> - 2007-07-14 08:32:31
|
So if this is partly to do with the kernel then I guess I can't avoid this by using different IPsec userspace software such as Openswan (although we already have good reasons not to use Openswan). 30s does seem a very long time to effectively check whether 254 entries contain any duplicates. It seems from your response that the only way to reduce this start time is to increase the processor speed or separate my network into several different communities which each have a lower number of tunnels defined, but who can't cross-communicate. Thanks for the response. RF First, your policy is added into the kernel's SPD. > When you start racoon, the kernel will send to racoon all its SPD > entries. racoon also keeps an spd database of sorts in its userspace. > For each SPD entry it receives from the kernel, racoon searches its > database first to see if it already exists before adding it. I think > this is perhaps what you are seeing those first 30 seconds... > > Regards, > Joy > > |
From: Scott L. <sl...@sl...> - 2007-07-14 14:14:16
|
ythhaj khkci wrote: > So if this is partly to do with the kernel then I guess I can't avoid > this by using different IPsec userspace software such as Openswan > (although we already have good reasons not to use Openswan). 30s does > seem a very long time to effectively check whether 254 entries contain > any duplicates. > > It seems from your response that the only way to reduce this start time > is to increase the processor speed or separate my network into several > different communities which each have a lower number of tunnels defined, > but who can't cross-communicate. > > Thanks for the response. I refuse to believe that 30 seconds for 254 entries is necessary. This is a bug. But it's hard to say more from the tiny log snippet you've posted. The most useful thing might be if you post an exact configuration that reproduces the delay. A "setkey -PD" might be useful, too, and easier to gather. I'm wondering how many actual policy rules there are. How sure are you about the exponential time? Is it possible it's actually something like O(n^3)? I'd find that a bit easier to believe. What data points have you gathered? > RF > > First, your policy is added into the kernel's SPD. > When you start racoon, the kernel will send to racoon all its SPD > entries. racoon also keeps an spd database of sorts in its userspace. > For each SPD entry it receives from the kernel, racoon searches its > database first to see if it already exists before adding it. I think > this is perhaps what you are seeing those first 30 seconds... But if it's receiving n SPD entries, even with a naive algorithm each search would be O(n), for a total of O(n^2). He's saying that it's taking exponential time - that's O(2^n), and he also said 30 seconds for 254 entries - which seems crazy. With an optimized algorithm, each search could be O(1). (If it's looking for presence of an identical rule, I'd think it could just search a hash table if optimization is necessary.) |
From: ythhaj k. <ka3...@go...> - 2007-07-14 19:16:16
|
I'll post more details on Monday when I get back into work and can look up my notes. But for now I can supply these configurations. On 14/07/07, Scott Lamb <sl...@sl...> wrote: > > I refuse to believe that 30 seconds for 254 entries is necessary. This > is a bug. But it's hard to say more from the tiny log snippet you've > posted. I didn't want to post the full 25MB log. With bzip2 -9 it compresses down to 272k which I could email to those interested, or even to this list if that's OK? The most useful thing might be if you post an exact configuration that > reproduces the delay. racoon.conf is below: ================================== path include "/usr/sbin/racoon"; path certificate "/etc/racoon/certs"; remote anonymous { exchange_mode main; my_identifier asn1dn; peers_identifier asn1dn "C=edited, O=edited, OU=edited, CN=*"; certificate_type x509 "edited.pem" "edited_priv.key"; ca_type x509 "edited.pem"; verify_identifier on; lifetime time 10 min; # edited initial_contact on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm aes; hash_algorithm sha256; authentication_method rsasig; dh_group 2; } } sainfo anonymous { pfs_group 2; encryption_algorithm aes; authentication_algorithm hmac_sha256; lifetime time 10 min; # edited compression_algorithm deflate; } complex_bundle on; ========================================== end of racoon.conf racoon.conf remains unchanged across my deployment size experiments. ipsec.conf I posted before, 'n' goes as high as the number of tunnels. So this is the version of ipsec.conf for the ipsec system with addresses 172.16.1.254/24 and 172.17.1.1/16. This one protects a server. Servers sit in the 172.16.x range, clients in the 172.18.y. range, where x and y are server and client number respectively. Note that where I say server or client I don't necessarily mean a single machine, hence they site within a /24 network but they are considered a single unit for these purposes. =========================== #!/usr/sbin/setkey -f # Flush the SAD and SPD flush; spdflush; spdadd 172.16.1.0/24 172.18.1.0/24 any -P out ipsec esp/tunnel/172.17.1.1-172.17.1.2/require; spdadd 172.18.1.0/24 172.16.1.0/24 any -P in ipsec esp/tunnel/172.17.1.2-172.17.1.1/require; spdadd 172.16.1.0/24 172.18.n.0/24 any -P out ipsec esp/tunnel/172.17.1.1-172.17.n.2/require; spdadd 172.18.n.0/24 172.16.1.0/24 any -P in ipsec esp/tunnel/172.17.n.2-172.17.1.1/require; and so on (for n=1; n<=total_size ; n++) ============================ An example ipsec.conf for the device protecting client number 45 (which would have addresses 172.18.45.254 and 172.17.45.2) would therefore be... ============================ #!/usr/sbin/setkey -f # Flush the SAD and SPD flush; spdflush; spdadd 172.18.45.0/24 172.16.1.0/24 any -P out ipsec esp/tunnel/172.17.45.2-172.17.1.1/require; spdadd 172.16.1.0/24 172.18.45.0/24 any -P in ipsec esp/tunnel/172.17.1.1-172.17.45.2/require; spdadd 172.18.45.0/24 172.16.2.0/24 any -P out ipsec esp/tunnel/172.17.45.2-172.17.2.1/require; spdadd 172.16.2.0/24 172.18.45.0/24 any -P in ipsec esp/tunnel/172.17.2.1-172.17.45.2/require; spdadd 172.18.45.0/24 172.16.m.0/24 any -P out ipsec esp/tunnel/172.17.45.2-172.17.m.1/require; spdadd 172.16.m.0/24 172.18.45.0/24 any -P in ipsec esp/tunnel/172.17.m.1-172.17.45.2/require; etc up to m equals at least 45 as the clients and servers come in equal numbers. (that was constructed from memory rather than copied and pasted so typos are by me) ============================================== A "setkey -PD" might be useful, too, and easier to gather. I'm wondering > how many actual policy rules there are. I'll check that too. This reminds me of a totally separate question. Does setkey -D show the *actual* traffic keys in the lines contaning (in my case) E: aes-cbc and A: hmac-sha256? How sure are you about the exponential time? Is it possible it's > actually something like O(n^3)? I'd find that a bit easier to believe. > What data points have you gathered? I've gathered data points in jumps of 30 or 40 tunnels, from 4 to 254. The numbers are at work so I'll check them and post them on monday. But if it's receiving n SPD entries, even with a naive algorithm each > search would be O(n), for a total of O(n^2). He's saying that it's > taking exponential time - that's O(2^n), and he also said 30 seconds for > 254 entries - which seems crazy. > > With an optimized algorithm, each search could be O(1). (If it's looking > for presence of an identical rule, I'd think it could just search a hash > table if optimization is necessary.) > Yes, it could very well be O(n^2). I'm certain about the 30s figure though. Thanks RF |
From: Matthew G. <mg...@sh...> - 2007-07-14 22:16:20
Attachments:
sainfosort.diff
|
ythhaj khkci wrote: > I'll post more details on Monday when I get back into work and can look > up my notes. > But for now I can supply these configurations. > The sainfo selection code if far from optimal. This is one of the patches I have laying around that you are welcome to try. I should have posted this sooner as it would have been a good 0.7 candidate. Anyhow, it cleans up the sainfo selection process significantly by sorting the entries in order of match priority when they are added to the list. This has several benefits ... 1) greatly simplifies the convoluted sainfo evaluation logic 2) increases the sainfo selection speed ( now a single pass ) 3) gives qualified sainfo higher match priority than semi-anonymous Let me know how this works out for you. -Matthew |
From: Matthew G. <mg...@sh...> - 2007-07-14 22:23:19
Attachments:
sainfosort.diff
|
Matthew Grooms wrote: > Err, here is a bit cleaner version :) -Matthew |
From: VANHULLEBUS Y. <va...@fr...> - 2007-07-16 13:06:20
|
On Sat, Jul 14, 2007 at 05:20:40PM -0500, Matthew Grooms wrote: [....] Hi. > The sainfo selection code if far from optimal. That's true, and your patch is interesting (I'll test it ASAP), but I don't think it's related to the problem explained in this thread. This problems really semms to be related to another "far from optimal" code section: dumping a copy of the SPD in racoon's memory. The first performance problem is the PFKey interface itself, because one message request (SADB_X_SPDDUMP, or something like that) will generate one kernel response per SPD entry (yes....). The second performance problem is the SPD matching code, where each new SPD received from the kernel will be compared against all other SPD entries. This will be a good thing to clean up / speed up that, but I'll have to verify the exact constraints of the SPD list before. And this won't solve the PFKey problem... For that, I guess Linux kernels don't have the problem because they don't really use PFKey interface (well, that's what I understood a long time ago...), and the only solution I have for BSD kernels is a big hack, with a new SADB_X_SPDDUMP_ONEBLOCK (call it as you like) PFKey message, where the userland gives the base address and size of a big memory block, and where the kernel fills all the informations in the memory block. It works, but we still have a problem: setiing up a correct size for the memory block..... Yvan. |
From: Matthew G. <mg...@sh...> - 2007-07-16 17:59:03
Attachments:
sainfosort.diff
|
On 7/16/2007, "VANHULLEBUS Yvan" <va...@fr...> wrote: >On Sat, Jul 14, 2007 at 05:20:40PM -0500, Matthew Grooms wrote: > >Hi. > >> The sainfo selection code if far from optimal. > >That's true, and your patch is interesting (I'll test it ASAP), but I >don't think it's related to the problem explained in this thread. > I noticed there were some issues with the match priority and insertion login. I have attached an updated patch. >This problems really seems to be related to another "far from optimal" >code section: dumping a copy of the SPD in racoon's memory. > Fair enough. Maybe we can hit it with a profiler and see whats up. If I have some time this evening, I will have a peek at it as well. -Matthew |
From: Scott L. <sl...@sl...> - 2007-07-16 18:44:08
|
VANHULLEBUS Yvan wrote: > On Sat, Jul 14, 2007 at 05:20:40PM -0500, Matthew Grooms wrote: > [....] > > Hi. > >> The sainfo selection code if far from optimal. > > That's true, and your patch is interesting (I'll test it ASAP), but I > don't think it's related to the problem explained in this thread. > > This problems really semms to be related to another "far from optimal" > code section: dumping a copy of the SPD in racoon's memory. > > The first performance problem is the PFKey interface itself, because > one message request (SADB_X_SPDDUMP, or something like that) will > generate one kernel response per SPD entry (yes....). Why is that a problem? This is asymptotically insignificant. > The second performance problem is the SPD matching code, where each > new SPD received from the kernel will be compared against all other > SPD entries. > > This will be a good thing to clean up / speed up that, but I'll have > to verify the exact constraints of the SPD list before. > > And this won't solve the PFKey problem... > For that, I guess Linux kernels don't have the problem because they > don't really use PFKey interface (well, that's what I understood a > long time ago...) Linux kernels use the same interface as BSD ones. This problem was encountered on Linux, not BSD. >, and the only solution I have for BSD kernels is a > big hack, with a new SADB_X_SPDDUMP_ONEBLOCK (call it as you like) > PFKey message, where the userland gives the base address and size of a > big memory block, and where the kernel fills all the informations in > the memory block. > > It works, but we still have a problem: setiing up a correct size for > the memory block..... The time is going into racoon2's O(n^2) algorithm, so I'm not sure why you think an interface change would solve it. And I have no idea why you would violate the clean message-based protocol like that. Best regards, Scott -- Scott Lamb <http://www.slamb.org/> |
From: Matthew G. <mg...@sh...> - 2007-07-16 20:07:45
|
On 7/16/2007, "Scott Lamb" <sl...@sl...> wrote: >VANHULLEBUS Yvan wrote: >> >> The first performance problem is the PFKey interface itself, because >> one message request (SADB_X_SPDDUMP, or something like that) will >> generate one kernel response per SPD entry (yes....). > >Why is that a problem? This is asymptotically insignificant. > As racoon runs a single process, there could potentially be a problem if it happens to be doing something else between reads from the pfkey socket. One example could be performing a select on another file descriptor. If you are seeing high cpu utilization during the initial spd dump processing, this is most likely not the case. >> The second performance problem is the SPD matching code, where each >> new SPD received from the kernel will be compared against all other >> SPD entries. >> >> This will be a good thing to clean up / speed up that, but I'll have >> to verify the exact constraints of the SPD list before. >> I believe you agree with Yvan here in your last statement. >> And this won't solve the PFKey problem... >> For that, I guess Linux kernels don't have the problem because they >> don't really use PFKey interface (well, that's what I understood a >> long time ago...) > >Linux kernels use the same interface as BSD ones. This problem was >encountered on Linux, not BSD. > I think Yvan was just stating that the PFKEY protocol implementations on Linux and BSD have operational differences. Obviously, they use the same interface as defined in the PFKEY RFC etc. >>, and the only solution I have for BSD kernels is a >> big hack, with a new SADB_X_SPDDUMP_ONEBLOCK (call it as you like) >> PFKey message, where the userland gives the base address and size of a >> big memory block, and where the kernel fills all the informations in >> the memory block. >> >> It works, but we still have a problem: setiing up a correct size for >> the memory block..... > >The time is going into racoon2's O(n^2) algorithm, so I'm not sure why >you think an interface change would solve it. And I have no idea why you >would violate the clean message-based protocol like that. > Yvan can correct me if my memory if faulty here, but I believe he was referring to work around for a BSD kernel limitation where you can reach an entry limit relatively quickly. I doubt this would apply to Linux kernels. It sounds like everyone is basically saying the same thing. We just need to come up with patch that provides an acceptable solution. -Matthew |
From: Joy L. <la...@au...> - 2007-07-16 20:42:47
|
On Mon, 2007-07-16 at 13:10 +0000, Matthew Grooms wrote: > On 7/16/2007, "Scott Lamb" <sl...@sl...> wrote: > >VANHULLEBUS Yvan wrote: > >> > >> The first performance problem is the PFKey interface itself, because > >> one message request (SADB_X_SPDDUMP, or something like that) will > >> generate one kernel response per SPD entry (yes....). > > > >Why is that a problem? This is asymptotically insignificant. > > > > As racoon runs a single process, there could potentially be a problem if > it happens to be doing something else between reads from the pfkey > socket. One example could be performing a select on another file > descriptor. If you are seeing high cpu utilization during the initial > spd dump processing, this is most likely not the case. > > >> The second performance problem is the SPD matching code, where each > >> new SPD received from the kernel will be compared against all other > >> SPD entries. > >> > >> This will be a good thing to clean up / speed up that, but I'll have > >> to verify the exact constraints of the SPD list before. > >> > > I believe you agree with Yvan here in your last statement. > > >> And this won't solve the PFKey problem... > >> For that, I guess Linux kernels don't have the problem because they > >> don't really use PFKey interface (well, that's what I understood a > >> long time ago...) > > > >Linux kernels use the same interface as BSD ones. This problem was > >encountered on Linux, not BSD. > > > > I think Yvan was just stating that the PFKEY protocol implementations on > Linux and BSD have operational differences. Obviously, they use the same > interface as defined in the PFKEY RFC etc. > Yes. I also wondered if he might be referring to the netlink xfrm api in Linux. It provides same abilities as pfkey but overcomes some known limitations with pfkey, specifically in regards to buffer sizes when dumping info, like spd entries. See http://sourceforge.net/mailarchive/forum.php?thread_name=20060208180357.55191.qmail%40web30915.mail.mud.yahoo.com&forum_name=ipsec-tools-devel > >>, and the only solution I have for BSD kernels is a > >> big hack, with a new SADB_X_SPDDUMP_ONEBLOCK (call it as you like) > >> PFKey message, where the userland gives the base address and size of a > >> big memory block, and where the kernel fills all the informations in > >> the memory block. > >> > >> It works, but we still have a problem: setiing up a correct size for > >> the memory block..... > > > >The time is going into racoon2's O(n^2) algorithm, so I'm not sure why > >you think an interface change would solve it. And I have no idea why you > >would violate the clean message-based protocol like that. > > > > Yvan can correct me if my memory if faulty here, but I believe he was > referring to work around for a BSD kernel limitation where you can reach > an entry limit relatively quickly. I doubt this would apply to Linux > kernels. > > It sounds like everyone is basically saying the same thing. We just need > to come up with patch that provides an acceptable solution. > Regards, Joy |
From: Scott L. <sl...@sl...> - 2007-07-16 22:17:03
|
Matthew Grooms wrote: > On 7/16/2007, "Scott Lamb" <sl...@sl...> wrote: >> VANHULLEBUS Yvan wrote: >>> The first performance problem is the PFKey interface itself, because >>> one message request (SADB_X_SPDDUMP, or something like that) will >>> generate one kernel response per SPD entry (yes....). >> Why is that a problem? This is asymptotically insignificant. >> > > As racoon runs a single process, there could potentially be a problem if > it happens to be doing something else between reads from the pfkey > socket. One example could be performing a select on another file > descriptor. If you are seeing high cpu utilization during the initial > spd dump processing, this is most likely not the case. Oh, yeah, that's not happening. > >>> The second performance problem is the SPD matching code, where each >>> new SPD received from the kernel will be compared against all other >>> SPD entries. >>> >>> This will be a good thing to clean up / speed up that, but I'll have >>> to verify the exact constraints of the SPD list before. >>> > > I believe you agree with Yvan here in your last statement. Yes. >>> And this won't solve the PFKey problem... >>> For that, I guess Linux kernels don't have the problem because they >>> don't really use PFKey interface (well, that's what I understood a >>> long time ago...) >> Linux kernels use the same interface as BSD ones. This problem was >> encountered on Linux, not BSD. >> > > I think Yvan was just stating that the PFKEY protocol implementations on > Linux and BSD have operational differences. Obviously, they use the same > interface as defined in the PFKEY RFC etc. I believe they're identical here. > It sounds like everyone is basically saying the same thing. We just need > to come up with patch that provides an acceptable solution. Yeah. Hmm. You know, I was thinking about it more, and O(n^2) or not, this shouldn't be that slow. Check this out: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 60.00 0.06 0.06 279312 0.00 0.00 spidx2str ... index % time self children called name ... 0.00 0.10 139656/139656 getsp [5] [4] 100.0 0.00 0.10 139656 cmpspidxstrict [4] 0.06 0.02 279312/279312 spidx2str [7] 0.01 0.00 96603/96603 cmpsaddrstrict [11] 0.01 0.00 279312/280427 debug_location [10] 0.00 0.00 279312/280427 plog [31] Why does cmpspidxstrict convert the policy to a string? That's where all the time's going. |
From: Scott L. <sl...@sl...> - 2007-07-16 22:26:01
|
Scott Lamb wrote: > Matthew Grooms wrote: >> On 7/16/2007, "Scott Lamb" <sl...@sl...> wrote: >>> VANHULLEBUS Yvan wrote: >>>> The first performance problem is the PFKey interface itself, because >>>> one message request (SADB_X_SPDDUMP, or something like that) will >>>> generate one kernel response per SPD entry (yes....). >>> Why is that a problem? This is asymptotically insignificant. >>> >> As racoon runs a single process, there could potentially be a problem if >> it happens to be doing something else between reads from the pfkey >> socket. One example could be performing a select on another file >> descriptor. If you are seeing high cpu utilization during the initial >> spd dump processing, this is most likely not the case. > > Oh, yeah, that's not happening. > >>>> The second performance problem is the SPD matching code, where each >>>> new SPD received from the kernel will be compared against all other >>>> SPD entries. >>>> >>>> This will be a good thing to clean up / speed up that, but I'll have >>>> to verify the exact constraints of the SPD list before. >>>> >> I believe you agree with Yvan here in your last statement. > > Yes. > >>>> And this won't solve the PFKey problem... >>>> For that, I guess Linux kernels don't have the problem because they >>>> don't really use PFKey interface (well, that's what I understood a >>>> long time ago...) >>> Linux kernels use the same interface as BSD ones. This problem was >>> encountered on Linux, not BSD. >>> >> I think Yvan was just stating that the PFKEY protocol implementations on >> Linux and BSD have operational differences. Obviously, they use the same >> interface as defined in the PFKEY RFC etc. > > I believe they're identical here. > >> It sounds like everyone is basically saying the same thing. We just need >> to come up with patch that provides an acceptable solution. > > Yeah. Hmm. You know, I was thinking about it more, and O(n^2) or not, > this shouldn't be that slow. Check this out: > > Flat profile: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 60.00 0.06 0.06 279312 0.00 0.00 spidx2str > > ... > index % time self children called name > ... > 0.00 0.10 139656/139656 getsp [5] > [4] 100.0 0.00 0.10 139656 cmpspidxstrict [4] > 0.06 0.02 279312/279312 spidx2str [7] > 0.01 0.00 96603/96603 cmpsaddrstrict [11] > 0.01 0.00 279312/280427 debug_location [10] > 0.00 0.00 279312/280427 plog [31] > > Why does cmpspidxstrict convert the policy to a string? That's where all > the time's going. Hmm, if I disable the two plog calls at the beginning, the time changes from this 1.25user 0.02system 0:01.59elapsed 79%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+542minor)pagefaults 0swaps to this 0.02user 0.00system 0:00.38elapsed 9%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+704minor)pagefaults 0swaps I'm gonna work up a patch that adds a PLOG #define to check the logging level before generating the plog arguments. Best regards, Scott -- Scott Lamb <http://www.slamb.org/> |
From: Scott L. <sl...@sl...> - 2007-07-16 22:49:18
|
before: 1.25user 0.02system 0:01.59elapsed 79%CPU after: 0.02user 0.00system 0:00.38elapsed 9%CPU (0avgtext+0avgdata Some systems are slow enough that the "1.25user" was actually "30user", so this is a huge optimization. Note this uses C99 variadic macro syntax. Given the gcc annotations throughout the code, I presume this is not a problem. Signed-off-by: Scott Lamb <sl...@sl...> --- src/racoon/crypto_openssl.c | 1 + src/racoon/kmpstat.c | 2 +- src/racoon/plog.c | 2 +- src/racoon/plog.h | 7 ++++++- 4 files changed, 9 insertions(+), 3 deletions(-) diff --git a/src/racoon/crypto_openssl.c b/src/racoon/crypto_openssl.c index fbb0320..491d299 100644 --- a/src/racoon/crypto_openssl.c +++ b/src/racoon/crypto_openssl.c @@ -89,6 +89,7 @@ #include "crypto/sha2/sha2.h" #endif #endif +#include "plog.h" /* 0.9.7 stuff? */ #if OPENSSL_VERSION_NUMBER < 0x0090700fL diff --git a/src/racoon/kmpstat.c b/src/racoon/kmpstat.c index 37c16c9..01200b6 100644 --- a/src/racoon/kmpstat.c +++ b/src/racoon/kmpstat.c @@ -186,7 +186,7 @@ bad1: * Dumb plog functions (used by sockmisc.c) */ void -plog(int pri, const char *func, struct sockaddr *sa, const char *fmt, ...) +_plog(int pri, const char *func, struct sockaddr *sa, const char *fmt, ...) { va_list ap; diff --git a/src/racoon/plog.c b/src/racoon/plog.c index c70a5a0..c9a8450 100644 --- a/src/racoon/plog.c +++ b/src/racoon/plog.c @@ -138,7 +138,7 @@ plog_common(pri, fmt, func) } void -plog(int pri, const char *func, struct sockaddr *sa, const char *fmt, ...) +_plog(int pri, const char *func, struct sockaddr *sa, const char *fmt, ...) { va_list ap; diff --git a/src/racoon/plog.h b/src/racoon/plog.h index 1fafd7c..3ddd1e0 100644 --- a/src/racoon/plog.h +++ b/src/racoon/plog.h @@ -64,7 +64,12 @@ extern int f_foreground; extern int print_location; struct sockaddr; -extern void plog __P((int, const char *, struct sockaddr *, const char *, ...)) +#define plog(pri, ...) \ + do { \ + if ((pri) <= loglevel) \ + _plog((pri), __VA_ARGS__); \ + } while (0) +extern void _plog __P((int, const char *, struct sockaddr *, const char *, ...)) __attribute__ ((__format__ (__printf__, 4, 5))); extern void plogv __P((int, const char *, struct sockaddr *, const char *, va_list)); -- 1.5.2.2.238.g7cbf2f2-dirty |
From: Scott L. <sl...@sl...> - 2007-08-16 17:33:42
|
Scott Lamb wrote: > before: 1.25user 0.02system 0:01.59elapsed 79%CPU > after: 0.02user 0.00system 0:00.38elapsed 9%CPU (0avgtext+0avgdata > > Some systems are slow enough that the "1.25user" was actually "30user", > so this is a huge optimization. > > Note this uses C99 variadic macro syntax. Given the gcc annotations > throughout the code, I presume this is not a problem. > > Signed-off-by: Scott Lamb <sl...@sl...> > --- > src/racoon/crypto_openssl.c | 1 + > src/racoon/kmpstat.c | 2 +- > src/racoon/plog.c | 2 +- > src/racoon/plog.h | 7 ++++++- > 4 files changed, 9 insertions(+), 3 deletions(-) What is the status of this patch? As you can see, it makes an enormous reduction in startup CPU time and is quite unobtrusive. Is there some reason it hasn't been applied? Scott -- Scott Lamb <http://www.slamb.org/> |
From: <ma...@ne...> - 2007-08-16 19:38:09
|
Scott Lamb <sl...@sl...> wrote: > What is the status of this patch? As you can see, it makes an enormous > reduction in startup CPU time and is quite unobtrusive. Is there some > reason it hasn't been applied? The developers are busy pushing out ipsec-tools 0.7, and nobody have been tracking patches theses days. We need to do a better patch tracking job. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Scott L. <sl...@sl...> - 2007-09-20 17:22:10
|
Emmanuel Dreyfus wrote: > Scott Lamb <sl...@sl...> wrote: > >> What is the status of this patch? As you can see, it makes an enormous >> reduction in startup CPU time and is quite unobtrusive. Is there some >> reason it hasn't been applied? > > The developers are busy pushing out ipsec-tools 0.7, and nobody have > been tracking patches theses days. We need to do a better patch tracking > job. > 0.7 is out. Here's my final attempt to send in this trivial, low-risk patch which makes an enormous reduction in CPU usage. |
From: VANHULLEBUS Y. <va...@fr...> - 2007-09-21 07:07:24
|
On Thu, Sep 20, 2007 at 10:22:13AM -0700, Scott Lamb wrote: > Emmanuel Dreyfus wrote: > >Scott Lamb <sl...@sl...> wrote: > > > >>What is the status of this patch? As you can see, it makes an enormous > >>reduction in startup CPU time and is quite unobtrusive. Is there some > >>reason it hasn't been applied? > > > >The developers are busy pushing out ipsec-tools 0.7, and nobody have > >been tracking patches theses days. We need to do a better patch tracking > >job. > > > > 0.7 is out. Here's my final attempt to send in this trivial, low-risk > patch which makes an enormous reduction in CPU usage. Hi. I'm out of office actually, and the only thiongI can do easilly is reading my mails. I'll handle this patch within a few days, thanks for the updated version. Yvan. |
From: VANHULLEBUS Y. <va...@fr...> - 2007-10-02 09:47:44
|
On Thu, Sep 20, 2007 at 10:22:13AM -0700, Scott Lamb wrote: > Emmanuel Dreyfus wrote: > >Scott Lamb <sl...@sl...> wrote: > > > >>What is the status of this patch? As you can see, it makes an enormous > >>reduction in startup CPU time and is quite unobtrusive. Is there some > >>reason it hasn't been applied? > > > >The developers are busy pushing out ipsec-tools 0.7, and nobody have > >been tracking patches theses days. We need to do a better patch tracking > >job. > > > > 0.7 is out. Here's my final attempt to send in this trivial, low-risk > patch which makes an enormous reduction in CPU usage. Hi. Sorry for the delay, I just commited it to HEAD. This is also a good candidate for a backport to 0.7 branch, any opinions on that ? Yvan. |
From: ythhaj k. <ka3...@go...> - 2007-11-20 15:55:36
|
Hello When we first tested Scott's patch to make a reduction in the startup CPU time for racoon it worked perfectly. We saw a reduction from 30s to low enough to be negligible. This took the power-on to encrypted-traffic-flowing time down to 60s from 90s. Even though the patch was against v0.6.? it was easy to apply against v0.7 and once compiler issues were solved we could easily run this on our little 266MHz PPC devices. Now we are doing more formal testing and looking at this more closely we see two issues which are both to do with racoon and both intermittent. The first is that sometimes this 30s delay comes back. We have checked all the different things that run when the system boots up and can only conclude that racoon is the cause of this delay. There are other things which can slow down the boot time but we have eliminated them from this. Here is the output when we run date > tmp/racoonlog.txt ; racoon -f /etc/racoon/racoon.conf -F >> /tmp/racoonlog.txt as part of our bootup scripts. A ping is started from one laptop, through the tunnel to a distant laptop at the same time as the system is powered up. With one packet being sent per second we can measure the total readiness time from power on by noting the sequence number of the first ping to return. root@****>more /tmp/racoonlog.txt Tue Jul 24 00:00:08 UTC 2007 Foreground mode. 2007-07-24 00:00:08: INFO: @(#)ipsec-tools 0.7 ( http://ipsec-tools.sourceforge.net) 2007-07-24 00:00:08: INFO: @(#)This product linked OpenSSL 0.9.8g 19 Oct 2007 (http://www.openssl.org/) 2007-07-24 00:00:08: INFO: Reading configuration from "/etc/racoon/racoon.conf" 2007-07-24 00:00:08: INFO: 172.16.1.254[500] used as isakmp port (fd=4) 2007-07-24 00:00:08: INFO: 172.17.1.1[500] used as isakmp port (fd=5) 2007-07-24 00:00:08: INFO: 127.0.0.1[500] used as isakmp port (fd=6) 2007-07-24 00:00:41: INFO: IPsec-SA request for 172.17.1.2 queued due to no phase1 found. 2007-07-24 00:00:41: INFO: initiate new phase 1 negotiation: 172.17.1.1 [500]<=>172.17.1.2[500] 2007-07-24 00:00:41: INFO: begin Identity Protection mode. 2007-07-24 00:00:41: WARNING: unable to get certificate CRL(3) at depth:1 SubjectName:/C=**/O=***/OU=**/CN=**** 2007-07-24 00:00:41: WARNING: unable to get certificate CRL(3) at depth:2 SubjectName:/C=**/O=***/OU=**/CN=**** 2007-07-24 00:00:41: INFO: ISAKMP-SA established 172.17.1 You can see that there is a 33s delay from t=8 to t=41. (Ignore the date of last July, there is no RTClock on the system and we set the date every time we boot so that certificates work properly). The time of 8s past midnight is the time from when we set the date until we run racoon at the end of the startup scripts. In those seconds we set up routes and check local ip addresses etc. This 8s is constant for a given number of tunnels. On wireshark traces we see nothing before the IKE negotiation followed immediately by the ESP packets going their merry way. The second issue is similar, but we see main mode happen then no quick mode packets for 30s. An equivalent racoon output is here (this time not output to a file and manually started several minutes after power-up): root@****>racoon -F -f /etc/racoon/racoon.conf racoon: /lib/libcrypto.so.0.9.8: no version information available (required by r acoon) Foreground mode. 2007-07-24 00:07:08: INFO: @(#)ipsec-tools 0.7 ( http://ipsec-tools.sourceforge.n et) 2007-07-24 00:07:08: INFO: @(#)This product linked OpenSSL 0.9.8g 19 Oct 2007 (h ttp://www.openssl.org/) 2007-07-24 00:07:08: INFO: Reading configuration from "/etc/racoon/racoon.conf" 2007-07-24 00:07:08: INFO: 172.16.1.254[500] used as isakmp port (fd=4) 2007-07-24 00:07:08: INFO: 172.17.1.1[500] used as isakmp port (fd=5) 2007-07-24 00:07:08: INFO: 127.0.0.1[500] used as isakmp port (fd=6) 2007-07-24 00:07:54: INFO: IPsec-SA request for 172.17.1.2 queued due to no phas e1 found. 2007-07-24 00:07:54: INFO: initiate new phase 1 negotiation: 172.17.1.1[500]<=>1 72.17.1.2[500] 2007-07-24 00:07:54: INFO: begin Identity Protection mode. 2007-07-24 00:07:54: WARNING: unable to get certificate CRL(3) at depth:1 Subjec tName:/C=**/O=***/OU=**/CN=****** 2007-07-24 00:07:54: WARNING: unable to get certificate CRL(3) at depth:2 Subjec tName:/C=**/O=**/OU=**/CN=*** 2007-07-24 00:07:55: INFO: ISAKMP-SA established 172.17.1.1[500]-172.17.1.2[500] spi:cac519846c66f418:ce5b662acbd7b98f 2007-07-24 00:07:55: INFO: initiate new phase 2 negotiation: 172.17.1.1[500]<=>1 72.17.1.2[500] 2007-07-24 00:08:25: INFO: IPsec-SA expired: ESP/Tunnel 172.17.1.2[0]-> 172.17.1. 1[0] spi=170745157(0xa2d5d45) 2007-07-24 00:08:25: ERROR: 172.17.1.2 give up to get IPsec-SA due to time up to wait. 2007-07-24 00:08:27: INFO: initiate new phase 2 negotiation: 172.17.1.1[0]<=>172 .17.1.2[0] 2007-07-24 00:08:27: INFO: IPsec-SA established: ESP/Tunnel 172.17.1.2[0]-> 172.1 7.1.1[0] spi=32635231(0x1f1f95f) 2007-07-24 00:08:27: INFO: IPsec-SA established: ESP/Tunnel 172.17.1.1[0]-> 172.1 7.1.2[0] spi=200966570(0xbfa81aa) Note the 30s delay between attempting quickmode at 00:07:55 and timing out before trying again at 00:08:25. The fact that we ran this manually and several minutes after powering on is not the cause as we have seen this when everything is scripted to run automatically on bootup. The first effect described is much more common than the second. I understand the fact that both are intermittent makes it hard to track down the root cause. Does anyone on the list have any ideas? Obviously I can supply lots of details if you tell me what you need to know. Though much of the setup is identical to when I first raised this issue and it was happening 100% of the time. Cheers RF On 03/10/2007, Scott Lamb <sl...@sl...> wrote: > > VANHULLEBUS Yvan wrote: > > Sorry for the delay, I just commited it to HEAD. > > Thanks! > > > This is also a good candidate for a backport to 0.7 branch, any > > opinions on that ? > > I'm all for it. > > Scott > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > |
From: Scott L. <sl...@sl...> - 2007-11-20 16:48:50
|
Hmm. Not sure, but I have some thoughts on gathering more information: 1) can you confirm with "ps" or "time" that the CPU is busy during these 30-second gaps? 2) any chance of running a profiler against a build with symbols? I know these are small systems, but that output would be helpful. 3) likewise, if you crank the debugging up a bit can you see any other visible difference between a fast run and a slow one? Do increase it a notch at a time, or you'll be back to the slow start every time. In fact, we may have to get the debugging to be faster to make use of it on your system. (By retaining saddr2src results and so forth.) Best regards, Scott |
From: Scott L. <sl...@sl...> - 2007-10-03 03:17:43
|
VANHULLEBUS Yvan wrote: > Sorry for the delay, I just commited it to HEAD. Thanks! > This is also a good candidate for a backport to 0.7 branch, any > opinions on that ? I'm all for it. Scott |
From: VANHULLEBUS Y. <va...@fr...> - 2007-08-20 15:21:16
|
On Thu, Aug 16, 2007 at 10:32:53AM -0700, Scott Lamb wrote: > Scott Lamb wrote: [....] > What is the status of this patch? As you can see, it makes an enormous > reduction in startup CPU time and is quite unobtrusive. Is there some > reason it hasn't been applied? Hi Scott. Your patch is interesting, and will be reported to ipsec-tools "quite soon". But as Manu said, we are currently working on releasing 0.7.0 (which is still not completly done due to packaging problems), and everything else is frozen until it is really a security issue. Yvan. |
From: ythhaj k. <ka3...@go...> - 2007-07-16 16:30:59
|
On 14/07/07, ythhaj khkci <ka3...@go...> wrote: > > I'll post more details on Monday when I get back into work and can look up > my notes. > The first time I ran this test with the current OS build I got these results: 4, 1 40, 1 80, 65 + 65 + 65 + 65 (tested four times) 81, 6 90, 8 120, 14 160, 24 200, 27 254, 27 Nice trend except for the 80 tunnels result. I really hope that is an anomaly. I ran the tests again today and saw these results: Number of tunnels, Racoon delay time 4, 1 30, 1 60, 4 90, 8 100, 34 + 11 120, 34 + 34 + 34 140, 34 150, 22 180, 27 210, 34 230, 27 240, 27 254, 34 After this time, the IKE negotiation happens and always took 2s. Then the traffic flows as expected. All these timings were done manually, I pinged from a server to a client machine at the same time as I ran racoon on both IPsec boards. So the accuracy of all times are probably +/- 1s. I'm going to try to get our suppliers to recompile the with the partch posted by Matthew and I'll report the results. Thanks RF |