Ubuntu 24.04: los cambios de Netplan no se aplican — por qué (y cómo hacer que perduren)

Guía de diagnóstico rápido

Cuando los cambios de Netplan no se aplican, la ruta más rápida es dejar de adivinar y responder tres preguntas:
(1) ¿Quién renderiza la red? (2) ¿Quién sobrescribe el YAML? (3) ¿Qué generó Netplan?
Puedes hacerlo en menos de cinco minutos si mantienes la disciplina.

1) Confirma el renderizador activo (NetworkManager o systemd-networkd)

• Comprueba qué servicio gestiona realmente la interfaz (no cuál prefieres).
• Si NetworkManager la gestiona, editar renderer: networkd no te dará la victoria mágicamente.

2) Comprueba si cloud-init reescribe la red en el arranque

• Si estás en una imagen de cloud (o derivada), asume que cloud-init tiene opiniones.
• Busca /etc/netplan/50-cloud-init.yaml y los logs relacionados.

3) Valida el YAML e inspecciona la salida generada

• Netplan compila YAML en configuraciones de backend.
• Si los archivos generados no coinciden con lo que esperas, Netplan no entendió tu YAML o no lo leyó.

4) Aplica de forma segura (no te ataques tu propio SSH)

• Utiliza netplan try para cambios remotos.
• Luego verifica con ip addr, ip route y resolución DNS.

Si haces solo una cosa: deja de editar archivos YAML al azar hasta haber identificado qué archivo es el autoritativo y qué renderizador está activo.
Si no, solo estarás representando la misma falla con más confianza.

Cómo funciona Netplan realmente (y por qué desaparecen tus ediciones)

Netplan no es tu gestor de red. Netplan es una capa de abstracción y un generador de configuración:
declaras intención en YAML bajo /etc/netplan/, y Netplan genera configuración para un renderizador de backend—más comúnmente
systemd-networkd en servidores, y NetworkManager en escritorios (y cada vez más en instalaciones “tipo servidor” donde la gente quiere herramientas GUI o Wi‑Fi).

Esa distinción importa porque crea tres modos comunes de fallo:

1. Editaste el archivo equivocado (existe un archivo, pero no es el que se usa tras la precedencia/orden lexicográfico).
2. El renderizador no es el que crees (NetworkManager está controlando la interfaz mientras escribes intención al estilo networkd).
3. Otro sistema lo reescribe (cloud-init es el sospechoso usual, pero no el único).

Y sí: puedes ejecutar netplan apply y aun así ver “no cambia nada” si el servicio backend rechaza la configuración generada, la interfaz está sin gestionar, o el YAML fue ignorado.
El trabajo de Netplan está mayormente hecho una vez escribe archivos generados y pide al backend que recargue.

A la gente de fiabilidad le gusta la propiedad clara. Las configuraciones Netplan fallan cuando la propiedad es difusa:
NetworkManager controla algunos dispositivos, networkd controla otros, cloud-init escribe YAML, y los administradores “arreglan” editando el archivo que parece más obvio.
Así se llega a un sistema donde todo está configurado y nada funciona.

Hechos y contexto histórico para usar en discusiones

Algunos puntos concretos que puedes mencionar en una revisión de diseño o en un postmortem, porque “parece que” no es una causa raíz.

1. Netplan se lanzó por primera vez en Ubuntu 17.10 como el intento de Canonical de unificar la configuración de red entre instaladores y entornos.
2. Netplan es YAML declarativo, pero la máquina ejecuta finalmente la configuración nativa del renderizador (unidades de networkd o perfiles de NetworkManager).
3. El orden de archivos importa: Netplan lee archivos YAML en orden léxico; archivos posteriores pueden sobrescribir a los anteriores.
4. Las imágenes cloud suelen usar cloud-init para generar 50-cloud-init.yaml, y puede reescribirlo en el arranque dependiendo del datasource y la configuración.
5. NetworkManager puede gestionar NICs “de servidor” ahora, especialmente donde la gente quiere herramientas consistentes entre portátiles y servidores.
6. systemd-networkd no es NetworkManager: es más ligero, más determinista y a menudo preferido para servidores sin interfaz gráfica—pero no tocará interfaces que no gestiona.
7. Ubuntu ha movido el manejo de DNS a lo largo de los años (resolvconf, luego systemd-resolved, además de comportamientos propios de NM). El “DNS que no se aplica” suele ser un problema de capas de resoluciones, no de Netplan.
8. “Apply” no siempre significa “persistir”: un cambio en tiempo de ejecución puede ocurrir pero ser sobrescrito al reiniciar por cloud-init, automatización o un renderizador distinto.

