One of the most frequent incidents in DevOps is losing access to a remote server after editing network settings. In 90% of cases, the cause is a conflict between manual editing of /etc/network/interfaces and an auto-generated Netplan configuration. For example, an engineer adds a static IP via legacy tools, and after netplan apply the configuration resets—SSH drops out. We'll show how to avoid this and provide working configurations for key scenarios: static IP, bonding, VLAN, Jumbo Frames. Our experience covers over 80 projects configuring network infrastructure for retail, fintech, and logistics, which reduced incidents by 30% and saved up to $450–650 per server per year.
What problems do we solve?
Let's break down three typical problems encountered when configuring Linux networking.
Conflict between Netplan and NetworkManager
On Ubuntu, Netplan manages configuration by default, but if you manually edit files in /etc/network/interfaces or /etc/NetworkManager/system-connections/, changes may be lost at the next netplan apply. This is the most common cause of sudden SSH disconnections—about 60% of incidents in our practice.
Incorrect MTU
Configuring Jumbo Frames without coordinating with the network equipment leads to packet fragmentation and performance drops of up to 40%. We have seen cases where MTU mismatch between nodes caused NFS and iSCSI traffic to fail.
Complexity with bonding and VLAN
Setting up channel aggregation (bonding) requires precise selection of mode (active-backup, LACP, balance-xor) and consideration of switch support. An incorrect mode yields instability rather than failover. Switching from ifupdown to Netplan saves up to 30% of network maintenance time.
How we configure network interfaces
Netplan: YAML on top of NetworkManager or systemd-networkd
Netplan is an abstraction that generates configuration for NetworkManager or systemd-networkd. On servers we typically use systemd-networkd as the backend; on desktops, NetworkManager. Netplan documentation explains: "Netplan uses YAML to configure network interfaces and generates the required configuration for the chosen backend."
Static IP on Ubuntu:
# /etc/netplan/00-installer-config.yaml
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 10.0.1.100/24
routes:
- to: default
via: 10.0.1.1
nameservers:
addresses: [1.1.1.1, 8.8.8.8]
search: [company.internal]
dhcp4: false
# Validate syntax
netplan generate
# Apply with rollback (120 seconds)
netplan try
# Apply without rollback
netplan apply
Bonding (link aggregation) via Netplan:
network:
version: 2
renderer: networkd
ethernets:
eth0: {}
eth1: {}
bonds:
bond0:
interfaces: [eth0, eth1]
addresses: [10.0.1.100/24]
routes:
- to: default
via: 10.0.1.1
parameters:
mode: active-backup # or 802.3ad for LACP
mii-monitor-interval: 100 NetworkManager: nmcli for server tasks
On RHEL/Rocky/CentOS, NetworkManager is the primary tool. nmcli is more convenient than editing files manually:
# List interfaces
nmcli device status
# Static IP
nmcli connection modify "Wired connection 1" \
ipv4.method manual \
ipv4.addresses "10.0.1.100/24" \
ipv4.gateway "10.0.1.1" \
ipv4.dns "1.1.1.1,8.8.8.8"
nmcli connection up "Wired connection 1"
# VLAN
nmcli connection add type vlan \
con-name vlan100 \
dev eth0 \
id 100 \
ipv4.method manual \
ipv4.addresses "192.168.100.10/24" systemd-networkd: for servers without NetworkManager
A minimalistic option—systemd-networkd without NetworkManager. Used in container and server distributions:
# /etc/systemd/network/20-wired.network
[Match]
Name=eth0
[Network]
Address=10.0.1.100/24
Gateway=10.0.1.1
DNS=1.1.1.1
DNS=8.8.8.8
Domains=company.internal
[Link]
MTUBytes=9000 systemctl enable systemd-networkd systemctl start systemd-networkd networkctl status eth0 MTU 9000 (Jumbo Frames) is effective only when enabled on switches. Standard MTU is 1500; increasing to 9000 reduces CPU load by up to 20% for large file transfers.
Comparison of network management tools
| Tool | Application area | Features |
|---|---|---|
| Netplan | Ubuntu, Debian (YAML description) | Generates configs for NetworkManager or systemd-networkd |
| NetworkManager | RHEL/CentOS/Rocky, desktops | Supports dynamic interfaces, VPN, mobile networks |
| systemd-networkd | Servers, containers | Lightweight, minimalistic, no unnecessary dependencies |
Bonding modes: comparison
| Mode | Fault tolerance | Throughput | Switch requirements |
|---|---|---|---|
| active-backup | ✅ | Single link | Any |
| 802.3ad (LACP) | ✅ | Aggregated | LACP support |
| balance-xor | ✅ | Aggregated without LACP | Any, but no guarantee of balance |
Why Netplan is better than ifupdown
ifupdown (utilities ifup/ifdown) is outdated and does not support modern scenarios: bonding, VLAN, bridges. Netplan describes everything in a single YAML file, is easy to read and version-control. Moreover, netplan try prevents loss of access to remote servers—a feature that ifupdown lacks. The cost of migrating from ifupdown to Netplan starts at $45–65 per server and pays off through fewer incidents.
How to avoid conflicts between NetworkManager and systemd-networkd?
Running both daemons simultaneously can cause duplicate routes and failures. We recommend choosing one backend: for servers—systemd-networkd (disable NetworkManager), for workstations—NetworkManager (disable systemd-networkd). In Netplan, set renderer: networkd or renderer: NetworkManager accordingly.
Step-by-step static IP configuration via Netplan
- Edit the file
/etc/netplan/00-installer-config.yaml. - Set the desired parameters (example above).
- Run
netplan generateto validate syntax. - Apply with
netplan try—if an error occurs, the connection automatically rolls back after 120 seconds. - If everything works, confirm with
netplan apply.
What is included in the work?
Network interface configuration is part of larger tasks. The standard package includes:
- Current configuration audit: check MTU, bonding modes, DNS, routing.
- Designing a new scheme: considering topology, fault tolerance and performance requirements.
-
Implementation: writing configs, applying them via
netplan tryornmcli, testing. - Documentation: capturing the final configuration, instructions for the on-call team (runbook).
- Support: 24/7 network monitoring (optional) and incident response.
Post-configuration verification
After applying the configuration, run ip addr show, ip route show, and ping -c4 10.0.1.1. If ping fails, check MTU and gateway. Average time for configuring one interface is 30 minutes, including testing.
Timelines and cost
Timelines: from 2 hours for simple static IP to 1-2 days for bonding + VLAN + jumbo frames with load testing. Cost is calculated individually—contact us for a project estimate. Our engineers hold Linux certifications (RHCE, LPIC) and have over 10 years of experience. In recent years, we've completed over 80 network infrastructure projects.
Get a consultation: we'll help you choose the optimal stack and configure your network without failures. Order a turnkey network setup.







