[Bug 1824340] Re: DHCPv4 can't set route

[Dan Streetman]

A quick read of RFC 3442 doesn't seem to specify that the server must
order them that way, but it certainly makes sense that it should.  An
argument could probably be made that systemd-networkd should handle out-
of-order routes like that, but i think it's more of a feature request
than a bug, per se.  And it doesn't look like the support for out-of-
order routes, like this, has been added upstream.  So I agree it's much
better for the server to be configured to provide the routes in order;
I'll close this bug.

** Changed in: systemd (Ubuntu)
       Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1824340

Title:
  DHCPv4 can't set route

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  Dear colleagues,

  I'm facing the problem in systemd-networkd with processing classless
  routes (in fact, I'm using netplan, but netplan use networkd).
  Environment is below.

  The problem:
  DHCP server sends the following classless routes in Opt.121 (in the following sequence):

  3.3.3.0/24 -> 10.0.3.14
  10.0.3.0/24 -> 0.0.0.0

  and systemd-networkd fails with the message:

  Apr 11 11:11:40 mother systemd-networkd[8357]: eth1: DHCPv4 address 10.0.2.15/24
  Apr 11 11:11:40 mother systemd-networkd[8357]: eth1: DHCP: No routes received from DHCP server: No data available
  Apr 11 11:11:40 mother systemd-networkd[8357]: eth1: Could not set DHCPv4 route: Network is unreachable
  Apr 11 11:11:40 mother systemd-networkd[8357]: eth1: Failed

  The cause is clear - at the moment when 3.3.3.0/24 appears, there is
  no route to it's nexthop (10.0.3.14).

  Default behavior of ISC DHCP client is the same but can be fixed in
  two ways:

  1) second run of dhclient installs 3.3.3.0/24 since 10.0.3.14 is accessible since first run
  2) OR changing /etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes in order to process connected routes (i.e. gateway is 0.0.0.0) first, while other routes - next.

  Is it possible to modify systemd-networkd behavior in some way? -
  1) sort routes and install connected first and other - next?
  2) OR use kind of max_retries after which systemd-networkd's dhcp client will fail finally
  3) OR add ability to use own scripts like mentioned above ISC's hook?

  Any recommendation on how to work around this issue are highly
  appreciated.

  Thank you.

  Environment:
  OS: Ubuntu 18.04.2
  systemd: 237
  DNS server: dnsmasq (Openstack)
  Netplan: 0.40.1~18.04.4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1824340/+subscriptions