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 1513009

Summary:	NetworkManager doesn't honor ip address order again
Product:	Red Hat Enterprise Linux 7	Reporter:	MiR <rovnanik>
Component:	NetworkManager	Assignee:	sushil kulkarni <sukulkar>
Status:	CLOSED WORKSFORME	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	7.4	CC:	antaylor, atragler, bgalvani, c.handel, derfian, desktop-qa-list, fedora, fgiudici, fweimer, ilmis, jan.engels, lrintel, mabrown, marco.mauritsch, msugaya, riehecky, rkhan, rmanes, rovnanik, rsawhill, sukulkar, thaller, tis, vasmith, vbenes, villapla
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1394500	Environment:
Last Closed:	2017-12-20 15:38: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 MiR 2017-11-14 15:13:35 UTC

+++ This bug was initially created as a clone of Bug #1394500 +++

ifcfg-eth0 has:

IPADDR=192.168.95.26
PREFIX=24
IPADDR1=192.168.95.25
PREFIX1=24
GATEWAY=192.168.95.1

192.168.95.26 is expected to be primary ip.

After update to RHEL 7.4 with NetworkManager-1.8.0-11.el7_4.x86_64, the 192.168.95.25 is used as primary ip.

It is expected that ip configured as primary ip is primary ip.

Please fix this regression as soon as possible becasue that affects source address selection causing servers to use wrong source ip.

Only ipv4 is affected, ipv6 address order is still honored.

Comment 2 Thomas Haller 2017-11-14 15:41:43 UTC

Thanks for reporting the bug.

The original issue was closed and verified. If you see similar symptoms, it is quite possibly for a different reason.
At least, with the provided configuration, the issue doesn't seem to reproduce for me. More information is required.

Please enable level=TRACE logging and attach the logfile showing the issue. 

Preferably, enable debug logging in the config file and restart NetworkManager to get complete logs from the start. See hints at https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf for how to get a logfile. Thank you.

Comment 3 MiR 2017-11-16 16:48:20 UTC

(In reply to Thomas Haller from comment #2)

Hi, thank you for your response.
I can't play with this anymore, the server is in production state. I wasn't able to investigate this issue, the update window was over. As a workaround I deleted the second IP address from the ifcfg file and added it by hand after. This way it is communicating as expected.

We have another server with the same configuration, just the IPs are in ascending order *.27 primary, *.28 secondary. This server was also updated and restarted at the same time with no network issue.

Both servers are physical (no vmware or so) HP ProLiant DL380 Gen9, RHEL 7.4, kernel 3.10.0-693.5.2.el7.x86_64, two NICs in teaming, LACP.

The whole ifcfg-team0 is like this:
=====
DEVICE=team0
DEVICETYPE=Team
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=no
IPV6_DEFROUTE=no
IPV6_FAILURE_FATAL=no
NAME=team0
UUID=c4c013e4-063f-4955-9e52-2aef7b66068c
ONBOOT=yes
TEAM_CONFIG="{   \"device\": \"team0\",   \"runner\": {     \"name\": \"lacp\",     \"active\": true,     \"fast_rate\": false,     \"tx_hash\": [\"eth\", \"ipv4\", \"ipv6\"]   },   \"link_watch\": {\"name\": \"ethtool\"},   \"ports\": {\"eno49\": {}, \"ens4f0\": {}} }"
IPV6_PEERDNS=no
IPV6_PEERROUTES=no
IPADDR=192.168.95.26
PREFIX=24
GATEWAY=192.168.95.1
=====

I just removed these lines to make it work:
=====
IPADDR1=192.168.95.25
PREFIX1=24
=====

What I can only try is to create two virtual machines in our lab to make some tests later.

Thank you, MiR

Comment 4 MiR 2017-12-19 18:14:05 UTC

Hi, I am not able to reproduce this problem on my test machines, and that production machine is not available for testing.

So feel free to close this bug report, maybe it was just some unique situation.

Thank you, MiR