Síntomas típicos y lo que suelen significar

Síntoma: netplan apply termina limpio, pero la IP nunca cambia

Normalmente: la interfaz no es gestionada por el renderizador para el que estás generando, o el YAML que editaste no es el que se está usando.
Ocasionalmente: el backend rechazó la configuración y retrocedió sin hacer ruido en tu terminal.

Síntoma: funciona hasta reiniciar, luego revierte

Normalmente: cloud-init reescribió el archivo en el arranque, o un sistema de gestión de configuración (o un script de “primer arranque” de la imagen) reaplicó una configuración antigua.
Menos a menudo: editaste un archivo que pierde por orden léxico frente a otro YAML.

Síntoma: las rutas están mal (puedes hacer ping al gateway pero no al exterior)

Normalmente: la ruta por defecto no se aplicó, una segunda interfaz está ganando la ruta por defecto, o existe enrutamiento por políticas (las VPN y redes overlay adoran esto).

Síntoma: el DNS no coincide con lo que pusiste en YAML

Normalmente: systemd-resolved está usando un upstream distinto, NetworkManager está empujando DNS, o estás mirando /etc/resolv.conf sin comprobar si es un stub o un enlace simbólico.

Una cita para mantener la calma durante la respuesta a incidentes:
“La esperanza no es una estrategia.” — James Cameron

Chiste #1: Si tu configuración de red “se aplicó” pero nada cambió, felicitaciones—has alcanzado la ambigüedad de grado empresarial.

Tareas prácticas: comandos, significado de salidas y decisiones

Estos son chequeos reales y ejecutables. Cada uno incluye: qué ejecutar, qué indica la salida y qué decidir después.
Hazlos en orden cuando estés de guardia y tu yo del futuro merezca misericordia.

Tarea 1: Lista archivos de Netplan y ve qué podría sobrescribir qué

cr0x@server:~$ ls -l /etc/netplan/
total 8
-rw-r--r-- 1 root root  348 Nov  2 10:14 00-installer-config.yaml
-rw-r--r-- 1 root root  512 Nov  2 10:15 50-cloud-init.yaml

Significado: Netplan lee YAML en orden léxico. Si ambos definen la misma interfaz, el archivo posterior (aquí 50-cloud-init.yaml) puede ganar.
Decisión: Si editaste 00-installer-config.yaml esperando que perdurara, probablemente perdiste la batalla de sobrescritura. O modifica el archivo autoritativo o elimina la fuente de las sobrescrituras.

Tarea 2: Ve qué piensa Netplan que es la configuración fusionada

cr0x@server:~$ sudo netplan get
network:
  ethernets:
    eno1:
      dhcp4: false
      addresses:
      - 10.20.30.40/24
      routes:
      - to: default
        via: 10.20.30.1
      nameservers:
        addresses:
        - 10.20.0.53
        - 10.20.0.54
  version: 2
  renderer: networkd

Significado: Esta es la configuración efectiva tras parsear y fusionar archivos.
Decisión: Si netplan get no muestra tus cambios, Netplan no está leyendo tu edición (archivo equivocado, error YAML o sobrescrito). Arregla eso antes de tocar backends.

Tarea 3: Valida sintaxis (y atrapa trampas invisibles de YAML)

cr0x@server:~$ sudo netplan --debug generate
DEBUG:command generate: running ['/usr/libexec/netplan/generate']
DEBUG:Parsing /etc/netplan/00-installer-config.yaml
DEBUG:Parsing /etc/netplan/50-cloud-init.yaml
DEBUG:eno1: setting default backend to 1
DEBUG:Configuration is valid

Significado: “Configuration is valid” es necesario, no suficiente. Pero si esto falla, para y corrige el YAML.
Decisión: Si la salida debug parsea un archivo distinto al que editaste, estás trabajando sobre la entrada equivocada.

Tarea 4: Inspecciona la configuración generada del backend (lo que realmente se aplica)

cr0x@server:~$ sudo ls -l /run/systemd/network/
total 4
-rw-r--r-- 1 root root 682 Nov  2 10:16 10-netplan-eno1.network

Significado: Netplan generó una unidad de networkd en tiempo de ejecución.
Decisión: Ábrela. Si no contiene tus direcciones/rutas, Netplan no está generando lo que crees. Si lo contiene, el problema es la aplicación del backend o un conflicto de control de interfaz.

Tarea 5: Lee el archivo generado para confirmar la intención aplicada exacta

cr0x@server:~$ sudo sed -n '1,120p' /run/systemd/network/10-netplan-eno1.network
[Match]
Name=eno1

