Netplan Config Generator

Introduction:

Netplan configuration describes how an Ubuntu system should bring up its network interfaces. A static Ethernet setup usually needs an interface identifier, one or more CIDR addresses, a default route, DNS resolvers, and the renderer that will hand the final settings to systemd-networkd or NetworkManager.

The risk is practical. A missing prefix can leave the host with no usable subnet, a gateway in the wrong address family can prevent outbound traffic, and a copied route can look correct until two default routes compete with the same priority. Netplan YAML is concise, so the same few lines often carry the full boot-time path for SSH, package updates, monitoring, and name resolution.

Generated Netplan YAML should be treated as a candidate configuration, not as proof that the target host will stay reachable. The target Netplan version, renderer support, existing files under /etc/netplan/, cloud image defaults, and the real network segment still decide whether the file can be applied safely.

The safest habit is to prepare the static interface definition, review the generated paths and warnings, then test with netplan try or netplan generate on the host or a staging clone before using netplan apply on a remote server.

Technical Details:

A Netplan file uses a network: mapping with version: 2. Ethernet settings sit under ethernets, where the map key either names the Linux interface directly or acts as an internal device ID paired with a match rule. Static addressing is written as CIDR values, because the prefix length tells Linux which destinations are on the directly connected subnet.

Default routing has two common forms. Current Netplan examples favor route entries such as to: default and via: 10.10.10.1, while older Ubuntu environments may still require gateway4 or gateway6. DNS settings live under nameservers, with resolver addresses and optional search suffixes kept separate.

Rule Core:

Route priority is determined by destination, address family, metric, and routing table. A duplicate default route with the same family, metric, and table is not always invalid, but it can make failover or multi-homed hosts behave differently from the intended design. The review warns about this specific collision so it can be corrected before the YAML reaches a server.

Validation Boundaries:

The YAML, Interface Audit, Route Ledger, Validation Review, and JSON view are generated from the same parsed network data. If the review shows an error, the YAML is still visible for diagnosis, but it should not be copied into /etc/netplan/ until the named issue is corrected.

Everyday Use & Decision Guide:

Start with networkd for a typical Ubuntu Server interface unless the host is managed by desktop NetworkManager profiles or another Netplan file already declares the renderer. Fill in the real interface name, one static address in CIDR form, one default gateway for the same IP family, and the DNS servers the host should use after boot.

Use the samples as quick resets, not as deployment templates. Static sample returns to a single-stack IPv4 server shape, while Dual-stack sample shows IPv4 and IPv6 addresses, two default gateways, a MAC match, a final interface name, and a custom MTU.

• Use Match MAC address before Set interface name when the kernel interface name can change across boots or VM hardware order changes.
• Leave Default gateway blank only for isolated, routed, or policy-routed interfaces that should not own a default route.
• Add Static routes as CSV rows only when the host needs more than the default path, and keep the route destination and gateway in the same address family.
• Set Default route metric when multiple route candidates need a clear priority. Distinct metrics make the Route Ledger easier to defend.
• Turn on Use legacy gateway4/gateway6 keys only for an older target that rejects routes with to: default.

The common wrong assumption is that clean YAML means safe connectivity. A generated file can still use the wrong NIC, inherit a conflicting renderer from another file, or define a gateway that is unreachable on the real subnet. Read Validation Review first, then compare Interface Audit and Route Ledger against the change ticket or IP address plan.

When the summary shows Netplan YAML ready, the next useful check is not more formatting. Run netplan try on the target host or a staging clone so a bad route or renderer choice can be rolled back before it locks out remote access.

Step-by-Step Guide:

Build the interface definition from the values that must survive reboot, then use the review tabs to catch route and addressing mistakes.

1. Choose Renderer. The summary badge should show networkd, NetworkManager, or renderer omitted.
2. Enter Interface name. If Validation Review reports an unsafe or blank name, use a kernel name such as ens192 or add Match MAC address with a simple Netplan ID.
3. Add one value per line in Static address CIDR. IPv4 values need prefixes such as /24; IPv6 values need prefixes such as /64.
4. Enter one Default gateway per address family. A duplicate IPv4 or IPv6 gateway in this field appears as an error.
5. Add DNS servers and optional Search domains. Resolver entries must be IP addresses, while search suffixes should be plain domain names.
6. Add optional Static routes as destination,gateway,metric,on-link,table. If a route warning appears, check the fourth and fifth CSV values before trusting the route row.
7. Open Advanced for Default route metric, Match MAC address, Set interface name, MTU, optional boot behavior, DHCP false flags, or legacy gateway output.
8. Read Validation Review. Clear every Error, then decide whether each Warning is intentional for the target host.
9. Use Interface Audit and Route Ledger to confirm YAML paths, then copy the Netplan YAML only after the review matches the planned network change.

Interpreting Results:

Netplan YAML ready means no blocking validation errors were found in the entered values. It does not prove that the host's Netplan version, renderer backend, file permissions, or existing configuration set will accept the result unchanged.

The JSON view is useful for records and automation notes, but Netplan consumes the YAML. If the JSON, ledger, or audit table makes the plan look wrong, change the form inputs instead of editing only the copied YAML text.

Worked Examples:

Single-stack server interface

A server on 10.44.20.0/24 can use Interface name ens192, Static address CIDR 10.44.20.10/24, gateway 10.44.20.1, two DNS servers, and route metric 100. The summary reads Netplan YAML ready, the primary value reads ens192 static, and Route Ledger shows one default route plus the entered static routes.

Dual-stack interface with a MAC match

Dual-stack sample uses interface ID id0, addresses 10.44.20.10/24 and 2001:db8:44:20::10/64, matching gateways, match.macaddress 00:11:22:33:44:55, set-name ens192, and MTU 1500. The badges include ipv4 + ipv6, and the YAML includes both dhcp4: false and dhcp6: false.

Gateway outside the entered subnet

If Static address CIDR is 10.44.50.21/24 and Default gateway is 10.44.60.1, Validation Review adds a Gateway reachability warning. That warning can be acceptable for special routing, but on a normal VM network it usually means the gateway or prefix is wrong.

Broken route CSV row

A route row such as 10.55.0.0/16,2001:db8::1,abc,maybe,bad table! produces several review entries: the destination is IPv4 while the gateway is IPv6, abc is not a valid metric, maybe is not a recognized on-link flag, and the table value may not be accepted. Fix the family match and CSV fields before using the generated route.

FAQ:

Glossary:

Netplan

Ubuntu's YAML-based network configuration system that hands settings to a renderer.

Renderer

The backend that applies the network definition, commonly systemd-networkd or NetworkManager.

CIDR

Address notation that combines an IP address and prefix length, such as 10.44.20.10/24.

Default route

The route used when no more specific destination route matches outbound traffic.

Metric

A route priority value used to order otherwise similar route choices.

on-link

A route flag that treats the gateway as directly reachable through the interface.

Route table

A separate Linux routing table used when policy routing or multi-path designs need isolation.

References:

• Netplan overview, Canonical.
• YAML configuration, Netplan documentation, Canonical.
• How to use static IP addresses, Netplan documentation, Canonical, updated October 15, 2024.
• Configuring networks, Ubuntu Server documentation.