{{ summaryHeading }}
{{ summaryValue }}
{{ summaryLine }}
Version 2 {{ outputTargetLabel }} {{ summaryBadge }}

Topology unavailable.

This changes only the outer YAML wrapper; it does not change the interface plan.
Examples: ens160, eth0, enp1s0, or id0 for a matched device.
One address/prefix per line. Replace the documentation-range defaults before use.
Leave blank only when another source installs the default path.
One resolver per line; the default IPv4 resolver is a documentation placeholder.
Optional resolver search suffixes, such as corp.example.
Format: destination,gateway,metric,table. Blank metric and table cells are allowed.
Samples use documentation values, stay local, and replace the current form.
Blank is neutral and usually the most portable starting point.
Blank omits the match block.
Blank keeps the target image's interface name.
Blank omits MTU; accepted values are 576 through 9216.
bytes
Blank omits the metric from generated default routes.
Blank/Off is neutral. Enable only after checking the image's networkd boot-wait behavior.
{{ optional_boot ? 'Enabled' : 'Disabled' }}
Off is neutral. Enable only for a known older image that cannot accept route-based defaults.
{{ legacy_gateway ? 'Enabled' : 'Disabled' }} 
{{ values.config_text }}
FieldValueOutput pathReview noteCopy
{{ row.field }}{{ row.value }}{{ row.path }}{{ row.note }}
LevelCheckDetailRecommendationCopy
{{ row.level }}{{ row.check }}{{ row.detail }}{{ row.recommendation }}
Netplan Config Generator Build Netplan YAML for Ubuntu static interfaces with CIDR addresses, DNS, routes, and warnings for gateway or priority mistakes.
WHOIS / RDAP Lookup Check domain registration data through RDAP with WHOIS fallback, then review expiry timing, nameservers and evidence coverage for follow-up.
dnsmasq DHCP Config Generator Generate a dnsmasq IPv4 DHCP scope with CIDR and pool checks plus reservations, client options and optional PXE lines for a review-ready config.
WireGuard Config Generator Generate WireGuard server and client configurations with CIDR validation, route-scope warnings, and explicit placeholders for safer key handling.

Static network data can decide whether a new virtual machine is reachable on its first boot. The operating system may start normally while remote access fails because the address lacks the right prefix, the gateway is outside the local link, the wrong interface received the plan, or name resolution points at unusable servers.

Cloud-init network configuration version 2 describes that early network state as YAML. An Ethernet definition can disable DHCP for the address families being configured, assign IPv4 or IPv6 addresses in classless inter-domain routing (CIDR) notation, install routes, and provide DNS servers and search domains. Optional matching and rename rules help identify a device whose kernel name may vary between images.

  • Link identity determines which adapter receives the settings. A configuration ID may be enough, while a rename should be tied to a unique hardware match.
  • Local addressing combines each IP address with a prefix length. A bare address does not say which destinations are on-link.
  • Routing sends nonlocal destinations through a gateway. IPv4 and IPv6 routes must use gateways from the same address family.
  • Name service separates literal DNS server addresses from plain search suffixes used to expand short hostnames.

Version 2 overlaps with Netplan syntax, but image behavior is not uniform. Netplan-based images can pass through options to networkd or NetworkManager; direct cloud-init rendering supports a narrower subset. A YAML document that parses successfully can still contain an unsupported renderer choice or an option that behaves differently on the target image.

Routes with to: default are the current form for default gateways. Older gateway4 and gateway6 keys remain a compatibility choice, but they are deprecated in Netplan and cannot express a default-route metric in this generated shape. Multiple defaults, policy routing, bonds, bridges, VLANs, and DHCP-derived routes need a broader design.

Boot-time networking should be tested with console or out-of-band access. Syntax checks cannot verify the datasource, virtual switch, reserved address, upstream gateway, route ownership, DNS service, end-to-end maximum transmission unit (MTU), or the renderer installed in the guest.

How to Use This Tool:

