On 11/28/22 09:53, Eelco Chaudron wrote:
> The datapath supports installing wider flows, and OVS relies on
> this behavior. For example if ipv4(src=1.1.1.1/192.0.0.0,
> dst=1.1.1.2/192.0.0.0) exists, a wider flow (smaller mask) of
> ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/128.0.0.0) is allowed
> to be added.
>
> However, if we try to add a wildcard rule, the installation fails:
>
> # ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
> ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
> # ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
> ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
> ovs-vswitchd: updating flow table (File exists)
>
> The reason is that the key used to determine if the flow is already
> present in the system uses the original key ANDed with the mask.
> This results in the IP address not being part of the (miniflow) key,
> i.e., being substituted with an all-zero value. When doing the actual
> lookup, this results in the key wrongfully matching the first flow,
> and therefore the flow does not get installed. The solution is to use
> the unmasked key for the existence check, the same way this is handled
> in the "slow" dpif_flow_put() case.
>
> OVS relies on the fact that overlapping flows can exist if one is a
> superset of the other. Note that this is only true when the same set
> of actions is applied. This is due to how the revalidator process
> works. During revalidation, OVS removes too generic flows from the
> datapath to avoid incorrect matches but allows too narrow flows to
> stay in the datapath to avoid the data plane disruption and also to
> avoid constant flow deletions if the datapath ignores wildcards on
> certain fields/bits. See flow_wildcards_has_extra() check in the
> revalidate_ukey__() function.
>
> The problem here is that we have a too narrow flow installed, and now
> OpenFlow rules got changed, so the actual flow should be more generic.
> Revalidators will not remove the narrow flow, and we will eventually get
> an upcall on the packet that doesn't match the narrow flow, but we will
> not be able to install a more generic flow because after masking with
> the new wider mask, the key matches on the narrow flow, so we get EEXIST.
>
> Fixes: beb75a40fdc2 ("userspace: Switching of L3 packets in L2 pipeline")
> Signed-off-by: Eelco Chaudron <echau...@redhat.com>
>
> ---
Thanks! Applied and backported down to 2.17.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
