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 2165874 - ovs-interface and mac cloning not working as expected
Summary: ovs-interface and mac cloning not working as expected
Keywords:
Status: CLOSED DUPLICATE of bug 2168477
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: nmstate
Version: 9.2
Hardware: All
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Gris Ge
QA Contact: Mingyu Shi
URL:
Whiteboard:
Depends On: 2168477
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-31 10:41 UTC by Quique Llorente
Modified: 2023-02-21 05:19 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-02-21 05:19:44 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker NMT-223 0 None None None 2023-01-31 10:42:15 UTC
Red Hat Issue Tracker RHELPLAN-147014 0 None None None 2023-01-31 10:42:19 UTC

Description Quique Llorente 2023-01-31 10:41:08 UTC 
Description of problem:

Cloning mac-address at ovs-interrface does not work as expected and DHCP is not assigning the expected address


Version-Release number of selected component (if applicable): nmstate-2.2.3-3.el9.x86_64


How reproducible: Always


Steps to Reproduce:
1. Retrieve the mac address from eth0 (let's say it's 52:55:00:D1:55:02)
2. Configure a ovs-bridge with eth0 as a port and other port with ovs-interface with cloned mac
- ipv4:
    dhcp: true
    enabled: true
  mac-address: 52:55:00:D1:55:02
  name: ovs0
  state: up
  type: ovs-interface
- bridge:
    options:
      stp: true
    port:
    - name: eth0
    - name: ovs0
  name: br69
  state: up
  type: ovs-bridge

Actual results:
ovs0 ovs-interface is not getting the expected IP from DHCP server


Expected results:
ovs0 ovs-interface has the same address previously owned by eth0


Additional info:
CI job: https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/nmstate_kubernetes-nmstate/1059/pull-kubernetes-nmstate-e2e-handler-k8s/1615696734632022016

NetworkManager logs https://gcsweb.ci.kubevirt.io/gcs/kubevirt-prow/pr-logs/pull/nmstate_kubernetes-nmstate/1059/pull-kubernetes-nmstate-e2e-handler-k8s/1615696734632022016/artifacts/NodeNetworkConfigurationPolicy_default_ovs-bridged_network_when_there_is_a_default_interface_with_dynamic_address_and_ovs_bridge_on_top_of_the_default_interface/

Looks like git repo version nmstate-2.2.4-0.alpha.20230118.8ec213b8 is working fine
Comment 1 Quique Llorente 2023-02-01 06:51:29 UTC 
We were pining to Gris personal repo to a temporal fix for centos 8 stream, this is for python, we will have the results with latest centos 9 stream soon.
Comment 2 Quique Llorente 2023-02-02 13:53:50 UTC 
We have reproduce it locally, looks like a race between NetworkManager cloning the mac and sending the DHCP DISCOVER

This is the dnsmasq logs when test is working fine 

dnsmasq-dhcp: DHCPDISCOVER(br0) 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPOFFER(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPACK(br0) 192.168.66.102 52:55:00:d1:55:02 node02
dnsmasq-dhcp: DHCPDISCOVER(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPOFFER(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPACK(br0) 192.168.66.102 52:55:00:d1:55:02 node02
dnsmasq-dhcp: DHCPDISCOVER(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPOFFER(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPACK(br0) 192.168.66.102 52:55:00:d1:55:02 node02
dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPACK(br0) 192.168.66.102 52:55:00:d1:55:02 node02

This is when failing 

dnsmasq-dhcp: DHCPDISCOVER(br0) 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPOFFER(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPACK(br0) 192.168.66.102 52:55:00:d1:55:02 node02
dnsmasq-dhcp: DHCPDISCOVER(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPOFFER(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPACK(br0) 192.168.66.102 52:55:00:d1:55:02 node02
dnsmasq-dhcp: DHCPDISCOVER(br0) 192.168.66.102 aa:c2:13:bc:b9:43 
dnsmasq-dhcp: DHCPOFFER(br0) 192.168.66.79 aa:c2:13:bc:b9:43 
dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.66.79 aa:c2:13:bc:b9:43 
dnsmasq-dhcp: DHCPACK(br0) 192.168.66.79 aa:c2:13:bc:b9:43 
dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.66.102 52:55:00:d1:55:02 
dnsmasq-dhcp: DHCPACK(br0) 192.168.66.102 52:55:00:d1:55:02 node02

So clearly this is the unexpected DHCPDISCOVER send by NetworkManager

dnsmasq-dhcp: DHCPDISCOVER(br0) 192.168.66.102 aa:c2:13:bc:b9:43 <- this is the generated mac not the cloned one from ovs0 interface

Then we have the following logs at NM

Feb 02 13:21:41 node02 NetworkManager[1697]: <info>  [1675344101.8489] dhcp4 (ovs0): activation: beginning transaction (no timeout)
Feb 02 13:21:41 node02 NetworkManager[1697]: <info>  [1675344101.8498] device (ovs0): set-hw-addr: set-cloned MAC address to 52:55:00:D1:55:02 (52:55:00:D1:55:02)
Feb 02 13:21:42 localhost.localdomain NetworkManager[1697]: <info>  [1675344102.9608] audit: op="checkpoint-adjust-rollback-timeout" arg="/org/freedesktop/NetworkManager/Checkpoint/1" pid=4017 uid=0 result="success"
Feb 02 13:22:18 localhost.localdomain NetworkManager[1697]: <info>  [1675344138.4800] dhcp4 (ovs0): state changed new lease, address=192.168.66.79
Feb 02 13:22:18 localhost.localdomain NetworkManager[1697]: <info>  [1675344138.4817] policy: set 'ovs0-if' (ovs0) as default for IPv4 routing and DNS

So NetworkManager is cloning the address but the ip address received by DHCP is like it was not cloned at all.

Same test with nmstate-git copr is working fine it also install a lot of dependencies at the nmstate-handler container.
Comment 3 Gris Ge 2023-02-09 07:03:26 UTC 
Problem reproduced on NM latest git build also.

Might be NetworkManager bug https://bugzilla.redhat.com/show_bug.cgi?id=2168477 waiting debug result from NM team.
Comment 4 Gris Ge 2023-02-21 05:19:44 UTC 

*** This bug has been marked as a duplicate of bug 2168477 ***
Note You need to log in before you can comment on or make changes to this bug.