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 1313091 - the restart of NetworkManager service disables a configured connection and creates a dynamic connection
Summary: the restart of NetworkManager service disables a configured connection and cr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.2
Hardware: Unspecified
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1350679
TreeView+ depends on / blocked
 
Reported: 2016-02-29 22:44 UTC by João Avelino Bellomo Filho
Modified: 2020-02-14 17:41 UTC (History)
9 users (show)

Fixed In Version: NetworkManager-1.4.0-0.1.git20160606.b769b4df.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 19:08:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2581 0 normal SHIPPED_LIVE Low: NetworkManager security, bug fix, and enhancement update 2016-11-03 12:08:07 UTC

Description João Avelino Bellomo Filho 2016-02-29 22:44:37 UTC 
Description of problem:

A restart of the NetworkManager service disables a connection and create a dynamic connection to the NIC related to the connection disabled.

The a system has two NIC and a NetworkManager connection configured to each one. The starting of the NetworkManager service works without issues, but if the service is restarted will be created a dynamic connection to the first NIC and the configured connection related to that NIC is disabled.

Version-Release number of selected component (if applicable):

NetworkManager-1.0.6-27.el7.x86_64

How reproducible:


Steps to Reproduce:

1. On a system with at least two NIC configure two connections on NetworkManager:

# head -n 100 /etc/sysconfig/network-scripts/ifcfg-conn*
==> /etc/sysconfig/network-scripts/ifcfg-conn0 <==
TYPE=Ethernet
BOOTPROTO=none
IPADDR=10.1.1.25
PREFIX=32
GATEWAY=10.1.1.1
DEFROUTE=no
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=conn0
UUID=a9abf672-12fd-4bed-8bd3-f854e755343b
DEVICE=ens3
ONBOOT=yes

==> /etc/sysconfig/network-scripts/ifcfg-conn1 <==
TYPE=Ethernet
BOOTPROTO=none
IPADDR=172.168.1.25
PREFIX=32
GATEWAY=172.168.1.1
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=conn1
UUID=bb0199d8-29b8-45bc-aecf-1dc8ab1fecad
DEVICE=ens4
ONBOOT=yes

2. Stop the service:

# systemctl stop NetworkManager

3. Start the service and check the result:

# systemctl start NetworkManager
# nmcli c
NAME   UUID                                  TYPE            DEVICE 
ens5   97368dce-9563-43a6-af5f-023d55f45912  802-3-ethernet  --     
ens6   d81af9c5-8d41-4b35-92b1-1c79597da983  802-3-ethernet  --     
conn0  a9abf672-12fd-4bed-8bd3-f854e755343b  802-3-ethernet  ens3   
conn1  bb0199d8-29b8-45bc-aecf-1dc8ab1fecad  802-3-ethernet  ens4   
ens7   4b7552c0-c66d-4d81-8bdc-f60dcc83fb59  802-3-ethernet  -- 

4. Restart the NetworkManager service:

# systemctl restart NetworkManager

Actual results:

# nmcli c
NAME   UUID                                  TYPE            DEVICE 
ens5   97368dce-9563-43a6-af5f-023d55f45912  802-3-ethernet  --     
ens6   d81af9c5-8d41-4b35-92b1-1c79597da983  802-3-ethernet  --     
conn0  a9abf672-12fd-4bed-8bd3-f854e755343b  802-3-ethernet  --     
ens3   8c6f2471-876e-4656-b89a-ff7f0995a44e  802-3-ethernet  ens3   
conn1  bb0199d8-29b8-45bc-aecf-1dc8ab1fecad  802-3-ethernet  ens4   
ens7   4b7552c0-c66d-4d81-8bdc-f60dcc83fb59  802-3-ethernet  --     


Expected results:

The expected result should be the same from step 3:

# nmcli c
NAME   UUID                                  TYPE            DEVICE 
ens5   97368dce-9563-43a6-af5f-023d55f45912  802-3-ethernet  --     
ens6   d81af9c5-8d41-4b35-92b1-1c79597da983  802-3-ethernet  --     
conn0  a9abf672-12fd-4bed-8bd3-f854e755343b  802-3-ethernet  ens3   
conn1  bb0199d8-29b8-45bc-aecf-1dc8ab1fecad  802-3-ethernet  ens4   
ens7   4b7552c0-c66d-4d81-8bdc-f60dcc83fb59  802-3-ethernet  -- 

Additional info:

