On 4/14/23 23:12, Ihar Hrachyshka wrote:
> When setting flows for LS, OVN distinguishes between two states: where
> there’s a stateful ACL present in its list (has_stateful == true *)
> and when it’s missing (all ACLs are stateless).
> 
> When has_stateful == true, the following is done (among other things):
> - ct handling flows are set;
> - they are omitted by a higher priority flow for “service” protocols:
>   NA, RA, MLD.
> 
> The latter is done because of a known issue in kernel ct
> implementation for the protocols:
> 
> * https://bugzilla.kernel.org/show_bug.cgi?id=11797
> 
> The assumption is that by default OVN allows all traffic unless
> explicitly forbidden, so omitting ct flows only avoids ct machinery
> but doesn't affect functional behavior of flow tables for the
> protocols.
> 
> But if an ACL that forbids these protocols is configured, because of
> the ct omittance, this ACL is not in effect. (But only when
> has_stateful == true.)
> 
> This behavior results in inconsistent and confusing behavior in
> OpenStack Neutron where
> 
> (1) the default security group behavior is drop all IP traffic
> (achieved with default "drop" Port_Group); and
> (2) ports that have stateful and stateless ACLs configured can
> co-exist in the same network.
> 
> In which case, depending on other "stateful" ports present in the
> network, "stateless" ports may or may not observe RA / NA / MLD
> traffic. Which affects their IPv6 address configuration.
> 
> In this patch, I suggest that we don't make RA / NA / MLD behavior
> dependent on whether "stateful" ACLs are present. Instead, make the
> protocols always allowed, regardless of ACLs configured (whether
> stateful ACLs or ACLs that forbid packets of these protocols).
> 
> Note: an argument can be made that the same "always-on" behavior
> should be guaranteed for ARP protocol that serves a similar goal in a
> IPv4 network as RA / NA do for IPv6 networks. This scenario is not
> directly related to the inconsistency between "purely stateless" and
> "mixed-stateful" networks and hence is left for a follow-up patch.
> 
> Note: this patch carries a test case that utilizes scapy tool to
> construct packets for the protocols under test. A proper backport may
> demand backporting scapy related patches too.
> 
> Reported-At: https://bugs.launchpad.net/neutron/+bug/2006949
> Reported-At: https://bugzilla.redhat.com/show_bug.cgi?id=2149731
> Signed-off-by: Ihar Hrachyshka <ihrac...@redhat.com>
> ---
> v1: initial version.
> v2: remove debug ov?-*ctl commands from the new test case.
> v2: adjust failing test cases that didn't expect new flows.
> v3: add always-on flow for S_SWITCH_IN_ACL_AFTER_LB stage too.
> v3: adjust acls used in test case to include --apply-after-lb.
> v3: update more test cases that match the list of flows against
>     expected.
> v4: added missing 'check' prefixes for test case ctl commands.
> v5: fixed a test failure due to a typo in v4.
> ---

Thanks, Ihar!

I applied this to main and backported it to all stable branches down to
22.03.  I also had to cherry pick b84b89664974 ("nbctl: Display
"apply-after-lb" information when listing ACLs.") to branches <= 22.12
to prevent the new test case from failing.

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to