Sounds great, thanks for the quick fix! Stéphane
On Tue, Dec 9, 2025 at 3:55 AM Dumitru Ceara <[email protected]> wrote: > > Hi Stéphane, > > On 12/9/25 12:27 AM, Stéphane Graber wrote: > > On Mon, Dec 8, 2025 at 2:57 PM Dumitru Ceara <[email protected]> wrote: > >> On 12/7/25 12:07 AM, Stéphane Graber via discuss wrote: > >>> Hello, > >>> > >> > >> Hi Stéphane, > >> > >>> Incus makes pretty active use of port groups and ACLs to handle > >>> firewalling/micro-segmentation within its networks. > >>> One thing we use quite a bit within our ACLs is the ability to refer > >>> to port groups in `inport` and `outport` (@ syntax). > >>> > >>> An issue we've noticed with that is that ovn-northd seems to only > >>> populate Port_Group entries in SB if they currently contain a port. > >>> For ease of maintenance, we pretty often will generate ACLs that > >>> reference a port group that's currently empty. > >>> > >> > >> I'm not sure I understand the use case. If the port group is empty then > >> that ACL will never match, will it? > > > > So basically we're decoupling the population of the ACL table from our > > users' configuration with them actually having a match on the > > source/target part. > > That allows for pushing through an ACL that for example would match > > ingress from any database server even though there currently are no > > such database servers deployed. > > Then when a database server is in fact deployed, it gets added to the > > relevant port group and now the ACL rule actually has a chance to > > match something. > > > > Makes sense. > > > We certainly could add a bunch of logic on our side to figure out > > whether a particular rule is referring to a port group that's > > currently empty and if so, exclude it. > > But at that point, why even use port groups. If we need to do the > > tracking ourselves, we could just provide the individual ports > > directly in the rule. > > > > No, you shouldn't do the tracking on your side, that's what port groups > are for, you're right. > > > I understand (and am relieved) that this is really just a warning and > > that it doesn't other impede the generation of the flows. > > That said, nobody really likes being presented with a wall of > > potentially thousands of warnings when running something like > > ovn-trace :) > > Well sure but I'm not sure I follow why users would run ovn-trace > themselves. ovn-trace is a debugging / troubleshooting tool. > > However, you can just run with log level ERR to not see all the warnings. > > ovn-trace -vovntrace:err ... > > In any case, it's a bit weird that we don't rate limit the warnings in > ovn-trace (we only do it for some things). I prepared a patch to do > that here: > > https://patchwork.ozlabs.org/project/ovn/patch/[email protected]/ > > That should help significantly reduce the wall of warnings you're getting. > > Please let us know if that works for you. > > Regards, > Dumitru > > > > > Stéphane > > > >>> This seems to be causing some problems as it appears that port groups > >>> without any ports currently in them will not be populated in the > >>> Southbound database. > >>> The result is a bunch of errors like this: > >>> > >>> ``` > >>> 2025-12-06T22:51:58Z|00002|ovntrace|WARN|reg0[8] == 1 && ((inport == > >>> @incus_acl10_egress_reversed) && (outport == > >>> "incus-net6-ls-int-lsp-router") && (tcp) && (tcp.dst == 80)): parsing > >>> expression failed (Syntax error at `@incus_acl10_egress_reversed' > >>> expecting port group name.) > >>> 2025-12-06T22:51:58Z|00003|ovntrace|WARN|reg0[7] == 1 && ((inport == > >>> @incus_acl10_egress_reversed) && (outport == > >>> "incus-net6-ls-int-lsp-router") && (tcp) && (tcp.dst == 443)): parsing > >>> expression failed (Syntax error at `@incus_acl10_egress_reversed' > >>> expecting port group name.) > >>> 2025-12-06T22:51:58Z|00004|ovntrace|WARN|reg0[7] == 1 && ((inport == > >>> @incus_acl40_egress_reversed) && (outport == > >>> "incus-net9-ls-int-lsp-router") && (tcp) && (tcp.dst == 443)): parsing > >>> expression failed (Syntax error at `@incus_acl40_egress_reversed' > >>> expecting port group name.) > >>> 2025-12-06T22:51:58Z|00005|ovntrace|WARN|reg0[8] == 1 && ((inport == > >>> @incus_acl48_egress_reversed) && (outport == > >>> "incus-net9-ls-int-lsp-router")): parsing expression failed (Syntax > >>> error at `@incus_acl48_egress_reversed' expecting port group name.) > >>> 2025-12-06T22:51:58Z|00006|ovntrace|WARN|reg0[8] == 1 && ((inport == > >>> @incus_acl40_egress_reversed) && (outport == > >>> "incus-net9-ls-int-lsp-router") && (tcp) && (tcp.dst == 80)): parsing > >>> expression failed (Syntax error at `@incus_acl40_egress_reversed' > >>> expecting port group name.) > >>> 2025-12-06T22:51:58Z|00007|ovntrace|WARN|reg0[7] == 1 && ((inport == > >>> @incus_acl10_egress_reversed) && (outport == > >>> "incus-net6-ls-int-lsp-router") && (tcp) && (tcp.dst == 80)): parsing > >>> expression failed (Syntax error at `@incus_acl10_egress_reversed' > >>> expecting port group name.) > >>> 2025-12-06T22:51:58Z|00008|ovntrace|WARN|reg0[8] == 1 && ((inport == > >>> @incus_acl9_egress_reversed) && (outport == > >>> "incus-net6-ls-int-lsp-router")): parsing expression failed (Syntax > >>> error at `@incus_acl9_egress_reversed' expecting port group name.) > >>> 2025-12-06T22:51:58Z|00009|ovntrace|WARN|reg0[8] == 1 && ((inport == > >>> @incus_acl10_egress_reversed) && (outport == > >>> "incus-net6-ls-int-lsp-router") && (tcp) && (tcp.dst == 443)): parsing > >>> expression failed (Syntax error at `@incus_acl10_egress_reversed' > >>> expecting port group name.) > >>> 2025-12-06T22:51:58Z|00010|ovntrace|WARN|reg0[7] == 1 && ((inport == > >>> @incus_acl9_egress_reversed) && (outport == > >>> "incus-net6-ls-int-lsp-router")): parsing expression failed (Syntax > >>> error at `@incus_acl9_egress_reversed' expecting port group name.) > >>> 2025-12-06T22:51:58Z|00011|ovntrace|WARN|reg0[7] == 1 && ((inport == > >>> @incus_acl48_egress_reversed) && (outport == > >>> "incus-net9-ls-int-lsp-router")): parsing expression failed (Syntax > >>> error at `@incus_acl48_egress_reversed' expecting port group name.) > >>> 2025-12-06T22:51:58Z|00012|ovntrace|WARN|reg0[8] == 1 && ((inport == > >>> @incus_acl40_egress_reversed) && (outport == > >>> "incus-net9-ls-int-lsp-router") && (tcp) && (tcp.dst == 443)): parsing > >>> expression failed (Syntax error at `@incus_acl40_egress_reversed' > >>> expecting port group name.) > >>> 2025-12-06T22:51:58Z|00013|ovntrace|WARN|reg0[7] == 1 && ((inport == > >>> @incus_acl40_egress_reversed) && (outport == > >>> "incus-net9-ls-int-lsp-router") && (tcp) && (tcp.dst == 80)): parsing > >>> expression failed (Syntax error at `@incus_acl40_egress_reversed' > >>> expecting port group name.) > >>> ``` > >>> > >>> The output above is what we get as a prelude to running ovn-trace in > >>> this case, but it also shows up in other contexts, it was just the > >>> easiest way to get all of them out in one shot. > >>> > >> > >> While I understand that might look alarming it's not more than ovn-trace > >> (or ovn-controller as I assume that's the other context you see this in) > >> ignoring that logical flow. Which is fine because, as I said above, if > >> I understand correctly the use case, these flows can never match. > >> > >>> To me it feels like, northd should either: > >>> - Count usage in an ACL as a valid reference requiring the inclusion > >>> of the port group into the SB DB > >>> - Somehow optimize the ACL rules in SB to handle the missing port > >>> groups, re-writing them back to their normal content when the port > >>> group does become active > >>> > >> > >> This last part should already be happening. As soon as the port group > >> becomes "non-empty" all ovn-controllers that handle logical switches (as > >> "local datapaths") with ports in the port group will generate the > >> corresponding OpenFlow rules for the ACLs that use the port group. > >> > >> If that's not the case, it sounds a bit like a bug. > >> > >>> Above is on current OVS 3.6.1 and OVN 25.09.2. > >>> > >>> Stéphane > >> > >> Regards, > >> Dumitru > >> > > > > > -- Stéphane _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
