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

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

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

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

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

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

removing NetworkManager fixes the issue

and so does setting NM_CONTROLLED="no" in /etc/sysconfig/network-scripts/ifcfg-eth0

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.

Yeah but its a change in behaviour - it used to work until now

Created attachment 1380476 [details]
NM log

provided by Beniamino

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.

running in CI on all architectures

*** Bug 1544537 has been marked as a duplicate of this bug. ***

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