Table of Contents
By Khimananda Oli | Last reviewed: August 2026
Modern Ubuntu Server releases rely entirely on Netplan for network management, rendering legacy /etc/network/interfaces files obsolete. If you are managing infrastructure today, mastering this YAML-based renderer is mandatory for reliable connectivity. This Ubuntu Network Configuration Guide provides the exact syntax, validation steps, and operational patterns needed to configure production systems safely without locking yourself out.
/etc/netplan/ using strict indentation. Define your static IP, gateway, and nameservers under the specific ethernet interface, then validate with sudo netplan try before applying permanently with sudo netplan apply.How does the Ubuntu Network Configuration Guide architecture work?
Understanding the abstraction layer is critical before editing configuration files. Netplan is not a network daemon itself; it is a translation utility that reads declarative YAML descriptions and generates backend-specific configurations for either systemd-networkd (server default) or NetworkManager (desktop default). When you run netplan apply, the tool parses your YAML, validates the schema, and writes low-level config files into /run/systemd/network/ or /run/NetworkManager/system-connections/.
This separation means you never edit backend files directly when using Netplan. Any manual changes to /run/systemd/network/ will be overwritten on the next reboot or apply cycle. For teams managing infrastructure as code, treat the Netplan YAML as your single source of truth. I recommend storing these templates in version control alongside your Ansible playbooks or Terraform modules, similar to how you would manage Ansible automation for server provisioning. This ensures every environment remains reproducible and auditable.
How do you configure a static IP address with Netplan?
DHCP is convenient for development but unacceptable for production servers where predictable addressing is required for firewall rules, monitoring targets, and service discovery. The most common task in any Ubuntu Network Configuration Guide is assigning a persistent static IP. Before editing, identify your exact interface name using ip link show. Modern Ubuntu uses predictable naming like enp3s0 or ens18 rather than the legacy eth0.
Create or edit the configuration file
Navigate to /etc/netplan/. You will typically find a file named 00-installer-config.yaml or 01-netcfg.yaml. Back up the original before making changes. Open the file with root privileges:
sudo cp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.bak
sudo nano /etc/netplan/00-installer-config.yamlReplace the contents with a valid static configuration. Pay extreme attention to indentation; YAML is whitespace-sensitive, and tabs will cause parsing failures. Use spaces only.
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: false
addresses:
- 192.168.10.50/24
routes:
- to: default
via: 192.168.10.1
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
search:
- example.comValidate and apply safely
Never run netplan apply blindly on a remote server. A typo can sever your SSH connection permanently if you lack console access. Always use the safety mechanism first:
sudo netplan try: Applies the configuration temporarily. If you do not confirm within 120 seconds, it automatically reverts to the previous working state.sudo netplan apply: Commits the configuration permanently once validated.ip addr show enp3s0: Verifies the new IP is active.
If you are deploying this across multiple nodes, consider integrating this into your CI/CD pipeline validation gates. Tools discussed in our build verification and quality gates guide can catch YAML syntax errors before they reach production hardware.
How do you manage DNS and routing in Ubuntu networking?
DNS misconfiguration is the leading cause of "network works but apps fail" incidents. In Netplan, DNS is defined per-interface, not globally in /etc/resolv.conf. That file is now a symlink managed by systemd-resolved; editing it directly is futile because changes vanish after reboot or service restart.
Configuring internal and external resolvers
For environments requiring split-horizon DNS (common in hybrid cloud setups serving Nepal-based clients with local AD controllers plus global services), specify both internal and external resolvers with search domains:
nameservers:
addresses:
- 10.0.0.5
- 1.1.1.1
search:
- corp.local
- example.comThe order matters. systemd-resolved queries the first nameserver listed. Place your authoritative internal resolver first if internal service discovery is priority. Verify resolution behavior with resolvectl query app.corp.local rather than deprecated nslookup.
Advanced routing and multi-homing
Servers with multiple NICs often need policy-based routing to prevent asymmetric paths. For example, a backup interface should only handle backup traffic, not general egress. Define additional route tables and rules:
ethernets:
ens19:
addresses:
- 10.10.10.5/24
routes:
- to: 10.10.10.0/24
via: 10.10.10.1
table: 100
routing-policy:
- from: 10.10.10.5
table: 100This ensures return traffic for the backup network exits through the correct interface. Without explicit routing policies, Linux defaults to the primary default route, causing packet drops at stateful firewalls. This level of precision distinguishes professional infrastructure from hobbyist setups.
What are common Netplan mistakes and how do you troubleshoot them?
Even experienced engineers trip over Netplan's strictness. After years of auditing infrastructure across AWS EC2 instances and on-prem VMware clusters, I have cataloged the recurring failure modes. Most stem from treating YAML like a forgiving format or misunderstanding the backend handoff.
| Mistake | Symptom | Fix |
|---|---|---|
| Tabs instead of spaces | Invalid YAML parse error | Configure editor to insert 2 or 4 spaces per tab |
| Wrong interface name | Config applies but no IP assigned | Verify with ip link; names change after kernel updates |
Missing renderer key | Desktop uses NetworkManager unexpectedly | Explicitly set renderer: networkd for servers |
| CIDR notation errors | Route unreachable or subnet mismatch | Use /24 not netmask 255.255.255.0 |
Editing /etc/resolv.conf | DNS resets after reboot | Define nameservers in Netplan YAML only |
Diagnostic commands for live debugging
When configuration appears correct but connectivity fails, move beyond ping. These commands reveal the actual runtime state versus intended state:
networkctl status enp3s0: Shows link state, assigned IPs, and whether systemd-networkd successfully loaded the config. Look for "State: routable" vs "degraded".resolvectl status: Displays per-interface DNS servers and search domains actually in use. Confirms if your Netplan DNS settings propagated.journalctl -u systemd-networkd --since "5 minutes ago": Captures real-time errors during apply cycles. Filter for "ERR" or "Failed".ip route get 8.8.8.8: Reveals which interface and source IP the kernel selects for outbound traffic. Essential for multi-NIC debugging.
If you suspect hardware-level issues or driver incompatibilities—especially on newer ARM-based cloud instances or older Nepali datacenter hardware—check dmesg | grep -i eth for PHY negotiation failures before blaming Netplan.
How does Netplan compare to legacy networking tools?
Engineers migrating from CentOS 7 or older Ubuntu LTS versions often resist Netplan due to familiarity bias. Understanding the trade-offs helps justify the transition to stakeholders accustomed to /etc/sysconfig/network-scripts/ or /etc/network/interfaces.
The primary advantage is atomicity. Legacy tools applied changes line-by-line; a mid-file error left systems half-configured. Netplan validates the entire document before touching runtime state. Additionally, the backend-agnostic design allows the same YAML to drive systemd-networkd on headless servers or NetworkManager on developer laptops. This portability simplifies golden image creation for teams supporting mixed deployment targets.
However, Netplan has limitations. It lacks support for some advanced bonding modes or complex bridge setups that require direct systemd-networkd .network files. In those edge cases, you can set renderer: networkd and drop supplemental files into /etc/systemd/network/ while keeping basic interfaces in Netplan. Just document the hybrid approach clearly to avoid future confusion during incident response.
Next steps for production-ready Ubuntu networking
Mastering this Ubuntu Network Configuration Guide eliminates an entire category of infrastructure drift and outage risk. Your immediate action items should be: audit all existing servers for legacy config remnants, standardize on a validated Netplan template stored in version control, and implement netplan try in your operational runbooks. For teams scaling beyond manual SSH sessions, integrate these configurations into automated provisioning workflows as outlined in our initial Ubuntu server setup guide.
If your organization needs help designing compliant, audit-ready network architectures across AWS, Azure, or on-prem environments in Nepal or globally, reach out to discuss your infrastructure requirements. Reliable networking is the foundation everything else depends on—get it right once, and stop revisiting it during every outage.