Work from the seed format to the link, then add only the routes and resolver details the guest actually needs.

  1. Choose Output target. NoCloud network-config emits version 2 at the document root; cloud.cfg.d snippet adds an outer network: mapping.
  2. Enter an Ethernet ID and at least one Static address CIDR. Put one IPv4 or IPv6 address and prefix on each line.
  3. Add at most one default gateway for each address family. Enter DNS servers as IP literals and search domains as plain suffixes without a URL scheme.
  4. Add extra routes as destination,gateway,metric,table. Destination may be default or CIDR; metric and table may be blank.
  5. Open Advanced only when the image requires an explicit renderer, MAC match, interface rename, MTU, route metric, optional boot behavior, or deprecated gateway keys.
  6. Replace every documentation-range sample, then read Validation review. Test the resulting YAML on a disposable VM with console access before reusing the seed.

Interpreting Results:

A generated configuration is available only after structural validation succeeds. Pass rows confirm local facts such as accepted address syntax or an emitted default path. Warning rows identify conditions that can still produce valid YAML but need target-specific review.

The most important warning is Boot verification, which always remains because the browser cannot inspect the guest image or network. A zero-warning result is therefore neither expected nor a reachability guarantee. Confirm the interface, applied addresses, selected routes, gateway reachability, and resolver behavior after boot.

Technical Details:

The generated model covers one static Ethernet definition. It parses and validates address data first, derives review warnings, emits version 2 YAML in a fixed order, and finally adds the selected outer wrapper. Changing the output target does not change the interface plan.

Transformation Core:

Input meaning Version 2 YAML projection Conditional behavior
Output target Root version: 2 document or a network: wrapper containing that document Only indentation and the outer mapping change
Address families addresses list plus dhcp4: false and/or dhcp6: false Each DHCP key appears only when that family has a static address
Default gateways Routes whose destination is default Legacy mode emits gateway4 or gateway6 instead and ignores the default-route metric
DNS values nameservers.addresses and nameservers.search The nameservers block is omitted when both lists are empty
Device identity Ethernet mapping key, optional match.macaddress, and optional set-name A rename without a MAC match produces a warning

Formula Core:

An IPv4 gateway is considered on-link when the address and gateway produce the same network value under the entered prefix mask.

Aaddress ∧ Mp = Agateway ∧ Mp

Here A is the 32-bit IPv4 value, p is the CIDR prefix from 0 through 32, M is the contiguous prefix mask, and ∧ is bitwise AND. A gateway outside every entered IPv4 subnet produces a warning. IPv6 gateway reachability is not modeled with an equivalent subnet calculation, so it still requires target-side verification.

Rule Core:

Field Accepted rule Boundary or consequence
Ethernet ID 1 to 64 letters, numbers, dots, underscores, colons, or hyphens Required
Static addresses One or more IPv4 or IPv6 CIDRs IPv4 prefix 0 to 32; IPv6 prefix 0 to 128
Default gateways Literal IP addresses At most one IPv4 and one IPv6 gateway
Static route default or CIDR destination, same-family IP gateway, optional metric and table Metric 0 to 4,294,967,295; table is a simple name or numeric ID up to 64 characters
MTU Whole number or blank 576 to 9216 inclusive
Default-route metric Whole number or blank 0 to 4,294,967,295 inclusive
MAC match Lowercase colon-separated six-byte address or blank Used only to emit a match block

Search suffixes must be plain DNS names. The parser rejects URL schemes, underscores, empty labels, and labels beginning or ending with a hyphen. DNS servers and route gateways must be literal IP addresses; hostnames are not resolved.

The review adds warnings for a missing default path, a gateway without a matching address family, an off-subnet IPv4 gateway, rename without MAC match, NetworkManager portability, optional boot with NetworkManager, deprecated gateway keys, an ignored metric in legacy mode, documentation examples, and the mandatory boot-verification limit.

Documentation addresses in 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24, plus example.invalid, trigger the sample warning. Replace the address, gateway, route, resolver, and suffix together rather than clearing only the warning-producing field.

Deployment Limits:

The data stays in the browser during generation, but local processing cannot make the plan safe to apply. The generated subset does not cover Wi-Fi, DHCP plans, multiple Ethernet definitions, bonds, bridges, VLANs, policy routing, route flags, or provider-specific metadata behavior.

Validate the YAML with the exact image tooling, boot a disposable instance, and keep console access. After boot, verify link state, assigned addresses, default and static routes, gateway reachability, DNS resolution, and persistence across a maintenance reboot.

References: