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