Marcio Cunha

How to set up automatic network failover in systemd-networkd

Learn how to configure native network failover in systemd-networkd by creating alternative static routes and monitoring links without external scripts.

Marcio Cunha•4 min
Also available in:PortuguêsEspañol
Summary
  • The systemd-networkd service manages network configurations and interfaces natively and deeply integrated with the Linux kernel without legacy daemons.
  • Native link monitoring uses gateway-scoped routes and priority metrics to detect connectivity drops automatically.
  • Alternative static routes with higher metrics ensure traffic migrates to a secondary link as soon as the primary gateway fails.
  • Auditing active connections with tools like the ss command complements the validation of network stability after route switches.
  • The absence of external cron scripts reduces operational complexity and eliminates additional points of failure in the infrastructure.

Why use systemd-networkd for network failover

Keeping servers always accessible requires both physical and logical resilience in your infrastructure. In modern Linux distributions, systemd-networkd — the native system service responsible for managing IP addresses, network cards, and connections — offers powerful tools to ensure your machine switches to a secondary route automatically if the primary one drops. In practice, this means that if your primary internet link or switch connection fails, traffic is diverted to an alternative path without dropping services or requiring manual intervention.

Unlike traditional approaches that rely on Python or Bash scripts running in the background to ping external addresses, systemd-networkd handles this natively at the kernel level. This reduces resource consumption and eliminates execution bugs common in external tooling. Furthermore, this approach integrates seamlessly with other infrastructure routines, such as managing firewall rules or auditing open ports, as detailed in guides on how to use the ss command on Linux to audit network connections. The result is a cleaner, more predictable, and easier-to-maintain environment over the long run.

Understanding native link monitoring

Native link monitoring in systemd-networkd relies on route health checks and gateway responsiveness. The Linux kernel maintains routing tables that define where each data packet should go. When we configure static routes with different metrics, we tell the system which path to prioritize. If the primary router stops responding to ARP packets or fails in forwarding, the operating system detects the loss of contact and invalidates that route.

In practice, systemd-networkd allows you to assign costs (metrics) and priorities to each network interface. A link with a lower metric is always preferred. When that link loses connectivity with its gateway, the route loses validity and the kernel automatically activates the next route, which has a higher metric. This switch happens in fractions of a second, ensuring critical applications keep running without noticeable drops for end users or clients connected to the server.

Structuring network interface configuration

To put high availability into practice, we need to create specific configuration files inside the /etc/systemd/network/ directory. Each physical interface gets a dedicated .network file defining its behavior. Below is an example configuration for a primary network card (for instance, eth0) operating with a static IP address and a low metric.

[Match]
Name=eth0

[Network]
Address=192.168.1.50/24
Gateway=192.168.1.1
Metric=10
DNS=8.8.8.8

In this block, the parameter Metric=10 defines that this interface has high priority. The system will prefer this route for all outgoing traffic. If you need to adjust local domain names or map additional static addresses for internal testing, it is worth checking the procedure described in how to configure the hosts file on Windows and Linux to complement name resolution on your local network.

Creating the alternative static route for failover

The secret to failover without external scripts lies in creating a secondary route with a higher metric. We configure a second interface (such as eth1) or a secondary gateway on the same network to take over if the primary link stops responding. We create a .network file for the backup interface with a higher metric, indicating it should only be used when the first one fails.

[Match]
Name=eth1

[Network]
Address=192.168.2.50/24
Gateway=192.168.2.1
Metric=100

With the parameter Metric=100, systemd-networkd understands that the eth1 interface is the secondary option. As long as eth0 is responding to gateway 192.168.1.1, all traffic flows through it. The moment the kernel detects signal loss or a failure in the main router, the routing table updates weights and redirects packets to gateway 192.168.2.1 in a completely transparent manner.

Validating and testing failover in practice

After applying configurations by saving files and restarting the service with the command sudo systemctl restart systemd-networkd, it is vital to validate that failover is working as expected. To simulate a real failure, you can physically disconnect the primary interface cable or temporarily disable it via terminal using link management tools.

  1. Disable the primary interface by executing the command to bring down the network card.
    sudo ip link set eth0 down
  2. Verify that the active route automatically switched to the secondary gateway listed in the system's routing table.
    ip route show
  3. Re-enable the primary interface to test automatic traffic return as soon as the link is restored.
    sudo ip link set eth0 up

During bench testing, also monitor component and hardware temperatures to ensure that processing stress and heavy traffic do not cause thermal instability on the motherboard or network adapters, following the recommendations in how to monitor NVMe temperature on Linux via terminal to maintain overall server health.

Final thoughts on network redundancy

Implementing automatic failover using native systemd-networkd features enhances Linux server reliability without adding unnecessary complexity to the system. By eliminating reliance on third-party daemons or complex verification scripts, you gain response speed and maintenance simplicity. Correct management of route metrics ensures your infrastructure remains online even during unexpected physical network failures.

Understanding kernel and routing table behavior empowers engineers and system administrators to build robust, predictable, and highly available environments. Adopting these native practices solidifies a clean architecture aligned with modern site reliability engineering standards.