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. 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. 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 :) 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
