Hide Forgot
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:
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