Bug 1503769 - ip route add default via is not working
Summary: ip route add default via is not working
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
: 1544537 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-18 17:17 UTC by Ade Bradshaw
Modified: 2021-03-11 16:02 UTC (History)
15 users (show)

Fixed In Version: NetworkManager-1:1.10.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 13:31:31 UTC
Target Upstream Version:


Attachments (Terms of Use)
Screenshot of above on 7.4 (74.16 KB, image/png)
2017-10-18 17:17 UTC, Ade Bradshaw
no flags Details
ip monitor 1 or 2 (111.33 KB, image/png)
2017-10-18 21:04 UTC, Ade Bradshaw
no flags Details
ip monitor 2 or 2 (158.50 KB, image/png)
2017-10-18 21:05 UTC, Ade Bradshaw
no flags Details
NM log (90.37 KB, text/x-vhdl)
2018-01-12 16:34 UTC, Thomas Haller
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0778 0 None None None 2018-04-10 13:32:56 UTC

Description Ade Bradshaw 2017-10-18 17:17:20 UTC
Created attachment 1340293 [details]
Screenshot of above on 7.4

Description of problem:
Adding a default route via the ip command no longer works

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


How reproducible:
100%

Steps to Reproduce:
1.delete your default route (ip route delete default
2.check the routing table (ip r)
3.add it back (ip route add default via x.x.x.x)
4 check the routing table again - not there

Actual results:
no default route added and no error either


Expected results:
A default gateway


Additional info:

Comment 2 Phil Sutter 2017-10-18 18:22:59 UTC
Hi Ade,

(In reply to Ade Bradshaw from comment #0)
> Created attachment 1340293 [details]
> Screenshot of above on 7.4
> 
> Description of problem:
> Adding a default route via the ip command no longer works
> 
> Version-Release number of selected component (if applicable):
> 
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1.delete your default route (ip route delete default
> 2.check the routing table (ip r)
> 3.add it back (ip route add default via x.x.x.x)
> 4 check the routing table again - not there

I can't reproduce this issue on my RHEL7 VM. According to your screen shot,
there is no error returned by iproute when adding the default route. So I
guess that operation was successful but some other instance dropped your route
again before you could verify it's there. To check this, could you please run
'ip monitor' in a second terminal and then repeat the 'ip r d' && 'ip r a'
commands? The monitor process should print what's happening.

Thanks, Phil

Comment 4 Ade Bradshaw 2017-10-18 21:04:19 UTC
Created attachment 1340382 [details]
ip monitor 1 or 2

These are the commands I ran with ip monitor running in another console - see 2nd attachment for monitor outpur

Comment 5 Ade Bradshaw 2017-10-18 21:05:15 UTC
Created attachment 1340383 [details]
ip monitor 2 or 2

This is the output of the ip monitor command while doing the steps i the other screenshot

Comment 6 Ade Bradshaw 2017-10-18 21:08:43 UTC
Just as a quick update - the version of iproute I have is

  iproute-3.10.0-87.el7.x86_64

The system was provisioned by Satellite6

Comment 7 Ade Bradshaw 2017-10-18 21:17:51 UTC
Maybe this is useful also

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
BOOTPROTO="dhcp"
DEVICE=eth0
HWADDR="00:1a:4a:16:01:82"
ONBOOT=yes
PEERDNS=yes
PEERROUTES=yes

Comment 8 Evgeni Golov 2017-10-19 06:23:44 UTC
I can trivially reproduce this on the official CentOS 7 Vagrant image (version 1708.01, https://app.vagrantup.com/centos/boxes/7):

[root@centos7 ~]# ip r s
default via 192.168.121.1 dev eth0 proto static metric 100 
192.168.121.0/24 dev eth0 proto kernel scope link src 192.168.121.41 metric 100 
[root@centos7 ~]# ip r del default via 192.168.121.1 dev eth0
[root@centos7 ~]# ip r s
192.168.121.0/24 dev eth0 proto kernel scope link src 192.168.121.41 metric 100 
[root@centos7 ~]# ip r add default via 192.168.121.1 dev eth0
[root@centos7 ~]# ip r s
192.168.121.0/24 dev eth0 proto kernel scope link src 192.168.121.41 metric 100 
[root@centos7 ~]# ip r add 0/0 via 192.168.121.1 dev eth0
[root@centos7 ~]# ip r s
192.168.121.0/24 dev eth0 proto kernel scope link src 192.168.121.41 metric 100

Comment 10 Evgeni Golov 2017-10-19 06:37:18 UTC
removing NetworkManager fixes the issue

Comment 11 Evgeni Golov 2017-10-19 06:42:22 UTC
and so does setting NM_CONTROLLED="no" in /etc/sysconfig/network-scripts/ifcfg-eth0

Comment 12 Phil Sutter 2017-10-19 07:14:39 UTC
OK, so NetworkManager is trying to prevent the user from messing with interfaces it has under it's control. I suppose that's intentional by design, but will reassign to allow for input from NM folks.

Comment 13 Ade Bradshaw 2017-10-19 07:45:05 UTC
Yeah but its a change in behaviour - it used to work until now

Comment 16 Thomas Haller 2018-01-12 16:34:02 UTC
Created attachment 1380476 [details]
NM log

provided by Beniamino

Comment 17 Beniamino Galvani 2018-01-24 10:30:07 UTC
Hi,

I could reproduce the problem with NM 1.8, but not with NM 1.10.

In NM 1.8 default routes were handled by the NMDefaultRouteManager, that enforced the lack of a default route when it was first removed externally. The NMDefaultRouteManager was dropped in NM 1.10 by this commit:

  https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=77ec302714795f905301d500b9aab6c88001f32e

In NM 1.10 default routes are handled as normal routes in the IP configuration; route added externally are never removed.

Therefore, this bug is fixed in RHEL 7.5 that ships NM 1.10.

Comment 19 Vladimir Benes 2018-02-08 11:54:05 UTC
running in CI on all architectures

Comment 20 Andrew Taylor 2018-02-12 22:28:23 UTC
*** Bug 1544537 has been marked as a duplicate of this bug. ***

Comment 23 errata-xmlrpc 2018-04-10 13:31:31 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://access.redhat.com/errata/RHBA-2018:0778


Note You need to log in before you can comment on or make changes to this bug.