strongSwan

Appreciate your quick feedback. Just saved me from banging my head on my keyboard for another day.
IPv6 VIPs are NOT supported. I'll cross my fingers for this showing up in a future release.

I'll cross my fingers for this showing up in a future release.

Why in particular are you interested in this? Are you testing an IPv6 pool implementation? It seems not that relevant for load tests if the client requests an IPv6 address or not.

Correct, the server implementation is 6in6 only. I agree, handing out v4 vs. v6 addresses shouldn't make a difference but I am like to test as close to production-like as I can get.
Right now, my vendor supplied test tools have some limitations that the load-tester plugin supports. I can still use my drivers running strongSwan in namespaces to get thousands of "real" simulated clients. However, the simplicity and scale of the load-test plugin has been great!

On a related note, does the load-tester not support the creation of IPv6 dynamic addresses?

For example,
addrs {
ens33 = 2001:a:b:c:d:e:f:1/112
}
addrs_prefix = 128
addrs_keep = yes

The log has:
04[CFG] no address found to install as load-tester external IP
04[CFG] allocating external address failed

The reason I assumed IPv6 dynamic addrs are supported is from the LoadTests page's "addrs_prefix" description that mentions a prefix length of 128

On a related note, does the load-tester not support the creation of IPv6 dynamic addresses?

No, currently not. The code requests an IPv4 address from the configured address pools.

The reason I assumed IPv6 dynamic addrs are supported is from the LoadTests page's "addrs_prefix" description that mentions a prefix length of 128

It's possible that the address pool implementation behaved differently in earlier versions (e.g. before 5.0.1, which added support for multiple address pools).

I pushed some commits to the 3595-load-test-ipv6 branch to address the two issues. Let me know if these work for you.

• I removed the IPv4 pool from the server and it is correctly assigning IPv6 addrs.
• I configured the load-tester with the addrs stanza and they were created and used as expected.

I am having some performance issues on the load-tester client. After around 2,000 of 6,000 sessions, the client was struggling. When using a single IPv6 and unique ports it was fine. I am guessing this related to all of the unique IPv6 addrs and some overhead I need to address. I need to do some further testing to know for sure. I'll try some things and update. I really appreciate the quick response and turn around!

I am having some performance issues on the load-tester client. After around 2,000 of 6,000 sessions, the client was struggling. When using a single IPv6 and unique ports it was fine. I am guessing this related to all of the unique IPv6 addrs and some overhead I need to address.

Did you see the note on LoadTests? strongSwan's kernel-netlink plugin might have some issues too (to avoid problems with route/source address lookups you could configure charon.plugins.kernel-netlink.fwmark to an "inverted" mark in strongswan.conf so the kernel's route lookup is used).

If I understood your suggestion (and the docs) correctly, I added the following:

• "fwmark = !0x42" to kernel-netlink.conf
• "fwmark = 0x42" to socket-default.conf

That didn't make a noticeable difference.

• "reuse_ikesa = no" (this made the biggest difference)
• "ikesa_table_segments = 128"
• "ikesa_table_size = 1024"
• "threads = 32"
• I also added a static ipv6 neigh entry for the router to minimize nd traffic
• I set the logging level to -1

Right now, the tunnel/sec rate getting created on the remote server is up to around 100/sec when creating up to 6,000 tunnels (10,000 gets similar results). The retransmissions, as reported by the load-tester, are < 1%.

I'm have been using "ipsec load-tester initiate 6000 10". Is this preferred over having it start with the daemon and the initiators & iterations?

As far as the original purpose of this ticket, the IPv6 dynamic addresses and the IPv6 VIPs are both working. The changes you made have worked for me without any issues.

1. I know there is a lot that goes into maximizing performance for a tool like this, but should I expect to get a greater tunnel rate (also given the CPUs, esp & proposals included below)? I don't want to chase this too far if you think I may only get minimal improvements. However, if I am way behind what you have seen or expect, I'll keep tinkering as time permits.
2. I do have a few additional observations/docs/bugs(?) relating to the load-tester I can put into a new ticket when I have time, unless you'd rather I continue in this thread.

Thank you

• This is a Ubuntu 18.04 VM on ESXi w/16 CPU (2 sockets w/ 8 cores), 32G RAM.
• Below are the relevant sections from the .conf files I have been using (anything else was commented out).
  Load-tester.conf
  

  load-tester {
      load = yes
      enable = yes
      addrs_keep = no
      version = 2
      initiators = 0
      iterations = 0
      delay = 10
      init_limit = 0
      ca_dir = /usr/local/etc/swanctl/x509ca
      issuer_cert = /usr/local/etc/swanctl/x509ca/signing.crt
      issuer_key = /usr/local/etc/swanctl/private/signing.key
      ike_rekey = 3600
      child_rekey = 1800
      crl = http://test/crl/enb/signing.crl.pem
      addrs
      {
      ens33 = 2001:a:a:4001:f::2/64
      }
      addrs_keep = yes
      addrs_prefix = 64
      responder = 2001:a:a:7001:1::1
      initiator_auth = pubkey
      responder_auth = pubkey
      responder_id = C=US, ST=IL, CN=site1pair1
      initiator_id = CN=conn-%d, OU=load-test, O=strongSwan
      initiator_tsi = ::/0
      initiator_tsr = ::/0
      delete_after_established = no
      digest = sha256
      mode = tunnel
      proposal = aes256gcm16-sha256-modp2048
      #proposal = aes256gcm16-sha256-modpnull
      esp = aes256gcm16-sha256
      request_virtual_ip = yes
      dpd_delay = 30
      shutdown_when_complete = no
  }
  

Charon.conf settings :

dos_protection = no
ikesa_table_segments = 128
ikesa_table_size = 1024
initiator_only = yes
install_routes = no
install_virtual_ip = yes
interfaces_use = ens33
reuse_ikesa = no
threads = 32