Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1503769

Summary: ip route add default via is not working
Product: Red Hat Enterprise Linux 7 Reporter: Ade Bradshaw <abradshaw>
Component: NetworkManagerAssignee: Beniamino Galvani <bgalvani>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.4CC: abradshaw, antaylor, atragler, bgalvani, bhaubeck, egolov, fgiudici, lmiksik, lrintel, mtenheuv, rchopra, rkhan, sukulkar, thaller, vbenes
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: NetworkManager-1:1.10.0-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 13:31:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshot of above on 7.4
none
ip monitor 1 or 2
none
ip monitor 2 or 2
none
NM log none

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