OVN log plugin merges log records from different log objects across projects

Bug #2110087 reported by Oleksandr Kozachenko

This bug report will be marked for expiration in 22 days if no further activity occurs. (find out why)

6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Incomplete
Undecided
Unassigned

Bug Description

The ovn-controller log plugin in Neutron appears to incorrectly associate log entries when security groups are used across different projects. When VMs in different projects (and domains) each have their own security groups and log objects, the log output from ovn-controller shows traffic to both VMs under the same log object, instead of segregating them by their correct log objects.

### How to Reproduce

1. Create two projects in different domains, e.g.:

   * `project-a` in `domain-a`
   * `project-b` in `domain-b`

2. In each project:

   * Create a security group (e.g., `sg-a` in `project-a`, `sg-b` in `project-b`)
   * Launch a VM (e.g., `vm-a` and `vm-b`)
   * Assign the respective security group to the VM

3. In each project:

   * Create a Neutron log object that tracks traffic for the corresponding security group (i.e., one for `sg-a`, one for `sg-b`)

4. Generate some network traffic involving both VMs (e.g., incoming pings or TCP traffic to the VMs)

---

### Observed Behavior

* The `ovn-controller` logs show destination IPs for both `vm-a` and `vm-b`
* However, all log entries are being attributed to only one of the Neutron log objects, despite being from different security groups and different projects/domains

---

### Expected Behavior

* Each log object should capture only the traffic related to the security group and project it is associated with
* Traffic logs should not be cross-associated or merged across different log objects, projects, or domains

Revision history for this message
Miro Tomaska (mtomaska) wrote (last edit ):

Hi Olegsandr,

Can you attach ovn-controller log showing the log entries you described?
Which openstack and OVN version are you using?

Thank you

Revision history for this message
Miro Tomaska (mtomaska) wrote :
Download full text (3.5 KiB)

Hi Olegsandr,

So I created two different domains, projects, users and security groups and then associated each security group with its own network log object. Lastly, I created a VM in each project

Network log output:

+--------------------------------------+---------+----------------+----------------+---------------------------------------------------------------+
| ID | Enabled | Name | Type | Summary |
+--------------------------------------+---------+----------------+----------------+---------------------------------------------------------------+
| acd4aa7c-635e-4fe9-aaa7-62b25a253fbf | True | security_log_b | security_group | Event: ALL, |
| | | | | Logged: (security_group) 2f25d1c6-a696-4978-a225-ca9dd8df8ba9 |
| fd9caf20-08b6-40e1-bde8-c33aee1f675a | True | security_log_a | security_group | Event: ALL, |
| | | | | Logged: (security_group) f621bad6-367f-4ecd-9fc8-e47ae22e95c2 |
+--------------------------------------+---------+----------------+----------------+---------------------------------------------------------------+

+--------------------------------------+------+--------+------------------------+--------------------------+-----------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+------+--------+------------------------+--------------------------+-----------+
| 892cec2e-4f06-41c7-9ccc-b39b57d66ffc | vm-b | ACTIVE | shared=192.168.233.237 | cirros-0.6.3-x86_64-disk | cirros256 |
| 94ea158e-4ada-4008-92f7-e53f1ba907aa | vm-a | ACTIVE | shared=192.168.233.47 | cirros-0.6.3-x86_64-disk | cirros256 |
+--------------------------------------+------+--------+------------------------+--------------------------+-----------+

Pinging each VM IP once resulted in following logs in ovn-controller.log

2025-05-08T19:10:50.022Z|00166|acl_log(ovn_pinctrl3)|INFO|name="neutron-fd9caf20-08b6-40e1-bde8-c33aee1f675a", verdict=drop, severity=info, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=fa:16:3e:68:e3:67,dl_dst=fa:16:3e:83:c6:e4,nw_src=192.168.233.2,nw_dst=192.168.233.237,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0

2025-05-08T19:11:10.918Z|00167|acl_log(ovn_pinctrl3)|INFO|name="neutron-fd9caf20-08b6-40e1-bde8-c33aee1f675a", verdict=drop, severity=info, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=fa:16:3e:68:e3:67,dl_dst=fa:16:3e:ee:9e:38,nw_src=192.168.233.2,nw_dst=192.168.233.47,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0

Is that more or less what you see in your ovn-controller.log?

In my ovn-controller.log I see `neutron-fd9caf20-08b6-40e1-bde8-c33aee1f675a` name repeating for each new log created even if I am pinging different port... I think that might be a bug but I would have to dig deeper into this feature... If i d...

Read more...

Revision history for this message
Elvira García Ruiz (elviragr) wrote (last edit ):