[Network]
Address=10.20.30.40/24
DNS=10.20.0.53 10.20.0.54
Gateway=10.20.30.1

Significado: Si esto coincide, Netplan hizo su trabajo. Ahora depuras networkd (o conflictos).
Decisión: Si esto no coincide, vuelve al YAML de Netplan y al orden de archivos; no “arregles” networkd directamente salvo que quieras pelear con Netplan en cada reinicio.

Tarea 6: Identifica qué servicio gestiona el enlace

cr0x@server:~$ networkctl status eno1
● 2: eno1
                 Link File: /usr/lib/systemd/network/99-default.link
              Network File: /run/systemd/network/10-netplan-eno1.network
                      Type: ether
                     State: routable (configured)
              Online state: online
                   Address: 52:54:00:12:34:56

Significado: networkd está gestionando eno1, y lo considera configurado.
Decisión: Si el estado es “unmanaged” o “configuring,” busca por qué networkd no lo toma (nombre match equivocado, desajuste de renderizador, o NM agarrándolo).

Tarea 7: Comprueba si NetworkManager también está involucrado (y por tanto puede deshacerte)

cr0x@server:~$ nmcli dev status
DEVICE  TYPE      STATE      CONNECTION
eno1    ethernet  unmanaged  --
lo      loopback  unmanaged  --

Significado: NM no está gestionando el dispositivo. Eso es bueno si usas networkd.
Decisión: Si NM muestra connected con un perfil en la interfaz, detente y decide si NM o networkd es el propietario previsto—luego haz que Netplan declare el renderizador acorde.

Tarea 8: Verifica IP y ruta en tiempo de ejecución (no confíes en una sola herramienta)

cr0x@server:~$ ip -br addr show eno1
eno1             UP             10.20.30.40/24

cr0x@server:~$ ip route show
default via 10.20.30.1 dev eno1 proto static
10.20.30.0/24 dev eno1 proto kernel scope link src 10.20.30.40

Significado: Esto es la verdad en el terreno. Si está mal, el cambio no se aplicó o fue sobrescrito después de aplicarlo.
Decisión: Si el runtime es correcto pero la conectividad está rota, pasa a DNS/firewall/enrutamiento upstream. Si el runtime es erróneo, vuelve al control del renderizador y a las configuraciones generadas.

Tarea 9: Revisa los logs de systemd-networkd por rechazos o flaps

cr0x@server:~$ sudo journalctl -u systemd-networkd -b --no-pager | tail -n 20
Nov 02 10:16:21 server systemd-networkd[812]: eno1: Configuring with /run/systemd/network/10-netplan-eno1.network.
Nov 02 10:16:21 server systemd-networkd[812]: eno1: Gained carrier
Nov 02 10:16:22 server systemd-networkd[812]: eno1: DHCPv4 client: disabled
Nov 02 10:16:22 server systemd-networkd[812]: eno1: Setting addresses
Nov 02 10:16:22 server systemd-networkd[812]: eno1: Setting routes
Nov 02 10:16:22 server systemd-networkd[812]: eno1: Configured

Significado: Puedes ver si networkd aplicó configuración estática, intentó DHCP, falló al establecer rutas, etc.
Decisión: Cualquier error aquí anula tus suposiciones. Arregla el problema registrado en los logs en lugar de reescribir YAML al azar.

Tarea 10: Comprueba si cloud-init controla la red en este host

cr0x@server:~$ sudo cloud-init status --long
status: done
boot_status_code: enabled-by-generator
detail:
  DataSource: DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net]
  errors: []

Significado: Cloud-init se ejecutó y tiene un datasource; puede también gestionar la configuración de red dependiendo de la configuración.
Decisión: Si ves cloud-init y un 50-cloud-init.yaml, asume que puede sobrescribir tu trabajo en el próximo arranque. Decide si desactivar cloud-init networking o proveerle la configuración correcta.

Tarea 11: Mira si cloud-init ha estado escribiendo YAML de Netplan recientemente

cr0x@server:~$ sudo journalctl -u cloud-init -b --no-pager | grep -i netplan | tail -n 20
Nov 02 10:10:03 server cloud-init[601]: Generating network configuration from datasource
Nov 02 10:10:03 server cloud-init[601]: Writing to /etc/netplan/50-cloud-init.yaml
Nov 02 10:10:04 server cloud-init[601]: Running command ['netplan', 'generate']

Significado: Esta es la pistola humeante. Si cloud-init escribe ese archivo, tus ediciones manuales pueden ser sobrescritas en el arranque.
Decisión: O bien impides que cloud-init gestione la red o realizas tus cambios a través de la configuración de red de cloud-init para que escriba el estado deseado.

