Project

General

Profile

Feature #3595

Load-test virtual IPv6 addresses

Added by Ryan Farrell about 1 month ago. Updated 26 days ago.

Status:
Closed
Priority:
Low
Category:
testing
Target version:
Start date:
Due date:
Estimated time:
Resolution:
Fixed

Description

My question is: Are IPv6 vips supported with the load-test plugin?

I am able to use a strongSwan client with the load-tester plugin to initiate many thousands of tunnels successfully. However, the server/responder (also strongSwan) has an IPv6 pool only. The clients do not get an IPv6 vip assigned. When I add an additional IPv4 pool to the server, the clients get an IPv4 vip assigned and all is well. I'd like to test with IPv6 vips.

The load-tester wiki states: "charon.plugins.load-tester.request_virtual_ip" - "Request an INTERNAL_IPV4_ADDR from the server." However, given IPv6 seems to be supported everywhere else I have used it, I am hoping I just missed something obvious or the wiki is wrong. I have tested with many setups on the load-tester client and searched the support site and Google with no luck.

If this isn't a simple yes/no questions, I will of course be able to provide the required & requested configs/logs/traces.

Thank you,
Ryan

Associated revisions

Revision 1d232d49 (diff)
Added by Tobias Brunner 27 days ago

load-tester: Use appropriate family to request addresses from source IP pools

Looks like this wasn't necessary before 40e90898895c ("Strictly enforce
address family match while acquiring mem_pool IPs").

Fixes #3595.

Revision f3f93cad (diff)
Added by Tobias Brunner 27 days ago

load-tester: Also request a virtual IPv6 address

Fixes #3595.

History

#1 Updated by Tobias Brunner about 1 month ago

  • Tracker changed from Issue to Feature
  • Status changed from New to Feedback
  • Affected version deleted (5.9.0)

The load-tester wiki states: "charon.plugins.load-tester.request_virtual_ip" - "Request an INTERNAL_IPV4_ADDR from the server." However, given IPv6 seems to be supported everywhere else I have used it, I am hoping I just missed something obvious or the wiki is wrong.

Neither, the option does, in fact, only request an IPv4 address (same goes for the traffic selectors, which are IPv4 only - unless manually configured).

#2 Updated by Ryan Farrell about 1 month ago

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.

#3 Updated by Tobias Brunner about 1 month ago

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.

#4 Updated by Ryan Farrell about 1 month ago

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!

#5 Updated by Ryan Farrell about 1 month ago

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

#6 Updated by Tobias Brunner about 1 month ago

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.

#7 Updated by Ryan Farrell about 1 month ago

Initial tests using the 3595-load-test-ipv6 branch look good so far.
  • 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!

#8 Updated by Tobias Brunner about 1 month ago

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).

#9 Updated by Ryan Farrell about 1 month ago

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.

I tried a number of different changes in charon.conf:
  • "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.

A few final questions:
  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

Additional reference (if needed):
  • 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

#10 Updated by Tobias Brunner 29 days ago

  • Category set to testing
  • Target version set to 5.9.1

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

The second is not necessary to enable the kernel route lookup.

That didn't make a noticeable difference.

That might be because you disabled the route installation.

I tried a number of different changes in charon.conf:
  • "reuse_ikesa = no" (this made the biggest difference)

Yes, that avoids a linear search through all SAs on the initiator.

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?

With the former you will only get a single initiator that initiates SAs one after another with the given delay in between (initiation here means creating a config, an IKE_SA and start the initiation to track it, it does not wait until the IKE_SA is complete, not even until the IKE_SA_INIT is sent). That basically gives you the observed 1000ms / ~10ms = ~100 initiations/s. To get multiple initiators (i.e. to replicate load-tester.initiators) you may use the command multiple times concurrently.

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.

OK, great, these will be included in the next release.

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.

Yes, please open a new ticket.

#11 Updated by Tobias Brunner 26 days ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

Also available in: Atom PDF