Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian /etc/network/interfaces et inet6

/etc/network/interfaces et inet6

11 réponses
Avatar
BERTRAND Jo=c3=abl
Bonjour à tous,

Un petit truc me chagrine dans la configuration d'IPv6 sur un serveur.
Ayant un fournisseur d'accès que je qualifierais d'"internet pour les
ploucs" (Wimax avec tous les ports fermés ou presque...), je suis
contraint d'utiliser un serveur dans un bureau distant comme broker IPv6
(et accès IPv4 entrant tant qu'à faire). Comme le FAI (celui d'internet
pour les ploucs) coupe autoritairement les ports mêmes utilisés, j'ai
bricolé un VPN sur deux ports avec du stp. Ça fonctionne. J'ai juste un
souci avec IPv6 au démarrage.

En effet, lors d'un redémarrage du serveur, tout fonctionne sauf le
routage IPv6 (comprendre : br0 a bien une adresse IPv6, mais la route
vers le sous réseau au bout de br0 n'est pas montée) :

ifconfig retourne :
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1336
inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::64b9:94ff:fe3b:1b5 prefixlen 64 scopeid 0x20<link>
inet6 2001:7a8:a8ed:1::1 prefixlen 64 scopeid 0x0<global>
ether 66:b9:94:3b:01:b5 txqueuelen 1000 (Ethernet)
RX packets 14018 bytes 1126600 (1.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 14995 bytes 25922932 (24.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
...
tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1336
ether 9e:74:8c:46:30:19 txqueuelen 100 (Ethernet)
RX packets 14018 bytes 1322852 (1.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 28464 bytes 26748756 (25.5 MiB)
TX errors 0 dropped 3 overruns 0 carrier 0 collisions 0

tap2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1336
ether 66:b9:94:3b:01:b5 txqueuelen 100 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4895 bytes 250208 (244.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Or, dans /etc/network/interface, j'ai bien :

auto br0
iface br0 inet static
bridge_stp on
mtu 1336
bridge_ports tap1 tap2
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
post-up /sbin/route add -net 192.168.10.0/24 gw 192.168.1.2
pre-down /sbin/route del -net 192.168.10.0/24

iface br0 inet6 static
address 2001:7a8:a8ed:1::1
netmask 64
post-up /sbin/route -A inet6 add 2001:7a8:a8ed:10::/64 gw
2001:7a8:a8ed:1::2
pre-down /sbin/route -A inet6 del 2001:7a8:a8ed:10::/64 gw
2001:7a8:a8ed:1::2

J'avoue que je ne comprends pas bien. Pourquoi br0 prend-elle la bonne
adresse IPv6 sans prendre la route associée ? Il suffit en effet que je
lance à la main :

/sbin/route -A inet6 add 2001:7a8:a8ed:10::/64 gw 2001:7a8:a8ed:1::2

pour que le routage IPv6 fonctionne à nouveau.

Le serveur est un Linux debian/testing, le client est un NetBSD (côté
NetBSD aucun problème de ce genre, le routage IPv6 est persistant).

Toute idée sera la bienvenue.

Bien cordialement,

JKB
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Daniel Huhardeaux
Le 04/09/2019 à 08:03, BERTRAND Joël a écrit :
Bonjour à tous,
Un petit truc me chagrine dans la configuration d'IPv6 sur un serveur.
Ayant un fournisseur d'accès que je qualifierais d'"internet pour les
ploucs" (Wimax avec tous les ports fermés ou presque...), je suis
contraint d'utiliser un serveur dans un bureau distant comme broker IPv6
(et accès IPv4 entrant tant qu'à faire). Comme le FAI (celui d'internet
pour les ploucs) coupe autoritairement les ports mêmes utilisés, j'ai
bricolé un VPN sur deux ports avec du stp. Ça fonctionne. J'ai juste un
souci avec IPv6 au démarrage.
En effet, lors d'un redémarrage du serveur, tout fonctionne sauf le
routage IPv6 (comprendre : br0 a bien une adresse IPv6, mais la route
vers le sous réseau au bout de br0 n'est pas montée) :
ifconfig retourne :
br0: flagsA63<UP,BROADCAST,RUNNING,MULTICAST> mtu 1336
inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::64b9:94ff:fe3b:1b5 prefixlen 64 scopeid 0x20<link>
inet6 2001:7a8:a8ed:1::1 prefixlen 64 scopeid 0x0<global>
ether 66:b9:94:3b:01:b5 txqueuelen 1000 (Ethernet)
RX packets 14018 bytes 1126600 (1.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 14995 bytes 25922932 (24.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
...
tap1: flagsA63<UP,BROADCAST,RUNNING,MULTICAST> mtu 1336
ether 9e:74:8c:46:30:19 txqueuelen 100 (Ethernet)
RX packets 14018 bytes 1322852 (1.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 28464 bytes 26748756 (25.5 MiB)
TX errors 0 dropped 3 overruns 0 carrier 0 collisions 0
tap2: flagsA63<UP,BROADCAST,RUNNING,MULTICAST> mtu 1336
ether 66:b9:94:3b:01:b5 txqueuelen 100 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4895 bytes 250208 (244.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Or, dans /etc/network/interface, j'ai bien :
auto br0
iface br0 inet static
bridge_stp on
mtu 1336
bridge_ports tap1 tap2
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
post-up /sbin/route add -net 192.168.10.0/24 gw 192.168.1.2
pre-down /sbin/route del -net 192.168.10.0/24
iface br0 inet6 static
address 2001:7a8:a8ed:1::1
netmask 64
post-up /sbin/route -A inet6 add 2001:7a8:a8ed:10::/64 gw
2001:7a8:a8ed:1::2
pre-down /sbin/route -A inet6 del 2001:7a8:a8ed:10::/64 gw
2001:7a8:a8ed:1::2
J'avoue que je ne comprends pas bien. Pourquoi br0 prend-elle la bonne
adresse IPv6 sans prendre la route associée ? Il suffit en effet que je
lance à la main :
/sbin/route -A inet6 add 2001:7a8:a8ed:10::/64 gw 2001:7a8:a8ed:1::2
pour que le routage IPv6 fonctionne à nouveau.
Le serveur est un Linux debian/testing, le client est un NetBSD (côté
NetBSD aucun problème de ce genre, le routage IPv6 est persistant).
Toute idée sera la bienvenue.

Bonjour,
j'ai eu un problème au démarrage/sortie hibernation ou sysctl
n'appliquait pas les règles ipv6. Mon post-up dans interfaces lance un
sctipt dans if-up.d dans lequel entre autres j'active sysctl par "sysctl
-p 1>&2>/dev/null" J'adapte également la mtu à 1492 ayant également eu
des soucis sans cette adaptation.
Ubuntu 16.04 tout comme Debian 9
--
Daniel
Avatar
BERTRAND Jo=c3=abl
Daniel Huhardeaux a écrit :
Bonjour,
j'ai eu un problème au démarrage/sortie hibernation ou sysctl
n'appliquait pas les règles ipv6. Mon post-up dans interfaces lance un
sctipt dans if-up.d dans lequel entre autres j'active sysctl par "sysctl
-p 1>&2>/dev/null" J'adapte également la mtu à 1492 ayant également eu
des soucis sans cette adaptation.

Je ne saisis pas bien la réponse. Dans mon cas, l'adresse IPv6 est bien
prise. Ce sont les scripts qui ne se lancent pas.
Sep 4 05:35:27 rayleigh avahi-daemon[1350]: Joining mDNS multicast
group on interface br0.IPv6 with address 2001:7a8:a8ed:1::1.
Sep 4 05:35:27 rayleigh avahi-daemon[1350]: New relevant interface
br0.IPv6 for mDNS.
Sep 4 05:35:27 rayleigh avahi-daemon[1350]: Registering new address
record for 2001:7a8:a8ed:1::1 on br0.*.
Sep 4 05:35:27 rayleigh systemd[1]: NetworkManager-dispatcher.service:
Succeeded.
Sep 4 05:35:33 rayleigh ifup[1368]: Waiting for DAD... Timed out
Sep 4 05:35:33 rayleigh ifup[1368]: ifup: failed to bring up br0
Sep 4 05:35:33 rayleigh systemd[1]: networking.service: Main process
exited, code=exited, status=1/FAILURE
Sep 4 05:35:33 rayleigh systemd[1]: networking.service: Failed with
result 'exit-code'.
Root rayleigh:[/var/log] > systemctl status networking.service
● networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled;
vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2019-09-04 05:35:33
CEST; 4h 29min ago
Docs: man:interfaces(5)
Process: 1368 ExecStart=/sbin/ifup -a --read-environment (code=exited,
status=1/FAILURE)
Main PID: 1368 (code=exited, status=1/FAILURE)
sept. 04 05:35:16 rayleigh ifup[1368]: Cannot find device "tap1"
sept. 04 05:35:16 rayleigh ifup[1368]: interface tap1 does not exist!
sept. 04 05:35:16 rayleigh ifup[1368]: Cannot find device "tap2"
sept. 04 05:35:16 rayleigh ifup[1368]: interface tap2 does not exist!
sept. 04 05:35:17 rayleigh ifup[1368]: Waiting for br0 to get ready
(MAXWAIT is 32 seconds).
sept. 04 05:35:33 rayleigh ifup[1368]: Waiting for DAD... Timed out
sept. 04 05:35:33 rayleigh ifup[1368]: ifup: failed to bring up br0
sept. 04 05:35:33 rayleigh systemd[1]: networking.service: Main process
exited, code=exited, status=1/FAILURE
sept. 04 05:35:33 rayleigh systemd[1]: networking.service: Failed with
result 'exit-code'.
sept. 04 05:35:33 rayleigh systemd[1]: Failed to start Raise network
interfaces.
tap1 et tap2 n'existent pas encore (il faut du temps pour qu'ils
montent). Mais visiblement, ce qui ne lui plaît pas, c'est "Waiting for
DAD... Timed out". Or je suis en adressage IPv6 _statique_. Je ne vois
pas trop ce que les paquets DAD viennnt faire ici.
JKB
Avatar
Daniel Huhardeaux
Le 04/09/2019 à 10:06, BERTRAND Joël a écrit :
Daniel Huhardeaux a écrit :
Bonjour,
j'ai eu un problème au démarrage/sortie hibernation ou sysctl
n'appliquait pas les règles ipv6. Mon post-up dans interfaces lance un
sctipt dans if-up.d dans lequel entre autres j'active sysctl par "sysctl
-p 1>&2>/dev/null" J'adapte également la mtu à 1492 ayant également eu
des soucis sans cette adaptation.

Je ne saisis pas bien la réponse. Dans mon cas, l'adresse IPv6 est bien
prise. Ce sont les scripts qui ne se lancent pas.

Dans mon cas également l'adresse ipv6 était prise: c'est la gw par
défaut qui ne l'était pas. En lançant manuellement c'était tout bon,
comme toi.
Tu as bien
net.ipv6.conf.lo.disable_ipv6 = 0
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
dans sysctl.conf ?
Sep 4 05:35:27 rayleigh avahi-daemon[1350]: Joining mDNS multicast
group on interface br0.IPv6 with address 2001:7a8:a8ed:1::1.
Sep 4 05:35:27 rayleigh avahi-daemon[1350]: New relevant interface
br0.IPv6 for mDNS.
Sep 4 05:35:27 rayleigh avahi-daemon[1350]: Registering new address
record for 2001:7a8:a8ed:1::1 on br0.*.
Sep 4 05:35:27 rayleigh systemd[1]: NetworkManager-dispatcher.service:
Succeeded.
Sep 4 05:35:33 rayleigh ifup[1368]: Waiting for DAD... Timed out
Sep 4 05:35:33 rayleigh ifup[1368]: ifup: failed to bring up br0
Sep 4 05:35:33 rayleigh systemd[1]: networking.service: Main process
exited, code=exited, status=1/FAILURE
Sep 4 05:35:33 rayleigh systemd[1]: networking.service: Failed with
result 'exit-code'.
Root rayleigh:[/var/log] > systemctl status networking.service
● networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled;
vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2019-09-04 05:35:33
CEST; 4h 29min ago
Docs: man:interfaces(5)
Process: 1368 ExecStart=/sbin/ifup -a --read-environment (code=exited,
status=1/FAILURE)
Main PID: 1368 (code=exited, status=1/FAILURE)
sept. 04 05:35:16 rayleigh ifup[1368]: Cannot find device "tap1"
sept. 04 05:35:16 rayleigh ifup[1368]: interface tap1 does not exist!
sept. 04 05:35:16 rayleigh ifup[1368]: Cannot find device "tap2"
sept. 04 05:35:16 rayleigh ifup[1368]: interface tap2 does not exist!
sept. 04 05:35:17 rayleigh ifup[1368]: Waiting for br0 to get ready
(MAXWAIT is 32 seconds).
sept. 04 05:35:33 rayleigh ifup[1368]: Waiting for DAD... Timed out
sept. 04 05:35:33 rayleigh ifup[1368]: ifup: failed to bring up br0
sept. 04 05:35:33 rayleigh systemd[1]: networking.service: Main process
exited, code=exited, status=1/FAILURE
sept. 04 05:35:33 rayleigh systemd[1]: networking.service: Failed with
result 'exit-code'.
sept. 04 05:35:33 rayleigh systemd[1]: Failed to start Raise network
interfaces.
tap1 et tap2 n'existent pas encore (il faut du temps pour qu'ils
montent). Mais visiblement, ce qui ne lui plaît pas, c'est "Waiting for
DAD... Timed out". Or je suis en adressage IPv6 _statique_. Je ne vois
pas trop ce que les paquets DAD viennnt faire ici.
JKB

--
Daniel Huhardeaux
+ sip:
+ tootaiNET
Avatar
Pascal Hambourg
Le 04/09/2019 à 10:06, BERTRAND Joël a écrit :
sept. 04 05:35:16 rayleigh ifup[1368]: Cannot find device "tap1"
sept. 04 05:35:16 rayleigh ifup[1368]: interface tap1 does not exist!
sept. 04 05:35:16 rayleigh ifup[1368]: Cannot find device "tap2"
sept. 04 05:35:16 rayleigh ifup[1368]: interface tap2 does not exist!
sept. 04 05:35:17 rayleigh ifup[1368]: Waiting for br0 to get ready
(MAXWAIT is 32 seconds).
sept. 04 05:35:33 rayleigh ifup[1368]: Waiting for DAD... Timed out
sept. 04 05:35:33 rayleigh ifup[1368]: ifup: failed to bring up br0
sept. 04 05:35:33 rayleigh systemd[1]: networking.service: Main process
exited, code=exited, status=1/FAILURE
sept. 04 05:35:33 rayleigh systemd[1]: networking.service: Failed with
result 'exit-code'.
sept. 04 05:35:33 rayleigh systemd[1]: Failed to start Raise network
interfaces.
tap1 et tap2 n'existent pas encore (il faut du temps pour qu'ils
montent).

Déjà, ça ce n'est pas terrible. A mon avis les ports ne devraient pas
être spécifiés s'ils n'existent pas à la création du pont.
Mais visiblement, ce qui ne lui plaît pas, c'est "Waiting for
DAD... Timed out". Or je suis en adressage IPv6 _statique_. Je ne vois
pas trop ce que les paquets DAD viennnt faire ici.

Pourquoi la DAD ne s'appliquerait-elle pas en statique ?
Si le problème vient de la DAD tu peux essayer de la désactiver avec
dad-attemps 0
Avatar
BERTRAND Jo=c3=abl
Pascal Hambourg a écrit :
Le 04/09/2019 à 10:06, BERTRAND Joël a écrit :
sept. 04 05:35:16 rayleigh ifup[1368]: Cannot find device "tap1"
sept. 04 05:35:16 rayleigh ifup[1368]: interface tap1 does not exist!
sept. 04 05:35:16 rayleigh ifup[1368]: Cannot find device "tap2"
sept. 04 05:35:16 rayleigh ifup[1368]: interface tap2 does not exist!
sept. 04 05:35:17 rayleigh ifup[1368]: Waiting for br0 to get ready
(MAXWAIT is 32 seconds).
sept. 04 05:35:33 rayleigh ifup[1368]: Waiting for DAD... Timed out
sept. 04 05:35:33 rayleigh ifup[1368]: ifup: failed to bring up br0
sept. 04 05:35:33 rayleigh systemd[1]: networking.service: Main process
exited, code=exited, status=1/FAILURE
sept. 04 05:35:33 rayleigh systemd[1]: networking.service: Failed with
result 'exit-code'.
sept. 04 05:35:33 rayleigh systemd[1]: Failed to start Raise network
interfaces.
tap1 et tap2 n'existent pas encore (il faut du temps pour qu'ils
montent).

Déjà, ça ce n'est pas terrible. A mon avis les ports ne devraient pas
être spécifiés s'ils n'existent pas à la création du pont.

Je sais que ce n'est pas terrible. Mais c'est la seule solution que
j'ai trouvé pour éviter les grosses grouilles en cas de démontage et
remontage de tap1 ou tap2. À l'autre bout, j'ai un FAI du type "internet
pour les ploucs" et j'ai bien essayé de faire avec les scripts openvpn
sans succès. Dans certains cas, je me retrouvais avec des routes en
double, bref, un truc pas fiable.
J'ai _aussi_ essayé de faire avec systemd, en lui demandant de ne créer
br0 que lorsque tap1 et tap2 étaient déjà là. Ça eut fonctionné avec une
version de systemd mais depuis une mise à jour vers une nouvelle version
plus mieux de la bouse systemd, ça ne fonctionne plus correctement.
Mais visiblement, ce qui ne lui plaît pas, c'est "Waiting for
DAD... Timed out". Or je suis en adressage IPv6 _statique_. Je ne vois
pas trop ce que les paquets DAD viennnt faire ici.

Pourquoi la DAD ne s'appliquerait-elle pas en statique ?

Parce que je pense que je suis assez intelligent pour ne pas avoir
d'adresse dupliquée sur un sous réseau qui ne comporte que deux adresses
IPv6.
Si le problème vient de la DAD tu peux essayer de la désactiver avec
  dad-attemps 0

Directement dans le fichier interfaces ?
JKB
--
Dr. KACHELHOFFER-BERTRAND Joël
Systella SAS, 7, la Sudrie 19130 VIGNOLS FRANCE
Tel.: +33 (0)6 16 01 80 60 / +33 (0)9 73 87 02 01
http://www.systella.fr
Avatar
Pascal Hambourg
Le 04/09/2019 à 11:26, BERTRAND Joël a écrit :
Si le problème vient de la DAD tu peux essayer de la désactiver avec
  dad-attemps 0

Directement dans le fichier interfaces ?

Oui, dans la définition inet6 de br0. Cf. man interfaces.
Avatar
BERTRAND Jo=c3=abl
Daniel Huhardeaux a écrit :
Le 04/09/2019 à 10:06, BERTRAND Joël a écrit :
Daniel Huhardeaux a écrit :
Bonjour,
j'ai eu un problème au démarrage/sortie hibernation ou sysctl
n'appliquait pas les règles ipv6. Mon post-up dans interfaces lance un
sctipt dans if-up.d dans lequel entre autres j'active sysctl par "sysctl
-p 1>&2>/dev/null" J'adapte également la mtu à 1492 ayant également eu
des soucis sans cette adaptation.

    Je ne saisis pas bien la réponse. Dans mon cas, l'adresse IPv6 est
bien
prise. Ce sont les scripts qui ne se lancent pas.

Dans mon cas également l'adresse ipv6 était prise: c'est la gw par
défaut qui ne l'était pas. En lançant manuellement c'était tout bon,
comme toi.
Tu as bien
net.ipv6.conf.lo.disable_ipv6 = 0
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
dans sysctl.conf ?

Root rayleigh:[~] > sysctl -a | grep ipv6 | grep disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.br0.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.eth1.disable_ipv6 = 0
net.ipv6.conf.eth2.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0
net.ipv6.conf.tap0.disable_ipv6 = 0
net.ipv6.conf.tap1.disable_ipv6 = 1
net.ipv6.conf.tap2.disable_ipv6 = 1
Je me demande bien d'où proviennent les deux dernières lignes,
d'ailleurs...
JKB
Avatar
Pascal Hambourg
Le 04/09/2019 à 11:21, BERTRAND Joël a écrit :
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.br0.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.eth1.disable_ipv6 = 0
net.ipv6.conf.eth2.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0
net.ipv6.conf.tap0.disable_ipv6 = 0
net.ipv6.conf.tap1.disable_ipv6 = 1
net.ipv6.conf.tap2.disable_ipv6 = 1
Je me demande bien d'où proviennent les deux dernières lignes,
d'ailleurs...

Peut-être du pontage, pour éviter que les interfaces membres d'un pont
se ramassent des adresses IPv6 (link local ou autoconf).
Avatar
MAS Jean-Louis
This is a cryptographically signed message in MIME format.
--------------ms050402090205050503030606
Content-Type: text/plain; charset=utf-8
Content-Language: fr
Content-Transfer-Encoding: quoted-printable
Le 04/09/2019 à 10:06, BERTRAND Joël a écrit :
tap1 et tap2 n'existent pas encore (il faut du temps pour qu'ils
montent). Mais visiblement, ce qui ne lui plaît pas, c'est "Waitin g for
DAD... Timed out". Or je suis en adressage IPv6 _statique_. Je ne vois
pas trop ce que les paquets DAD viennnt faire ici.

J'ai un gag similaire tout récemment avec Debian 10 avec samba et le DAD
qui comme toi empêche le service de redémarrer.
Peut être est-ce lié à ce bug qui est réapparu :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bugp5996
Personnellement je l'ai solutionné en ajoutant une ligne dans l'unit
systemd du service
ExecStartPre=/bin/sleep 3.
La solution proposée par Pascal me parait beaucoup plus propre.
Néanmoins, je vois que je pourrais a la place désactiver le DAD sur ces
serveurs spécifiquement avec la commande temporaire
echo 0 > /proc/sys/net/ipv6/conf/all/accept_dad
Ou avec une ligne dans un fichier de configuration sysctl.d
net.ipv6.conf.all.accept_dad=0
Sachant que comme toi je suis en IPv6 fixe et que l'autoconf et le ra
sont désactivés
Des objections ou des remarques ?
Cordialement
--
Jean Louis Mas
--------------ms050402090205050503030606
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Signature cryptographique S/MIME
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
Cj8wggUAMIID6KADAgECAhADS+4XH7fhBjcv1HJCQL0qMA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgx
MjAwMDBaFw0yNDExMTgxMjAwMDBaMGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1I
b2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMU
VEVSRU5BIFBlcnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG
pbsfVYL0pTRyFHJlm1/V6qBo2JuCiU9TYpx7jM4O2tQyDq8bjMum69vg6wM0lMGHflMgqB75
GxeKfQFmEldoXi2cLishqFUvU2cJeM3SaRsLk2BsuCgTzh9NsYgmrUX60KHOq7eYKVZxbPFW
JF2nMOBuMXNu2qBXTGSLeLXHnNvG3r7TLzGg1oA5teAxQE6Eo8ySSeIXbP7wZB76urwlh51P
IbrJZjkDjdQVELh7OlTP1WO6T/Hf6BsEfeFcpoa1e+MW/lw0VetTPPHQ15HYKYP2WYohHxzD
iC+QUwE7UZVBlp9cXIpwHuDzSibc5RG3z0n/j2SQCx0Dk5FMAUErAgMBAAGjggGmMIIBojAS
BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjB5BggrBgEFBQcBAQRtMGswJAYI
KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDov
L2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYD
VR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl
ZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYc
aHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQU8CHpSXdzn4WuGDvoUnAU
Bu1C7sowHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQAD
ggEBADrCGyv+Y967YbS5R6j8fAWxJiAiUZvIPfn1xVgesF6jspwCQY8xGn/MG04d+Jh97I8I
/Xfx29JEEFq2rQmw4PxiO9RiDZ7xoDxNd4rrRDR7jrtOKQP8J+o+ah0vSOP62hnD/zPS7NRM
tIyVS2G277KAL5fIR62ngr984fmJghDv0bsjGAmeu3EP0xhUsDJT61IoAGoKBnxBPAeg3WXs
dSm4Gn7btyvakeyFtYebr2KmOBSa28PRqGSDur56aZhJoM2eMzc6prmvGwwtAzRsc5t2OsKR
uHWV6O3anP2K27jGZR2bi1VX1NQUvIbpVNTuwjm+XcZtsa/AAJF9KGkEseAwggU3MIIEH6AD
AgECAhAJLazAihvRT4gRT5kBJfvdMA0GCSqGSIb3DQEBCwUAMGkxCzAJBgNVBAYTAk5MMRYw
FAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRF
UkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENBIDMwHhcNMTgxMTMwMDAwMDAwWhcN
MjExMTMwMTIwMDAwWjBtMQswCQYDVQQGEwJGUjEOMAwGA1UEBxMFUGFyaXMxNTAzBgNVBAoT
LENlbnRyZSBuYXRpb25hbCBkZSBsYSByZWNoZXJjaGUgc2NpZW50aWZpcXVlMRcwFQYDVQQD
Ew5NQVMgSmVhbi1Mb3VpczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKray44/
bExLT16aJr2/lzn89NyAKWKxGrvfkuW6Qxgp+icCm3lruzCFTNT2J00+iZObGPj5KhA3hMUK
m3JeSv6BOHPzaQjWm+6XozCnYHZ4Yd92LED3cPCNvoEFjd/AyVG6aiu0DbHlf4XOibf2Fglt
9mIQGI3iXQQf2A3db2tkvRyPtRgVW9Pg2lYvtgQV9FczcZZE+TKQF9ygNNy6I2jiYndi4N8r
GgG60FhjU+H6bMeIdqcXVhSv1cyZpvj5HdZZK6F0BbSQevVZIWerrjVIdgFyT2J84XXJRBvP
GDz+SRk4kQ+gc0WIzJ+Cu277YL3NEDKWrqBvmhtqqpztN60CAwEAAaOCAdUwggHRMB8GA1Ud
IwQYMBaAFPAh6Ul3c5+Frhg76FJwFAbtQu7KMB0GA1UdDgQWBBS9Epfbejv9ixMzA3ElS1+y
OJ5r1jAMBgNVHRMBAf8EAjAAMCEGA1UdEQQaMBiBFmplYW4tbG91aXMubWFzQGltYWcuZnIw
DgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAE
PDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQu
Y29tL0NQUzB1BgNVHR8EbjBsMDSgMqAwhi5odHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVEVS
RU5BUGVyc29uYWxDQTMuY3JsMDSgMqAwhi5odHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVEVS
RU5BUGVyc29uYWxDQTMuY3JsMHMGCCsGAQUFBwEBBGcwZTAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuZGlnaWNlcnQuY29tMD0GCCsGAQUFBzAChjFodHRwOi8vY2FjZXJ0cy5kaWdpY2Vy
dC5jb20vVEVSRU5BUGVyc29uYWxDQTMuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBjYBHOfV87
yWCHnwgzlR+B6dGWv1dFPXNRY0kiUxW4XvIqOY+lDxoClRpr7CvFRBOt/Vs2rprXYqZGXDxp
hyBLH/QJi8yeLGJIQ+8rX80u7iq6DX7vs5iWILrq8R7YV0W9U3bOVbLDQ+jPzpmVUVvdkowq
UpuIvDjD7KWL+NEaMuRoQy8RHSoyf9Ds/sjMOedpYXho4ds6QiA8zlyBxW883jVoDBYWg+VG
6uThIkS/AIP1ZuaKbSrLvR+GiYpGWtkKwUpt8JfAaI8gWpsY4avmk2BH2He4WznnI27qPBLT
8QaMTJlpfo8efjqAdNwURXt3g+LlX3cJN0R1W3e6P0hrMYIDozCCA58CAQEwfTBpMQswCQYD
VQQGEwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMQ8w
DQYDVQQKEwZURVJFTkExHTAbBgNVBAMTFFRFUkVOQSBQZXJzb25hbCBDQSAzAhAJLazAihvR
T4gRT5kBJfvdMA0GCWCGSAFlAwQCAQUAoIIB9zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0xOTA5MDYxMjIzMjVaMC8GCSqGSIb3DQEJBDEiBCCvU0saw7ev
FLQkkwmA9L0pd8/nnVJH6Y2inJ6Cz5jhvDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB
KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGMBgkrBgEEAYI3EAQxfzB9MGkxCzAJBgNV
BAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzAN
BgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENBIDMCEAktrMCKG9FP
iBFPmQEl+90wgY4GCyqGSIb3DQEJEAILMX+gfTBpMQswCQYDVQQGEwJOTDEWMBQGA1UECBMN
Tm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZURVJFTkExHTAb
BgNVBAMTFFRFUkVOQSBQZXJzb25hbCBDQSAzAhAJLazAihvRT4gRT5kBJfvdMA0GCSqGSIb3
DQEBAQUABIIBAEvXIwyjkEfpXKPEAfq0j/+3GF8G8e4uMfsvhMziciPpFe4iTu0vTO6sA6i9
7aAOyk9bRY85Renrf91jyR0VYzIx0WDrHJN9IyD+4emsFvuES0yihrnipQiGmTmeAJTveO+f
9mPxIpTOOldMZHoDiDrlToYfi4+tpJ885OB5gkFJKIsC5aAGxIFjaoV+VucgXcc9dsB6zx3U
SPMtoqQFjQMN6Htv49zjgQfCGOQ6MGx6+yvXYXR2R/ESazewlTIeRr2p9A+IL2XH1eKFMm3K
oZ8tWZn6Kbtpx2dSbmKJvpe7zVAf5A0CBOkSDqTuLrYZ3+TzpfS9UN5Nn+CaBjUGryQAAAAA
AAA --------------ms050402090205050503030606--
Avatar
BERTRAND Jo=c3=abl
MAS Jean-Louis a écrit :
Le 04/09/2019 à 10:06, BERTRAND Joël a écrit :
tap1 et tap2 n'existent pas encore (il faut du temps pour qu'ils
montent). Mais visiblement, ce qui ne lui plaît pas, c'est "Waiting for
DAD... Timed out". Or je suis en adressage IPv6 _statique_. Je ne vois
pas trop ce que les paquets DAD viennnt faire ici.

J'ai un gag similaire tout récemment avec Debian 10 avec samba et le DAD
qui comme toi empêche le service de redémarrer.
Peut être est-ce lié à ce bug qui est réapparu :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bugp5996
Personnellement je l'ai solutionné en ajoutant une ligne dans l'unit
systemd du service
ExecStartPre=/bin/sleep 3.

De quel service ?
La solution proposée par Pascal me parait beaucoup plus propre.

Je viens de m'apercevoir qu'elle ne fonctionne malheureusement pas.
Néanmoins, je vois que je pourrais a la place désactiver le DAD sur ces
serveurs spécifiquement avec la commande temporaire
echo 0 > /proc/sys/net/ipv6/conf/all/accept_dad
Ou avec une ligne dans un fichier de configuration sysctl.d
net.ipv6.conf.all.accept_dad=0

Je vais essayer de forcer cela sur br0.
Sachant que comme toi je suis en IPv6 fixe et que l'autoconf et le ra
sont désactivés
Des objections ou des remarques ?

Pas encore, mais ce problème risque d'être rigolo à corriger...
JKB
1 2