/test

I think the "+4 for tunnel routing" is only expected for 1.17+. Maybe we should do some versioning control?

Good catch!
I've checked v1.16 and v1.15 and the logic is also different:

• https://github.com/cilium/cilium/blob/v1.16/.github/actions/ipsec-key-rotate/action.yaml#L41-L60
• https://github.com/cilium/cilium/blob/v1.15/.github/actions/ipsec-key-rotate/action.yaml#L37-L46

So, does it mean that we should have something like this:

if ciliumVersion > 1.17 {
   // new expected keys 
} else if ciliumVersion == 1.16 {
  // old algorithm-1
} else {
  // old algorithm-2
}

?

does it mean that we should have something like this

Yes, thank you

Yes, thank you

Hey @jschwinger233, I've added version check but looks like the algorithm is incorrect.

I have local 4 node kind cluster with enabled IPsec and VXLAN.
cilium-dbg encrypt status returns Keys in use: 18.
But CLI cilium encrypt status:

IPsec keys in use: 18 on 4/4
IPsec expected key count: 20

Viktor: I believe you are right, I didn't think over this thoroughly.

The correct algorithm for 1.17 should be:

• ipv4, from/to remote: (node_number - 1) * 2
• ipv6, from/to remote: (node_number - 1) *2
• ipv4, VinE: (node_number - 1) * 2

in total, it's (node_number - 1) * 6.

Would you like to fix the workflow in a separate PR?

@jschwinger233 one clarification:
What is VinE? Is it VXLAN encapsulation?
Thank you!

VinE is Vxlan in ESP: #36345

@jschwinger233 Paul and I agreed to support IPsec key status and rotation starting from Cilium v1.18.
Could you please review one more time?

/test

/test