On Thu, 7 Dec 2023, Michael Rossberg wrote:
I would actually like to refrain from writing 2 * 1.024 keys from the control
plane to the data plane, just because a single IKE SA rekeyed...
If you rekey the IKE SA, there is no change to the Child SA's. The new
IKE SA inherits the existing Child SAs. So no 2 * 1024 new keys.
On your big router that connects 10k clients, there is no point in using
multi-sa to gain speed. It has enough SAs that it can just leave them
all on a single CPU for each client. So you only need to have a multi-sa
child sa per client core (which you say is 2) and not 64 because your
server has 64 cores. With 10k clients, you already have 156 clients per
core. You gain nothing by splitting those into 64.
You are right about scaling for the black to red path, but for the other
way around, one had to determine the right core when the unencrypted
packet enters the VPN box. So either the NIC in the red side “knows”
about the core allocation or, if you would use RSS, you will stick with
inter-CPU-core communication in most cases, unless you have one
SA per Core (or even more "for MPLS, QoS, uplinks, etc…”)
Sub-SA would of course completely resolve that issue...
I guess I'm insure how you would deal with QoS related issues when you
have two cores, but one uplink bandwidth. How would the cores not stomp on
each other? It seems you need to synchronise things on the client router
onto a single entity that determines which packet goes out first to keep
the stream complying with QoS settings.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
