Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
Given a system with VLAN over bond holding static IPv4 address created by nmstate
When user bring all bond ports link down and bring them up again after 10 seconds
Then user are expecting VLAN of bond got reactivated with original desired IPv4 address.
Version-Release number of selected component (if applicable):
NetworkManager-1.30.0-14.el8_4.x86_64
How reproducible:
100%
Steps to Reproduce:
1. wget http://file.apac.redhat.com/fge/OCPBUGS-11300/bug.sh
2. chmod +x bug.sh
3. sudo ./bug.sh
Actual results:
The `bond0.1656` got no IPv4 address assigned.
Expected results:
The `bond0.1656` got IPv4 address assigned.
Additional info:
This is customer case in https://issues.redhat.com/browse/OCPBUGS-11300
The content of http://file.apac.redhat.com/fge/OCPBUGS-11300/bug.sh is:
#!/bin/bash -x
ip netns add tmp
ip link add eth2 type veth peer name eth2peer
ip link add eth1 type veth peer name eth1peer
ip link set eth1 up
ip link set eth2 up
ip link set eth1peer netns tmp
ip link set eth2peer netns tmp
ip netns exec tmp ip link set eth1peer up
ip netns exec tmp ip link set eth2peer up
nmcli device set eth1 managed yes
nmcli device set eth2 managed yes
echo 'interfaces:
- name: bond0
type: bond
state: up
ipv4:
enabled: false
ipv6:
enabled: false
link-aggregation:
mode: active-backup
options:
miimon: 100
port:
- eth1
- eth2
- name: bond0.1656
type: vlan
state: up
ipv4:
enabled: true
dhcp: false
address:
- ip: 192.168.122.10
prefix-length: 24
ipv6:
enabled: false
vlan:
base-iface: bond0
id: 1656
- name: eth2
type: ethernet
state: up
- name: eth1
type: ethernet
state: up' | sudo nmstatectl set -
echo 'interfaces:
- name: bond0
type: bond
state: up
ipv4:
enabled: false
ipv6:
enabled: false
link-aggregation:
mode: active-backup
options:
miimon: 100
port:
- eth1
- eth2
- name: bond0.1656
type: vlan
state: up
ipv4:
enabled: true
dhcp: false
address:
- ip: 192.168.122.10
prefix-length: 24
ipv6:
enabled: false
vlan:
base-iface: bond0
id: 1656
- name: eth2
type: ethernet
state: up
- name: eth1
type: ethernet
state: up' | sudo nmstatectl set -
ip addr show bond0.1656
ip link set eth1 down
ip link set eth2 down
sleep 10
ip addr show bond0.1656
ip link set eth1 up
ip link set eth2 up
sleep 10
ip addr show bond0.1656
nmcli c
nmcli d
Comment 4Beniamino Galvani
2023-05-31 09:06:09 UTC
From the log and the discussion we had, it seems that the problem is that nmstate blocks autoconnect when adding/updating the connection; this prevents the connection to go up when the bond gets carrier again.
The solution is that nmstate should unblock autoconnect when it's done. It seems to me there is no API currently to do that, so we should either:
1. unblock the connection when the Reapply() D-Bus is called. This probably solves the nmstate use case, but I can't think of a reason why this should be expected from an API point of view;
2. introduce a new Update() flag to unblock autoconnect; this seems the best approach to me;
3. maybe, use the AUTOCONNECT property on the device instead to block autoconnect?
Forgot to mention, to reproduce the problem, you also need to crate /etc/NetworkManager/conf.d/ignore_carrier.conf with content
[main]
ignore-carrier=no
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:7118