In flow-filter, mark NAT requirements for packets #1225
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The enum holds per-port-range data associated with connecting to a given destination IP prefix: it contains destination VPC discriminants for all valid exposed (IP prefix + port range) for the given IP prefix. Rename it to make this notion more explicit. Signed-off-by: Quentin Monnet <qmo@qmon.net>
Move the destination VPC discriminant that we return from a flow-filter lookup into a dedicated RemoteData struct. Right now this is the only field of the struct, but we'll add another one in a follow-up commit. Signed-off-by: Quentin Monnet <qmo@qmon.net>
Based on the user-provided configuration, store in the flow-filter table whether a connection between given prefixes would require stateful NAT, stateless NAT, or no NAT for the source and destination IPs and ports. We will use it in a follow-up commit to mark packets accordingly. Signed-off-by: Quentin Monnet <qmo@qmon.net>
Make the code less verbose by passing an Option<VpcDiscriminant> rather than an Option<Vni> to helper create_test_packet(), and reusing the existing variables when available. Signed-off-by: Quentin Monnet <qmo@qmon.net>
This will help us figure out whether NAT, what NAT mode, and for what direction, is required for a given packet. We'll use it to simplify some of the processing in the NAT stage, in a follow-up commit. Signed-off-by: Quentin Monnet <qmo@qmon.net>
Now that we mark packets for stateful or stateless NAT, let's use the flags to determine whether a packet requires to go through the NAT stages at all. Signed-off-by: Quentin Monnet <qmo@qmon.net>
Now that we mark packets that require stateful NAT, we don't need the additional "exempt [from stateful NAT] table" lookup anymore. Let's remove it. Because of the change of internal behaviour for the stateful NAT stage, we remove test portions where we had no NAT happening. This is OK, because the pipeline stage will no longer process packets that don't require NAT, so we do not need to validate this code path now. Signed-off-by: Quentin Monnet <qmo@qmon.net>
Now that we mark packets that require stateful NAT, we should never have a case when we failed to find the prefix matching the source IP in the NAT pools (because no prefix for this IP means we shouldn't be trying to NAT the packet in the first place). We could remove the related error, but just in case, leave it in place and log an error if this ever happens. Signed-off-by: Quentin Monnet <qmo@qmon.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Based on the context we have for the flow-filter stage, it's easy to add NAT requirements and to attach them to packets, to simplify processing in the NAT stages (and avoid traversing the NAT stages in the first place for the packets that don't require it).
Work in progress.