Tarea 12: Confirma permisos/propietario de archivos (Netplan ignorará archivos inseguros)

cr0x@server:~$ sudo stat -c '%A %U:%G %n' /etc/netplan/*.yaml
-rw------- root:root /etc/netplan/00-installer-config.yaml
-rw-r--r-- root:root /etc/netplan/50-cloud-init.yaml

Significado: Netplan espera que las configuraciones sean propiedad de root y no escribibles por grupo/otros. Modos demasiado permisivos pueden hacer que el archivo sea ignorado.
Decisión: Si ves escritura por grupo o mundo, corrige los permisos y vuelve a ejecutar generate/apply.

Tarea 13: Aplica con rollback (amistoso para cambios remotos)

cr0x@server:~$ sudo netplan try
Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 120 seconds

Significado: Netplan prepara un cambio y revertirá si pierdes conectividad o no confirmas.
Decisión: Úsalo cuando estés por SSH y valores tu tiempo. Si no logra poner el enlace arriba, el revert ocurre automáticamente—luego depuras sin un largo viaje al datacenter.

Tarea 14: Si DNS “no se aplica”, inspecciona el estado de resolved (no solo resolv.conf)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54

Significado: systemd-resolved está a cargo y conoce tus servidores DNS deseados.
Decisión: Si Netplan muestra un DNS pero resolvectl muestra otro, el renderizador (o NM) puede estar empujando DNS de forma distinta. Decide quién posee el DNS y configura esa capa correctamente.

Tarea 15: Confirma que el nombre de interfaz coincide realmente con lo que configuraste

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             52:54:00:12:34:56
enp6s0           DOWN           52:54:00:aa:bb:cc

Significado: Los nombres predictibles de interfaz existen para reducir ambigüedad, pero aún causan problemas durante cambios de plantilla de VM y reordenamiento de NICs.
Decisión: Si configuraste ens3 pero el sistema tiene eno1, tu YAML es un hermoso poema que nadie lee. Corrige el nombre de coincidencia.

Cloud-init: el silencioso reescritor de configuración

Cloud-init existe para hacer que las imágenes sean portables: arrancar en cualquier sitio, descubrir metadata, configurar red, inyectar claves SSH y en general hacer las cosas que no quieres hornear en una imagen dorada.
El problema es que una vez que una máquina deja de ser “efímera”, la ayuda de cloud-init se vuelve indistinguible de sabotaje.

En imágenes cloud de Ubuntu 24.04, es común encontrar /etc/netplan/50-cloud-init.yaml. Este archivo no es sagrado.
Se genera. Y dependiendo de la configuración de cloud-init y del datasource, puede regenerarse en el arranque.
Si lo editas manualmente, estás negociando con un sistema automatizado que nunca duerme y no lee tus comentarios de ticket.

Cómo saber si cloud-init sobrescribirá la red

La señal más rápida son las entradas de log que muestran que escribe 50-cloud-init.yaml.
La segunda señal es que tus cambios “funcionan hasta que reinicias”.
La tercera señal es que tu gestión de configuración “sigue perdiendo”, aunque el archivo YAML en disco parezca correcto inmediatamente después de que corre tu automatización.

Hacer que perdure: elige una de estas estrategias

1. Deshabilitar la gestión de red de cloud-init en hosts de larga vida.
   Esto es común en centros de datos privados donde los metadatos de instancia no son la fuente de la verdad.
2. Proveer a cloud-init la configuración de red deseada para que genere el YAML de Netplan correcto.
   Esto es mejor cuando realmente quieres portabilidad en la nube y un comportamiento consistente en el primer arranque.
3. Mover el orden de tus archivos de Netplan para que tu archivo gane (por ejemplo, 99-local.yaml), pero solo si estás seguro de que cloud-init no regenera otras claves de las que dependes.
   Esto es una solución táctica. No es una arquitectura limpia.

Chiste #2: Cloud-init es como un compañero bienintencionado que “arregló” tu hoja de cálculo ordenándola—técnicamente correcto, operativamente catastrófico.

Deshabilitar la gestión de red de cloud-init (con cuidado)

Si la máquina ya no debe ser configurada dinámicamente por metadata, desactiva esa funcionalidad explícitamente.
El mecanismo exacto puede variar según el entorno, pero el objetivo es consistente: cloud-init debe dejar de generar y aplicar configuración de red.

Tras cambiar ajustes de cloud-init, reinicia o vuelve a ejecutar las etapas relevantes de cloud-init solo si entiendes el impacto. En producción, prefiere una ventana de reinicio controlada y acceso por consola.

Guerras de renderizadores: NetworkManager vs systemd-networkd

Netplan puede dirigirse a múltiples renderizadores. Los dos que encontrarás en la vida real son systemd-networkd y NetworkManager.
Tu trabajo no es elegir el “mejor” en abstracto. Tu trabajo es asegurar que exactamente uno de ellos posea cada interfaz, de forma predecible.

systemd-networkd: aburrido, determinista y adecuado para servidores

networkd suele preferirse en servidores sin interfaz porque es simple, se integra con systemd y hace menos cosas “útiles”.
Cuando declaras IPs estáticas, rutas y DNS en Netplan con renderer: networkd, normalmente buscas este mundo.

NetworkManager: flexible, fácil de usar y a veces demasiado listo

NM brilla en escritorios, Wi‑Fi, VPNs y entornos de red dinámica.
También aparece en servidores cuando los equipos se estandarizan en nmcli y quieren comportamiento consistente en flotas.
Eso está bien—hasta que alguien edita Netplan asumiendo networkd, mientras NM gestiona activamente la NIC.

La regla que previene el 80% de incidentes “Netplan no se aplicó”

Elige un renderizador por host (o al menos por interfaz) y haz que se cumpla.
Mezclar es posible, pero necesitas una razón, documentación y pruebas. Si no, es solo entropía con YAML.

Trampas de YAML, permisos y por qué “válido” no basta

YAML es amigable en la misma forma que un cuchillo de mantequilla es amigable: no te apuñalará, pero aún puede arruinar tu día si lo tratas como una cuchara.
Con Netplan, las trampas clásicas son sutiles: indentación incorrecta, ubicación errónea de claves, claves obsoletas y archivos que Netplan ignora silenciosamente por seguridad.

Orden léxico: el mecanismo silencioso de sobrescritura

Netplan lee /etc/netplan/*.yaml en orden léxico. Si dos archivos definen la misma interfaz, los posteriores pueden sobrescribir las declaraciones anteriores.
Esto es tanto una característica como una fuente de “juro que lo cambié”.

El enfoque pragmático para sobrescrituras locales (cuando debes hacerlo) es un archivo tail claramente nombrado como 99-local.yaml.
Pero si usas automatización, prefiere un único archivo autoritativo en lugar de una pila de sobrescrituras que nadie recuerda.

Permisos: Netplan no confiará en un config escribible

Si alguien hizo YAML de Netplan escribible por grupo para “ayudar al equipo”, accidentalmente creó una trampa de seguridad.
Netplan mitiga eso ignorando configuraciones inseguras. El resultado se ve como: “apply no hizo nada”, con una guarnición de confusión.

Claves obsoletas y semánticas cambiadas

Netplan ha evolucionado. Algunas claves que funcionaban en ejemplos antiguos pueden estar obsoletas o desaconsejadas. En Netplan moderno, usar routes explícitas suele ser preferible frente a atajos de gateway en configuraciones complejas.
La solución no es memorizar cada cambio—es apoyarse en netplan --debug generate e inspeccionar las configuraciones generadas.

Rutas, DNS y “se aplicó pero aún no funciona”

La categoría más frustrante es cuando Netplan aplicó genuinamente tu configuración—la dirección IP es correcta, el enlace está arriba—pero el sistema aún no puede alcanzar lo que necesita.
Eso no es un fallo de Netplan; es que tu intención de red está incompleta.

Conflictos de ruta por defecto

Los servidores multi-NIC son comunes ahora: una interfaz para gestión, otra para almacenamiento, otra para tráfico frontal, a veces overlays o VPNs.
Si dos interfaces ofrecen una ruta por defecto (vía DHCP o rutas estáticas), Linux elegirá una según métricas y tiempos.
Eso puede parecer “conectividad aleatoria”, especialmente tras reinicios.

La solución es ser explícito: define qué interfaz posee la ruta por defecto y considera usar métricas de ruta o enrutamiento por políticas si tu diseño necesita múltiples uplinks.

Problemas por capas de DNS

La gente aún trata el DNS como “un archivo en /etc/resolv.conf”. En Ubuntu 24.04, esa mentalidad es como perder una hora.
A menudo /etc/resolv.conf es un stub que apunta a systemd-resolved. NetworkManager también puede inyectar DNS.
Netplan puede establecer servidores DNS, pero el comportamiento final depende del renderizador y de la pila de resolución.

Diagnostica con resolvectl. Luego decide quién posee el DNS: networkd+resolved, o NetworkManager, o una configuración de resolutor dedicada. Haz un camino autoritativo.

Tres micro-historias corporativas desde el campo

1) Incidente causado por una suposición errónea: “Netplan es el gestor de red”

Un equipo heredó una flota de servidores Ubuntu que “usaban Netplan”. Querían mover una VLAN de servicio y decidieron actualizar un bloque de IPs estáticas.
La solicitud de cambio era simple: editar YAML, ejecutar netplan apply, verificar. Hicieron exactamente eso.

En la mitad de los hosts, no cambió nada. En la otra mitad, cambió y luego revirtió tras reiniciar durante un mantenimiento coordinado.
El equipo asumió que “netplan apply está roto en 24.04”, porque esa era la única herramienta visible que tocaron.

El análisis post-incident fue vergonzosamente sencillo: los hosts eran una mezcla de instalaciones.
Algunos usaban renderer: networkd. Otros tenían NetworkManager instalado y gestionando las NICs por un trabajo previo de “estandarización”.
Y las imágenes derivadas de la nube tenían cloud-init generando 50-cloud-init.yaml.

La remediación no fue ingeniería heroica. Fue gobernanza: elegir un renderizador por rol de host, eliminar el otro gestor donde proceda, deshabilitar cloud-init networking en nodos de larga vida y añadir una comprobación CI para fallar si múltiples archivos de netplan definen la misma interfaz.
El siguiente mantenimiento fue silencioso. Eso es lo mejor.

2) Optimización que salió mal: “Aceleremos el aprovisionamiento dejando cloud-init gestionar siempre la red”

Otra organización apostó fuerte por aprovisionamiento rápido. Usaron la red de cloud-init no solo en el primer arranque, sino como “fuente de la verdad” permanente para la configuración de red.
Funcionó genial mientras cada instancia era efímera. Luego empezaron a mantener algunos nodos meses porque la gravedad de los datos es real.

Ocurrió un cambio de red: se rotaron servidores DNS, cambiaron rutas y se requirió un nuevo MTU para un overlay. La automatización actualizó YAML de Netplan directamente en /etc/netplan.
Parecía correcto en disco, pero el siguiente reinicio lo revirtió. A veces revirtió solo partes—como DNS—creando un divertido cerebro dividido donde la conectividad funcionaba a medias.

La “optimización” era que cloud-init mantendría la red alineada con metadata. En la práctica, metadata y realidad divergieron: algunas instancias tenían metadata obsoleta, otras no tenían, y otras un datasource personalizado.
Cloud-init aplicaba fielmente sinsentidos.

Lo arreglaron cambiando el objetivo de la optimización. En lugar de “dejar que cloud-init siempre posea la red”, hicieron que la configuración de primer arranque fuera la frontera:
cloud-init configuró la red una vez, luego la propiedad de la red pasó al sistema de gestión de configuración. También añadieron un guardrail: si cloud-init intenta reescribir Netplan después del primer arranque, lo registra en rojo y falla el pipeline de despliegue.
El aprovisionamiento siguió siendo rápido, pero las operaciones dejaron de ser un juego de adivinanzas.

3) Práctica aburrida pero correcta que salvó el día: netplan try + acceso por consola + despliegue por etapas

Una compañía necesitaba cambiar la IP de una red de gestión en un gran entorno. Los cambios eran rutinarios pero riesgosos: no puedes arreglar un servidor bloqueado por SSH.
El SRE líder insistió en tres prácticas “aburridas”: siempre usar netplan try para cambios remotos, siempre tener acceso por consola fuera de banda probado previamente, y desplegar cambios en lotes pequeños.

El primer lote reveló una descoincidencia sutil: algunas NICs fueron renombradas por una renovación de hardware, así que la configuración de Netplan apuntaba al nombre de interfaz equivocado.
En esos nodos, netplan try no logró establecer conectividad y revirtió automáticamente.
Ese revert ahorró tiempo y evitó un montón de sesiones de consola de emergencia.

Como el despliegue fue por etapas, ajustaron el mapeo de inventario, regeneraron YAML con los nombres correctos de interfaz y continuaron.
Sin gran incidente. Sin heroísmos. Solo el tipo de proceso que nunca recibe premios pero mantiene los sistemas disponibles.

La lección no fue “netplan try es genial”. La lección fue que mecanismos deterministas de rollback y despliegues por etapas son características de fiabilidad, no ceremonias opcionales.

Errores comunes: síntoma → causa raíz → solución

1) “Edité el YAML y no pasó nada”

Síntoma: netplan apply devuelve sin errores; la IP sigue sin cambiar.
Causa raíz: Editaste un archivo que es sobrescrito por otro YAML (orden léxico), o Netplan ignoró el archivo por permisos inseguros.
Solución: Ejecuta sudo netplan get para confirmar la configuración fusionada; asegura propiedad root y permisos seguros; consolida a un archivo autoritativo o mueve tu sobrescritura a 99-local.yaml.

2) “Funciona hasta reiniciar, luego revierte”

Síntoma: Correcto tras apply; incorrecto tras reinicio.
Causa raíz: cloud-init reescribe 50-cloud-init.yaml o vuelve a generar la red en el arranque.
Solución: Evita que cloud-init gestione la red en ese rol de host, o mueve la intención de red a la configuración de cloud-init para que genere el YAML correcto en cada arranque (si realmente lo deseas).

3) “Netplan muestra networkd pero NM está realmente conectado”

Síntoma: YAML declara renderer: networkd, pero nmcli dev status muestra connected en la NIC.
Causa raíz: Desajuste de renderizador; NetworkManager gestiona la interfaz y puede sobrescribir dirección/DNS/rutas.
Solución: Decide la propiedad. O cambia Netplan a renderer: NetworkManager (y gestiona vía NM), o configura NM para no gestionar ese dispositivo y usa networkd de forma consistente.

4) “La IP se aplicó pero no hay internet / no hay ruta”

Síntoma: La interfaz tiene la dirección correcta; no puede alcanzar fuera de la subred.
Causa raíz: Falta de ruta por defecto, gateway incorrecto, o rutas por defecto competidoras en otra interfaz.
Solución: Usa ip route show. Define la ruta por defecto explícitamente bajo routes:, ajusta métricas y asegura que exista solo una ruta por defecto prevista (a menos que hagas enrutamiento por políticas a propósito).

5) “El DNS no cambia”

Síntoma: YAML lista servidores DNS; /etc/resolv.conf muestra otra cosa.
Causa raíz: Stub de systemd-resolved, inyección de DNS por NM, o configuración de resolutor por encima de Netplan.
Solución: Revisa resolvectl status y decide el propietario del DNS. Alinea el renderizador de Netplan con ese propietario; no edites a mano /etc/resolv.conf esperando que persista.

6) “netplan apply rompe SSH”

Síntoma: El apply corta la conexión; el sistema puede o no recuperarse.
Causa raíz: Cambios remotos aplicados sin rollback; nombre de interfaz equivocado; eliminación accidental de direcciones/rutas.
Solución: Usa netplan try. Asegura acceso por consola. Haz cambios de forma incremental: dirección primero, ruta después, DNS al final.

Listas de verificación / plan paso a paso

Lista A: Hacer que los cambios de Netplan perduren en un servidor de larga vida

1. Lista archivos YAML de Netplan: identifica sobrescrituras y archivos generados (ls -l /etc/netplan).
2. Confirma la intención fusionada (sudo netplan get). Si no es lo que esperas, detente.
3. Verifica propiedad del renderizador: networkctl status IFACE y nmcli dev status.
4. Comprueba propiedad de cloud-init: cloud-init status --long, logs de escritura de Netplan YAML.
5. Decide tu modelo de autoridad:
   • Cloud-init posee primer arranque, luego CM lo gestiona; o
   • Cloud-init posee la red siempre (rara vez sabio para nodos de larga vida); o
   • No usar cloud-init para red, nunca (común en metal desnudo).
6. Consolida YAML en un archivo por rol de host siempre que sea posible.
7. Establece permisos seguros: propiedad root, no escribible por grupo/otros.
8. Ejecuta sudo netplan --debug generate e inspecciona la configuración de backend generada.
9. Aplica con sudo netplan try si estás remotamente.
10. Valida con ip -br addr, ip route y resolvectl.

Lista B: Secuencia segura de cambio para migración de IP estática

1. Confirma nombres de interfaz y MACs coincidan con tu inventario (ip -br link).
2. Añade la nueva IP como secundaria (si tu entorno lo permite) antes de eliminar la antigua para evitar caídas.
3. Actualiza rutas, verifica conectividad al gateway y redes de siguiente salto.
4. Actualiza DNS al final, porque fallos de DNS confunden y parecen problemas de enrutamiento.
5. Programa un test de reinicio para persistencia una vez los cambios sean estables.

Lista C: Cuando sospechas conflictos (NM vs networkd vs cloud-init)

1. Prueba quién posee la interfaz (networkctl y nmcli).
2. Prueba quién escribe YAML de Netplan (logs de cloud-init, logs de CM, mtimes de archivos).
3. Prueba qué generó Netplan (/run/systemd/network/ o perfiles de conexión NM según el renderizador).
4. Elimina o desactiva al lado perdedor. La coexistencia parcial es cómo se obtienen fallos intermitentes.

Preguntas frecuentes

1) ¿Por qué netplan apply tiene éxito pero nada cambia?

Porque Netplan puede parsear y generar configs, pero el backend puede no gestionar esa interfaz, o otro YAML sobrescribe la tuya.
Confirma con netplan get, luego comprueba networkctl/nmcli, y luego inspecciona archivos generados.

2) ¿Qué archivo debo editar: 00-installer-config.yaml o 50-cloud-init.yaml?

Ninguno por defecto. Edita el archivo que sea autoritativo para el modelo de propiedad de tu host.
Si cloud-init escribe 50-cloud-init.yaml en el arranque, las ediciones manuales allí son una ilusión temporal.
Prefiere un archivo estable administrado por tu sistema de configuración, o provee a cloud-init la configuración de red correcta.

3) ¿Cómo sé qué renderizador estoy usando?

No confíes en la memoria. Usa netplan get para ver el renderizador declarado, y verifica el control real con networkctl status IFACE y nmcli dev status.
El propietario de la interfaz es lo que importa.

4) ¿Puedo mezclar NetworkManager y systemd-networkd en el mismo host?

Puedes, pero probablemente no deberías salvo que tengas una razón clara y pruebas.
La propiedad mixta aumenta las posibilidades de confusión de rutas/DNS y comportamiento “aplicado pero revertido”.
Si mezclas, asegúrate de que cada interfaz esté claramente gestionada por exactamente un servicio.

5) ¿Por qué el DNS en Netplan no coincide con /etc/resolv.conf?

Porque /etc/resolv.conf a menudo es un stub o enlace bajo systemd-resolved, y NetworkManager también puede inyectar DNS.
Usa resolvectl status para ver los resolutores efectivos, y luego alinea tu renderizador y la pila de resoluciones.

6) ¿Es seguro usar netplan try por SSH?

Sí—ese es el objetivo. Aplica cambios con un timeout y rollback a menos que confirmes.
No es magia, pero es la diferencia entre un cambio controlado y un viaje no planificado a la consola.

7) ¿Por qué mis cambios revierten solo a veces?

Porque múltiples sistemas compiten: renovaciones DHCP, autoconexión de NetworkManager, etapas de arranque de cloud-init, o incluso automatización que reaplica.
El comportamiento intermitente es característico de propiedad en conflicto. Identifica quién escribe y elimina el conflicto.

8) ¿Dónde escribe Netplan la configuración generada?

Para networkd, comúnmente bajo /run/systemd/network/ como 10-netplan-*.network.
Para NetworkManager, se traduce a perfiles de conexión NM (gestionados por NM). Los artefactos exactos dependen del renderizador, así que inspecciona lo presente y activo en el sistema.

9) ¿Cuál es la forma más segura de asegurar persistencia tras reinicio?

Asegura una única fuente de la verdad: un archivo YAML de Netplan gestionado por root y tu automatización, un renderizador que posea la interfaz, y cloud-init networking deshabilitado o correctamente configurado.
Luego reinicia durante una ventana de mantenimiento y verifica el estado en tiempo de ejecución.

10) ¿Debería editar a mano los archivos generados en /run/systemd/network/?

No, no como solución. Esos archivos son efímeros y se regenerarán.
Edita el YAML de Netplan (o la entrada de cloud-init) para que la salida generada sea correcta.
La única vez para editar archivos generados es como experimento temporal de diagnóstico cuando entiendes que estás saliendo del sistema.

Conclusión: siguientes pasos que no te harán recibir alertas después

Cuando los cambios de Netplan no se aplican en Ubuntu 24.04, el sistema normalmente está haciendo exactamente lo que se le dijo—solo que no por ti, y no en la capa que estás editando.
La solución rara vez es “intenta otra vez”. La solución es establecer propiedad y hacer la canalización de configuración aburrida.

Haz esto a continuación, en orden:

1. Ejecuta sudo netplan get y confirma que tu intención esté realmente en la configuración fusionada.
2. Confirma la propiedad de la interfaz con networkctl y nmcli; elige un renderizador y haz que se cumpla.
3. Comprueba si cloud-init reescribe y decide si cloud-init debe poseer la red en este host.
4. Inspecciona la configuración de backend generada bajo /run para probar qué se aplicará.
5. Usa netplan try para cambios remotos y luego valida con ip/resolvectl.

Hazlo determinista. Hazlo testeable. Hazlo para que la próxima persona de guardia no tenga que aprender tu infraestructura leyendo logs a las 03:00.