If the gateway from conn0 connection is removed the issue does not happen.
Comment 2 Beniamino Galvani 2016-03-01 11:03:21 UTC 
(In reply to João Avelino Bellomo Filho from comment #0)
> Description of problem:
>
> A restart of the NetworkManager service disables a connection and create a
> dynamic connection to the NIC related to the connection disabled.

> # head -n 100 /etc/sysconfig/network-scripts/ifcfg-conn*
> ==> /etc/sysconfig/network-scripts/ifcfg-conn0 <==
> TYPE=Ethernet
> BOOTPROTO=none
> IPADDR=10.1.1.25
> PREFIX=32
> GATEWAY=10.1.1.1
> DEFROUTE=no

What confuses NM is the presence of both a GATEWAY and DEFROUTE=no
(which indicates not to set a default route). After a restart of the
service, the connection matching code doesn't find a default route
associated with the connection and discards conn0 as a possible match.

NM should handle better this situation; however the configuration as
written has some conflicting keys which should be fixed.
Comment 3 Dan Williams 2016-03-15 15:07:39 UTC 
I think ifcfg-rh should probably ignore GATEWAY when DEFROUTE=no and certainly warn about the configuration.
Comment 4 Beniamino Galvani 2016-03-17 09:28:15 UTC 
(In reply to Dan Williams from comment #3)
> I think ifcfg-rh should probably ignore GATEWAY when DEFROUTE=no and
> certainly warn about the configuration.

Right, but I wonder if this should be fixed at a higher level, because
there is the same problem when using the keyfile plugin. Maybe
consider this as a normalizable error during verify of
NMSettingIPConfig and remove the gateway during normalization? The
downside is that when never-default is enabled and a user adds a
gateway it will silently disappear, which is kind of unexpected.
Comment 5 Beniamino Galvani 2016-03-22 21:34:32 UTC 
IMO we should do the following:

 - ignore the gateway if never-default is set when loading a
   connection in both the ifcfg-rh and keyfile plugins, so that
   existing configurations continue to work

 - make gateway and never-default mutually exclusive and consider the
   IP setting invalid if both are present, so that users cannot create
   ambiguous configurations

Please review branch bg/gateway-never-default-rh1313091.
Comment 6 Mike McCune 2016-03-28 22:20:08 UTC 
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Comment 9 Joachim Backes 2016-04-16 08:33:29 UTC 
Having similar problems in Fedora 24 (See https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/Z3T5B4TDMMGEH45ZIH5PCBCB5VJVN45I/)
Comment 10 Beniamino Galvani 2016-04-21 14:40:18 UTC 
(In reply to Joachim Backes from comment #9)
> Having similar problems in Fedora 24 (See
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/
> thread/Z3T5B4TDMMGEH45ZIH5PCBCB5VJVN45I/)

Hi, can you please show the output of 'nmcli c' before and after the restart?
Comment 11 Thomas Haller 2016-04-21 17:32:25 UTC 
(In reply to Beniamino Galvani from comment #5)
> IMO we should do the following:
> 
>  - ignore the gateway if never-default is set when loading a
>    connection in both the ifcfg-rh and keyfile plugins, so that
>    existing configurations continue to work
> 
>  - make gateway and never-default mutually exclusive and consider the
>    IP setting invalid if both are present, so that users cannot create
>    ambiguous configurations
> 
> Please review branch bg/gateway-never-default-rh1313091.

>> libnm-core: don't allow a gateway to be set with never-default

this is a change in behavior on D-Bus: if a user happens to send Update(), the connection would now fail verification and be rejected. That might be right.

But an alternative would be to make this a normalizable error and fix it during normalization.
Then you also don't need the change to keyfile, because it would just be normalized.
(you would need the change to ifcfg-rh, if you want to print a warning about it).
Comment 12 Beniamino Galvani 2016-04-23 14:29:22 UTC 
(In reply to Thomas Haller from comment #11)
> this is a change in behavior on D-Bus: if a user happens to send Update(),
> the connection would now fail verification and be rejected. That might be
> right.

Yeah, unfortunately this changes behavior, however I'm not sure if it's worse than accepting an inconsistent configuration and report success.
 
> But an alternative would be to make this a normalizable error and fix it
> during normalization.
> Then you also don't need the change to keyfile, because it would just be
> normalized.
> (you would need the change to ifcfg-rh, if you want to print a warning about
> it).

Sounds like a better idea to me, pushed bg/gateway-never-default-rh1313091-v2.
Comment 13 Thomas Haller 2016-04-26 15:58:40 UTC 
I like v2. lgtm
Comment 14 Lubomir Rintel 2016-04-27 14:54:21 UTC 
looks good to me too
Comment 30 Vladimir Benes 2016-08-31 08:43:51 UTC 
GW and never-default is working well over NM restart.
Comment 32 errata-xmlrpc 2016-11-03 19:08:17 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, 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://rhn.redhat.com/errata/RHSA-2016-2581.html
Note You need to log in before you can comment on or make changes to this bug.