Network Configuration with Netplan

A newly installed server can usually obtain an IP address automatically via DHCP, which is sufficient just to connect to the network. However, production servers almost never rely solely on that. Web servers require a static IP address that does not change so that DNS always points to the correct address, servers with two network interface cards need bonding to remain operational even if one link fails, and servers serving multiple network segments simultaneously require VLANs so that a single physical interface can be logically split. All these requirements lead to the same core task: system-level network configuration, and on Ubuntu Server, that core system is called Netplan.

This chapter opens Part III of the series, which specifically covers server networking. We will start with the concept of Netplan as an abstraction layer, move on to the practical configuration of static IPs most commonly used by Sysadmins daily, explore the concepts of bonding and VLANs for more complex network topologies, and wrap up with how to safely apply changes and troubleshoot common issues. The networking topics in this chapter serve as the foundation for subsequent chapters in Part III, ranging from DNS in Chapter 9 to time synchronization in Chapter 11.

8.1 Netplan as a Network Configuration Abstraction

Netplan is a declarative-based network configuration tool that has been the default in Ubuntu since the 17.10 release, replacing the legacy method of directly editing /etc/network/interfaces (the ifupdown package) or manually relying on nmcli. Instead of imperatively instructing the system to "perform steps A, B, and C", we simply describe "what the final state of this network should look like" in a YAML file, and Netplan translates it into actual configurations on the appropriate backend.

This approach simplifies tasks for Sysadmins because the same single YAML format can be used across various scenarios, whether on physical servers, virtual machines, or cloud images, without needing to learn different syntaxes for each backend. Developers who need a testing environment with a specific network topology can also copy the same YAML file to multiple servers without major modifications.

8.1.1 YAML Files in /etc/netplan/

All Netplan configurations are stored as one or more YAML files in the /etc/netplan/ directory. An Ubuntu Server installed via Subiquity (see Chapter 2) typically comes with an initial configuration file, usually named 00-installer-config.yaml, whereas cloud instances provisioned via cloud-init (Chapter 37) typically use 50-cloud-init.yaml. If there is more than one file, Netplan processes them sequentially according to alphabetical order of the file names, and configurations in files that appear later will override matching configurations from previous files.

Practical Steps

1. View the existing Netplan configuration files on the server.

   ls -la /etc/netplan/

2. Display the contents of the configuration file to understand its basic structure.

   cat /etc/netplan/00-installer-config.yaml

The basic structure of a Netplan YAML file always begins with the network key, a version number (currently only 2 is supported), followed by interface type blocks such as ethernets, bonds, or vlans.

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: true

Verification and Troubleshooting

