Netplan vs. NetworkManager: detectar conflictos y forzar una configuración de red coherente

Netplan vs. NetworkManager no es una cuestión académica, sino un riesgo operativo: cuando dos componentes intentan controlar los mismos recursos de red se producen fallos, asignaciones de IP inconsistentes y problemas para servicios como Kubernetes. Esta guía está dirigida a administradores, ingenieros de sistemas y operadores y explica en pasos prácticos cómo detectar conflictos, hacer cumplir una Renderer‑Policy clara, migrar con seguridad nodos de Kubernetes, establecer validaciones automatizadas y preparar rollbacks rápidos.

Por qué la Renderer‑Policy es tan importante

Netplan es un frontend declarativo: archivos YAML bajo /etc/netplan describen la topología de red deseada. Netplan traduce esas especificaciones en tiempo de ejecución a archivos de configuración para un Renderer. Los Renderer son los gestores reales — típicamente systemd-networkd (a menudo abreviado como networkd) o NetworkManager. NetworkManager es un daemon persistente con su propio estado y política. Si la organización no tiene una política clara, surgen condiciones de carrera, porque netplan escribe la configuración del Renderer durante el despliegue mientras NetworkManager gestiona conexiones en paralelo o cloud‑init aplica nuevas configuraciones en el arranque.

Diagnóstico: sistemático y no invasivo

Empiece por los hechos: ¿qué está configurado efectivamente en el kernel en este momento? A continuación compruebe qué gestores están activos y cómo Netplan genera las configuraciones en tiempo de ejecución.

Comandos básicos para estado y visibilidad

ip -br link
ip -br addr
ip route show

Esta vista es independiente de Netplan o NetworkManager y muestra el estado actual en el kernel.

Perspectivas de los gestores

systemctl is-active NetworkManager.service || true
systemctl is-active systemd-networkd.service || true
nmcli -t -f DEVICE,STATE device status
networkctl --no-legend --all

nmcli muestra la perspectiva de NetworkManager, networkctl la de systemd‑networkd. Las contradicciones aquí son una indicación clara de control concurrente.

Patrones de fallo y sus causas

Síntomas relevantes y causas típicas — explicadas brevemente:

• La IP cambia tras un reinicio: o bien hay múltiples clientes DHCP o cloud‑init aplica valores distintos en el primer arranque.
• La ruta por defecto desaparece: el Renderer aplica una política/métrica de enrutamiento distinta, o una interfaz se desactiva.
• Nodo de Kubernetes NotReady: la interfaz CNI fue recreada o NetworkManager modificó una bridge/bond. Los plugins CNI esperan relaciones estáticas en el host.
• Entradas de log con „Device is already managed“: NetworkManager detecta un dispositivo que netplan en realidad quería asignar a networkd.

Comprobaciones concretas cuando algo falla

Si las causas no son evidentes, proceda de forma secuencial:

1. Verifique tiempos y orden: compare journalctl antes y después de reinicios o cambios de configuración.
2. Monitorice el tráfico DHCP para detectar clientes en paralelo.
3. Inspeccione la generación de Netplan para ver qué se escribe realmente en el Renderer.

journalctl -b -u NetworkManager -u systemd-networkd --no-pager | sed -n '1,400p'
# DHCP und ARP beobachten (kurzes Sample)
tcpdump -n -i ens3 arp or port 67 or port 68 -c 200
# Netplan generieren, ohne anzuwenden
netplan generate
ls -l /run/systemd/network /run/NetworkManager 2>/dev/null

Ejemplos de configuración: Cómo se controla el Renderer

Netplan‑YAML define el renderer de forma declarativa. Ejemplo: forzar networkd como renderer.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: true
      optional: true

Después de desplegar el archivo, use netplan generate y netplan apply. netplan generate muestra qué archivos se generarían; netplan apply aplica activamente. En hosts críticos resulta útil netplan try: revierte automáticamente el cambio si no confirma dentro del temporizador.

