Netplan Config Generator

Ubuntu network changes often come down to a short YAML file, but that file decides how a host finds its address, gateway, DNS servers, and route priority after boot. Netplan is the declarative layer that reads configuration under /etc/netplan/ and hands the work to a renderer such as systemd-networkd or NetworkManager. The YAML is compact, which is useful for automation, but it also means a copied address, missing prefix, or wrong backend choice can break a server that otherwise looks healthy.

A static Ethernet configuration has two separate jobs. First it identifies the device that should receive the settings, either by the current interface name or by a stable match such as a MAC address. Then it describes the network facts attached to that device: CIDR addresses, default routes, additional routes, resolver addresses, search domains, and optional interface details such as MTU. These pieces need to agree with each other. An IPv4 gateway should normally live inside one of the entered IPv4 subnets, IPv6 routes need IPv6 next hops, and route metrics need to make the preferred path obvious when several defaults exist.

Several Netplan terms carry more meaning than their names suggest:

Renderer

The backend that applies the network definition. Server installs commonly use networkd; desktop and managed-profile systems often use NetworkManager.

CIDR address

An IP address plus prefix length, such as 10.44.20.10/24 or 2001:db8:44:20::10/64. The prefix defines the directly connected subnet.

Default route

The route used when no more specific destination matches. Current Netplan examples represent it as a route with to: default and a next hop in via.

Metric

A route priority value. Lower metrics are usually preferred when two routes cover the same destination in the same table.

Match and set-name

A way to bind settings to a physical device and optionally give it a stable final name, useful when kernel interface names may change.

The risky part is not only YAML syntax. Cloud images may already have files generated by provisioning systems, a desktop image may expect NetworkManager, a virtual machine may expose a new interface name after migration, and multi-homed servers may need different route tables or metrics. A file that looks correct in isolation can still lose connectivity if it conflicts with those host-level facts.

A good Netplan change is therefore both syntactically valid and operationally believable. The address plan, gateway, renderer, interface identity, and route priority should be checked before the file is applied, and remote systems should be tested with rollback protection whenever the environment supports it.

How to Use This Tool:

Build one static Ethernet definition at a time and compare the YAML with audit tables before moving it to a host.

1. Choose Renderer. Use networkd for most Ubuntu Server hosts, NetworkManager for desktop or centrally managed hosts, or omit the renderer only when another Netplan file intentionally owns the global renderer.
2. Enter the Interface name. Use the real Linux interface name, such as ens192 or enp1s0, unless you plan to match by MAC address and assign a final name in Advanced.
3. Add each Static address CIDR with a prefix. Dual-stack hosts can include both IPv4 and IPv6 addresses, one per line or comma-separated.
4. Add a Default gateway only for the families this interface should route. Keep one IPv4 gateway and one IPv6 gateway in that field; use Static routes for extra destinations, weighted defaults, on-link routes, or route tables.
5. Enter DNS servers as IP addresses and Search domains as plain suffixes. The review will flag malformed resolver IPs and suspicious search-domain text.
6. Open Advanced when the host needs a default route metric, MAC match, final interface name, MTU, optional boot behavior, explicit static-family DHCP flags, or legacy gateway4/gateway6 keys.
7. Use Static sample or Dual-stack sample when you want a complete starting point. These buttons replace the current form values, so copy anything important first.
8. Read Validation Review before copying the YAML. Fix every Error, then decide whether each Warning matches the intended network design.

Interpreting Results:

Netplan YAML ready means the entered values passed the generator's local checks. It does not prove that the interface exists, that a renderer is installed, that another YAML file will not override a setting, or that the gateway can actually answer on the target network.

Copy and download actions are available for the YAML and JSON. The audit tables can be copied or downloaded as CSV, and the interface, route, and validation tables can be exported as DOCX review notes when the page environment supports document export.

Technical Details:

Netplan version 2 configuration uses a top-level network: mapping. Physical Ethernet devices are declared under ethernets, where each key names an interface definition. The same definition can hold static addresses, DHCP flags, name matching, renaming, nameservers, routes, MTU, and boot behavior.

