Kernel is very picky about accepting a route with "src" parameter.
The src address must have a corresponding local route, which it usually has when the IP address is added. Otherwise configuring it fails.

Say, you configure this profile:

  nmcli connection add \
      type ethernet \ 
      con-name x \
      autoconnect no \
      ipv6.method disabled \
      ipv4.method manual \
      ipv4.addresses 10.0.0.1/24 \
      ipv4.routes "10.0.0.0/24 src=10.0.0.1 table=5000"
      ipv4.dad-timeout 500


this seems a sensible thing to do, because you want to use policy routing and add the device route to another table. Something similar might happen with

  nmcli connection add \
      type ethernet \ 
      con-name x \
      autoconnect no \
      ipv6.method disabled \
      ipv4.method manual \
      ipv4.addresses 10.0.0.1/24 \
      ipv4.route-table 5000 \
      ipv4.routes "10.0.0.0/24 src=10.0.0.1"
      ipv4.dad-timeout 500

(check both approaches, because they are not exactly the same!)




Anyway. With this, DAD/ACD is delaying the addition of the IPv4 address, and the IPv4 local route does not exist. At this point, the pref-src route cannot be added yet. What must happen, is that NM notices this, and retries later when the circumstances are right.

I guess, something similar could also happen with IPv6. Test that too!!


The underlying problem is because kernel tries to be overly helpful, and requiring that non-trivial relations between addresses/routes are honored. When it should just accept the configuration that the user wants to make. It's not that you couldn't configure wrong routing in kernel, this only captures a very very narrow case.