On 11/11/25 3:49 AM, shy liu wrote: > Hi Dumitru, > Hi Xie Liu,
> Thanks for your review. > > On Mon, Nov 10, 2025 at 7:42 PM Dumitru Ceara <[email protected]> wrote: >> >> Hi Xie Liu, >> >> Thanks for the patch! >> >> On 11/7/25 5:48 AM, [email protected] wrote: >>> From: Xie Liu <[email protected]> >>> >>> Consider the case of stateful Firewall for N-S traffic: >>> >>> PUBLIC---S1-(S1-R1)---------(R1-S1)-R1 -------- S2 ---- VM1 >>> >>> Configuration: >>> >>> ovn-nbctl pg-add pg_dgw >>> ovn-nbctl pg-set-ports pg_dgw S1-R1 >>> ovn-nbctl acl-add pg_dgw from-lport 2000 "inport == @pg_dgw && ip4 && >>> icmp4" allow-related >>> ovn-nbctl acl-add pg_dgw from-lport 1000 "outport == @pg_dgw && ip4" drop >>> ovn-nbctl acl-add pg_dgw to-lport 1000 "outport == @pg_dgw && ip4" drop >>> ovn-nbctl lsp-set-options S1-R1 router-port=R1-S1 >>> enable_router_port_acl=true >>> >>> VM1 pings external network. >>> >>> Through this patch[1], the ovn-controller assigned a CT zone ID >>> to the localnet LSP but not the dgw LSP. >>> >>> This caused ACL failures: ICMP reply packets from external networks >>> performed CT lookups in the wrong zone, couldn't match established >>> connections, and were incorrectly dropped. >> >> While I understand why the CT lookup in the wrong zone (in the VIF zone) >> causes issues, I have my concerns about this behavior change. >> >>> >>> Fix by ensuring ports without CT zone allocation use default zone 0, >>> preventing incorrect zone inheritance and restoring proper ACL behavior >>> for distributed gateway scenarios. >>> >> >> Default zone 0 is most likely already used by the host traffic. Which >> means we might have unexpected collisions here. Please see the >> ovn-kubernetes use case where traffic from the host itself is also sent >> through conntrack (also in zone 0). >> >> Would a correct approach be to instead allocate explicit zone ids for >> ports that have enable_router_port_acl=true? > Yes, allocating explicit zone IDs for ports with enable_router_port_acl=true > is also an option I have considered. It indeed looks more reasonable, > and I will adopt this approach in the next patch. Thank you, looking forward to the next revision. Regards, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
