Sure thing, Vladislav, thanks for the update! would appreciate it if you keep 
me posted on the progress.

regards,

-venu
________________________________
From: Vladislav Odintsov <[email protected]>
Sent: Friday, November 22, 2024 2:06 AM
To: Venu Iyer <[email protected]>
Cc: Han Zhou <[email protected]>; Dumitru Ceara <[email protected]>; ovs dev 
<[email protected]>
Subject: Re: [ovs-dev] [ovn] Unable to mix Load Balancers with allow-stateless 
ACL

External email: Use caution opening links or attachments


Hi Venu,


On 21.11.2024 03:32, Venu Iyer wrote:
Thanks Dumitru!

Hi, Vladislav :


________________________________
From: Dumitru Ceara <[email protected]><mailto:[email protected]>
Sent: Wednesday, November 20, 2024 3:26 PM
To: Vladislav Odintsov <[email protected]><mailto:[email protected]>; ovs 
dev <[email protected]><mailto:[email protected]>
Cc: Han Zhou <[email protected]><mailto:[email protected]>; Venu Iyer 
<[email protected]><mailto:[email protected]>
Subject: Re: [ovs-dev] [ovn] Unable to mix Load Balancers with allow-stateless 
ACL

External email: Use caution opening links or attachments


On 11/21/24 00:12, Dumitru Ceara wrote:
> On 11/5/24 18:05, Vladislav Odintsov wrote:
>> Hi all,
>>
>
> Hi Vladislav,
>
>> I've tried to upgrade OVN from 22.09.1 to the fresh version and our
>> internal tests showed that commit [0] broke scenario where we do use in
>> logical switches both: Load Balancers AND allow-stateless ACLs at the
>> same time.
>>
>
> Thanks for the report!  I added Venu (original author of [0]) and Han in CC.
>
>> Prior to this change all traffic directed to load balancer's IP address
>> passed to conntrack and finally worked correctly, while there were
>> allow-stateless rules, which, for example covered all other traffic,
>> except this LB.
>>

Prior to this commit[0], IIRC, if there was any LB on the switch, there was no 
stateless
handling, even "allow-stateless" would be tracked.


>> We use such mix because of need both: LBs and stateless handling for all
>> traffic except LB.
>>
>
> If I understand the change in [0] correctly it will only skip the egress
> pre-LB stage if traffic _matched_ the "allow-stateless" to-lport ACL.

Right.

> Is that your case too?
>
> From the ovn-nb documentation (even before [0] was committed):
>
>   allow-stateless: Always forward the packet in stateless
>     manner, omitting connection tracking mechanism, regardless of other
>     rules defined for the switch.
>
> If I'm reading this correctly, it already implied that the CMS needs to
> ensure that the stateless ACLs don't match any traffic that might have
> to go to conntrack (including reply traffic that's part of a load
> balanced session).
>

I believe even with stateful and stateless on a switch, the intent was to always
prioritize stateless; i.e. if there is an overlap, stateless will take 
precedence.
Do you have an overlap between the LB and stateless flows? If so, as Dumitru 
suggested, is it
possible to avoid the  overlap?

I had an offline talk to Dumitru on ovscon, we will try to express this in ACL 
conditions. There is a possible negative matching problem for the returning 
traffic from LB backends, I'll get back after we finish our experiments. To 
unlock the wanted OVN upgrade we'll try to temporarily revert the mentioned 
patch.

thanks,

-venu

>> Also, this patch was backported to a minor releases, which brought major
>> behavior changes (now we can't upgrade to 22.09.2+ without reverting
>> mentioned patch).
>>
>> Is there any advice, how this can be fixed (except revert in our local
>> repo)?
>>
>
> Would it be possible to change your allow-stateless to-lport ACLs to
> exclude LB backend IPs (because your problem seems to be related to
> reply traffic)?
>
> I'm not sure how feasible it is, but an option might be to create a
> higher priority allow-related to-lport ACL that matches on all traffic
> coming from load balancer backends.  There's still a chance that we
> match more traffic than we should and send it through conntrack (e.g.,
> if the backend IP+port is actually the originator of other connections -
> non LB).  But that might be acceptable.
>

On second thought, that probably won't work because allow-related ACLs
don't generate flows in the ls_out_pre_acl stage (only allow-related
ACLs do).

It's a bit icky but (depending on the number of LB backends you have) it
might work if you change your allow-stateless ACLs to match whatever
traffic they currently match _except_ LB backend+port combinations.  Is
that an option for you?

>> 0:
>> https://github.com/ovn-org/ovn/commit/a0f82efdd9dfd3ef2d9606c1890e353df1097a51
>>
>
> Regards,
> Dumitru
>


--
Regards,
Vladislav Odintsov
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to