To update a statically assigned IPv6 prefix in systemd-networkd without rebooting, you must modify the specific .network configuration file and then trigger a reconfiguration of that interface. The correct command is
networkctl reload <interface_name>, which instructs systemd-networkd to reread its configuration for the specified link and apply changes immediately. This approach avoids the overhead of restarting the entire network service or rebooting the host system, ensuring minimal disruption to active connections while updating address assignments.
Understanding systemd-networkd Configuration Structure
systemd-networkd manages network interfaces through declarative configuration files located in directories such as
/etc/systemd/network/ or
/usr/lib/systemd/network/. These files typically use the
.network extension and define settings for specific interfaces using wildcards or explicit names. When dealing with static IPv6 addresses, the configuration block usually resides within the
[Network] section of the file associated with your target interface.
The key directive for assigning a static IPv6 address is
Address=. For example, an entry might look like
Address=2001:db8::1/64. To change the prefix, you simply edit this line to reflect the new subnet identifier. It is crucial to ensure that the syntax remains valid, including the CIDR notation suffix (e.g., /64, /48), as systemd-networkd validates these entries before applying them. Misconfigured prefixes can lead to connectivity loss or routing errors, so verifying the new prefix against your network administrator's specifications is essential before making changes.
Editing the Network Configuration File
Begin by identifying the correct configuration file for your interface. You can list existing configurations using
ls /etc/systemd/network/ or check which file applies to your interface by examining the content of
/run/systemd/network/ after a boot. Once identified, open the file using a text editor with root privileges. For instance, if your interface is
eth0 and the config file is
10-eth0.network, you would run:
sudo nano /etc/systemd/network/10-eth0.network
Locate the
[Network] section and find the
Address= line corresponding to the IPv6 address you wish to update. Change the value to the new prefix while keeping the rest of the configuration intact. Save the file and exit the editor. If you have multiple IPv6 addresses assigned, ensure you only modify the one relevant to the prefix change. It is good practice to comment out the old address temporarily if you are unsure about the rollback procedure, allowing you to restore it easily if the new configuration fails.
Applying Changes Without Reboot
After saving the modified configuration file, you need to signal systemd-networkd to pick up the changes. The standard and most effective method is to use the
networkctl utility. Unlike
systemctl restart systemd-networkd.service, which affects all interfaces globally and may cause brief interruptions across the entire system, reloading a specific interface is targeted and safer. Execute the following command:
sudo networkctl reload eth0
Replace
eth0 with your actual interface name. This command tells the daemon to discard the current state of the interface and reinitialize it based on the updated configuration file. You should observe output indicating that the link is being reconfigured. If successful, the new IPv6 address will be assigned almost immediately. You can verify the change by running
ip -6 addr show dev eth0 to confirm that the new prefix is active.
If
networkctl reload does not apply the changes, it may be because the interface is down or in a state that prevents immediate reconfiguration. In such cases, bringing the interface down and up again using
sudo ip link set eth0 down followed by
sudo ip link set eth0 up can force the reload process. However, this will briefly disconnect network traffic on that interface, so it should be used as a fallback rather than a primary method.
Troubleshooting Common Issues
Sometimes, the new configuration may fail to apply due to syntax errors or conflicts. Check the journal logs for detailed error messages using
journalctl -u systemd-networkd. Look for lines containing "Failed" or "Error" related to the interface. Common issues include invalid CIDR notation, duplicate addresses, or missing dependencies in other configuration sections. Additionally, ensure that no other network manager, such as NetworkManager, is conflicting with systemd-networkd on the same interface. Disabling NetworkManager for managed interfaces or removing conflicting
.network files can resolve these conflicts.
For more complex scenarios involving multiple prefixes or dynamic updates, consider reviewing how systemd-networkd handles address lifetimes and routing. Refer to
Configuring Two ULA Addresses on One Interface for insights into managing multiple IPv6 addresses on a single link, which can help prevent address collision when updating prefixes.
Frequently Asked Questions
What happens to active connections during a networkctl reload?
Active TCP connections may drop briefly as the interface reconfigures, but UDP flows and non-stateful protocols generally remain unaffected. The duration of interruption is typically less than a second, depending on the complexity of the reconfiguration.
Can I use systemctl restart instead of networkctl reload?
Restarting the systemd-networkd service via systemctl affects all managed interfaces globally, potentially causing widespread network downtime. Using networkctl reload is preferred for targeted updates to minimize impact on other services and connections.
How do I verify the new IPv6 address was applied correctly?
Run the command
ip -6 addr show dev <interface> to display the current IPv6 addresses assigned to the interface. Compare the output with your expected new prefix to ensure accuracy.
What if the networkctl reload command fails?
Check the system logs using
journalctl -u systemd-networkd for specific error messages. Syntax errors in the configuration file are the most common cause of failure, so validating the file structure is the first step in troubleshooting.
Does this method work for DHCP-assigned addresses?
No, this method specifically targets statically configured addresses defined in .network files. For DHCP-assigned addresses, you would need to restart the DHCP client service or renew the lease, as the prefix is determined by the server, not the local configuration.