Red Hat Bugzilla – Bug 1313091
the restart of NetworkManager service disables a configured connection and creates a dynamic connection
Last modified: 2016-11-03 15:08:17 EDT
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.
(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.
I think ifcfg-rh should probably ignore GATEWAY when DEFROUTE=no and certainly warn about the configuration.
(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.
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.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Having similar problems in Fedora 24 (See https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/Z3T5B4TDMMGEH45ZIH5PCBCB5VJVN45I/)
(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?
(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).
(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.
I like v2. lgtm
looks good to me too
GW and never-default is working well over NM restart.
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