But systemd-networkd dhcp client get route with /8 netmask - 192.0.0.0/8 via 10.254.254.1
Is it a bug of systemd-networkd or my error in configuration?
#### ip -4 route | fgrep eth0.10
10.254.254.0/24 dev eth0.10 proto kernel scope link src 10.254.254.40
192.0.0.0/8 via 10.254.254.1 dev eth0.10 proto dhcp src 10.254.254.40 metric 1024
I would run Wireshark on the interface that is connected to 10.254.254.1
Then renew the DHCP address lease and see which packets go by and study the DHCP response. That way you can decide if the DHCP server is to blame or the systemd-networkd dhcp client.
I’ve saw right host route lease (Option 33 = Static Route) in wireshark.
Next, I’ve taked a notebook with new clean Tumbleweed installation and tried to get routes from
my the dhcp-server (centos8).
The NetworkManager has got right route with host netmask. (192.168.1.2/32)
(clean and reboot)
The wicked has got strange route with /31t netmask. (192.168.1.2/31)
(clean and reboot)
The systemd-networkd has add /24 netmask to my host route. (192.168.1.0/24)
So, it’s very strange, my first test was with Raspberry 4 (Tumbleweed), and it got /8 netmask
for host static route with systemd-networkd…
You are mistaken. This is the wrong option to use. Option 33 does not include netmask nor does it define actual interpretation of address that is not exact class A/B/C network address.
You need option 121 (classless route) that allows you to specify exactly what mask to use and provide host route without any ambiguity.
The NetworkManager has got right route with host netmask. (192.168.1.2/32)
It is not “right”. It just happens to match what you want.
The wicked has got strange route with /31t netmask. (192.168.1.2/31)
I can imagine how it could come up with this result. Anyway, it is just as valid as other results - as I already said, you get undefined behavior here. It is garbage in - garbage out.
The systemd-networkd has add /24 netmask to my host route. (192.168.1.0/24)
That is the most common interpretation of option 33 and it is just as right (or just as wrong) as any other you listed.
So back to your original question - it is configuration problem, you are using the wrong dhcpd option
No, it is not. It was created for classful network routes. If you feed it with anything else, result is undefined. NetworkManager has heuristic to assume host route is default host part is not zero. wicked has heuristic to extend network mask if default host part is not zero. systemd-networkd simply assumes default class mask.
In all cases it is implementation defined and neither implementation is better than any other.