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 >> > > _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
