Cloud-init Network Config Generator

Output target:

Choose where this YAML will be placed before boot.

Interface ID:

Examples: ens160, eth0, enp1s0, or id0 for a matched device.

Static address CIDR:

One address per line; prefixes are required.

Default gateway:

Leave blank only when another route source provides the default path.

DNS servers:

Resolvers are emitted under nameservers.addresses.

Search domains:

Optional; keep blank when no resolver search path is needed.

Static routes:

One route per line using destination,gateway,metric,table.

Samples stay local and overwrite the current form.

Renderer:

Optional network-config renderer field.

Match MAC address:

Optional; use lowercase colon-separated MAC notation.

Set interface name:

Optional target interface name after matching.

MTU:

Use only when the VM network requires a non-default MTU.

bytes

Default route metric:

Blank omits metric from generated default routes.

Mark interface optional:

Adds optional: true so boot does not wait for this interface.

Use legacy gateway keys:

Default output uses routes with to: default; enable only for older images that require gateway keys.

{{ result.yaml }}

Field	Value	Output path	Note	Copy
{{ row.field }}	{{ row.value }}	`{{ row.path }}`	{{ row.note }}

Severity	Check	Detail	Recommendation	Copy
{{ row.severity }}	{{ row.check }}	{{ row.detail }}	{{ row.recommendation }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Static networking is one of the few VM settings that can break access before the operating system is fully usable. A guest may boot, run services, and still be unreachable because the first network plan selected the wrong adapter name, pointed the default route at the wrong gateway, or omitted the resolver settings needed for hostnames. Cloud-init is often the piece that applies those early boot facts on cloud images, lab templates, and cloned virtual machines.

The network plan has to describe both identity and reachability. Identity answers which interface receives the configuration, either by a known device name such as ens160 or by a hardware match such as a MAC address. Reachability answers which addresses belong on the link, where packets leave the subnet, and which DNS servers and search suffixes the guest should use after boot.

Cloud-init network configuration version 2 uses YAML with terms that overlap Netplan: ethernets, addresses, nameservers, and routes. That overlap is useful, but it is also where portability mistakes happen. Images that pass version 2 data through to Netplan can accept broader Netplan syntax, while non-Netplan rendering supports a narrower cloud-init subset. A plan copied from one distribution image can be valid YAML and still be a poor fit for another image.

CIDR address: An address and prefix length together, such as 10.44.50.21/24. The prefix decides which destinations are considered local to the link.
Default route: The path used when no more specific route matches. Current version 2 plans commonly express it as a route with to: default.
Renderer: The network backend expected to apply the data inside the guest. Leaving it unset is often more portable than naming a backend too early.
MAC match: A hardware-address match rule that helps a renamed interface point at the intended adapter instead of whatever name the kernel assigned.

Several common errors are small on the page and large at boot time. A bare IP address without a prefix cannot define the local network. An IPv6 gateway cannot serve an IPv4 default route. Duplicate default gateways for one address family need a more explicit routing design. Search domains should be DNS suffixes, not URLs, and a rename without a tight match rule can attach the final name to the wrong device.

A generated static plan is a preflight artifact, not a reachability guarantee. The datasource, guest image, virtual switch, renderer, upstream gateway, DNS service, and cloud-init version still need to be tested on a disposable VM before the same seed is trusted for production clones.

How to Use This Tool:

Work from the boot context outward: choose the output target, identify the interface, then add addresses, default paths, resolver data, and any advanced identity rules.

Choose NoCloud network-config for a standalone seed file. Choose cloud.cfg.d snippet when the version 2 network block should be nested under network: for a cloud-init configuration drop-in.
Enter the Interface ID. Use a real device name for simple cases. If the device will be selected by hardware address, use a stable ID and fill Match MAC address plus Set interface name in Advanced.
Add one Static address CIDR per line. Include the prefix on every address, and mix IPv4 and IPv6 only when the guest is meant to be dual stack.
Enter at most one Default gateway for IPv4 and at most one for IPv6. Leave the field blank only when some other boot-time network source will install the default path.
Add literal IP addresses under DNS servers and plain suffixes under Search domains. A value such as example.internal is a search suffix; a full web address with a scheme is not.
Use Static routes for extra paths in destination,gateway,metric,table form. The destination may be default or a CIDR block, with metric and table left blank when they are not needed.
Open Advanced only for renderer choice, MAC matching, rename, MTU, default route metric, optional boot behavior, or legacy gateway4/gateway6 output.
Read Validation Review before copying or downloading. Fix every error, then decide whether each warning is acceptable for the image and network you will boot.

Interpreting Results:

The summary distinguishes blocking errors, warnings, and a clean validation pass. A clean pass means the entered values fit the supported one-interface YAML shape and the local checks did not find common mistakes. It does not prove that the guest image can render the data, that the virtual gateway is reachable, or that DNS will answer after boot.

Cloud-init network configuration result cues and follow-up checks
Result Cue	Meaning	Check Before Use
`fix required`	At least one validation error exists.	Correct the named field before copying the YAML.
`validated`	No errors or warnings were found by the current checks.	Boot a disposable VM and confirm address, default route, and resolver behavior from inside the guest.
`routes with to: default`	Default gateways will be emitted as route entries.	Use this for current version 2 plans unless an older image requires legacy gateway keys.
`gateway4/gateway6`	Legacy gateway output is enabled.	Do not expect a default route metric to appear in that legacy output.
`Gateway reachability`	An IPv4 gateway is outside every entered IPv4 subnet.	Check the prefix and gateway, or keep the warning only when an on-link route design is deliberate.
`Renderer portability`	`NetworkManager` was selected.	Confirm that the target image supports that renderer path for version 2 data.

The Cloud-init YAML tab is the artifact to place in the chosen seed or configuration location. Network Ledger restates the parsed interface, route, DNS, renderer, boot, and MTU decisions for review. Validation Review separates errors, warnings, informational notes, and pass rows. The JSON view carries the same plan in a structured form for tickets or repeatable handoff.

Warnings matter when console access is limited. Valid YAML can still fail operationally if it assumes the wrong renderer, leaves a rename too loose, or describes a gateway that the VM cannot reach through its virtual switch.

Technical Details:

Cloud-init network version 2 is a declarative YAML format. The core shape uses version: 2 and a device map such as ethernets, where each entry combines address assignment, DHCP flags, routes, resolver settings, and optional device matching. The generated plan here covers one static ethernet device, not bonds, bridges, VLANs, Wi-Fi, VRFs, or policy routing.

NoCloud seed data and cloud-init drop-ins differ mainly in the outer wrapper. A NoCloud network file can start directly with the version 2 network data. A cloud-init configuration drop-in nests the same network data under a top-level network: key. The interface facts do not change when the wrapper changes.

Transformation Core:

The generated YAML starts with one ethernet map and emits optional keys only when the related input is present or required by the selected address family.

Cloud-init network version 2 transformation rules
Input Area	YAML Result	Rule
`Output target`	Direct version 2 block, or `network:` wrapper	The selected target changes the wrapper only.
`Interface ID`	`ethernets.<id>`	The ID is the ethernet key. With a MAC match, it can act as a stable reference while `set-name` supplies the final device name.
`Static address CIDR`	`addresses`, plus `dhcp4: false` or `dhcp6: false`	IPv4 addresses disable IPv4 DHCP for the device; IPv6 addresses disable IPv6 DHCP for the device.
`Default gateway`	`routes` entries with `to: default`, or legacy `gateway4`/`gateway6`	Route-based defaults are used unless legacy gateway output is enabled. Only one default gateway per family is accepted.
`DNS servers` and `Search domains`	`nameservers.addresses` and `nameservers.search`	Resolver addresses must be IP literals. Search values are checked as DNS suffixes.
`Static routes`	`routes` entries with `to`, `via`, optional `metric`, optional `table`	Destination and gateway families must match when the destination is a CIDR block.
`Optional boot`	`optional: true`	The key is emitted only when enabled; otherwise required-interface behavior remains implicit.

Formula Core:

The IPv4 gateway warning compares the network portion of each entered IPv4 address with the network portion of the IPv4 gateway. Both values are converted to 32-bit integer form before the mask is applied.

mask = 2^{32} - 2^{32 - p}

sameSubnet = (A & mask) = (G & mask)

A is the IPv4 address, G is the IPv4 gateway, p is the CIDR prefix length, and & is bitwise AND.

With 10.44.50.21/24 and gateway 10.44.50.1, the /24 mask keeps 10.44.50 as the network portion for both values. With gateway 10.44.60.1, the masked gateway network becomes 10.44.60.0, so the reachability warning appears.

Validation Boundaries:

Validation boundaries for cloud-init network configuration inputs
Field	Accepted Boundary	Validation Result
`Interface ID`	Letters, numbers, dot, dash, underscore, or colon.	Missing values or risky characters produce an error.
`Static address CIDR`	IPv4 prefix `0` to `32`; IPv6 prefix `0` to `128`.	Missing prefixes and invalid address literals produce errors.
`Default gateway`	Valid IPv4 or IPv6 literal, with one gateway per family.	Invalid literals and duplicate family defaults produce errors; missing matching address family produces a warning.
`Static route`	`default` or CIDR destination, valid next hop, non-negative metric.	Missing destination, missing gateway, invalid metric, or family mismatch produces an error.
`Match MAC address`	Lowercase colon-separated form such as `00:11:22:33:44:55`.	Other formats produce an error because version 2 MAC matches are documented in lowercase form.
`Set interface name`	Simple Linux interface-name characters.	A rename without a MAC match produces a warning; risky characters produce an error.
`MTU`	Blank, or integer from `576` through `9216`.	Out-of-range values produce an error.
`Default route metric`	Blank, or integer from `0` through `4294967295`.	Out-of-range values produce an error; legacy gateway mode ignores the value and warns.

Renderer handling stays conservative. Version 2 documentation names networkd and NetworkManager, but cloud-init rendering outside Netplan is narrower. A NetworkManager choice is therefore treated as a portability warning rather than a syntax error.

Limitations and Privacy Notes:

The validation review checks syntax shape, address families, numeric bounds, subnet comparison for IPv4 gateways, and common cloud-init network mistakes. It does not contact a VM, inspect the guest image, run Netplan, check the virtual switch, or prove that resolver addresses answer queries.

Entered network details are processed in the browser. Copying, downloading, exporting, or sharing the result is controlled by the user, but the resulting artifacts can reveal private address ranges, internal search suffixes, MAC addresses, and route design. Keep generated YAML and screenshots out of public tickets unless those values are safe to disclose.

The scope is one static ethernet definition. Multi-NIC designs, bonds, bridges, VLANs, Wi-Fi authentication, VRFs, routing policy, and per-platform datasource quirks need a fuller cloud-init or Netplan review.

Worked Examples:

A single-stack VM using ens160, address 10.44.50.21/24, gateway 10.44.50.1, and DNS servers 10.44.10.53 and 10.44.10.54 should generate one IPv4 static address, dhcp4: false, resolver entries, and a default route when legacy gateway mode is off.

A dual-stack template can use ID id0, addresses 10.44.50.21/24 and 2001:db8:44:50::21/64, one gateway for each family, a lowercase MAC match, and ens160 as the final name. The ledger should show both address families, the device match, and separate IPv4 and IPv6 default routes.

For a reachability warning, pair 10.44.50.21/24 with gateway 10.44.60.1. The warning appears because the address masks to 10.44.50.0 while the gateway masks to 10.44.60.0. Fix the prefix, change the gateway, or design a fuller on-link route if the topology requires it.

For an older image that accepts gateway4 but rejects default routes written with to: default, enable Use legacy gateway keys and leave Default route metric blank. A metric in legacy mode triggers a warning because that legacy gateway shape does not carry the metric.

FAQ:

Why is CIDR notation required?

The prefix length tells the guest which addresses are local to the interface. A bare value such as 10.44.50.21 does not say where the local subnet ends.

Should I choose NoCloud network-config or cloud.cfg.d snippet?

Choose NoCloud network-config for a standalone seed network file. Choose cloud.cfg.d snippet when the network block belongs inside a cloud-init configuration file under network:.

Can I enter two default gateways?

Use at most one IPv4 default gateway and one IPv6 default gateway. Multiple default paths for one family usually need route metrics, separate routing tables, or policy routing outside this one-interface generator.

Why does the MAC address need lowercase letters?

Version 2 documentation shows MAC matches as lowercase colon-separated values, and quoted lowercase values avoid YAML parsing surprises. Use a value such as 00:11:22:33:44:55.

When should legacy gateway keys be used?

Use route-based defaults for current version 2 data. Enable legacy keys only when a known older image rejects default routes written with to: default.

Does validation replace a boot test?

No. Validation catches input and YAML-shape problems. A boot test is still needed to prove datasource discovery, renderer support, interface naming, routing, and DNS on the target image.

Glossary:

cloud-init: A boot-time configuration system used by many cloud images and virtual machine templates.
NoCloud: A cloud-init datasource that can read instance data from local seed media, a local path, or a configured remote source.
network-config: The NoCloud network data file that can contain version 1 or version 2 network configuration.
CIDR: Address notation that combines an IP address and prefix length, such as 10.44.50.21/24.
Renderer: The guest-side backend expected to apply the version 2 network settings, commonly networkd or NetworkManager.
Default route: The route used when no more specific destination route matches a packet.

References:

Networking config Version 2, cloud-init documentation.
NoCloud, cloud-init documentation.
YAML configuration, Netplan documentation.
How to troubleshoot a Linux network outage, Simplified Guide.