strongSwan - Feature #3595
Load-test virtual IPv6 addresses
14.10.2020 19:09 - Ryan Farrell

ステータス:

Closed

開始日:

優先度:

Low

期日:担当者:

Tobias Brunner

予定工数:

カテゴリ:

testing

対象バージョン:5.9.1

Resolution:

Fixed

0.00時間

説明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, theserver/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
履歴#1 - 14.10.2020 19:44 - Tobias Brunner- トラッカー を Issue から Feature に変更- ステータス を New から Feedback に変更- Affected version を削除 (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 manuallyconfigured).
#2 - 14.10.2020 20:18 - Ryan Farrell
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 - 15.10.2020 09:44 - Tobias Brunner

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 - 16.10.2020 02:28 - Ryan Farrell
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!

14.10.2024

1/4

#5 - 20.10.2020 18:41 - Ryan Farrell
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 of128#6 - 21.10.2020 16:29 - Tobias Brunner

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 lengthof 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 - 21.10.2020 23:57 - Ryan Farrell
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 asingle 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 todo some further testing to know for sure. I'll try some things and update. I really appreciate the quick response and turn around!
#8 - 22.10.2020 10:02 - Tobias Brunner

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 asingle 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 - 23.10.2020 23:05 - Ryan Farrell
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

14.10.2024

2/4

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 similarresults). 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 theCPUs, 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'drather I continue in this thread.
Thank youAdditional 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 = yesenable = yes
addrs̲keep = noversion = 2
initiators = 0
iterations = 0
delay = 10
init̲limit = 0ca̲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 = nodigest = 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 = noikesa̲table̲segments = 128
ikesa̲table̲size = 1024
initiator̲only = yes
install̲routes = noinstall̲virtual̲ip = yesinterfaces̲use = ens33

14.10.2024

3/4

reuse̲ikesa = nothreads = 32
#10 - 26.10.2020 11:52 - Tobias Brunner- カテゴリ を testing にセット
- 対象バージョン を 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 haveworked 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'drather I continue in this thread.

Yes, please open a new ticket.
#11 - 28.10.2020 15:34 - Tobias Brunner- ステータス を Feedback から Closed に変更- 担当者 を Tobias Brunner にセット
- Resolution を Fixed にセット

14.10.2024

4/4