Alright, let’s talk Netplan. If you’ve landed on a modern Ubuntu system and tried to go poking around in /etc/network/interfaces like it’s 2010, you were probably met with a polite, yet firm, suggestion to get with the times. Netplan is that suggestion. It’s not a network daemon itself; think of it as the diplomatic translator that sits between you (the human, writing clean YAML) and the low-level networking engines that do the actual heavy lifting (systemd-networkd and NetworkManager). Its entire reason for being is to provide a consistent, declarative network configuration across all Ubuntu flavors. And it does this by making us write YAML. I’m sorry. We’ll get through this together.

The Absolute Basics of a Netplan Config File

You’ll find these files in /etc/netplan/. There’s probably already one there called 01-network-manager-all.yaml or 50-cloud-init.yaml. Netplan processes these files in lexicographical order, and later files can override settings from earlier ones. The structure is always the same: a top-level network key, followed by a version, and then the real meat: ethernets, wifis, or bridges.

Here’s the “Hello, World” of Netplan—a simple static IP configuration. We’re going to tell the system to stop being a leaf on the wind (DHCP) and become a sturdy, predictable oak tree (a static address).

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: no
      addresses: [192.168.1.42/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

Let’s break this down. We’re using version 2 of the config syntax (always use this). The renderer tells Netplan which backend to use—networkd for servers or headless machines, NetworkManager if you’re on a desktop and need that sweet, sweet GUI integration. Under ethernets, we use the actual interface name as a key. We disable DHCP, assign an IP and subnet mask (note the CIDR notation /24—it’s mandatory), define a default route, and set our DNS servers. It’s all very logical.

Applying This Masterpiece

You don’t restart a service here. You apply the configuration. This is Netplan’s killer feature: it sanity-checks your YAML before it brutally mangles your network connection.

sudo netplan apply

This command translates your YAML into backend-specific config files (/run/systemd/network/ for networkd) and brings the interfaces up with the new settings. If you completely bork your remote connection by applying a bad config, sudo netplan apply won’t save you. This is where the generate and try commands come in.

sudo netplan generate checks your YAML for syntax errors. It’s your first line of defense. sudo netplan try applies the configuration and then waits for you to press Enter. If you don’t press Enter (because your SSH session just died and you can’t), it automatically rolls back after 120 seconds. It’s a lifesaver for remote administration. Always use try when you’re making changes over SSH. Always.

The Devilish Details: DHCP and Multiple IPs

Need more than one IP on an interface? Netplan has you covered, though the syntax is a bit… listy. Also, want to use DHCP but also set a static IP? That’s called “ipv4 dhcp-override” for some reason, and it’s a classic case of a necessary feature with a slightly bizarre name.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: yes
      addresses:
        - 192.168.1.99/24
        - 10.0.0.5/24
      nameservers:
        addresses: [1.1.1.1]
      dhcp4-overrides:
        use-dns: no
        use-routes: no

Here, we’re getting an address via DHCP and setting two static addresses. The dhcp4-overrides block is crucial: it tells the system, “Hey, get your IP from the DHCP server, but ignore the routes and DNS settings it gives you. We’re doing our own thing for those.” Without this, your static routes and DNS would likely be overwritten by the DHCP-provided ones, leading to confusing and inconsistent behavior.

Common Pitfalls and The “Gotchas”

  1. YAML Syntax: This is the big one. YAML is whitespace-sensitive and hates tabs. Use spaces. Always. If your netplan apply fails with a cryptic error, run yamllint on your file. It’s almost always a indentation or formatting issue.
  2. Missing the Renderer: Forgetting the renderer key is a common mistake. It will probably default to something, but do you really want to leave that to chance? Be explicit.
  3. The routes Indentation: The routes block is a list of dictionaries. Notice the hyphen and the indentation in the example. Messing this up is a rite of passage.
  4. Not Using netplan try: I said it before, but it’s worth repeating. If you value your SSH session, you will use sudo netplan try when testing new configurations on a remote machine. It’s the difference between a minor oopsie and a frantic drive to the data center.

Netplan can feel a bit abstract at first, especially if you’re used to the imperative style of old-school scripts. But once you get the hang of its declarative nature, you’ll appreciate the clarity. You’re not telling the system how to do its job; you’re telling it what the end state should look like. It’s a higher-level way of thinking, and for better or worse, it’s the future on Ubuntu. Now go forth and configure. And maybe keep a netplan try safety net handy.