New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

networkd: add option to prune addresses #780

Closed
SimonPe opened this Issue Jul 29, 2015 · 6 comments

Comments

6 participants
@SimonPe
Copy link
Contributor

SimonPe commented Jul 29, 2015

It would be nice to be able to configure networkd to remove all addresses that aren't managed by networkd.

This would be useful in combination with configmanagement systems, where they just need to write the .network files, and restart networkd if they were changed.

Example:

[Network]
PruneAddresses=yes
Address=1.2.3.4/24
LinkLocalAddressing=no
...

this would remove any other address from the matched interface, including linklocal addresses (because LinkLocalAddressing is disabled)

@teg

This comment has been minimized.

Copy link
Contributor

teg commented Jul 29, 2015

We plan to change the behavior so that this becomes the standard behavior. I don't think it is worth making it configurable.

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Jul 31, 2015

@teg, I agree we should flush things out by default, but we probably should do so only if at least one IP setting is done, i.e. DHCP, IPV4LL or an explicit address is configured in the .network file. This would then allow VPN software to add interfaces with their own IP setting where we could add more settings on top.

We should also avoid playing games with admins: when the add an additional ip address during runtime, we should not automatically flush that again, we should only flush when the network device is first taken possession of by systemd.

@grazzolini

This comment has been minimized.

Copy link

grazzolini commented Aug 10, 2015

@poettering
Currently systemd-networkd doesn't bring down addresses even if they were dynamically configured, i.e. by setting DHCP=yes on a .network file.

This goes against the documented behaviour in it's manual page. I've come across this because I'm using a systemd enabled initrd and systemd-networkd is being run on the early userspace. It's not pruning a IP address setup with DHCP=yes. After the initrd systemd-networkd is killed and the switch root happens, the second systemd-networkd will kick in and configure another ip address on it (statically configured). The interface ends up being with two IP addresses. In case the interface was statically configured from early userspace, I think that systemd-netword shouldn't prune the address when it's run for the second time. Only dynamic ip addresses should be pruned, as is documented on it's man page.

If this 'PruneAddress' option is added or become the default, would fix this situation.

@gdamjan

This comment has been minimized.

Copy link
Contributor

gdamjan commented Dec 20, 2015

when the add an additional ip address during runtime, we should not automatically flush that again

it seems flushing has been implemented in 228, but this breaks NFS booting. The kernel/initramfs gets an ip address via dhcp, and mounts the root from nfs.
But when networkd starts, first thing it flushes the ip address and this crashes the system since the root fs is inaccessible. This should either be configurable OR networkd just shouldn't flush /user/ configured addresses.

@ppira

This comment has been minimized.

Copy link

ppira commented Jan 4, 2016

But when networkd starts, first thing it flushes the ip address and this crashes the system since the root fs is inaccessible. This should either be configurable OR networkd just shouldn't flush /user/ configured addresses.

It is configurable. Set CriticalConnection=true and systemd-networkd shall not deconfigure the interface before aquiring a new address. In reality, this is broken in 228 and CriticalConnection have no effect what so ever. ( Works fine in 227)

@gdamjan

This comment has been minimized.

Copy link
Contributor

gdamjan commented Jan 4, 2016

The description of CriticalConnection is »When true, the connection will never be torn down even if the DHCP lease expires.« and is only checked in dhcp_lease_acquired and dhcp_lease_renew to (not) get the lease lifetime, and in dhcp4_handler when SD_DHCP_CLIENT_EVENT_IP_CHANGE to not change the address.

But IMHO maybe it makes sense to reuse this flag and NOT flush the addresses for these interfaces? I could prepare a patch if it's ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment