bpf:tests:encrypt_host: extend suite with Overlay coverage#45084
bpf:tests:encrypt_host: extend suite with Overlay coverage#45084smagnani96 wants to merge 1 commit intomainfrom
Conversation
This commit extends the encrypt_host test suite with new tests for encryption with Overlay encapsulation, both for WireGuard and IPsec. Signed-off-by: Simone Magnani <simone.magnani@isovalent.com>
88cd086 to
02717e1
Compare
|
/test |
| #ifndef TUNNEL_MODE | ||
| ipcache_v4_add_entry_with_mask_size(DST_POD_CIDR_V4, 0, WORLD_ID, | ||
| DST_NODE_V4, ENCRYPT_KEY, | ||
| v4_pod_cidr_size); | ||
| #endif | ||
|
|
||
| #ifdef ENABLE_IPSEC | ||
| ipsec_set_encrypt_state(ENCRYPT_KEY); | ||
| node_v4_add_entry(DST_NODE_V4, DST_NODE_ID, ENCRYPT_KEY); | ||
| #endif | ||
|
|
||
| #ifdef TUNNEL_MODE | ||
| set_identity_mark(ctx, SRC_POD_SEC_IDENTITY, MARK_MAGIC_OVERLAY); | ||
| #else | ||
| set_identity_mark(ctx, SRC_POD_SEC_IDENTITY, MARK_MAGIC_IDENTITY); | ||
| #endif |
There was a problem hiding this comment.
I think what feels awkward is that we're overloading the test cases. In my mind what each test does is to take (1.) a certain controlplane-derived state (== BPF map entries) and (2.) a certain packet (headers, packet mark, tc_index, ...) - and evaluates how this is processed by the datapath, with a given Cilium config.
So what I would expect here is additional tests (that only get executed under TUNNEL_MODE), for how the datapath treats VXLAN packets with MARK_MAGIC_OVERLAY. I don't think we even need to handle the case where MARK_MAGIC_OVERLAY is not set for such a packet - unless we can explain a scenario where such a packet would occur. If we believe that fluctuation in controlplane-derived state matters for such packets, then let's add different tests for that.
What that also gives us is the opportunity to run the "standard" encryption tests, even when TUNNEL_MODE is set. And thus cover mixed-routing scenarios, where some endpoints are reachable without tunnel.
Follow-up of #44339.