Bug 1284442 - With DEFROUTE=no networkmanager inserts link type default route
With DEFROUTE=no networkmanager inserts link type default route
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.2
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Beniamino Galvani
Desktop QE
:
Depends On:
Blocks: 1301628
  Show dependency treegraph
 
Reported: 2015-11-23 05:49 EST by Tuomo Soini
Modified: 2016-03-02 10:59 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-15 10:58:00 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tuomo Soini 2015-11-23 05:49:03 EST
Description of problem:

After update to NetworkManager-1.0.6-27.el7.x86_64 interface with DEFROUTE=no stopped working properly. After some debugging I found out there was link default route added which caused real default route on different routing table not to work.

ip route list dev eth2

0.0.0.0  scope link  src 91.156.27.251 
91.156.0.0/19  proto kernel  scope link  src 91.156.27.251  metric 100 
172.24.24.45  proto static  scope link  metric 100 

Downgrade to older NetworkManager-1.0.0-16.git20150121.b4ea599c.el7_1.x86_64
restored working routing table

91.156.0.0/19  proto kernel  scope link  src 91.156.27.251  metric 100 
91.156.0.1  scope link  src 91.156.27.251 
172.24.24.45  proto static  scope link  metric 100 

It looks like gateway is errorously reset to 0.0.0.0 on new networkmanager.
Comment 2 Beniamino Galvani 2015-11-24 04:09:28 EST
(In reply to Tuomo Soini from comment #0)
> It looks like gateway is errorously reset to 0.0.0.0 on new networkmanager.

I tried to reproduce this without success, can you please attach your ifcfg file?
Comment 3 Tuomo Soini 2015-11-24 04:30:43 EST
This is more complicated than simple ifcfg - problem is deep inside NetworkManager. Somebody made a decision upstream that DEFROUTE=no is the reason to clear GATEWAY data.

The system which broke has dhcp dsl line with backup route which is done with policy routing. Because networkmanager uses totally unpredictable file name for dhcp.leases gateway name dhcp provided (but which can't be used in main routing table) is asked with nmcli by using:

nmcli --terse --fields IP4.GATEWAY device show ${1} | cut -f2- -d':'

With old NetworkManager gateway was provided with this query but upstream has changed gateway to 0.0.0.0 if DEFROUTE=no. That really wipes only real place to query dhcp provided gateway from scripting.

These networkmanager commits look like potential reason for this error:

ed85fcc711ca4ff6fa394e92ac33c5ead5c460f5
063677101ab7d43a9aa94c70eb1ca3a201269043

Clear was supposed to happen to GATEWAY which is from /etc/sysconfig/network but that's not what really happens.

I can confirm that Fedora has same problem, gateway info is lost. So this is problem introduced after NetworkManager 1.0.0. Unfortunately my Fedora testing vm was too simple config and I couldn't see the problem there.

So that 0.0.0.0 route is installed by shorewall multi-isp code because nmcli gives wrong info about gateway.


ifcfg-eth2 in my case is quite simple:

TYPE=Ethernet
IPV6INIT=no
NAME=eth2
BOOTPROTO=dhcp
DEFROUTE=no
DHCLIENTARGS="-nc"
HWADDR=52:54:00:8C:8C:78
IPV4_FAILURE_FATAL=yes
IPV6_PEERDNS=no
ONBOOT=yes
PEERNTP=no
UUID=88d5d046-bb88-47c7-b2b4-e488f0a1ee82
PEERDNS=no
PEERROUTES=yes
Comment 4 Beniamino Galvani 2015-11-26 03:45:08 EST
From description in comment 0 it looked like NM was adding wrong
routes, but if I understand correctly from comment 3 actually those
routes are added externally by another process which screen-scrapes
the output of nmcli to find out the DHCP-provided gateway (which
however is not used by NM since DEFROUTE=no).

The information returned by "nmcli d show <dev>" in the IP4 and IP6
sections is what is currently configured on the interface and, in this
case, there is no gateway set for the interface (because of
DEFROUTE=no). So it looks like the output we are providing now is
correct (*) and if in the past the IP4.GATEWAY was showing something
different, that was a bug.

It's unfortunate that someone started using that field, but the
correct way of obtaining DHCP-provided info through NM in my opinion
is with "nmcli -f DHCP4.OPTION device show <dev>" which returns the
value of all the DHCP options. Maybe the output format is not the best
one to parse, but it has everything you need (including the "routers"
option):

DHCP4.OPTION[1]:        requested_classless_static_routes = 1
DHCP4.OPTION[2]:        requested_rfc3442_classless_static_routes = 1
DHCP4.OPTION[3]:        subnet_mask = 255.255.255.0
DHCP4.OPTION[4]:        requested_subnet_mask = 1
DHCP4.OPTION[5]:        domain_name_servers = 192.168.10.1
DHCP4.OPTION[6]:        ip_address = 192.168.10.168
DHCP4.OPTION[7]:        requested_static_routes = 1
DHCP4.OPTION[8]:        dhcp_server_identifier = 192.168.10.1
DHCP4.OPTION[9]:        requested_nis_servers = 1
DHCP4.OPTION[10]:       requested_time_offset = 1
DHCP4.OPTION[11]:       broadcast_address = 192.168.10.255
DHCP4.OPTION[12]:       requested_interface_mtu = 1
DHCP4.OPTION[13]:       dhcp_rebinding_time = 2268000
DHCP4.OPTION[14]:       requested_domain_name_servers = 1
DHCP4.OPTION[15]:       dhcp_message_type = 5
DHCP4.OPTION[16]:       requested_broadcast_address = 1
DHCP4.OPTION[17]:       routers = 192.168.10.1
DHCP4.OPTION[18]:       dhcp_renewal_time = 1296000
[...]

Does that make sense?

(*) Actually, there is a bug, that the output shows gateway "0.0.0.0"
instead of an empty value; but this can be easily fixed and is not
the point of this bug.
Comment 5 Tuomo Soini 2015-11-26 04:42:11 EST
Yes, that is work-around I can use but not really a fix.

Example: ppp over ethernet. Now if you set DEFROUTE=no there is no way to find remote provided gateway because NetworkManager returns 0.0.0.0, not ppp peer which would work for policy routing.

We can use this as work-around but it's still a bug that networkmanager sets 0.0.0.0 to GATEWAY when remote really told real gateway ip. Using gateway is different thing. This worked correctly on NetworkManager 1.0.0.

Setting to 0.0.0.0 was work-around for GATEWAY being set in /etc/sysconfig/network. There are other ways to ignore that and current solution is not really working.
Comment 6 Beniamino Galvani 2015-11-27 03:48:00 EST
(In reply to Tuomo Soini from comment #5)
> We can use this as work-around but it's still a bug that networkmanager sets
> 0.0.0.0 to GATEWAY when remote really told real gateway ip. Using gateway is
> different thing. This worked correctly on NetworkManager 1.0.0.

As explained in previous comment, I consider the previous behavior a
bug, because IP4.GATEWAY is supposed to represent the current, in-use
gateway. The IP4 section is the current state of the device, and the
device has no gateway set.

And this is also consistent with what we do for other properties; for
example, if you set ipv4.method=auto (i.e. DHCP) and
ipv4.ignore-auto-dns=yes, NM will receive the DNS server through DHCP
but will not use it; as a consequence, IP4.DNS will not show that
server because the server is not in use.

But that is just my opinion, let's hear others' one.

> Setting to 0.0.0.0 was work-around for GATEWAY being set in
> /etc/sysconfig/network. There are other ways to ignore that and current
> solution is not really working.

This seems more the result of commit 557667df12fc ("device: better
accept external IP changes") which explicitly added this behavior and
looks right to me. From the commit message:

    Another important improvement is that the NMIPxConfig of the active
    device reflects when addresses or routes get removed externally. Before
    we would continue to expose those entires although they were not
    actually configured on the device.
Comment 7 Thomas Haller 2016-01-15 09:12:04 EST
(In reply to Beniamino Galvani from comment #6)
> (In reply to Tuomo Soini from comment #5)
> > We can use this as work-around but it's still a bug that networkmanager sets
> > 0.0.0.0 to GATEWAY when remote really told real gateway ip. Using gateway is
> > different thing. This worked correctly on NetworkManager 1.0.0.
> 
> As explained in previous comment, I consider the previous behavior a
> bug, because IP4.GATEWAY is supposed to represent the current, in-use
> gateway. The IP4 section is the current state of the device, and the
> device has no gateway set.
> 
> And this is also consistent with what we do for other properties; for
> example, if you set ipv4.method=auto (i.e. DHCP) and
> ipv4.ignore-auto-dns=yes, NM will receive the DNS server through DHCP
> but will not use it; as a consequence, IP4.DNS will not show that
> server because the server is not in use.
> 
> But that is just my opinion, let's hear others' one.

I agree.

IP4.GATEWAY shows what is currently configured. When configuring DEFROUTE=no, there is no gateway.

When caring about DHCP provided settings, checking DHCP4.OPTION is the right way.
Comment 8 Beniamino Galvani 2016-01-15 10:58:00 EST
According to comments above NM behavior seems correct, closing this. Please reopen if needed.

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