sytemd-networkd fails to add classless static routes

[hasso]

With DHCP option 121 content like this I'd expect to have 1.1.1.1/32 routed to the DHCP device and default routed to the 1.1.1.1. It doesn't happen though - the route for 1.1.1.1/32 is there, but no default. The source of the problem appears to be that the scope of the 1.1.1.1/32 route must be link, but it isn't and therefore adding the default fails.

Option 121 configuration from ISC DHCP config file:

option classless-routes code 121 = array of integer 8;
option classless-routes 32, 1, 1, 1, 1, 0, 0, 0, 0, 0, 1, 1, 1, 1;

[yuwata]

Is this still reproducible? We have several commits about classless static routes e.g., #6885, #7432, and #7807. I hope this is already fixed.

[daryltucker]

I'm not sure if it's exactly related, but I came across this issue when trying to debug my classless routes. I discovered very strange behavior that I couldn't fix until I put the default route at the end of the list of static routes.

        # Working
        option classless-routes
            24,10,1,2, 10,1,0,2,
            24,10,1,3, 10,1,0,3,
            0,0,0,0,  0,0,0,0;

$ ip route
0.0.0.0 dev eno1 proto dhcp scope link src 10.1.0.100 metric 203 
default via 10.1.0.1 dev eno1 proto dhcp src 10.1.0.100 metric 203 
10.1.0.0/24 dev eno1 proto dhcp scope link src 10.1.0.100 metric 203 
10.1.2.0/24 via 10.1.0.2 dev eno1 proto dhcp src 10.1.0.100 metric 203 
10.1.3.0/24 via 10.1.0.3 dev eno1 proto dhcp src 10.1.0.100 metric 203

The 10.1.0.1/24 network is omitted, as that route is handled by the subnet declaration. Attempting to adjust/declare this network as a classless/static route can cause strange behavior.

0, 0,0,0 0,0,0,0 also worked, by itself, but didn't provide the wanted routes.

---

Here is an example of the 'strange behavior' seen when the default route is not the final entry:

        option classless-routes
            0,0,0,0,  0,0,0,0,
            24,10,1,2, 10,1,0,2,
            24,10,1,3, 10,1,0,3;

$ ip route
0.0.0.0 dev eno1 proto dhcp scope link src 10.1.0.100 metric 203 
default via 0.0.24.10 dev eno1 proto dhcp src 10.1.0.100 metric 203 
0.0.24.10 dev eno1 scope link src 10.1.0.100 metric 203 
10.1.0.1/24 dev eno1 proto dhcp scope link src 10.1.0.100 metric 203 
10.1.3.0/24 via 10.1.0.3 dev eno1 proto dhcp src 10.1.0.100 metric 203

If this makes sense, and is not the result of a bug, could someone point me in the right direction to understand this behavior? It seems like it's taking on in-addr.arpa/rDNS and somehow getting confused. There is no reference to 10.1.2.0/24, but you can see 10.1.3.0/24.

[poettering]

Let's close this, since there's a good chance the original issue is already fixed and @hasso never replied.

the issue @daryltucker should be discussed/reported separately, as it doesn't look like it is identical to the original issue here