Re: Change of route metric are not well propagated for default route



On Wed, 2018-07-18 at 07:30 +0000, Frederic Martinsons wrote:
Hello guys,

I would like to change route metric on a device without reactivated
its connection profile. For example, with nmcli, to change the metric
from 100 to 800, I do the following:

nmcli device modify eth0 ipv4.route-metric 800

This works perfectly fine with NetworkManager 1.10.10 and I ended
up with a routing table like this one:

default via 10.30.1.254 dev eth0 proto static metric 800 
10.30.0.0/16 dev eth0 proto kernel scope link src 10.30.38.49 metric
800

But this doesn't work with NetworkManager 1.12.0 and only the route
metric to reach subnet is changed (the one to reach the gateway is
not changed):

default via 10.30.1.254 dev eth0 proto static metric 100 
10.30.0.0/16 dev eth0 proto kernel scope link src 10.30.38.60 metric
800

Moreover, always with NM 1.12, if I configured my device with a
manual IP (ip4.method=manual), the metric change is also correctly
propagated to all route that implies the device. 

I've raised the logging level of NetworkManager but I did'nt manage
to know why the default route is not changed when dhcp setup is
involved. I join two log files (one in dhcp and one in manual) to
emphasize the moment I execute the nmcli command.

Can you guys please help me or give me some advice to solve this ?

Note: I use internal dhcp client in the NetworkManager conf.

Hi,

I think what you see here is a bug. It has the effect, that

  nmcli device modify "$IF" ipv4.route-metric "$VALUE"

and

  nmcli connection modify "$PROFILE" ipv4.route-metric "$VALUE"
  nmcli device reapply "$IF"

don't work correctly to change the default-route.

I think this issue is also tracked as [1].


In 1.8, NetworkManager treated the default-route specially, and then
reapply (`nmcli device modify`) worked correctly to change the metric
of the default-route.

With 1.10, NetworkManager's handling of routes was significantly
reworked. I actually would expect, that the bug was introduced already
in 1.10.0, as side effect of the rework. Since you say, it worked in
1.10, I am a bit surprised.
Anyway, clearly there is a misbehavior in 1.12.0.


TODO.

Sorry for the incovenience.

best,
Thomas

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1528071#c4

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]