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.

Bug 2028751

Summary: The ipv4.dad-timeout parameter in NetworkManager is invalid for bonding device.
Product: Red Hat Enterprise Linux 8 Reporter: xiaoyali
Component: NetworkManagerAssignee: Fernando F. Mancera <ferferna>
Status: CLOSED ERRATA QA Contact: David Jaša <djasa>
Severity: medium Docs Contact:
Priority: high    
Version: 8.5CC: bgalvani, djasa, ferferna, fge, lrintel, rkhan, sukulkar, till, vbenes
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: NetworkManager-1.36.0-0.8.el8 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-10 14:54:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description xiaoyali 2021-12-03 07:05:41 UTC
Description of problem:
- The ipv4.dad-timeout parameter in NetworkManager is invalid for bonding device.

Version-Release number of selected component (if applicable):
- NetworkManager-1.32.10-4.el8.x86_64

How reproducible:


Steps to Reproduce:
1. First configure an IP address like 192.168.5.1/24 in 192.168.5.0/24 subnet on a RHEL server like:

# nmcli con add type ethernet ifname eth5 con-name eth5 ipv4.addresses 192.168.5.1/24 ipv4.method manual
# nmcli con up eth5

2. Next configure the bonding using the same IP address on the other RHEL server within the same subnet:

# nmcli con add type bond ifname bond0 con-name bond0 bond.option mode=1 ipv4.addresses 192.168.5.1/24 ipv4.method manual ipv4.dad-timeout 2001
# nmcli con add type bond-slave ifname eno1 con-name eno1 master bond0
# nmcli con add type bond-slave ifname eno2 con-name eno2 master bond0
# nmcli con up bond0

3.

Actual results:
- The bond0 device can be up.

Expected results:
- The bond0 device should not be up because of the ipv4.dad-timeout parameter which will detect the conflict address.

Additional info:
- There is also no warning from NetworkManager in the message log.
- As my test, if not using bond, only configure the eth5 with the same ip address and ipv4.dad-timeout parameter, NetworkManager will not let the eth5 up if the duplicate address is detected by DAD.

Comment 1 xiaoyali 2021-12-03 07:18:13 UTC
Just want to update the Additional info:

Additional info:
- There is also no warning from NetworkManager in the message log.
- As my test, if not using bond, only configure the eno1 on the other RHEL server with the same ip address and ipv4.dad-timeout parameter, NetworkManager will not let the eno1 up if the duplicate address is detected by DAD.

- And I also reproduce the same issue in RHEL 7's latest NetworkManager(NetworkManager-1.18.8-2.el7_9.x86_64). The only difference is the NetworkManager in RHEL 7 will print the warn message like below:
~~~
NetworkManager[790]: <warn>  [1638336733.5504] device (bond0): IPv4 DAD result: address 192.168.5.1 is duplicate
~~~

- And I can use arping -D to detect the duplicate address which configures on bonding device. ( https://access.redhat.com/solutions/28876 )

Comment 3 Gris Ge 2022-01-06 09:42:38 UTC
Acceptance criteria: The IPv4 and IPv6 DAD(duplicate address detection) should works the same on bond interface.

Comment 10 Beniamino Galvani 2022-02-10 12:52:43 UTC
I have verified that the fix works as expected with the following script:

#!/bin/sh                                                                                                                                                                                            

ip netns add ns1
ip link add veth0 type veth peer name veth1
ip link set veth1 netns ns1
ip -n ns1 link set veth1 up
ip -n ns1 addr add dev veth1 172.25.13.1/24

nmcli connection add type bond ifname bond1 con-name bond1+ ip4 172.25.13.1/24 ipv4.dad-timeout 3000 connection.autoconnect no connection.autoconnect-slaves yes
nmcli connection add type ethernet ifname veth0 con-name veth0-port+ master bond1 connection.autoconnect no
nmcli connection up bond1+

sleep 5

if ip addr show dev bond1 | grep -q 172.25.13.1; then
    echo "*** Error ***"
    exit 1
fi

exit 0

Comment 11 Beniamino Galvani 2022-02-10 16:16:07 UTC
Note that the expectation is that, in case of an address conflict, the bridge/bond/team will remain active but without the conflicting address.

Comment 18 David Jaša 2022-02-22 12:57:40 UTC
ok in 1.36.0-0.8. Verified in virtual environment using just veth pair as testbed to avoid ARP drops by Linux bridge (so my change to assigned in comment 14 looks bogus with my current knowledge of the situation).

Automated test:
- commit: https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/commit/55ea70222e08db2e7e323e9585bd848588ef3beb
- MR: https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/965

Comment 22 errata-xmlrpc 2022-05-10 14:54:52 UTC
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/RHEA-2022:1985