Architecting Network Configuration with Ubuntu Netplan

The Problem: Configuration Drift in Hybrid Network Environments

Managing network interfaces across a fleet of Ubuntu servers often leads to "configuration drift," where manual changes to /etc/network/interfaces or nmcli commands create undocumented states. The risk is highest during remote updates: a single typo in a static IP or a subnet mask can permanently sever SSH access, requiring physical or console access to recover.

The takeaway is to treat network configuration as declarative intent. By using Netplan, you define the desired state in YAML and let a renderer translate that intent for the underlying system daemon, providing a safety valve via a timed rollback mechanism.

Requirements for a Declarative Network Layer

To move away from imperative commands, a network management system must meet these engineering requirements:

• Backend Agnostic: The ability to switch between systemd-networkd (optimized for servers/containers) and NetworkManager (optimized for desktops/laptops) without rewriting the interface logic.
• Atomic Application: Changes should be validated before being fully committed to the kernel.
• Human-Readable Schema: A standardized format that can be version-controlled in Git.

The Smallest Suitable Design

Netplan does not manage the network itself; it is a configuration renderer. The architecture consists of three layers:

1. The Intent Layer: YAML files located in /etc/netplan/. These files describe what the network should look like.
2. The Generator: The netplan utility, which parses the YAML and generates low-level configuration files.
3. The Backend: The actual daemon (e.g., systemd-networkd) that reads the generated files and configures the Linux kernel interfaces.

Example: Static IP with Gateway and DNS

For a server environment using systemd-networkd, the following configuration represents the minimum viable design for a static interface on Ubuntu 22.04 LTS or 24.04 LTS.

# File: /etc/netplan/01-netcfg.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: no
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]

Trust and Data Boundaries

Because network configuration controls the entry and exit points of the system, the trust boundary is strictly limited to the root user.

• File Permissions: YAML files in /etc/netplan/ should be owned by root with 600 or 644 permissions to prevent unauthorized users from redirecting traffic or creating man-in-the-middle scenarios via DNS hijacking.
• Execution: The netplan apply command requires sudo privileges. It triggers the generator to overwrite files in /run/systemd/network/, which are the actual files read by the daemon.

Operational Checks and Verification

To prevent lockout, the netplan try command is the primary operational check. It applies the configuration but starts a countdown timer. If the user does not confirm the changes, the system automatically rolls back to the previous state.

Implementation Steps

1. Run the trial: Run sudo netplan try on the server. This command will prompt for confirmation after a default period (usually 120 seconds).
2. Verify connectivity: While the timer is running, open a separate SSH session to ensure you can still reach the machine.
3. Confirm or Rollback: If the new session works, press ENTER to accept. If the session fails, wait for the timer to expire to restore the old config.

Diagnostic Verification

To verify that Netplan successfully rendered the configuration to the backend, inspect the generated files. This confirms the abstraction layer is working correctly:

# Run as root to see the rendered systemd-networkd config
ls /run/systemd/network/
cat /run/systemd/network/10-netplan-enp0s3.network

Failure Modes

Failure Mode	Cause	Result
YAML Syntax Error	Incorrect indentation or missing colons	netplan apply fails; backend config is not updated; network remains in previous state.
Backend Mismatch	Specifying renderer: NetworkManager on a headless server without NM installed	Configuration is ignored by the active daemon; interface remains unconfigured.
Route Conflict	Defining multiple default gateways	Non-deterministic routing behavior or packet loss.

Conditions for Redesign

This declarative architecture is suitable for most static and semi-dynamic environments. However, a shift in design is required if:

• High-Frequency Changes: If network settings must change every few seconds (e.g., certain SDN controllers), the overhead of YAML rendering and daemon restarts is too high; direct API calls to the kernel or iproute2 are necessary.
• Complex Dynamic Logic: If the IP depends on complex runtime logic not supported by the Netplan schema, custom scripts interfacing with systemd-networkd directly may be required.