# Interaktives Anwenden mit Fallback
netplan try
# Oder idempotent in Automatisierung
netplan generate && netplan apply

NetworkManager: Ejemplo de Keyfile y unmanaged‑devices

NetworkManager utiliza keyfiles para conexiones persistentes. Si NetworkManager debe permanecer activo, pero debe ignorar determinadas interfaces CNI, cree una configuración en /etc/NetworkManager/conf.d/:

# /etc/NetworkManager/conf.d/10-unmanaged.conf
[main]
plugins=keyfile

[keyfile]
unmanaged-devices=interface-name:cni0;interface-name:flannel.1;interface-name:calico0

Esta entrada impide que NetworkManager gestione los bridges/interfaces CNI — importante para Kubernetes.

systemd‑networkd: Ejemplo de .network

Si prefiere networkd como renderer, puede usar archivos .network para ajustes de host más finos (normalmente no necesario si Netplan genera todo de forma centralizada, pero útil para reglas específicas).

# /etc/systemd/network/10-ens3.network
[Match]
Name=ens3

[Network]
DHCP=yes
IPv6AcceptRA=yes

[Route]
Gateway=192.0.2.1

Un archivo .network directo lo lee networkd; Netplan genera dichos archivos automáticamente cuando está configurado como renderer networkd.

Estrategia de migración: segura, gradual, reversible

En cambios en entornos productivos, es imprescindible adoptar un enfoque conservador. Pasos recomendados:

1. Definir la política: asigne grupos de hosts (p. ej. k8s‑worker, db‑server, workstation) y su renderer.
2. Canary‑Rollout: seleccione 1–3 nodos no críticos como caso de prueba.
3. Crear copias de seguridad: respalde /etc/netplan, /etc/NetworkManager y las configuraciones de cloud‑init.
4. Ventana de cambios y acceso fuera de banda: asegure KVM/IPMI/consola serie.
5. Validación automatizada: comprobar IP, rutas, CNI, estado de kubelet y salud de servicios.
6. Despliegue gradual y monitorización: vigilar métricas, alertas según patrones definidos.

Ejemplo de script de validación (Básico)

#!/usr/bin/env bash
set -euo pipefail
IF=ens3
# IP prüfen
ip addr show "$IF" | grep -q "inet " || { echo "IP fehlt"; exit 2; }
# Default-Route prüfen
ip route show default | grep -q "dev $IF" || { echo "Default-Route fehlt"; exit 3; }
# Kubelet prüfen (nur auf K8s-Nodes)
systemctl is-active --quiet kubelet || { echo "kubelet nicht aktiv"; exit 4; }
# CNI-Interfaces prüfen
ip link show | grep -E "cni|calico|flannel" >/dev/null || echo "Keine CNI-Interfaces gefunden (ist das ok?)"
echo "Validation ok"

Este script es deliberadamente sencillo; amplíelo con comprobaciones de Prometheus, una consulta a la API del kube‑apiserver o pods de prueba si lo integra en CI/CD.

Detalles específicos de Kubernetes y puntos críticos

Kubernetes hace visibles los cambios de red de forma inmediata: los Pods pierden conectividad, los complementos CNI pueden volver a inicializarse y kubelet verifica las condiciones de red del host. Observaciones específicas:

• Drain y uncordon: Antes de cambios de red mayores, siempre ejecutar drain (kubectl drain) y tras la validación ejecutar uncordon.
• Tener en cuenta los DaemonSets: los demonios CNI se ejecutan en cada nodo; gestione las secuencias de actualización para evitar que el CNI se reinicie simultáneamente.
• IP‑Masquerade y forwarding: Verifique las reglas de iptables/nftables, ya que NetworkManager ocasionalmente puede ajustar las relaciones del cortafuegos.

