1 adresse IPv4 en trop sur eth0 de Debian Jessie...
Salut, J'ai installé une Debian Jessie sur une machine avec l'interface eth0 en dhcp et gnome. Par la suite j'ai personnalisé un peu la configuration et j'ai rajouté une configuration statique d'eth0 dans /etc/network/interfaces. Tout serait parfait si l'ancienne adresse (celle obtenue par dhcp) n'était plus associée à eth0 alors que la config dynamique n'est plus active. Du coup je me retrouve avec 2 ipv4 sur eth0, en principale l'ancienne adresse et en secondaire la nouvelle, statique. J'ai viré, NetworkManager et isc-dhcp-client, mais ça ne change pas grand chose... Pour l'instant en fouillant dans le système des fichiers je trouve une référence à eth0 et à cette ancienne adresse dans /run/net-eth0.conf. Je ne vois pas eth0 dans /run/network/ifstate, eth1 et lo y sont... Tout cela me semble bien mystérieux, mais surtout anormal... J'ai posé la même question sur la ML Debian User French mais toujours pas de solution en vue... Un petit coup de main, svp ? -- Cordialement, Artur.
On Fri Jun 26 15:01:38 2015, Artur wrote:
J'ai viré, NetworkManager et isc-dhcp-client, mais ça ne change pas grand chose...
Est-ce que tu as essayé de faire un ifdown eth0 suivit d’un ifup eth0 pour voir si par hasard il ne gardait pas juste l’ancienne IP pour d’obscures raisons. Si tu redémarres l’interface, normalement il devrait repartir de zéro. -- Alarig Le Lay
Le 26/06/2015 15:21, Alarig Le Lay a écrit :
On Fri Jun 26 15:01:38 2015, Artur wrote:
J'ai viré, NetworkManager et isc-dhcp-client, mais ça ne change pas grand chose... Est-ce que tu as essayé de faire un ifdown eth0 suivit d’un ifup eth0 pour voir si par hasard il ne gardait pas juste l’ancienne IP pour d’obscures raisons. Si tu redémarres l’interface, normalement il devrait repartir de zéro.
J'ai même rebooté cette machine plusieurs fois... Mais ça persiste et il y a ça dans /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.16.222 netmask 255.255.255.0 gateway 192.168.16.254 auto eth1 iface eth1 inet static address 192.168.1.254 netmask 255.255.255.0 Rien dans le répertoire /etc/network/interfaces.d/ -- Cordialement, Artur.
Le Fri, 26 Jun 2015 15:21:39 +0200, Alarig Le Lay <alarig@swordarmor.fr> a écrit :
On Fri Jun 26 15:01:38 2015, Artur wrote:
J'ai viré, NetworkManager et isc-dhcp-client, mais ça ne change pas grand chose...
Est-ce que tu as essayé de faire un ifdown eth0 suivit d’un ifup eth0 pour voir si par hasard il ne gardait pas juste l’ancienne IP pour d’obscures raisons. Si tu redémarres l’interface, normalement il devrait repartir de zéro.
Tu peux toujours supprimer l'adresse en trop : ip addr del xxx.xxx.xxx.xxx/yy dev eth0 Si tu redémarre la machine, l'adresse surnuméraire est toujours là ? Pep
Le 26/06/2015 15:30, Pep a écrit :
Tu peux toujours supprimer l'adresse en trop :
ip addr del xxx.xxx.xxx.xxx/yy dev eth0
Si tu redémarre la machine, l'adresse surnuméraire est toujours là ?
Cela donne ça : # ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.184/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.16.222/24 brd 192.168.16.255 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever # ip addr del 192.168.16.184/24 dev eth0 Assez violent, ça supprime tout : # ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever # ifup eth0 # ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever Ca semble OK -> Reboot Et cette fois-ci je ne vois plus l'ancienne adresse !!! # ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever Ce qui est également un miracle parce que cette manip je l'ai déjà faite plusieurs fois la semaine dernière et au reboot on retrouvait la situation du début. Peut-être que l'adresse apparaissait aussi longtemps que le bail DHCP était valide ??? Mais quel mécanisme permettait donc de réaffecter cette adresse dynamique après un reboot ? -- Cordialement, Artur.
Le Fri, 26 Jun 2015 15:50:43 +0200, Artur <frsag@pydo.org> a écrit :
Le 26/06/2015 15:30, Pep a écrit :
Tu peux toujours supprimer l'adresse en trop :
ip addr del xxx.xxx.xxx.xxx/yy dev eth0
Si tu redémarre la machine, l'adresse surnuméraire est toujours là ?
Cela donne ça :
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.184/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.16.222/24 brd 192.168.16.255 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
# ip addr del 192.168.16.184/24 dev eth0
Assez violent, ça supprime tout :
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Si je le fais sur ma machine, il n'enlève que l'adresse précisée dans la commande.
# ifup eth0 # ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Ca semble OK -> Reboot
Et cette fois-ci je ne vois plus l'ancienne adresse !!!
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Ce qui est également un miracle parce que cette manip je l'ai déjà faite plusieurs fois la semaine dernière et au reboot on retrouvait la situation du début. Peut-être que l'adresse apparaissait aussi longtemps que le bail DHCP était valide ???
Ça me semble possible. As-tu eu une nouvelle demande de bail, quand la machine à re-démarré ?
Mais quel mécanisme permettait donc de réaffecter cette adresse dynamique après un reboot ?
Aucune idée sur la manière et l'endroit où la conf réseau "en cours" est stockée. Mais ça veut dire que le système stocke la conf réseau qque part pour un reboot. Bon we, Pep
-----Original Message----- From: FRsAG [mailto:frsag-bounces@frsag.org] On Behalf Of Pep Sent: vendredi 26 juin 2015 16:14 To: frsag@frsag.org Subject: Re: [FRsAG] 1 adresse IPv4 en trop sur eth0 de Debian Jessie... Le Fri, 26 Jun 2015 15:50:43 +0200, Artur <frsag@pydo.org> a écrit :
Le 26/06/2015 15:30, Pep a écrit :
Tu peux toujours supprimer l'adresse en trop :
ip addr del xxx.xxx.xxx.xxx/yy dev eth0
Si tu redémarre la machine, l'adresse surnuméraire est toujours là ?
Cela donne ça :
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.184/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.16.222/24 brd 192.168.16.255 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
# ip addr del 192.168.16.184/24 dev eth0
Assez violent, ça supprime tout :
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Si je le fais sur ma machine, il n'enlève que l'adresse précisée dans la commande.
# ifup eth0 # ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Ca semble OK -> Reboot
Et cette fois-ci je ne vois plus l'ancienne adresse !!!
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Ce qui est également un miracle parce que cette manip je l'ai déjà faite plusieurs fois la semaine dernière et au reboot on retrouvait la situation du début. Peut-être que l'adresse apparaissait aussi longtemps que le bail DHCP était valide ???
Ça me semble possible. As-tu eu une nouvelle demande de bail, quand la machine à re-démarré ?
Mais quel mécanisme permettait donc de réaffecter cette adresse dynamique après un reboot ?
Aucune idée sur la manière et l'endroit où la conf réseau "en cours" est stockée. Mais ça veut dire que le système stocke la conf réseau qque part pour un reboot. Bon we, Pep _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ Marrant, J'ai exactement le même problème sur un rasPi 2 upgradé en jessie. Tout comme toi, ca me rend fou, j'ai beau supprimer l'adresse DHCP, au reboot elle réapparait. Dans la séquence de boot j'ai eu l'impression que c'est Avahi qui persistait à déclencher une requete DHCP. J'ai supprimé avahi mais n'ai pas encore rebooté depuis, je me demande si ça résoud le problème... Joël
On 26/06/2015 17:26, Radu-Adrian Feurdean wrote:
On Fri, Jun 26, 2015, at 17:01, Joël DEREFINKO wrote:
J'ai exactement le même problème sur un rasPi 2 upgradé en jessie. Puisque c'est vendredi et que tout est permis: c'est avec systemd (sinistrement default) ou avec sysvinit (a installer manuellement) ? Ca sent le systemd et le network-manager avec des bouts de conf (considéré comme un state, plutot qu'une conf) qui doivent trainer dans /var
Le 26/06/2015 17:26, Radu-Adrian Feurdean a écrit :
On Fri, Jun 26, 2015, at 17:01, Joël DEREFINKO wrote:
J'ai exactement le même problème sur un rasPi 2 upgradé en jessie. Puisque c'est vendredi et que tout est permis: c'est avec systemd (sinistrement default) ou avec sysvinit (a installer manuellement) ?
systemd dans mon cas. -- Cordialement, Artur.
-----Original Message----- From: FRsAG [mailto:frsag-bounces@frsag.org] On Behalf Of Artur Sent: vendredi 26 juin 2015 18:10 To: frsag@frsag.org Subject: Re: [FRsAG] 1 adresse IPv4 en trop sur eth0 de Debian Jessie... Le 26/06/2015 17:26, Radu-Adrian Feurdean a écrit :
On Fri, Jun 26, 2015, at 17:01, Joël DEREFINKO wrote:
J'ai exactement le même problème sur un rasPi 2 upgradé en jessie. Puisque c'est vendredi et que tout est permis: c'est avec systemd (sinistrement default) ou avec sysvinit (a installer manuellement) ?
systemd dans mon cas. -- Cordialement, Artur. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ Idem, systemd sur mon rasp Joel
Le 2015-06-26 16:13, Pep a écrit :
Le Fri, 26 Jun 2015 15:50:43 +0200, Artur <frsag@pydo.org> a écrit :
Le 26/06/2015 15:30, Pep a écrit :
Tu peux toujours supprimer l'adresse en trop :
ip addr del xxx.xxx.xxx.xxx/yy dev eth0
Si tu redémarre la machine, l'adresse surnuméraire est toujours là ?
Cela donne ça :
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.184/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.16.222/24 brd 192.168.16.255 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
# ip addr del 192.168.16.184/24 dev eth0
Assez violent, ça supprime tout :
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Si je le fais sur ma machine, il n'enlève que l'adresse précisée dans la commande.
# ifup eth0 # ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Ca semble OK -> Reboot
Et cette fois-ci je ne vois plus l'ancienne adresse !!!
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Ce qui est également un miracle parce que cette manip je l'ai déjà faite plusieurs fois la semaine dernière et au reboot on retrouvait la situation du début. Peut-être que l'adresse apparaissait aussi longtemps que le bail DHCP était valide ???
Ça me semble possible. As-tu eu une nouvelle demande de bail, quand la machine à re-démarré ?
Mais quel mécanisme permettait donc de réaffecter cette adresse dynamique après un reboot ?
Aucune idée sur la manière et l'endroit où la conf réseau "en cours" est stockée. Mais ça veut dire que le système stocke la conf réseau qque part pour un reboot.
Bon we,
Pep
Tu as regardé autour de network-manager ? Cdlt,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Bonjour, On 26/06/2015 16:13, Pep wrote:
inet 192.168.16.184/24 brd 192.168.16.255 scope global eth0 inet 192.168.16.222/24 brd 192.168.16.255 scope global secondary inet6 fe80::208:54ff:fe37:cd20/64 scope link
# ip addr del 192.168.16.184/24 dev eth0
Assez violent, ça supprime tout
Si je le fais sur ma machine, il n'enlève que l'adresse précisée dans la commande.
Cette partie là vient de ce que la seconde IP était "secondary" donc liée à la première. Elle est secondary parce que le subnet était le même. Si vous faites la même manip avec une 2eme IP qui est dans 192.168.17.0/24 par exemple, la seconde restera quand vous retirez la première. Cordialement, S. Vallerot - -- Gixe - Association 1901 - conseil, hébergement, opérateur pour tous SIREN 450 404 769 - http://www.gixe.net - contact@gixe.net venez nous voir sur IRC geeknode #gixe - tél: 0950315474 - 0686383868 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlWWQ3QACgkQJBGsD8mtnRGJygEAnPqupt0pOXAtp64K+7LbDdE7 JHAJo72YOA0kKv2ii60A/2KwsxjegKty35NBWJeKn+ZslMhYHWCXbUukGsLB3kY4 =SGgp -----END PGP SIGNATURE-----
Le Fri, 03 Jul 2015 10:10:28 +0200, Sylvain Vallerot <sylvain@gixe.net> a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Bonjour,
On 26/06/2015 16:13, Pep wrote:
inet 192.168.16.184/24 brd 192.168.16.255 scope global eth0 inet 192.168.16.222/24 brd 192.168.16.255 scope global secondary inet6 fe80::208:54ff:fe37:cd20/64 scope link
# ip addr del 192.168.16.184/24 dev eth0
Assez violent, ça supprime tout
Si je le fais sur ma machine, il n'enlève que l'adresse précisée dans la commande.
Cette partie là vient de ce que la seconde IP était "secondary" donc liée à la première. Elle est secondary parce que le subnet était le même. Si vous faites la même manip avec une 2eme IP qui est dans 192.168.17.0/24 par exemple, la seconde restera quand vous retirez la première.
Cordialement, S. Vallerot
Re bonjour Sylvain, Je viens de refaire la manip sur ma machine, et elle ne fonctionne pas comme ça ! Je peux ajouter et enlever des ips sur des interfaces, dans le même sous-réseau ou pas, la commande s'applique uniquement sur l'ip précisée. J'ai essayé en Sid et en Wheezy, même résultat. Un lien sur cette ip "secondary" ? Pep
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Re, On 03/07/2015 11:03, Pep wrote:
Je viens de refaire la manip sur ma machine, et elle ne fonctionne pas comme ça !
Je peux ajouter et enlever des ips sur des interfaces, dans le même sous-réseau ou pas, la commande s'applique uniquement sur l'ip précisée.
J'ai essayé en Sid et en Wheezy, même résultat.
Etonnant, car j'ai testé (wheezy / linux 3.2.0-4-686-pae) avant de poster root@eugenie:/home/lulu# ip a list dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:24:e8:ca:7f:7e brd ff:ff:ff:ff:ff:ff inet 10.0.0.12/24 brd 10.0.0.255 scope global eth0 inet 10.0.0.13/24 scope global secondary eth0 inet6 fe80::224:e8ff:feca:7f7e/64 scope link valid_lft forever preferred_lft forever root@eugenie:/home/lulu# ip a del 10.0.0.12/24 dev eth0; ip a list dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:24:e8:ca:7f:7e brd ff:ff:ff:ff:ff:ff inet6 fe80::224:e8ff:feca:7f7e/64 scope link valid_lft forever preferred_lft forever Ca doit dépendre "d'autre chose". Je précise que network-manager a été stoppé avant. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlWWYH8ACgkQJBGsD8mtnRGnLgD/Wo4dbXk+1eA6uQ4YT9eEYsHL 9GVcfN7ODOPYufxwakcA/iT/PfqJt1waWifIWyPGbpxzmvGQcUk3inrpe+Y1mZLf =pR8b -----END PGP SIGNATURE-----
Bonjour, A verifier, mais j'ai constate que lorsque une IP avait ete affectee via DHCP, si lors du reboot le serveur n'etait plus joignable qu'elle que soit la raison, le mecanisme de boot la reattribuait quoi qu'il arrive. J'ai eu le cas en changeant un routeur sur lequel j'avais oublie de remttre le dhrelay. Je ne peux pas retster, mais dhclient semble maintenir cette information quelque part, ce qui en l'occurrence m'avait bien servi ;) -- Sébastien Coureau Graal Network
Le 26 juin 2015 à 15:50, Artur <frsag@pydo.org> a écrit :
Le 26/06/2015 15:30, Pep a écrit :
Tu peux toujours supprimer l'adresse en trop :
ip addr del xxx.xxx.xxx.xxx/yy dev eth0
Si tu redémarre la machine, l'adresse surnuméraire est toujours là ?
Cela donne ça :
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.184/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.16.222/24 brd 192.168.16.255 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
# ip addr del 192.168.16.184/24 dev eth0
Assez violent, ça supprime tout :
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
# ifup eth0 # ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Ca semble OK -> Reboot
Et cette fois-ci je ne vois plus l'ancienne adresse !!!
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Ce qui est également un miracle parce que cette manip je l'ai déjà faite plusieurs fois la semaine dernière et au reboot on retrouvait la situation du début. Peut-être que l'adresse apparaissait aussi longtemps que le bail DHCP était valide ??? Mais quel mécanisme permettait donc de réaffecter cette adresse dynamique après un reboot ?
-- Cordialement, Artur.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Qu'y a-t-il dans ton fichier /etc/udev/rules.d/70-persistent-net.rules ? Guy Larrieu. Le 26/06/2015 17:37, Sebastien Coureau a écrit :
Bonjour, A verifier, mais j'ai constate que lorsque une IP avait ete affectee via DHCP, si lors du reboot le serveur n'etait plus joignable qu'elle que soit la raison, le mecanisme de boot la reattribuait quoi qu'il arrive. J'ai eu le cas en changeant un routeur sur lequel j'avais oublie de remttre le dhrelay.
Je ne peux pas retster, mais dhclient semble maintenir cette information quelque part, ce qui en l'occurrence m'avait bien servi ;)
-- Sébastien Coureau Graal Network
Le 26 juin 2015 à 15:50, Artur <frsag@pydo.org> a écrit :
Le 26/06/2015 15:30, Pep a écrit :
Tu peux toujours supprimer l'adresse en trop :
ip addr del xxx.xxx.xxx.xxx/yy dev eth0
Si tu redémarre la machine, l'adresse surnuméraire est toujours là ?
Cela donne ça :
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.184/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.16.222/24 brd 192.168.16.255 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
# ip addr del 192.168.16.184/24 dev eth0
Assez violent, ça supprime tout :
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
# ifup eth0 # ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Ca semble OK -> Reboot
Et cette fois-ci je ne vois plus l'ancienne adresse !!!
# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:08:54:37:cd:20 brd ff:ff:ff:ff:ff:ff inet 192.168.16.222/24 brd 192.168.16.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe37:cd20/64 scope link valid_lft forever preferred_lft forever
Ce qui est également un miracle parce que cette manip je l'ai déjà faite plusieurs fois la semaine dernière et au reboot on retrouvait la situation du début. Peut-être que l'adresse apparaissait aussi longtemps que le bail DHCP était valide ??? Mais quel mécanisme permettait donc de réaffecter cette adresse dynamique après un reboot ?
-- Cordialement, Artur.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On Fri Jun 26 17:47:37 2015, Guy Larrieu wrote:
Qu'y a-t-il dans ton fichier /etc/udev/rules.d/70-persistent-net.rules ?
Ce fichier est là pour assurer la correspondance entre adresse MAC et numéro de port (eth{1..42}), je ne vois pas trop ce qu’une adresse IP viendrait foutre là-dedans. De plus, je doute que dhclient puisse y écrire. -- Alarig Le Lay
participants (10)
-
Alarig Le Lay -
Artur -
Guy Larrieu -
Jean-Yves LENHOF -
Joël DEREFINKO -
Pep -
Radu-Adrian Feurdean -
Sebastien Coureau -
Simon Morvan -
Sylvain Vallerot