Re-add flow-table-based dst_vpcd lookup in case of prefixes overlap #1257
+1,953
−252
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
Fredi-raspall
force-pushed
the
pr/fredi/nat_use_cases
branch
2 times, most recently
from
b738ec1 to
50d68da
Compare
qmonnet
changed the title
qmonnet
force-pushed
the
pr/fredi/nat_use_cases
branch
from
50d68da to
5b0b995
Compare
Member
|
I simply rebased on |
Differentiate between 2 cases when logging: - no flow entry is found in table for a given key - did not build a flow key (because of the type of packet) Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
Add srcVpcd to FlowTuple so that it gets displayed/logged too. The flowTuple type could be used as the single input to the lookup function. Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
Make it such that no string needs to be created. Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
Flow-filter should be the first stage so that other stages can use the flow-info. Up until now, the flow-filter couldn't because it preceeded the flow-lookup stage. Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
Augment FlowInfoLocked to include a VpcDiscriminant so that we can determine the dst VPC from a flow entry as a fallback. Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
Rename the type (NF) so that it is clear its purpose. Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
If, in the flow filter, the destination vpc (discriminant) cannot be determined for a packet, try to discover it from the flow-info attached to the packet. Ofc, the correctness of this depends on whether we store a flow-entry for the corresponding flow and what information we keep there. Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
qmonnet
force-pushed
the
pr/fredi/nat_use_cases
branch
from
5b0b995 to
b8c8518
Compare
And update NAT tests accordingly. Co-authored-by: Quentin Monnet <qmo@qmon.net> Signed-off-by: Quentin Monnet <qmo@qmon.net> Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
This will allow us to handle the case when we have multiple matching possible destination VPCs for a packet in the flow-filter lookup, to support some overlap of publicly-exposed prefixes between peerings. The current commit only adds the enum with a single variant, we'll add a new variant in a follow-up commit. This is somewhat of a revert of commit d588e14 ("chore(flow-filter): Remove code for exposed IP overlap support"). Signed-off-by: Quentin Monnet <qmo@qmon.net>
For the destination VPC lookup, support returning a "MultipleMatches" variant indicating that the destination is ambiguous, and that looking up in the flow-filter table without additional state context from the flow table is not enough to provide a definitive answer. Based on this return value, we adjust the processing for the packet: if we find no destination VPC at all, we drop it immediately. When we get MultipleMatches instead, we fall back to the flow table lookup. Note that we don't actually exercise this code yet, because we never build the case where we have multiple matches in the flow-filter table. This will come in a follow-up commit. Signed-off-by: Quentin Monnet <qmo@qmon.net>
In preparation for allowing support again for some cases of overlapping prefixes, adjust the update() method for DstConnectionData objects so it accepts overwriting a value, when both the old and new value refer to multiple matches for the destination VPC lookup. Signed-off-by: Quentin Monnet <qmo@qmon.net>
Generate "MultipleMatches" enum variants to populate the table for the destination VPC discriminant lookup for prefixes that overlap across peerings, so we can handle this specific case and fall back to the flow table lookup for trying to determine the actual destination VPC when the result is otherwise ambiguous. Note that prefix overlap is still forbidden at the validation step, so the related code remains unused in practice for now. Signed-off-by: Quentin Monnet <qmo@qmon.net>
In preparation for splitting overlapping prefixes to support overlapping again, this time with "default"-destination expose blocks, rework the processing of a peering to add it to the context table for the flow-filter stage. In particular, we want to dissociate the processing of the default expose from the processing of the prefixes from regular exposes, because for the latter case we want to work with list of prefixes (local_prefixes, remote_prefixes) rather than looping over exposes. This will help with handling lists of split prefixes in a follow-up commit. This reapplies some elements from commit d588e14 ("chore(flow-filter): Remove code for exposed IP overlap support"). Signed-off-by: Quentin Monnet <qmo@qmon.net>
Add support partial overlap between exposed prefixes, by splitting prefixes into smaller segments that are either fully overlapping (and can share common destination information), or not overlapping at all. This is a partial and updated reapply of commit d588e14 ("chore(flow-filter): Remove code for exposed IP overlap support"). Signed-off-by: Quentin Monnet <qmo@qmon.net>
The motivation is to better troubleshoot flow table lookups: printing the table in Debug mode is particularly tedious because of the circular dependencies inside the allocated NAT resources (ports linking to IPs linking to allocator containing the ports etc.). The new dump format is sooo much easier to work with. Note that we can't implement Display for FlowTable's values directly, because the type is not defined in the flow-info crate (we use NatFlowState<I> objects that are defined only in the "nat" crate, which depends on flow-info, and we can't introduce a circular dependency). So we make FlowInfoItem require the Display trait as well, to make sure we can leverage it when printing values in FlowTable's implementation for Display. We also improve the Display implementation for NatFlowState and FlowKeyData, and add the one for FlowKey, as all of them are used for FlowTable. Signed-off-by: Quentin Monnet <qmo@qmon.net>
If we consider VPC 1 peered with both VPC 2 and VPC 3, with VPC 2 and VPC 3 exposing the same prefix to VPC 1, we have an issue for determining the destination VPC. We've been preventing this situation to happen by rejecting overlap at the validation step. However, if VPC 2 and VPC 3 both use stateful NAT, then we'll create a flow table entry when either of these send a packet, and we may be able to determine the destination VPC based on that entry. So we enable overlap again, at the condition that both exposes containing the overlapping prefixes use stateful NAT. We had this support in the past, we're only re-introducing the feature. Signed-off-by: Quentin Monnet <qmo@qmon.net>
Following the recent re-introduction of support for overlapping prefixes when involved expose blocks use stateful NAT, re-introduce the relevant unit tests in the flow-filter and nat crates. This is a partial (rebased) reapply of commit 514646a ("chore(flow-filter): Remove code for exposed IP overlap support"). Signed-off-by: Quentin Monnet <qmo@qmon.net>
qmonnet
force-pushed
the
pr/fredi/nat_use_cases
branch
from
c7b016c to
0ade936
Compare
Member
|
I squashed the NAT tests fixes into |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
No description provided.