bpf: nodeport: SNAT before adding tunnel info in NAT egress path #25305
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When forwarding to a remote backend via tunnel, we currently first add the encap info and only then apply SNAT to the packet. Meaning that the TRACE_TO_OVERLAY in __encap_with_nodeid() doesn't report the final header content.
This is in contrast to the non-tunnel path (where the TRACE_TO_NETWORK in to-netdev will report the post-SNAT header content), and the reply path (where from-overlay raises the TRACE_FROM_OVERLAY long before checking for revSNAT).
So re-order the NAT egress path to first apply SNAT, and then add the encap info afterwards.
For now this just helps to make the TRACE_TO_OVERLAY entry consistent. In the future it's also needed to enable in-XDP encap (as we want to SNAT the inner packet, before adding the encap headers).