Network Configuration, NetworkManager, and Netplan

1. Change the source of truth, not only the running state

Commands such as ip address add and ip route add change kernel runtime state and are valuable for temporary tests. Persistent configuration is usually owned by NetworkManager, systemd-networkd, Netplan, cloud-init, an installer, a configuration-management system, or a provider agent. Editing the wrong layer creates drift or configuration that disappears on restart.

flowchart TB
  A["Requirements and infrastructure policy"] --> B["Persistent declaration"]
  B --> C["NetworkManager profile or Netplan YAML"]
  C --> D["Renderer: NetworkManager or networkd"]
  D --> E["Kernel links, addresses, routes, rules"]
  E --> F["DNS manager and resolver state"]
  F --> G["Verification: route, DNS, sockets, application"]
  G --> H["Commit or rollback"]

2. Detect the active manager and configuration sources

# Service ownership
systemctl is-active NetworkManager 2>/dev/null || true
systemctl is-active systemd-networkd 2>/dev/null || true
systemctl is-active systemd-resolved 2>/dev/null || true

# NetworkManager inventory
nmcli general status 2>/dev/null || true
nmcli device status 2>/dev/null || true
nmcli connection show 2>/dev/null || true

# Netplan merged configuration, if installed
netplan get 2>/dev/null || true
find /etc/netplan -maxdepth 1 -type f -name '*.yaml' -print 2>/dev/null || true

# networkd state
networkctl list 2>/dev/null || true
networkctl status 2>/dev/null | sed -n '1,160p' || true

# Cloud-init may regenerate networking
cloud-init status 2>/dev/null || true

Do not assume a distribution always uses one manager. Desktop and server editions can differ, cloud images can add generated files, and Netplan can render either NetworkManager or systemd-networkd configuration. Identify generated-file comments and automation ownership before editing.

3. NetworkManager separates devices from connection profiles

A device is an interface; a connection profile is persistent configuration that can be activated on a compatible device. Profiles contain addressing method, routes, DNS settings, autoconnect behavior, and many other properties. Modify a profile, activate it intentionally, then verify runtime state.

# Readable profile inventory
nmcli -f NAME,UUID,TYPE,DEVICE,AUTOCONNECT connection show
nmcli -f GENERAL,IP4,IP6 device show 2>/dev/null | sed -n '1,220p'

# Inspect one active profile
profile=$(nmcli -t -f NAME connection show --active 2>/dev/null | head -n 1)
[ -n "$profile" ] && nmcli connection show "$profile"

# Illustrative static profile commands: review values before use
# nmcli connection modify "$profile" \
#   ipv4.method manual \
#   ipv4.addresses 192.0.2.25/24 \
#   ipv4.gateway 192.0.2.1 \
#   ipv4.dns '192.0.2.53 192.0.2.54'
# nmcli connection up "$profile"

4. Netplan declares configuration and delegates rendering

Netplan reads YAML from /etc/netplan/ and related paths, merges configuration, validates it, and generates backend configuration for NetworkManager or systemd-networkd. YAML indentation and file permissions matter. Modern route declarations use routes:; nameservers contain address and search-domain policy.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      addresses:
        - 192.0.2.25/24
      routes:
        - to: default
          via: 192.0.2.1
          metric: 100
      nameservers:
        addresses:
          - 192.0.2.53
          - 192.0.2.54
        search:
          - example.internal

# Read merged configuration and validate generation
sudo netplan get
sudo netplan generate

# Transactional trial with automatic rollback prompt
# Use from a console or with a tested fallback path.
sudo netplan try

# Non-transactional activation after validation and review
# sudo netplan apply

# Inspect the result
ip -brief address
ip route show
resolvectl status 2>/dev/null || cat /etc/resolv.conf

netplan generate validates and writes backend configuration without necessarily activating it. netplan try applies temporarily and rolls back unless confirmed, making it preferable for interactive remote changes where supported. It is not a substitute for console access or an out-of-band recovery plan.

5. Design the rollback before the change

6. Hands-on lab: validate a disposable Netplan declaration

This lab writes configuration only inside your home directory. If Netplan is installed, it uses its parser with an isolated root directory; it does not apply anything to the host network.

lab="$HOME/devops-academy/linux/chapter12/lesson05"
root="$lab/root"
mkdir -p "$root/etc/netplan" "$root/run/netplan" "$root/lib/netplan"

cat > "$root/etc/netplan/90-academy-lab.yaml" <<'YAML'
network:
  version: 2
  renderer: networkd
  ethernets:
    academy0:
      match:
        name: "academy0"
      dhcp4: false
      addresses:
        - 192.0.2.25/24
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses: [192.0.2.53]
        search: [example.internal]
YAML
chmod 600 "$root/etc/netplan/90-academy-lab.yaml"

if command -v netplan >/dev/null 2>&1; then
  netplan --root-dir "$root" get > "$lab/merged.txt"
  netplan --root-dir "$root" generate
  find "$root/run" -type f -maxdepth 4 -print > "$lab/generated-files.txt"
else
  printf 'Netplan is not installed; review YAML manually.\n' > "$lab/merged.txt"
fi

sed -n '1,160p' "$root/etc/netplan/90-academy-lab.yaml"
sha256sum "$root/etc/netplan/90-academy-lab.yaml" > "$lab/evidence.sha256"

7. Common configuration mistakes

8. Knowledge check

9. Summary

Persistent Linux networking requires identifying the source of truth. NetworkManager stores connection profiles; Netplan declares YAML and renders to NetworkManager or systemd-networkd; cloud and configuration-management systems may own an even higher layer. Safe changes record a baseline, back up declarations, validate before activation, protect remote access, verify application behavior, and prove persistence or rollback.

10. Further reading

• nmcli reference manual.
• Netplan YAML reference and official examples.
• networkctl(1), systemd.network(5), and cloud-init network configuration documentation.