Static addresses are written in CIDR notation because the prefix length defines the local subnet. Routes use destinations such as default, 0.0.0.0/0, ::/0, or another CIDR block, and the gateway must be an IP address from the same family as the destination. When default gateways are not emitted through legacy keys, they become route rows with to: default.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens192:
      dhcp4: false
      addresses:
        - 10.44.20.10/24
      nameservers:
        addresses:
          - 10.44.10.53
      routes:
        - to: default
          via: 10.44.20.1
          metric: 100

Generated YAML Areas:

Validation Boundaries:

Static route input uses CSV rows in the order destination, gateway, metric, on-link flag, and route table. Blank optional columns are allowed, but the destination and gateway must still form a valid route. The generated route ledger is a useful audit view because it normalizes 0.0.0.0/0 and ::/0 defaults, shows the family, and makes route-table or metric choices visible before the YAML is applied.

Limitations and Privacy:

The YAML is assembled in the browser from the values you enter, and no server lookup is needed to generate the configuration. That keeps the drafting step local, but it also means the checks are limited to text shape, address families, route consistency, and common Netplan hazards.

The generator cannot inspect the target host's existing Netplan files, renderer availability, cloud-init behavior, kernel interface inventory, link state, VLAN or switch setup, routing policy database, firewall rules, or real DNS reachability. It can warn when an IPv4 gateway is outside an entered subnet, but only the host and network segment can prove whether an on-link or routed design is valid.

• Use netplan try on remote systems when possible so a bad configuration can roll back if it is not confirmed.
• Use netplan generate to catch parser errors before applying a file permanently.
• Keep console or out-of-band access for important servers, especially when changing default routes, renderer, or interface identity.
• Verify rollback and on-disk configuration after a failed or cancelled netplan try, because the target host remains the source of truth.

Advanced Tips:

• Keep route-based defaults selected unless the target host is known to require gateway4 or gateway6; current Netplan files are easier to audit when defaults appear in the route list.
• Use Default route metric whenever another interface can also carry a default route, then confirm the Route Ledger shows distinct priority or table values.
• Pair Match MAC address with Set interface name on cloned or migrated systems so the generated definition binds to the physical device before renaming it.
• Set MTU only when the link, virtual switch, overlay, or provider network supports the chosen frame size from end to end.
• Use the Dual-stack sample to check IPv4 and IPv6 family separation, then replace every documentation address and gateway before copying the YAML.
• Copy the validation or route table into a change ticket when default routes, on-link flags, or route tables are part of the approval risk.

Worked Examples:

Single-stack Ubuntu Server interface

For a VM on 10.44.20.0/24, choose networkd, enter ens192, add 10.44.20.10/24, set the gateway to 10.44.20.1, and add resolver IPs. A clean result should show one IPv4 address, one default route, and explicit static-family DHCP false output when that option is enabled.

Dual-stack host with stable naming

A dual-stack server can include one IPv4 CIDR and one IPv6 CIDR on the same Ethernet definition, plus one gateway per family. If the hardware name may change after migration, add a lowercase MAC match and a final interface name. Review the audit row for interface identity before trusting the generated YAML.

Multiple default routes

A host with more than one outbound path can use additional route rows for weighted defaults. The route ledger should show distinct metrics or tables so the active path is intentional. Two defaults with the same destination, family, metric, and table are review-worthy because troubleshooting becomes ambiguous.

Broken route row

A row such as 10.55.0.0/16,2001:db8::1,abc,maybe,bad table! is not safe. The destination is IPv4 while the gateway is IPv6, the metric is not numeric, the on-link flag is unclear, and the table text is suspicious. Fix those issues before copying the YAML.

FAQ:

Glossary:

Netplan

Ubuntu's declarative network configuration system that reads YAML and asks a renderer to apply the resulting network setup.

Renderer

The backend that applies the configuration, most commonly networkd or NetworkManager.

CIDR

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

Default route

The route used for traffic that does not match a more specific destination.

On-link

A route flag that treats the gateway as directly reachable even when it is outside the entered subnet.

Route table

A routing table used to separate route decisions, often with policy routing.

References:

• YAML configuration, Netplan documentation.
• Configuration examples, Netplan documentation.
• netplan try, Netplan documentation.
• How to add a static route in Linux, Simplified Guide.
• How to change DNS servers in Linux, Simplified Guide.