Modifico dhcp a estático en / etc / network / interfaces (como a continuación).
# The primary network interface
auto eth0
iface eth0 inet static
netmask 255.255.0.0
address 10.10.130.128
gateway 10.10.1.1
Luego reinicie la interfaz.
$ sudo ifdown eth0; sudo ifup eth0
...
$ ifconfig
eth0 Link encap:Ethernet
inet addr:10.10.130.128 Bcast:10.10.255.255 Mask:255.255.0.0
Entonces la nueva dirección entra en juego.
¿Pero DHCP sigue ahí?
$ ps aux | grep dhc
root ... dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -1 eth0
¿Eso es normal? Si no es así, ¿cómo reiniciar la interfaz en IP estática y detener DHCP al mismo tiempo?
Muchas gracias.
networking
dhcp
usuario276851
fuente
fuente
Respuestas:
sudo ifdown eth0
Luego edite la configuración
nano /etc/network/interfaces
Vuelva a colocar la interfaz
sudo ifup eth0
De
dhclient
lo contrario no se apaga correctamente,fuente
/etc/network/interfaces
archivo? ¿Hay alguna manera de forzar un restablecimiento a los valores predeterminados y comenzar de nuevo?ifdown
se ejecuta, el administrador de red no sabe que debe detenersedhclient
, ya que todo lo que ve en elinterfaces
archivo es una entrada estática. Después, la interfaz está inactiva, emiteifup
lecturas correctas y aplica la configuración estática, pero tampoco sabe que sedhclient
había iniciado.Tuve el mismo problema (Ubuntu 16.04). Sin embargo, esta fue una instancia en la nube y no pude bajar la interfaz tan fácilmente.
Respuesta corta: eliminé el archivo
/etc/network/interfaces.d/50-cloud-init.cfg
ifup fue activado por ese archivo específico.Respuesta larga: configuré la interfaz usando
/etc/network/interfaces
una dirección IP estática, pero todavía encontré en el daemon.log que dhclient todavía solicitaba IP del DHCP y dhclient se inició a través de systemd. Específicamente, systemd llamó a la unidad networking.service, que llamó a ifup, que leía tanto el archivo de interfaces como el archivo 50-cloud-init.cfg. Resultando en algunos conflictos, pero sigue siendo una red funcional.fuente
Descubrí que esto se debía a que NetworkManager de gnome seguía ejecutándose y pensaba que estaba a cargo del dispositivo. En retrospectiva, esto debería haber sido obvio, ya que
ps
mostró que dhclient estaba siendo lanzado por NetworkManager.Una vez que reinicié mi sistema, el dispositivo pasó a "no administrado" en NetworkManager y dejó de intentar configurarlo. Tal vez podría haber logrado lo mismo con solo detener / reiniciar NetworkManager, no estoy seguro.
fuente