Bug 1313091 - the restart of NetworkManager service disables a configured connection and creates a dynamic connection
the restart of NetworkManager service disables a configured connection and cr...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.2
Unspecified Linux
medium Severity low
: rc
: ---
Assigned To: Beniamino Galvani
Desktop QE
:
Depends On:
Blocks: 1350679
  Show dependency treegraph
 
Reported: 2016-02-29 17:44 EST by João Avelino Bellomo Filho
Modified: 2016-11-03 15:08 EDT (History)
9 users (show)

See Also:
Fixed In Version: NetworkManager-1.4.0-0.1.git20160606.b769b4df.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 15:08:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description João Avelino Bellomo Filho 2016-02-29 17:44:37 EST
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 06:03:21 EST
(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 11:07:39 EDT
I think ifcfg-rh should probably ignore GATEWAY when DEFROUTE=no and certainly warn about the configuration.
Comment 4 Beniamino Galvani 2016-03-17 05:28:15 EDT
(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 17:34:32 EDT
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 18:20:08 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 9 Joachim Backes 2016-04-16 04:33:29 EDT
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 10:40:18 EDT
(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 13:32:25 EDT
(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 10:29:22 EDT
(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 11:58:40 EDT
I like v2. lgtm
Comment 14 Lubomir Rintel 2016-04-27 10:54:21 EDT
looks good to me too
Comment 30 Vladimir Benes 2016-08-31 04:43:51 EDT
GW and never-default is working well over NM restart.
Comment 32 errata-xmlrpc 2016-11-03 15:08:17 EDT
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.