# Sicheres Node-Update Ablauf (Kurzform)
kubectl drain node01 --ignore-daemonsets --delete-local-data
# Änderungen anwenden
# Validieren: CNI Pods, kubelet, Netztests
kubectl uncordon node01

Monitorización: métricas, alertas y umbrales razonables

Configure la monitorización de modo que no cada fluctuación dispare un pager. Ejemplos de métricas relevantes:

• Flaps de interfaz por host en 10 minutos (>5 → advertencia).
• Renovaciones DHCP por MAC (>3 en 5 minutos → indicador de clientes en conflicto).
• Eventos Kubernetes Node NotReady tras cambios de red (crítico).
• Bucles de reinicio de servicio para NetworkManager o systemd‑networkd (alertar a nivel de host).

Casos límite típicos y cómo resolverlos

Algunos problemas solo aparecen bajo ciertas condiciones — los más comunes son:

• Imágenes del proveedor: las imágenes cloud a veces tienen perfiles de NetworkManager preconfigurados. Revíselos y límpielos antes del despliegue.
• Nombrado persistente de interfaces: cambios en udev/hardware pueden renombrar interfaces. Use coincidencias basadas en MAC en Netplan o en archivos .network si existe riesgo.
• VLANs, bridging y bonding: NetworkManager y networkd difieren en sintaxis y comportamiento; pruebe el failover de bonding y LACP en un entorno de pruebas.

VLAN + Bond Beispiel (Netplan)

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3: {}
  bonds:
    bond0:
      interfaces: [ens3]
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 100
  vlans:
    vlan100:
      id: 100
      link: bond0
      dhcp4: true

Práctica de rollback: la preparación lo es todo

Un rollback suele tardar más que el cambio. Prepare los siguientes artefactos:

• Copias de seguridad: /root/netcfg-backups con marcas de tiempo únicas.
• Scripts de rollback: pasos automatizados que RESTauran archivos y reinician servicios.
• Acceso Out‑of‑Band y plan de pruebas: ¿qué se medirá para confirmar el éxito?

# Backup (bevor Änderungen gemacht werden)
mkdir -p /root/netcfg-backups/$(date +%F_%H%M)
cp -a /etc/netplan /root/netcfg-backups/$(date +%F_%H%M)/
cp -a /etc/NetworkManager /root/netcfg-backups/$(date +%F_%H%M)/ || true
cp -a /etc/cloud /root/netcfg-backups/$(date +%F_%H%M)/ || true

Recomendaciones operativas — breves y prácticas

• Defina para cada grupo de hosts una política de renderer clara y consérvela en CM/GitOps.
• Use netplan try en hosts críticos para revertir automáticamente si se produce pérdida de red.
• Proteja las interfaces CNI con unmanaged-devices antes de permitir NetworkManager.
• Pruebe todos los cambios en un entorno de staging incluyendo drains de nodo para Kubernetes.
• Implemente validaciones y alertas automáticas que reaccionen a patrones y no a eventos aislados.

Conclusión

Netplan vs. NetworkManager es en la práctica una cuestión de disciplina: una operación bien gestionada conduce a una Single Source of Truth, protege los CNI‑Devices, automatiza las validaciones y mantiene un plan de rollback probado. Medidas técnicas (Netplan‑Renderer, unmanaged‑devices, Node‑Drain) junto con directrices organizativas (Hostgruppen, Change‑Windows, Out‑of‑Band‑Zugriff) minimizan el riesgo y mantienen las redes mantenibles. Planifique su migración por fases, documente las decisiones y mida los efectos de forma automatizada — así su red permanecerá fiable y reproducible.

Netplan vs. NetworkManager: Estrategias de integración, seguridad y deriva

Además de la Renderer‑Policy debe abordar tres niveles operativos: integración en la gestión de configuración/GitOps, auditoría y endurecimiento frente a cambios no deseados en tiempo de ejecución, así como procedimientos seguros de prueba y validación. Estos aspectos evitan que la deriva de configuración, cambios no autorizados en D‑Bus o agentes de proveedor socaven su topología de red.