• Pay attention to the permissions of the YAML files in /etc/netplan/. These files can potentially store sensitive data such as Wi-Fi passwords, so modern versions of Netplan will display a warning if permissions are too open. Ensure that only root can read and write to these files.

  sudo chmod 600 /etc/netplan/*.yaml
  ls -la /etc/netplan/

• In production environments, never delete default installer configuration files without reading their contents first. These files often store details such as interface names already recognized by the system during installation, providing a reference that speeds up the process when rewriting your own configuration.

8.1.2 Backend: NetworkManager vs systemd-networkd

Netplan itself does not directly manage the network. It merely translates (renders) the YAML file into native configurations for one of two available backends: systemd-networkd or NetworkManager. Ubuntu Server uses systemd-networkd as its default renderer, which is lightweight and ideal for headless environments without a GUI. Conversely, Ubuntu Desktop uses NetworkManager by default because it is more suitable for scenarios involving frequent network switches, such as laptop Wi-Fi.

The renderer key in the YAML file determines which backend is used. If this key is omitted entirely, Netplan defaults to networkd.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: true

Verification

• Check active interface statuses and the active renderer directly from Netplan.

  sudo netplan status

• If the active backend is systemd-networkd, check its status using networkctl.

  networkctl list
  networkctl status enp0s3

As a Sysadmin managing headless servers, you will almost always stick with systemd-networkd. Choosing NetworkManager on a server is only relevant when specific requirements exist, such as using a USB cellular modem whose connection management is easier via nmcli.

8.2 Static IP Configuration

DHCP is practical for initial setup, but production servers ideally require a fixed IP address. Consider the consequences if a web server's IP changes after a reboot while network DNS and firewalls still point to the old IP: all visitor traffic will fail until someone notices and manually fixes it. Therefore, configuring a static IP is one of the most fundamental network administration tasks that every Sysadmin must master.

Practical Steps

1. Check the active network interface names on the server first, as naming conventions can vary across servers (enp0s3, eth0, and similar).

   ip a

2. Open the existing Netplan configuration file, or create a new file if one does not exist.

   sudo nano /etc/netplan/00-installer-config.yaml

3. Replace the dhcp4: true configuration with a static IP address, gateway, and DNS servers. Adjust the addresses, prefix, and gateway according to the actual network scheme being used.

   network:
     version: 2
     renderer: networkd
     ethernets:
       enp0s3:
         dhcp4: false
         addresses:
           - 192.168.1.10/24
         routes:
           - to: default
             via: 192.168.1.1
         nameservers:
           addresses: [1.1.1.1, 8.8.8.8]

4. Before applying, validate the YAML syntax. This command will immediately report errors if there are indentation mistakes or misspelled keys without modifying the active network configuration.

   sudo netplan generate

Verification and Troubleshooting

• After the configuration is applied (see Section 8.4 for instructions on applying safely), verify that the IP address has updated as configured.

  ip a show enp0s3
  ip route

• Test DNS resolution and outbound connectivity to ensure the configured nameservers are working properly.

  resolvectl status enp0s3
  ping -c 3 8.8.8.8

• The most common error here is incorrect YAML indentation, as YAML is extremely sensitive to spacing and does not accept tab characters at all. Use an editor that clearly displays indentation and always run netplan generate before apply as a standard habit.

8.3 Bonding and VLANs: Conceptual Overview

In addition to basic IP configuration, Netplan handles two more complex networking scenarios commonly encountered on production servers: combining multiple physical network interfaces into a single interface (bonding), and splitting a single physical interface into multiple logical networks (VLANs). This section covers the fundamental concepts as a foundation, without diving into all the extensive configuration variations found in production environments.

8.3.1 Bonding: Redundancy and Bandwidth Aggregation

Bonding combines two or more physical network interfaces into a single logical interface. The purpose can be redundancy (if one cable or switch port fails, traffic automatically fails over to the other interface without downtime), or bandwidth aggregation (combining the capacity of two links into one). The most common modes used are active-backup, where only one interface is active and the rest serve as backups, and 802.3ad (LACP), which aggregates link bandwidth but requires switch-side configuration support for LACP.

network:
  version: 2
  ethernets:
    enp0s3: {}
    enp0s8: {}
  bonds:
    bond0:
      interfaces: [enp0s3, enp0s8]
      parameters:
        mode: active-backup
      addresses:
        - 192.168.1.10/24
      routes:
        - to: default
          via: 192.168.1.1

Note that both physical interfaces (enp0s3 and enp0s8) are defined without their own IP configurations, as the IP address now attaches to bond0 as the combined interface.

Verification

After the bonding configuration is applied (see Section 8.4), check which interface is active and which is on backup using the status file provided by the kernel.

cat /proc/net/bonding/bond0
ip a show bond0

8.3.2 VLANs: Logical Network Segmentation

A VLAN (Virtual LAN) allows a single physical interface connected to a trunk port on a switch to be split into multiple separate logical networks, each identified by a VLAN ID (a number from 0 to 4094). A common real-world scenario: a single server using one physical network cable needs to reside on a management network segment and a data network segment simultaneously, without adding new physical network cards.

network:
  version: 2
  ethernets:
    enp0s3: {}
  vlans:
    vlan100:
      id: 100
      link: enp0s3
      addresses:
        - 10.0.100.10/24
    vlan200:
      id: 200
      link: enp0s3
      addresses:
        - 10.0.200.10/24

This server-side VLAN configuration only functions if the switch port to which the server is connected is configured as a trunk port with tagged VLANs 100 and 200. Coordinating with the network team or department managing the switches is a mandatory step before Netplan-side VLAN configurations can become operational.

Verification

Verify that the VLAN interfaces are created and linked to the correct parent interface, along with their assigned VLAN IDs.

ip -d link show vlan100

8.4 Applying Changes: netplan apply

Applying an incorrect network configuration to a remote server is one of the most alarming scenarios for a Sysadmin: as soon as the command runs, the SSH session used to execute it can disconnect immediately, resulting in total loss of access without physical console access (see Chapter 3 regarding console access as a fallback). Fortunately, Netplan provides a dedicated, safe mechanism for this exact scenario.

Practical Steps

1. For minor changes that you are certain about and are executing via direct console access (not remote SSH), apply the configuration directly.

   sudo netplan apply

2. For changes that risk dropping network access, such as changing a static IP over an SSH session, use netplan try instead of apply. This command temporarily applies the new configuration and automatically rolls back to the previous configuration if not confirmed within 120 seconds.

   sudo netplan try

3. If the new configuration works properly and the SSH session remains connected, confirm the changes by pressing Enter before the 120-second timer expires. If the connection drops due to a misconfiguration, simply wait; Netplan will restore the previous configuration automatically once the timeout is reached, recovering SSH access.

Verification and Troubleshooting

• netplan try accepts a custom wait time via the --timeout option if 120 seconds is insufficient, such as for bonding topologies that require extra time to stabilize.

  sudo netplan try --timeout 180

• Make using netplan try a mandatory habit, not an optional step, whenever changing network configurations over a remote session. Forgetting it just once while changing a production IP address can render a server completely unreachable without physical console access or out-of-band management like IPMI/iDRAC.

8.5 Netplan Troubleshooting

Failed network configurations can stem from various causes, ranging from simple YAML syntax errors to conflicts with leftover legacy configurations. This section summarizes the diagnostic steps most frequently used in the field.

Practical Steps

1. If netplan apply fails or displays errors, run generate with debug mode enabled to view detailed YAML parsing logs.

   sudo netplan --debug generate

2. Check the status of all active interfaces and configurations, including those that failed to apply.

   sudo netplan status --all

3. For the systemd-networkd backend, view service logs via journalctl if unexpected errors occur.

   journalctl -u systemd-networkd -b --no-pager

Common Issues and Solutions

• YAML Indentation Errors. The most frequent cause of netplan generate failures. Ensure all files use consistent spacing (typically 2 spaces per indent level) and contain no mixed tab characters, which the YAML parser will reject.
• Misspelled Interface Names. Configurations referencing interface names like eth0 when the actual interface name on the server is enp0s3 (following predictable network interface naming defaults in modern Ubuntu) will prevent Netplan from applying changes to any interface. Always confirm interface names using ip a before writing configurations.
• Conflicting Configuration Files. If multiple YAML files exist in /etc/netplan/ that configure the same interface differently, the file sorted later alphabetically takes precedence. If the resulting outcome is unexpected, inspect the entire directory rather than just the file you edited.

  ls -la /etc/netplan/
  grep -r "" /etc/netplan/*.yaml

• YAML File Permission Warnings. As noted in Section 8.1.1, Netplan triggers warnings if configuration files are readable by users other than root. While this warning does not block the apply process, it should still be resolved to prevent leaking network credentials like Wi-Fi passwords.
• Loss of SSH Access Due to Misconfiguration. If this occurs and netplan try was not used, the only remedy is direct console access, whether physical, via a hypervisor (KVM/VMware), or through a cloud provider serial console, as discussed in Chapter 3.

At this point, we have covered Netplan as the foundation for Ubuntu Server network configuration: understanding YAML file structures and backend differences, practicing static IP assignment, learning bonding and VLAN concepts for complex topologies, and establishing the habit of using netplan try as a safety net before running apply on production servers. Chapter 9 will continue the networking section with DNS server configuration using BIND9, building upon the static IP configured in this chapter.