Instalé Ubuntu 17.10 con las últimas actualizaciones en una máquina virtual vmware. Netplan no configura mis 2 ethernet.
Aquí está mi /etc/netplan/01-netcfg.yaml
network:
version: 2
renderer: networkd
ethernets:
lan:
match:
macaddress: 00:12:34:a8:29:e8
set-name: lan
dhcp4: false
dhcp6: false
accept-ra: false
addresses:
- 10.10.0.48/24
- 1701:5740:5000:3301::48/64
failover:
match:
macaddress: 00:45:57:89:27:e8
set-name: failover
dhcp4: false
dhcp6: false
accept-ra: false
addresses:
- 17.25.111.30/27
- 1701:5740:5000:3300::30/64
gateway4: 17.25.111.1
gateway6: 1701:5740:5000:3300::1
nameservers:
search:
- example.at
- intern.example.at
addresses:
- 10.10.0.1
- 1701:5740::66
Volví a dispositivos predecibles como eth0, y después del arranque todos los dispositivos se nombran correctamente, pero no están configurados.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: lan: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:12:34:a8:29:e8 brd ff:ff:ff:ff:ff:ff
3: failover: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:45:57:89:27:e8 brd ff:ff:ff:ff:ff:ff
Después de iniciar sesión y activar systemctl, reinicie systemd-networkd dispositivos están configurados. netplan apply también hace el trabajo.
Jugué mucho con systemd-networkd.service y systemd-networkd.timer pero nada me ayudó.
Es bastante frustrante configurar la red manualmente después de cada reinicio. Alguien sabe cómo resolver esto?
networking
systemd
netplan
Thomas Aichinger
fuente
fuente
Respuestas:
Creo que has accedido a LP: # 1770082 - "systemd-networkd no renombra dispositivos en el arranque".
Básicamente, cuando su sistema está arrancando, el dispositivo de red aparecerá como
eth0
/eth1
etc. El orden no es predecible, por lo que udev cambia el nombre de los dispositivos a cosas comoens3
oenp2s0
en la fase de inicio del arranque. (Debería poder ver esto haciendo clic en la salida dedmesg
).Tienes una
set-name
estrofa en tu netplan YAML. Más adelante en el arranque, esoset-name
genera una regla de cambio de nombre en un archivo de enlace systemd , que es leído por udev. Sin embargo, un archivo de enlace no hará que se cambie el nombre de un dispositivo si ya se ha cambiado el nombre. En su caso, entonces, el dispositivo no se cambiará de nombre porque probablemente se renombró anteriormente en initrd.Abrí un error contra systemd ( problema # 9006 - "udev: nombre de interfaz en el archivo de enlace no aplicado") sobre esto. También propuse un cambio a netplan ( PR # 31 - "Generar archivos de reglas udev para cambiar el nombre de los dispositivos") que hará que se cree un archivo de reglas systemd así como un archivo de enlace, ya que se respeta un archivo de reglas incluso si el dispositivo tiene Ya ha sido renombrado.
Como solución alternativa, intente arrancar con
net.ifnames=0
en la línea de comando del núcleo. Para una solución a largo plazo, espere que mi cambio a netplan se regrese a Bionic y se lance en el próximo mes más o menos.fuente
set-name
directivas por ahora, no probé elnet.ifnames=0
cmdline del núcleo. Conset-name
, los dispositivos cambiaron de nombre, pero no se mencionaron.Tengo exactamente el mismo problema en Ubuntu 18.04, pero la solución de R. Pietsch no lo resuelve :(
También intenté habilitar al usuario root, que está deshabilitado por defecto en Ubuntu, pero no tuve suerte.
La única forma en que tengo que ganar conectividad es:
Si no "sudo netplan apply", no tengo conexión en la máquina. ¿Cómo es posible poner en una versión LTS un software tan roto?
Me gustaría agregar más detalles sobre mi escenario, para ser útil a otras personas para reconocer los fenómenos de los que estamos hablando. Esto es lo que estaba sucediendo en mi caso:
Creo que netplan es una buena mejora en comparación con / etc / network / interfaces, pero este comportamiento debería repararse lo antes posible :)
ACTUALIZAR:
Depuré el problema usando los siguientes comandos:
Parece que fue el panel de Network Manager en LXDE lo que interfirió con él. Incluso si las conexiones se mostraban como "no administradas", desmarqué la casilla "Habilitar redes" y parece que solucionó el problema.
Podemos cerrar este :)
fuente
Ahora lo he probado con Ubuntu 18.04 y creo que este error se ha solucionado.
Funciona para mi ahora.
fuente
Solucioné este problema insertando
en el crontab de root. No es la solución real para el problema, sino una solución que lo solucionó.
fuente
Con ubuntu 18.04, netplan también era bastante nuevo para mí, seguí una guía para crear el
/etc/netplan/01-netcfg.yaml
archivo y ejecutarlosudo netplan apply
y, como tú, en cualquier momento reiniciar la conectividad se había ido.La ejecución manual
sudo netplan apply
hizo que volviera a funcionar. Pero eso fue molesto.En mi caso, la solución fue editar
/etc/network/interfaces
y comentar todas las estrofas enp0 ** (verifique cómo se llaman en su sistema).Luego reiniciar.
Básicamente, la configuración anterior en / etc / nwtwork / interfaces estaba en conflicto con netplan.
fuente
Tuve un problema en el que necesitaba volver a activar los eventos. Esencialmente, netplan hizo toda la configuración correctamente pero networkd lo ignoró. Volver a conectar los dispositivos como "netplan apply" lo arreglaría.
Entonces, para algunos, la solución podría ser hacer como
Quizás esto ayude a algunos a buscar este problema.
Como creo que esto es realmente un error, presenté este error al respecto.
fuente
Ok, mejor respuesta. Lo arreglé. Vuelve a ifupdown hasta que se arregle netplan. sudo apt install ifupdown luego configure la interfaz sudo nano / etc / network / interfaces
auto enp3s0 iface enp3s0 dirección estática inet 192.168.1.100 máscara de red 255.255.255.0 red 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 dns-nameservers 192.168.1.0,8.8.8.8
y quien implementó esto en una versión del servidor LTS obviamente no lo probó
fuente
Como este es un problema continuo, tengo otro enfoque para resolver este problema:
Cree un temporizador systemd y aplique stettings de red después del arranque.
Aquí está el script: check_network. Debe reemplazar la interfaz ens32 con la suya.
Esta es la unidad de servicio check_network.service
Y este es el temporizador systemd check_network.timer llamado 30 segundos después del arranque y luego cada hora
Copie check_network en / root / jobs
Copie check_network.service en / etc / systemd / system
Copie check_network.timer en / etc / systemd / system
Y luego habilite el servicio y el temporizador
fuente
usuario de netplan en 18.04.1 Suponiendo que la configuración de netplan se lee al reiniciar networkd: esto en sí mismo fue un poco problemático porque hay como 10 servicios de red diferentes que systemctl conoce. Ninguno de ellos trajo el resultado deseado, así que recurrí a reiniciar toda la máquina. En vano. Eventualmente descubrí que 'netplan apply' ayuda aquí no solo en la aplicación sino que también indica fallas de sintaxis. Entonces, después del cambio, parece que debe aplicar netplan y luego listo. Esto no se describe en el manual a menos que me lo haya perdido, así que lo incluyo aquí para otros pequeños gusanos pobres como yo.
fuente