RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1966382 - cannot change accept-all-mac-addresses of an ovs internal interface
Summary: cannot change accept-all-mac-addresses of an ovs internal interface
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: nmstate
Version: 8.5
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: beta
: ---
Assignee: Gris Ge
QA Contact: Mingyu Shi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-01 03:02 UTC by Mingyu Shi
Modified: 2021-06-22 15:09 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-22 15:09:03 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)

Description Mingyu Shi 2021-06-01 03:02:48 UTC 
Description of problem:
Nmstate cannot change accept-all-mac-addresses of an ovs internal interface. It works well on a system interface.

Version-Release number of selected component (if applicable):
nmstate-1.1.0-0.1.el8.noarch
nispor-1.1.0-1.el8.x86_64
NetworkManager-1.32.0-0.4.el8.x86_64
openvswitch2.13-2.13.0-105.el8fdp.x86_64

How reproducible:
100%

Steps to Reproduce:
echo "interfaces:
- name: ovsbr0
  type: ovs-bridge
  state: up
  bridge:
    port:
    - name: ovs0" | nmstatectl apply -

echo "interfaces:
- name: ovs0
  type: ovs-interface
  state: up
  accept-all-mac-addresses: true" | nmstatectl apply -


Actual results:
Traceback (most recent call last):
  File "/usr/bin/nmstatectl", line 11, in <module>
    load_entry_point('nmstate==1.1.0', 'console_scripts', 'nmstatectl')()
  File "/usr/lib/python3.6/site-packages/nmstatectl/nmstatectl.py", line 73, in main
    return args.func(args)
  File "/usr/lib/python3.6/site-packages/nmstatectl/nmstatectl.py", line 343, in apply
    args.save_to_disk,
  File "/usr/lib/python3.6/site-packages/nmstatectl/nmstatectl.py", line 407, in apply_state
    save_to_disk=save_to_disk,
  File "/usr/lib/python3.6/site-packages/libnmstate/netapplier.py", line 81, in apply
    _apply_ifaces_state(plugins, net_state, verify_change, save_to_disk)
  File "/usr/lib/python3.6/site-packages/libnmstate/netapplier.py", line 132, in _apply_ifaces_state
    _verify_change(plugins, net_state)
  File "/usr/lib/python3.6/site-packages/libnmstate/netapplier.py", line 145, in _verify_change
    net_state.verify(current_state)
  File "/usr/lib/python3.6/site-packages/libnmstate/net_state.py", line 83, in verify
    self._ifaces.verify(current_state.get(Interface.KEY))
  File "/usr/lib/python3.6/site-packages/libnmstate/ifaces/ifaces.py", line 658, in verify
    cur_iface.state_for_verify(),
libnmstate.error.NmstateVerificationError: 
desired
=======
---
name: ovs0
type: ovs-interface
state: up
accept-all-mac-addresses: true

current
=======
---
name: ovs0
type: ovs-interface
state: up
accept-all-mac-addresses: false
ipv4:
  enabled: false
ipv6:
  enabled: false
lldp:
  enabled: false
mac-address: 2A:77:DE:CA:E0:F0
mtu: 1500
ovs-db:
  external_ids:
    NM.connection.uuid: 604c63cb-bf78-481f-be05-83b21bd89ddd

difference
==========
--- desired
+++ current
@@ -2,4 +2,15 @@
 name: ovs0
 type: ovs-interface
 state: up
-accept-all-mac-addresses: true
+accept-all-mac-addresses: false
+ipv4:
+  enabled: false
+ipv6:
+  enabled: false
+lldp:
+  enabled: false
+mac-address: 2A:77:DE:CA:E0:F0
+mtu: 1500
+ovs-db:
+  external_ids:
+    NM.connection.uuid: 604c63cb-bf78-481f-be05-83b21bd89ddd

Expected results:
No failure

Additional info:
`ip link set ovs0 promisc on` can do, and `nmstatectl show` can report the correct value
Comment 1 Fernando F. Mancera 2021-06-08 22:57:21 UTC 
Hi Mingyu, does it make sense to enable accept all mac addresses mode on ovs internal interface? The kernel allow it because is an interface flag but I think it is useless. I didn't find any usecase on the internet.

For example, in kernel you can enable this for infiniband interfaces but it is useless so NetworkManager does not support it.

What do you think?

Thanks,
Fernando.
Comment 2 Mingyu Shi 2021-06-10 08:37:13 UTC 
Hi Fernando,

I agree with you: for an ovs internal interface, I don't think this feature is important, either. As this feature works on ovs system interface, which users care about in general.

However, from the side of a crazy tester/bug hunter :) , I think this error more or less confuses: it is shown by nmstate and technically configurable, but just go wrong and the reason is not clear.
IMO, it's a potential experience issue rather than a bug, I will lower the priority.

If working on it at present is not worth, please feel free to close it. We can reopen it when needed.
Note You need to log in before you can comment on or make changes to this bug.