However, if I modify the IP address e.g. 192.168.102.2 and issue a systemctl restart systemd-networkd the ifconfig output does not change (as it should, as far as I can understand). However, this is the output from networkctl status:
# networkctl status
● State: routable
Address: 192.168.102.1 on eth0
192.168.102.2 on eth0
192.168.11.1 on usb0
fe80::214:2dff:fe4a:4bcf on eth0
And if I change the IP address to end with 3 and restart the service another record is added to this list. The device will now answer pings on all 3 IP addresses. ifconfig output is still unchanged from the listing above, i.e. it report the IP address the device booted with, not the “latest” one.
This seems like a bug to me but could of course be some feature that I don’t understand. Could you please look into this?
This is currently a known limitation of systemd-networkd. The behavior has been intended at first, to allow the user to manually configuring IP addresses besides the running networkd service. With the release of systemd 228 this behavior has been changed and the network addresses will be removed (see also systemd issue #780). However, even our next release will likely not contain that fix yet (our next release will build upon Angstrom 2015.12, which uses systemd 225 or 226).
As a work around you can either just reboot the whole system or extend the systemd-networkd.service file with an additional commit
ExecStartPre=/sbin/ip addr flush dev eth0
By restarting the service, the new network settings should get applied:
However, systemd-networkd (at least at its current version of 219) seems like it has some maturing to do. I did not use a capital N for “Name” in my configuration file (the config file I posted above apparently did not make it intact to my system). Instead of just refusing to load networking due to a config syntax error my rule now matched all interfaces and caused an interface named “sit0” (the ipv6 bridging interface) to be started as well with the same IP address as eth0. This had the odd consequence that any address on the network answered pings. I did some scratching of the head over that until I tried
journalctl -u systemd-networkd
which hinted at the core issue. For anyone reading this considering to go down this route there appears to be a lot of movement in networkd at the moment. I had intended to use the DHCPServer feature I found documented somewhere but apparently it was only added in September 2015, i.e. 227 which then probably will show up in the June-2016 version of Angstrom:
Yeah there is indeed quite some movement in networkd development, especially in supplementary function such as DHCP. We use the DHCP functionality for the RNDIS interface (to provide an IP to the host) and discovered some oddity there too.
However, some features just works very nicely already today, e.g. we also used the bridging feature, which is really nice to configure through networkd.
One thing: the ip command is located in /sbin . Also, I had some trouble doing this via reload so I’m just restarting the service instead, can’t see any downsides to that. To summarize, this is what I added to /lib/systemd/system/systemd-networkd.service undir the [Service] section:
