AARCH64: why is a host route to gateway host set?

[slashdolt]

I'm running aarch64 on an RPI 3 and an RPI 4. For some reason, a host route for the gateway is added.

Output of "ip r" on rpi4:
$this->bbcode_second_pass_code('', '
default via 172.16.20.1 dev eth0 proto dhcp src 172.16.20.5 metric 1024
172.16.20.0/26 dev eth0 proto kernel scope link src 172.16.20.5
172.16.20.1 dev eth0 proto dhcp scope link src 172.16.20.5 metric 1024
')
and on rpi3:
$this->bbcode_second_pass_code('', '
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.21 metric 1024
(--other routes here omitted--)
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.21
192.168.1.1 dev eth0 proto dhcp scope link src 192.168.1.21 metric 1024
')
It's that last route--why/how is that added? I can delete it and of course everything keeps working fine. On my laptop, running Arch x86_64 and NetworkManager, that route is not created.

The Pis are running standard systemd-networkd and systemd-resolved and DHCP.

Obviously not a huge deal but I couldn't track down why or how it's happening and wondered if anyone here has an answer. Thanks for reading.

[summers]

Not quite clear exactly what you are asking, becuase its not totally clear what your network is. Its usual though when a network connection is brought up, and an IP address is set that if a broadcast gets a reply that the route of the nearest neighbor gets added. This happens for me as part of the network interface configuration, so its quite early and before any default route gets set. So if I take a very simple example, the route on my pocket beagle, that *only* has a usb ethernet port on the usb otg port:
$this->bbcode_second_pass_code('', 'default via 192.168.7.17 dev usb0 proto static
192.168.7.16/30 dev usb0 proto kernel scope link src 192.168.7.18 ')
So the 192.168.7.16/30 was set when the interface was brought up, this was done by systemd-networkd via the script, /etc/systemd/networkd/usb0.network:
$this->bbcode_second_pass_code('', '[Match]
Name=usb0

[Network]
DNS=192.168.2.1
DHCPServer=true

[Address]
Address=192.168.7.18/30

[Route]
Gateway=192.168.7.17

[DHCPServer]
EmitDNS=false
EmitNTP=false
EmitSIP=false
EmitRouter=false
')
So can see how the usb otg device has been set up to be a very limited /30 address. Also how the default gateway is on 192.168.7.17 - which is conveniently in the /30 address range. Now when that default route is set up, route checks the routing and sees where to send those packets. In this case it out 192.168.7.17 that the rest of the routing says goes via usb0. So you can see both lines in routing are needed, kinda conceptually - one when the interface comes up, and one when default routing gets set.

A more complex example is on my router, running openwrt:
$this->bbcode_second_pass_code('', 'default via 195.166.130.255 dev pppoa-wan
192.168.2.0/24 dev br-lan scope link src 192.168.2.1
192.168.7.0/24 via 192.168.2.144 dev br-lan
195.166.130.255 dev pppoa-wan scope link src 87.112.62.10
')
There two directly connected interfaces are brought up 192.168.2.0/24 - which is the local LAN, a gang of four ethernet ports, and also the wifi lives under 192.168.2.0/24 - thing to note is how its tied to the br-lan device which descibes that hardware.

The second directly connected route is 195.166.130.255, which goes out across a network connection on the ADSL line. This is the WAN.

The default route when it came to added is sent via the WAN, and although that will have been set via the ip number, when added to the route table, the device is added - to make that routing easier. SO all default traffic goes on the ppoa-wan device to the gateway 195.166.130.255.

Finally note the 192.168.7.0/24 route, odd in that it doesn't go via a physical device, but it sent to the 192.168.2.144 machine (on the br-lan). That machine is actually my NAS, and its has my beagle farm plugged into its usb ports. So this means my router knows about where my beagle farm lives, and as my router is the default route for my LAN, its where all traffic goes. This means that my LAN knows about the beagle network - so I can log into the beagle farm from anywhere on the LAN.

Now as far as I can see, your set up is doing just the same, setting the interface route up separately from the default gateway. And this is good.

[slashdolt]

Thanks for your response. Sorry if my question wasn't clear. I would simply like to know how this host route is being added to my routing table on my aarch64 machine:
$this->bbcode_second_pass_code('', '
172.16.20.1 dev eth0 proto dhcp scope link src 172.16.20.5 metric 1024
')
It's not needed and I can delete it with no consequence. My other Arch machines on the same network (one using NetworkManager and one dhcpcd) don't set it. Their routing tables are 2 lines long, like yours in the first code snippet of your response.
Does systemd-networkd add this route for some reason?

[summers]

Think its added when the interface comes up. Its exactly what I have on my desktop. Think you can see if you bring up the interface by hand. So
$this->bbcode_second_pass_code('', 'default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.21 metric 1024 [b]WAN[/b]
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.21 [b]LAN[/b]
192.168.1.1 dev eth0 proto dhcp scope link src 192.168.1.21 metric 1024 [b]either nearest neighbor, or WAN router[/b] ')
The WAN address is only set up when you set up the default gateway.

The nearest neighbor, is I think what happens when you bring the interface up, before doing the default gateway.

The LAN, I'm not sure on. I think it comes up when you bring up the interface in the first place. Think it maybe that systemd-networkd by default assumes you are in a /24 LAN, and so brings up the routing for that LAN.

Its why my pocket beagle example is interesting, as there you can see explicitly how the interface was defined, and how the LAN subnet /30 is part of the interface address.

Now part of how these get set up, will end up depending on what your dhcp server- usually the router says. It certainly as part of dhcp negotiation gives out the network address and default router. I don't know if it plays a part in defining the LAN.

If you can long directly on the machine, you could of course take the interface down, disable the automatic stuff (e.g. temp stop in systemd) and then bring up by hand - then you can see what comes up when. Actually may do that when I get home just for interest.

[slashdolt]

Is your desktop running systemd-networkd? I have a desktop running dhcpcd and a laptop running NetworkManager. Neither adds this host route (both are Arch x86_64).

For example my laptop (on the same network and with the same DHCP server as the rpi4):
$this->bbcode_second_pass_code('', '
default via 172.16.20.1 dev wlan0 proto dhcp metric 600
172.16.20.0/26 dev wlan0 proto kernel scope link src 172.16.20.61 metric 600
')
It's kind of academic because there's no harm in that host route being there. I just don't understand how it's being set. I suspect systemd-networkd is responsible based on the fact that it's not set on my machines running dhcpcd and NetworkManager.

[summers]

Just tried on my laptop (session below) and yes its systemd-networkd that sets this:
$this->bbcode_second_pass_code('', '[root@summers-laptop summers]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 30:85:a9:7f:ee:8c brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 74:e5:43:5f:b8:7b brd ff:ff:ff:ff:ff:ff
inet 192.168.1.46/24 brd 192.168.1.255 scope global dynamic wlp2s0
valid_lft 86374sec preferred_lft 86374sec
inet6 fe80::76e5:43ff:fe5f:b87b/64 scope link
valid_lft forever preferred_lft forever
[root@summers-laptop summers]# ip link set wlp2s0 down
[root@summers-laptop summers]# ip r
[root@summers-laptop summers]# systemctl stop systemd-networkd.socket
[root@summers-laptop summers]# systemctl stop systemd-networkd.service
[root@summers-laptop summers]# ip link set wlp2s0 up
[root@summers-laptop summers]# ip r
[root@summers-laptop summers]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 30:85:a9:7f:ee:8c brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 74:e5:43:5f:b8:7b brd ff:ff:ff:ff:ff:ff
inet6 fe80::76e5:43ff:fe5f:b87b/64 scope link
valid_lft forever preferred_lft forever
[root@summers-laptop summers]# ip add add 192.168.1.46/24 dev wlp2s0
[root@summers-laptop summers]# ip r
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.46
[root@summers-laptop summers]# ip r add default via 192.168.1.1
[root@summers-laptop summers]# ip r
default via 192.168.1.1 dev wlp2s0
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.46
[root@summers-laptop summers]# systemctl start systemd-networkd.service
[root@summers-laptop summers]# ip r
default via 192.168.1.1 dev wlp2s0 proto dhcp src 192.168.1.46 metric 1024
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.46
192.168.1.1 dev wlp2s0 proto dhcp scope link src 192.168.1.46 metric 1024
')
And notice how these have been set by dhcp - so its the dhcp server on the far end that is setting them.