Conversation
795e4b1 to
cfda5f1
Compare
|
/test |
There was a problem hiding this comment.
Just dropping a few minor comments. It's a bit annoying that we're hiding this feature behind a new config flag (default false), that will make e2e test coverage really difficult.
-
What's your overall intention towards testing? I think we'll definitely want some BPF-level tests to demonstrate this code-path in action, and what results the FIB lookup potentially returns (mocking would be good enough here for a start). So it's easier to catch regressions, and others later working on the code have a reference.
-
I'm less certain about e2e-level testing - in the current framework, are we able to test more than the good path? I feel there might be some value in having a more involved e2e-test once we also switch the BPF-Masq path over - confirming that an external endpoint is accessed with the expected interface / source IP. Similar how we currently test EGW.
-
I see an upgrade impact here, where in-flight connections would potentially change their source IP.
-
When users modify their routing setup on-the-fly and this changes what source IP is returned for some connections, this would also impact established connections. But I guess the answer there is "don't do that".
cfda5f1 to
e782ada
Compare
|
@julianwiedmann re:
Yes, I think for now, we add a fib lookup mock which injects a different source IP from the fallback IP used (direct routing IP), and simply confirm we see this in the resulting skb_buff. I can add this as an additional commit to this PR.
Yeah, for e2e to be worth it, we need a multi-homed node I think, and we need to confirm the packet egresses that interface with the expected source IP. I'm not familiar with EGW tests, but I can look into this to understand if it provides inspiration.
Yes, I would say this is an operational issue, just like modifying your routing table at runtime. No safeguards there on native linux, you need to know what you're doing. That is why this is 'opt-in', it gives a switch for the user, saying "okay now, native FIB matters, and we need to be conscious of changes there". |
|
Added don't merge label until eBPF tests are implemented. |
e782ada to
b1fe67d
Compare
julianwiedmann
left a comment
There was a problem hiding this comment.
Just a few smaller things left ...
73d4507 to
a51d1a6
Compare
a51d1a6 to
c9e8c30
Compare
|
(looking at the CI failures, you'll need to adjust for #44755) |
c9e8c30 to
ae30fd9
Compare
|
@julianwiedmann yup just saw that on my end prior to reading that comment, handled in latest force push. |
78203d8 to
47a5253
Compare
04d006c to
54c7ee8
Compare
|
/test |
50b9932 to
c7322ee
Compare
Add a flag for opt-in of dynamic source IP resolution in the N/S nodeport loadbalancing path, not yet implemented. Signed-off-by: Louis DeLosSantos <louis.delos@isovalent.com>
Add a probe to test if the BPF_FIB_LOOKUP_SRC flag is supported for the bpf_fib_lookup helper. This probe results in a new config variable declared in node.h, `supports_fib_lookup_src`, which informs the data-path if the preferred source IP can be retrieved on fib lookup. Signed-off-by: Louis DeLosSantos <louis.delos@isovalent.com>
Perform dynamic source IP resolution for SNAT in the N/S nodeport load balancing path. Introduce the `fib_lookup_src_v[4|6]` for resolving a source address given a destination. Utilize this method in the nodeport egress SNAT path for both native routing mode SNAT and post-SNAT tunnel mode encapsulation. Signed-off-by: Louis DeLosSantos <louis.delos@isovalent.com>
Add three new tests which ensure source IP resolution works correctly in the nodeport load balancing path when supported. Signed-off-by: Louis DeLosSantos <louis.delos@isovalent.com>
c7322ee to
8d0620d
Compare
|
/test |
This pull request uses the fairly new
BPF_FIB_LOOKUP_SRCFIB lookup flag to support dynamic source IP resolution in the N/S node port load balancing path.A new flag is introduced to opt into this new functionality
--enable-dynamic-source-lookup-nodeport,nodePort.enableDynamicSourceLookupbeing the Helm analog.Additionally a probe is added which short-circuits the source IP lookup functionality if the kernel does not support it.
When the flag is enabled and the kernel supports the feature the N/S load balancing path will dynamically resolve the preferred source IP, from the kernel's FIB perspective, it should use for the SNAT operation prior to forwarding the packet to the final destination.
This pull request makes no change in the data path which immediately delivers a node port request to a local backend, as no SNAT is required.