Detectar y corregir proactivamente la deriva de configuración

No confíe en que los archivos en /etc coincidan automáticamente con su repositorio Git. Un trabajo de comprobación breve y automatizable detecta desviaciones y, si procede, puede RESTaurar una configuración aprobada o generar una alerta.

#!/usr/bin/env bash
set -euo pipefail
REPO=/srv/git/netcfg.git
TMP=/tmp/netcheck
rm -rf "$TMP" && git clone "file://$REPO" "$TMP"
if ! diff -r "$TMP/etc/netplan" /etc/netplan >/dev/null; then
  echo "Drift detected: /etc/netplan differs from Git" >&2
  # optional: RESTore or trigger automation
  exit 2
fi
echo "Netplan OK"

Esos trabajos se ejecutan como Cron, systemd‑timer o en la pipeline CI/CD. Decida si debe aplicarse una corrección automática (git checkout) o solo alertas: ambas opciones tienen ventajas y desventajas respecto al control de cambios.

Aspectos de seguridad: D‑Bus, PolicyKit y bloqueo de servicios

NetworkManager expone funciones de control a través de D‑Bus; eso facilita cambios dirigidos por API, pero abre vectores de ataque. RESTringa las modificaciones de red mediante reglas de PolicyKit, permisos de archivo estrictos y, cuando sea apropiado, el enmascaramiento (masking) del servicio.

# NetworkManager temporär sperren (wird beim Maskieren nicht gestartet)
sudo systemctl mask NetworkManager
# Zurücksetzen
sudo systemctl unmask NetworkManager && sudo systemctl start NetworkManager

Para entornos con requisitos de auditoría registre todos los cambios en /etc/netplan y las llamadas D‑Bus (auditd o journald con filtros de campo). De ese modo dispondrá de una cadena de cambios trazable para cumplimiento y análisis post‑mortem.

Pruebas en sandbox con namespaces de red

Antes de aplicar reglas en producción, simule el comportamiento de forma aislada con veth‑pairs y netns. Así puede comprobar DHCP, VLANs o políticas de enrutamiento sin afectar a las interfaces del host.

# Einfacher Test: veth-Paar und DHCP-Client in Namespace
ip netns add tn
ip link add veth0 type veth peer name veth1
ip link set veth1 netns tn
ip addr add 192.0.2.1/24 dev veth0; ip link set veth0 up
ip netns exec tn ip link set lo up; ip netns exec tn ip link set veth1 up
# Im Namespace kann man jetzt dhclient, ip route etc. testen
ip netns exec tn dhclient -v veth1 & sleep 5; ip netns exec tn ip addr show

Automatización: tareas idempotentes y verificaciones previas (preflight‑checks)

Utilice en Ansible o en su CM módulos/tareas idempotentes y añada comprobaciones previas (preflight) que validen el estado del kernel (ip addr, ip route, CNI‑Bridges). Aplique los cambios solo si todas las comprobaciones previas son satisfactorias; en caso contrario, interrumpa el proceso y genere una alarma.

# Beispiel (Ansible, vereinfachte Form)
- name: Deploy Netplan from repo
  hosts: k8s_workers
  tasks:
    - name: Ensure /etc/netplan matches repo
      copy:
        src: files/50-netcfg.yaml
        dest: /etc/netplan/50-netcfg.yaml
        owner: root
        mode: '0644'
      notify: Apply netplan

Combine la integración, la seguridad y la automatización de pruebas: solo así conseguirá configuraciones de red reproducibles, evitará cambios inesperados por terceros (agentes del proveedor, procesos de usuario) y mantendrá el control sobre Netplan frente a NetworkManager en la operación diaria.

Para este tema son también relevantes los conflictos entre el renderizador de Netplan y NetworkManager. El artículo sitúa estos aspectos de forma comprensible y muestra en qué debe centrarse en el día a día.