Hi, this is because of a known limitation in Security Group Logging with OVN that is given from the ML2/OVN architecture.

- Neutron works by blacklisting, this is, all traffic is dropped unless it's otherwise specified.
- Opposite to that, OVN works by whitelisting, all traffic is allowed unless it's otherwise specified.

In OVN, dropped and accepted traffic is monitored and allowed through ACL (Access Control List) entries on the DB. To deal with this with difference on what we allow, Neutron has a general ACL that monitors ALL dropped traffic, which is called neutron_pg_drop. Since the logging we can do is totally binded to the ACLs we have, the end result is that we can either enable or disable logging DROP traffic for all SGs or none.

This means that if you choose to log both ACCEPT and DROP traffic (ALL event), you will have the side effect of logging all dropped traffic.

There has been some attemps to modify the blacklisting method and remove this limitation, but we did not ever get that to a merge status, unfortunately for this feature. See https://review.opendev.org/c/openstack/neutron/+/839066

This is also explained on the packet logging documentation: https://docs.openstack.org/neutron/latest/admin/config-logging.html

Revision history for this message
Miro Tomaska (mtomaska) wrote :

Hi Olegsandr,

So I discussused this issue with Elvira. The behavior I saw in my comment is expected. Neutron will create a drop OVN ACL for anything that is not explicitly allowed in neutron security group. In my case sg-a and sg-b did not have allow ICMP security rule. Thus the ovn-controller.log all drop under the same general drop ACL, in my case it was `neutron-fd9caf20-08b6-40e1-bde8-c33aee1f675a`.

If you could post your ovn-controller.log to see what you are seeing, that would be great.

Lastly, as I mentioned in my comment 1
"As far as showing only logs that belong that project(if I understand your concern correctly) would be outside of this feature. OVN does not have concept of separate projects. OVN-controller is only concerned about the chassis it is on and ports that are bound to it."

Changed in neutron:
status: New → Incomplete
Revision history for this message
Oleksandr Kozachenko (okozachenko) wrote :
Download full text (5.4 KiB)

Hi Miro and Elvira.
Thanks for your digging into this.

Here is the detailed information you requested.

```
❯ openstack --os-cloud ark-dev-1-admin network log create --resource-type security_group --resource deny-all-ingress --project 21108-dev --event ALL test-log-21108
❯ openstack --os-cloud ark-dev-1-admin network log create --resource-type security_group --resource ark-trusted-ingress --project 63781-app-dev --event ALL ark-trusted

❯ openstack --os-cloud ark-dev-1-admin network log list
+--------------------------------------+---------+----------------+----------------+---------------------------------------------------------------+
| ID | Enabled | Name | Type | Summary |
+--------------------------------------+---------+----------------+----------------+---------------------------------------------------------------+
| 4054c65c-9a05-4bf4-8abe-f31959dbd56f | True | ark-trusted | security_group | Event: ALL, |
| | | | | Logged: (security_group) c40034c8-8393-4a72-9ca9-6d4be2da5db1 |
| 4bb3d932-b31c-49b8-a802-320c9aacd9ae | True | test-log-21108 | security_group | Event: ALL, |
| | | | | Logged: (security_group) 9775b1e6-0e6b-4b12-a53d-0067e65a0665 |
+--------------------------------------+---------+----------------+----------------+---------------------------------------------------------------+

❯ openstack --os-cloud ark-dev-1-admin security group list | grep c40034c8-8393-4a72-9ca9-6d4be2da5db1
| c40034c8-8393-4a72-9ca9-6d4be2da5db1 | ark-trusted-ingress | | da5ee651377b44bdb7be83d1c91f00e9 | [] |
❯ openstack --os-cloud ark-dev-1-admin security group list | grep 9775b1e6-0e6b-4b12-a53d-0067e65a0665
| 9775b1e6-0e6b-4b12-a53d-0067e65a0665 | deny-all-ingress | | a8155c67fd214da1a5c1eec70169fcbb | [] |

❯ openstack --os-cloud ark-dev-1-admin project show da5ee651377b44bdb7be83d1c91f00e9
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | |
| domain_id | 937521fdda004ebeb4adffbcbc9f4ab9 |
| enabled | True |
| id | da5ee651377b44bdb7be83d1c91f00e9 |
| is_domain | False |
| name | 63781-app-dev |
| options | {} |
| parent_id | 937521fdda004ebeb4adffbcbc9f4ab9 |
| tags | [] |
+-------------+----------------------------------+
❯ openstack --os-cloud ark-dev-1-admin project show a8155c67fd214da1a5c1eec70169fcbb ...

Read more...

Revision history for this message
Oleksandr Kozachenko (okozachenko) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.