La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: vivien le 11 mars 2018 à 11:42:45
-
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
Édit cause : Ubuntu serveur utilise l'IPv6 HS du RA (Router Advertisement), à la place de celle indiquée dans /etc/network/interfaces
J'ai un problème vraiment étranges sur tous mes serveurs avec plusieurs plages IPv4 / IPv6 : Après un reboot j'ai environ 10% de chance de ne pas avoir d'IPv6, car la gateway IPv6 se change en fe80::2a52:61ff:fed7:84c2
En PIv6, fe80 c'est une adresse locale, un peu comme 192.168.0.0/24 en IPv4.
J'ai pourtant mis en place un fichier pour éviter ça:
nano /etc/sysctl.d/19-patch-ipv6.conf
# Ignorer les paquets Router Advertisement si IPv6 configuré manuellement
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.accept_dad = 0
Les serveurs ont tous une configuration assez simple avec une seule interface 10 Gb/s (carte réseau Intel X710 for 10GbE SFP+) qui porte les différentes IPv4 et IPv6.
Voici /etc/network/interfaces d'un serveur SpeedTest (le dossier /etc/network/interfaces.d/ est vide). Il y a :
- une plage IPv4 (89.84.1.200/29) qui est utilisée pour une IPv4 unicast.
- une plage IPv6 (2001:860:DE01:1102::/64) qui est utilisée pour deux IPv6 unicast.
- une seconde plage IPv4 (89.84.1.228/30) qui est utilisée par une IPv4 anycast.
- une seconde plage IPv6 (2001:860:DEFF:1002::/64) qui est utilisée pour une IPv6 anycast.
Les IP anycast sont utilisées par d'autres serveurs situées dans d'autres villes: C'est le réseau qui route vers le serveur le plus proche.[/size]
# cat
# 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
# Interface 10Gb/s
auto enp1s0f0
# IPv4v6 unicast N°1 :
iface enp1s0f0 inet static
address 89.84.1.202
netmask 255.255.255.248
gateway 89.84.1.201
iface enp1s0f0 inet6 static
address 2001:860:de01:1102::2
netmask 64
gateway 2001:860:de01:1102::1
dns-nameservers 2001:860:b0ff:1::1 2001:860:b0ff:1::2
# IPv6 unicast N°2 :
pre-up ip -6 addr add 2001:860:de01:1102::3/64 dev $IFACE preferred_lft 0
down ip -6 addr del 2001:860:de01:1102::3/64 dev $IFACE preferred_lft 0
# IPv4v6 Anycast :
pre-up ip addr add 89.84.1.230/30 dev $IFACE label $IFACE:0
down ip addr del 89.84.1.230/30 dev $IFACE label $IFACE:0
pre-up ip -6 addr add 2001:860:deff:1002::2/64 dev $IFACE preferred_lft 0
down ip -6 addr del 2001:860:deff:1002::2/64 dev $IFACE preferred_lft 0
Cas où IPv6 est fonctionne après un reboot :
Voici ce que l'on a quand l'IPv6 est fonctionnel après un reboot (c'est le cas dans 90% des reboot) : On note le Next Hop 2001:860:de01:1102::1 qui correspond à ma configuration.
$ route -6
Table de routage IPv6 du noyau
Destination Next Hop Flag Met Ref Use If
2001:860:de01:1102::/64 :: U 256 2 1 enp1s0f0
2001:860:deff:1002::/64 :: U 256 1 0 enp1s0f0
fe80::/64 :: U 256 1 0 enp1s0f0
::/0 2001:860:de01:1102::1 UG 1024 8 485 enp1s0f0
::/0 :: !n -1 1 488 lo
::1/128 :: Un 0 9 56 lo
2001:860:de01:1102::2/128 :: Un 0 10 121 lo
2001:860:de01:1102::3/128 :: Un 0 2 0 lo
2001:860:deff:1002::2/128 :: Un 0 9 145 lo
fe80::3efd:feff:fe1d:8f00/128 :: Un 0 4 5 lo
ff00::/8 :: U 256 3 7 enp1s0f0
::/0 :: !n -1 1 488 lo
$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:860:de01:1102::2/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:860:deff:1002::2/64 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 2001:860:de01:1102::3/64 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 fe80::3efd:feff:fe1d:8f00/64 scope link
valid_lft forever preferred_lft forever
Cas où IPv6 est HS après un reboot :
Voici ce que l'on a quand l'IPv6 est HS après un reboot (c'est le cas dans 10% des reboot) : On note le Next Hop fe80::2a52:61ff:fed7:84c2 qui explique pourquoi nous n'avons pas de connectivité IPv6.
On note la présence d'une IPv6 dynamique alors que ce n'est nullement demandé dans ma configuration.
$ route -6
Table de routage IPv6 du noyau
Destination Next Hop Flag Met Ref Use If
2001:860:de01:1102::/64 :: UA 256 2 1 enp1s0f0
2001:860:deff:1002::/64 :: U 256 1 0 enp1s0f0
fe80::/64 :: U 256 1 0 enp1s0f0
::/0 fe80::2a52:61ff:fed7:84c2 UGDAe 1024 8 557 enp1s0f0
::/0 :: !n -1 1 557 lo
::1/128 :: Un 0 9 62 lo
2001:860:de01:1102::2/128 :: Un 0 9 108 lo
2001:860:de01:1102:3efd:feff:fe1d:8f00/128 :: Un 0 2 0 lo
2001:860:de01:1102::3/128 :: Un 0 2 0 lo
2001:860:deff:1002::2/128 :: Un 0 9 139 lo
fe80::3efd:feff:fe1d:8f00/128 :: Un 0 4 8 lo
ff00::/8 :: U 256 3 8 enp1s0f0
::/0 :: !n -1 1 557 lo
$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
4: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:860:de01:1102::2/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:860:deff:1002::2/64 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 2001:860:de01:1102::3/64 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 2001:860:de01:1102:3efd:feff:fe1d:8f00/64 scope global mngtmpaddr dynamic
valid_lft 2591700sec preferred_lft 604500sec
inet6 fe80::3efd:feff:fe1d:8f00/64 scope link
valid_lft forever preferred_lft forever
C'est donc toutes les IPv6 qui sont HS après le reboot vu que je n'ai spécifié qu'une seule Gateway.
Je ne sais pas depuis quand ce problème est présent, mais je m'en aperçois clairement maintenant à cause des reboot réguliers nécessaires pour le bug Fuite mémoire avec le kernel 4.13 sous Ubuntu 16.04 LTS (https://lafibre.info/serveur-linux/fuite-memoire/).
Si vous avez une piste de solution, je suis preneur.
IPv4 :
Voici les infos en IPv4 si cela peut aider : IPv4 fonctionne toujours :
$ route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default 89.84.1.201 0.0.0.0 UG 0 0 0 enp1s0f0
89.84.1.200 * 255.255.255.248 U 0 0 0 enp1s0f0
89.84.1.228 * 255.255.255.252 U 0 0 0 enp1s0f0
$ ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
4: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq portid 3cfdfe1d8f00 state UP group default qlen 1000
inet 89.84.1.202/29 brd 89.84.1.207 scope global enp1s0f0
valid_lft forever preferred_lft forever
inet 89.84.1.230/30 scope global enp1s0f0:0
valid_lft forever preferred_lft forever
-
Tu as surement des RA sur le réseau.
Cadeau :p
hugues@hubble:~$ cat /etc/sysctl.d/19-patch-for-shitty-ipv6.conf
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.accept_dad = 0
net.ipv6.conf.ens18.autoconf = 0
net.ipv6.conf.ens18.accept_ra = 0
net.ipv6.conf.ens18.accept_dad = 0
-
Merci, j'étais persuadé qu'il n'y avait d'autoconf quand on a tout spécifié a la main.
Le fait que cela se produise rarement (quand il reçois le paquet RA avant d'avoir mis la conf je suppose) est assez pernicieux.
Petite question pour tes lignes, cela me semble redondant.
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_dad = 0
n'est pas suffisant ?
Il faut en plus mettre le faire pour chaque interface ?
-
Fort probable, dans le doute, j'en fous 15, ça m'a tellement gavé ce truc.
-
Je pense que tu viens de me résoudre un autre problème que j'avais avec des IP qui n'étaient encore pas configurées alors que Apache démarrait et refuser de démarrer car il ne pouvait pas écouter sur les IP spécifiées dans sa conf :
DAD is fast, but not always fast enough. Since services like Apache are started soon after networking is configured on system boot, there is a race condition. Sometimes your critical services start on boot, and sometimes they don't! This is clearly not acceptable behavior for a production server.
Source : Beware the IPv6 DAD Race Condition (https://www.agwa.name/blog/post/beware_the_ipv6_dad_race_condition)
C'est pour cette raison que j'ai mis des "pre-up" car un "up" ne permettait pas d'avoir toutes les IP configurées au lancement d'Apache2.
-
Tant mieux ;D
J'ai passé quelques mois a devoir remettre les IP a chaque redémarrage de mes VM à la maison.
Parce que moi ca remplaçait ma gateway, certes. Mais ça me virait les IPv6, et ça c'était d'un chiant...
J'ai toujours le souci chez Online, où les RA sont obligatoires. Du coup je mets un post-up avec un "ip addr add"...
-
J'ai toujours le souci chez Online, où les RA sont obligatoires. Du coup je mets un post-up avec un "ip addr add"...
Chez Online, si tu n'utilises pas les RA et que tu définies tes IPv6 à la main, elles ne sont pas joignables ?
-
Ben, t'as pas de gateway sans RA, déjà.
Il faut un DHClient bien configuré, qui renouvelle régulièrement mais pas trop non plus... Une misère.
-
Petite question pour tes lignes, cela me semble redondant.
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_dad = 0
n'est pas suffisant ?
Il faut en plus mettre le faire pour chaque interface ?
Fort probable, dans le doute, j'en fous 15, ça m'a tellement gavé ce truc.
Voici ce que cela donne en ne mettant que "all" : cela n'a modifié l’état que des lignes en rouge.
Je me demande si cela ne sert à rien ou si c'est entièrement désactivé.
# sysctl -a |grep autoconf
sysctl: lecture de la clé « net.ipv6.conf.all.stable_secret »
net.ipv6.conf.all.autoconf = 0
sysctl: lecture de la clé « net.ipv6.conf.default.stable_secret »
net.ipv6.conf.default.autoconf = 1
sysctl: lecture de la clé « net.ipv6.conf.eno1.stable_secret »
net.ipv6.conf.eno1.autoconf = 1
sysctl: lecture de la clé « net.ipv6.conf.eno2.stable_secret »
net.ipv6.conf.eno2.autoconf = 1
sysctl: lecture de la clé « net.ipv6.conf.enp2s0f0.stable_secret »
net.ipv6.conf.enp2s0f0.autoconf = 0
sysctl: lecture de la clé « net.ipv6.conf.enp2s0f1.stable_secret »
net.ipv6.conf.enp2s0f1.autoconf = 1
sysctl: lecture de la clé « net.ipv6.conf.lo.stable_secret »
net.ipv6.conf.lo.autoconf = 1
# sysctl -a |grep "accept_ra "
sysctl: lecture de la clé « net.ipv6.conf.all.stable_secret »
net.ipv6.conf.all.accept_ra = 0
sysctl: lecture de la clé « net.ipv6.conf.default.stable_secret »
net.ipv6.conf.default.accept_ra = 1
sysctl: lecture de la clé « net.ipv6.conf.eno1.stable_secret »
net.ipv6.conf.eno1.accept_ra = 1
sysctl: lecture de la clé « net.ipv6.conf.eno2.stable_secret »
net.ipv6.conf.eno2.accept_ra = 1
sysctl: lecture de la clé « net.ipv6.conf.enp2s0f0.stable_secret »
net.ipv6.conf.enp2s0f0.accept_ra = 0
sysctl: lecture de la clé « net.ipv6.conf.enp2s0f1.stable_secret »
net.ipv6.conf.enp2s0f1.accept_ra = 1
sysctl: lecture de la clé « net.ipv6.conf.lo.stable_secret »
net.ipv6.conf.lo.accept_ra = 1
# sysctl -a |grep accept_dad
sysctl: lecture de la clé « net.ipv6.conf.all.stable_secret »
net.ipv6.conf.all.accept_dad = 0
sysctl: lecture de la clé « net.ipv6.conf.default.stable_secret »
net.ipv6.conf.default.accept_dad = 1
sysctl: lecture de la clé « net.ipv6.conf.eno1.stable_secret »
net.ipv6.conf.eno1.accept_dad = 1
sysctl: lecture de la clé « net.ipv6.conf.eno2.stable_secret »
net.ipv6.conf.eno2.accept_dad = 1
sysctl: lecture de la clé « net.ipv6.conf.enp2s0f0.stable_secret »
net.ipv6.conf.enp2s0f0.accept_dad = 1
sysctl: lecture de la clé « net.ipv6.conf.enp2s0f1.stable_secret »
net.ipv6.conf.enp2s0f1.accept_dad = 1
sysctl: lecture de la clé « net.ipv6.conf.lo.stable_secret »
net.ipv6.conf.lo.accept_dad = -1
-
C'était peut-être pour ça que j'ai mis les trois, finalement ;D
-
La doc dit :
- all => the variable for all interfaces and default will be changed as well
- default => all future interfaces will have the value you specify. This should only affect machines that can add interfaces at run time, such as laptops with PCMCIA cards, or machines that create new interfaces via VPNs or PPP, for example.
Je vais tenter quelques semaines avec :
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.accept_dad = 0C'est mis en place sur 8 serveurs.
Je vous ferais un retour si cela suffit. (mettre le nom de chaque interface complique la conf d'un serveur)
-
Tu peux aussi enquêter pour savoir pourquoi un device èmet ces RA sur ce LAN.
D'apres l'adresse gw link-local reçue c'est l'adresse MAC d'un routeur Cisco.
ps: tout ca pour dire que dans un environnement "controlé" c'est mieux de ne pas désactivé les accept_ra car ils servent a autre chose que la default gw. Apres si l'interface ethernet en question est sur LAN public/partagé la y'a pas photo faut accept_ra a 0.
-
C'est probablement l'équipement sur lequel il est connecté, un Cisco Nexus, qui est mal configuré.
-
Les cisco envoient automatiquement des RA. Il faut les désactiver explicitement...
-
La doc dit :
- all => the variable for all interfaces and default will be changed as well
- default => all future interfaces will have the value you specify. This should only affect machines that can add interfaces at run time, such as laptops with PCMCIA cards, or machines that create new interfaces via VPNs or PPP, for example.
Je vais tenter quelques semaines avec :
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.accept_dad = 0C'est mis en place sur 8 serveurs.
Je vous ferais un retour si cela suffit. (mettre le nom de chaque interface complique la conf d'un serveur)
Ce soir reboot, mais pas d'IPv6...
J'ai pourtant l'interface qui as net.ipv6.conf.enp1s0f0.autoconf = 0
Voici ce que j'ai relevé alors que la machine avait une route d'IPv6 bidon :
# sysctl -a |grep autoconf
sysctl: lecture de la clé « net.ipv6.conf.all.stable_secret »
net.ipv6.conf.all.autoconf = 0
sysctl: lecture de la clé « net.ipv6.conf.default.stable_secret »
net.ipv6.conf.default.autoconf = 0
sysctl: lecture de la clé « net.ipv6.conf.eno1.stable_secret »
net.ipv6.conf.eno1.autoconf = 1
sysctl: lecture de la clé « net.ipv6.conf.eno2.stable_secret »
net.ipv6.conf.eno2.autoconf = 1
sysctl: lecture de la clé « net.ipv6.conf.enp1s0f0.stable_secret »
net.ipv6.conf.enp1s0f0.autoconf = 0
sysctl: lecture de la clé « net.ipv6.conf.enp1s0f1.stable_secret »
net.ipv6.conf.enp1s0f1.autoconf = 1
sysctl: lecture de la clé « net.ipv6.conf.lo.stable_secret »
net.ipv6.conf.lo.autoconf = 1
# sysctl -a |grep "accept_ra "
sysctl: lecture de la clé « net.ipv6.conf.all.stable_secret »
net.ipv6.conf.all.accept_ra = 0
sysctl: lecture de la clé « net.ipv6.conf.default.stable_secret »
net.ipv6.conf.default.accept_ra = 0
sysctl: lecture de la clé « net.ipv6.conf.eno1.stable_secret »
net.ipv6.conf.eno1.accept_ra = 1
sysctl: lecture de la clé « net.ipv6.conf.eno2.stable_secret »
net.ipv6.conf.eno2.accept_ra = 1
sysctl: lecture de la clé « net.ipv6.conf.enp1s0f0.stable_secret »
net.ipv6.conf.enp1s0f0.accept_ra = 0
sysctl: lecture de la clé « net.ipv6.conf.enp1s0f1.stable_secret »
net.ipv6.conf.enp1s0f1.accept_ra = 1
sysctl: lecture de la clé « net.ipv6.conf.lo.stable_secret »
net.ipv6.conf.lo.accept_ra = 1
# sysctl -a |grep accept_dad
sysctl: lecture de la clé « net.ipv6.conf.all.stable_secret »
net.ipv6.conf.all.accept_dad = 0
sysctl: lecture de la clé « net.ipv6.conf.default.stable_secret »
net.ipv6.conf.default.accept_dad = 0
sysctl: lecture de la clé « net.ipv6.conf.eno1.stable_secret »
net.ipv6.conf.eno1.accept_dad = 1
sysctl: lecture de la clé « net.ipv6.conf.eno2.stable_secret »
net.ipv6.conf.eno2.accept_dad = 1
sysctl: lecture de la clé « net.ipv6.conf.enp1s0f0.stable_secret »
net.ipv6.conf.enp1s0f0.accept_dad = 1
sysctl: lecture de la clé « net.ipv6.conf.enp1s0f1.stable_secret »
net.ipv6.conf.enp1s0f1.accept_dad = 1
sysctl: lecture de la clé « net.ipv6.conf.lo.stable_secret »
net.ipv6.conf.lo.accept_dad = -1
SI vous avez une idée...
-
t'as toujours la route par défaut dynamique comme indiqué sur ton 1er poste ? (ie flags "UGDA" dans route -6 pour ::0)
cherche "ADDRCONF" dans les logs aussi pour voir.
-
Oui, on est bien dans le cas du 1er post.
Je ne trouve rien ADDRCONF dans kern.log ou syslog
-
pour le flag A indique que la route a été installée par ADDRCONF.
apres y'a peut-être des spécificités d'ubuntu concernant la séquence de boot et sysctl (ton "/etc/init.d/procps" est standard ?)
-
Oui, c'est un /etc/init.d/procps standard.
Sur mes PC avec Ubuntu + interface graphique, j'ai bien des lignes ADDRCONF (à 1029 secondes, c'est l'activation du WiFi).
cat /var/log/syslog | grep ADDRCONF
Mar 15 19:00:31 vivien5 kernel: [ 3.925993] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
Mar 15 19:00:31 vivien5 kernel: [ 3.974652] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
Mar 15 19:00:31 vivien5 kernel: [ 3.979524] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
Mar 15 19:00:31 vivien5 kernel: [ 3.993234] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
Mar 15 19:00:31 vivien5 kernel: [ 4.072738] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
Mar 15 19:00:34 vivien5 kernel: [ 6.913973] IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready
Mar 15 19:17:36 vivien5 kernel: [ 1029.254593] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready
J'ai revérifié sur mes serveurs : pas de lignes ADDRCONF
J'ai trouvé ce bug 1633479 (https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1718568) made a change to isc-dhcp to wait for an interface's link-local ipv6 address to switch from 'tentative' to normal, because all link-local addresses briefly go through a 'tentative' state while the kernel is performing ipv6 link-local 'duplicate address detection' (DAD). While in the 'tentative' state, dhclient can't take over the interface and send out dhcpv6 requests; it must wait until DAD completes.
mais cela ne semble concerner que DHCPv6
-
J'ai toujours le même problème de perte d'IPv6 au reboot (présent dans uniquement dans 10% des reboot).
route -6 affiche alors ::/0 avec le flag UGDAe et un next hop fe80::2a52:61ff:fed7:84c2
Voici le DMESG complet : 201803_dmesg_serveur_ubuntu1604.txt (https://lafibre.info/testdebit/ubuntu/201803_dmesg_serveur_ubuntu1604.txt) si vous trouvez qq chose pour m'aider.
Pour le retour de sysctl -a |grep autoconf / sysctl -a |grep "accept_ra " / sysctl -a |grep accept_dad c'est exactement le retour publié dans le message précédent : https://lafibre.info/serveur-linux/perte-ipv6/msg528490/#msg528490
Si vous avez une piste.
La configuration est toujours celle du premier message de ce sujet.
-
Je ne sais pas si ça peut t'aider mais perso dans le fichier interfaces je mets accept_ra
Si je veux mettre une gateway fixe je mets accept_ra 0 :
iface eth0 inet6 static
address 2001:bc8:1111:111::1/64
gateway ...
accept_ra 0
À l'inverse si je veux utiliser les ra :
iface eth0 inet6 static
address 2001:bc8:1111:111::1/64
accept_ra 1
-
Bientôt plus supporté sous Netplan ça... :/
-
Comme je vois que j'ai net.ipv6.conf.enp1s0f0.accept_ra = 0 même quand le problème est présent, je me demande si c'est la bonne piste.
-
le flag UGDAe indique que c'est un RA.
donc soit y'a un bug.
soit a un moment accept_ra est a 1 pendant l'init puis passe a 0 apres.
nb: le fait de mettre accept_ra a 0 une fois qu'on a deja configuré une route a cause d'un RA ne supprime pas cette route.
-
Bientôt plus supporté sous Netplan ça... :/
Pourtant dans la documentation de netplan je vois bien accept_ra : http://manpages.ubuntu.com/manpages/artful/man5/netplan.5.html
Common properties for all device types
...
accept-ra (bool)
Accept Router Advertisement that would have the kernel configure
IPv6 by itself. On by default.
...
Après je n'ai jamais essayé netplan.
Comme je vois que j'ai net.ipv6.conf.enp1s0f0.accept_ra = 0 même quand le problème est présent, je me demande si c'est la bonne piste.
Justement c'est ce que j'ai vu, c'est pour ça que j'avais un doute que ça allait t'aider.
Après pourquoi ne pas essayer ? Il y a peut-être une histoire d'ordre de démarrage avec sysctl et ifdownup...
-
Après pourquoi ne pas essayer ? Il y a peut-être une histoire d'ordre de démarrage avec sysctl et ifdownup...
Oui, j'ai rajouté la ligne accept_ra 0 immédiatement après la gateway IPv6 sur 8 serveurs. On verra bien. tous mes démarrages se sont bien dérroulés sans pb d'IPv6, mais le pb n'est pas fréquent.
Hugues : accept_ra 0 est bien proposé dans le man interfaces, même sous Ubuntu 17.10.
nb: le fait de mettre accept_ra a 0 une fois qu'on a déjà configuré une route a cause d'un RA ne supprime pas cette route.
Donc ce qui se passe probablement, c'est que de temps en temps, c'est le RA qui configure l'interface avant la conf manuelle de /etc/netwok/interfaces.
-
Donc ce qui se passe probablement, c'est que de temps en temps, c'est le RA qui configure l'interface avant la conf manuelle de /etc/netwok/interfaces.
oui reste a savoir pourquoi.
-
Je ne sais pas si ça peut t'aider mais perso dans le fichier interfaces je mets accept_ra
Si je veux mettre une gateway fixe je mets accept_ra 0 :
iface eth0 inet6 static
address 2001:bc8:1111:111::1/64
gateway ...
accept_ra 0
J'ai eu de nouveau une route par défaut en IPv6 apprise d'un Router Advertisement foireux lors du reboot, alors que j'avais bien mis accept_ra 0
Si vous avez des idées pour creuser.
J'ai cherché "ADDRCONF" puis "Router Advertisement" dans l'ensemble des fichiers de /var/log sans sucés.
-
Bientôt plus supporté sous Netplan ça... :/
Je ne connaissais pas, mais Netplan n'est-il pas déjà utilisé par défaut sous Ubuntu 17.10 ?
https://websiteforstudents.com/configuring-static-ips-ubuntu-17-10-servers/
Donc est-il désactivé ?
http://www.ubuntugeek.com/disable-netplan-on-ubuntu-17-10.html
-
Tu peut essayer ipv6.autoconf=0 en argument du noyau au boot ?
-
semblerais que ce soit un vieux 'bug' que personne ne veut corriger: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997605
la solution d'un argument au boot de thenico pourrait marcher.
ps: j'ai mis 'bug' entre guillement car c'est plus un probleme de sequence au boot qu'un bug en soit.
-
Merci kgersen.
J'avais cherché dans les bug mais en filtrant sur les bug de moins d'un an...
Impressionnant que depuis 2012 personne ne propose de solution pour corriger la chose.
-
En lisant le bugtracker j'ai l'impression que les dev Ubuntu rejettent la faute sur le kernel (no userland issue), or il semble bien que soit un souci d'ordre des scripts d'init plutôt non ? N'ont-ils pas évacué le problème un peu vite, pourtant l'analyse du soumetteur semblait plutôt claire ?
-
Impressionnant que depuis 2012 personne ne propose de solution pour corriger la chose.
Les joies de l'open source...
C'est comme le fait que la boite de dialogue d'upload de GTK ne possède pas de visualisation en mode vignette, alors que c'est demandé depuis...2004.
Quand un problème est ignoré, on peut être sûr que le wontfix peut traîner des années...
-
Les joies de l'open source...
Ce n'est pas propre à l'open source : il existe par exemple 2 bugs dans le code ZFS Solaris ouverts chez Oracle depuis presque 10 ans qui n'ont toujours pas été réglés.
L'un concerne la possibilité de retirer un device non redondé (shrink) et l'autre la possibilité de supprimer sans rebooter un Zpool en erreur dont un device n'est plus accessible.
Soit 2 énormes régressions par rapport à ce qui existait avant même ZFS, dont Oracle se contrefout, classées simplement en enhancement.
-
Ouais, je confirme pour les bugs qui trainent des années dans des logiciels propriétaires (principalement des compilateurs dans mon cas).
-
je crois surtout que ca concerne tellement peu de monde :
- soit les gens n'ont pas IPv6 d'activé
- soit ils font tout en statique et y'a pas de routeur qui balancent des RA
- soit y'a un routeur qui balance des RA et le SLAAC et/ou les RA sont utilisés.
c'est quand meme un peu la philosophie et le plus d'IPv6 de permettre la conf auto sans bidouiller les adresses a la main.
Apres il est vrai que 'théoriquement' ton cas rare devrait marcher aussi mais ce n'est pas vraiment un bug, chaque composant fonctionne normalement c'est juste un problème d'ordre au boot (networking demarrant avant sysctl ?).
En plus c'est difficile a détecter cela il faut que le RA surviennent pendant la période très courte entre le boot et la prise en compte de procps.conf. Des serveurs ne reboot pas souvent et les RA ne sont pas fréquents (intervalle 30 secondes par défaut sur Cisco il me semble).
A mon avis il faut aussi vérifier quand tu fais le sysctl au boot. Sous Systemd y'a des changements d'ordre aussi (par exemple ne rien mettre dans /etc/sysctl.conf sous systemd).
-
Commande tcpdump pour voir si vous avez des "router advertisement" sur vos serveurs : tcpdump -n -i eth0 icmp6 and ip6[40] == 134
# tcpdump -n -i enp1s0f0 icmp6 and ip6[40] == 134
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:21:30.795827 IP6 fe80::2a52:61ff:fed7:84c2 > ff02::1: ICMP6, router advertisement, length 96
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel
avec l'option -v :
# tcpdump -v -n -i enp1s0f0 icmp6 and ip6[40] == 134
tcpdump: listening on enp1s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:34:16.754662 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 96) fe80::2a52:61ff:fed7:84c2 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 96
hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 28:52:61:d7:84:c2
prefix info option (3), length 32 (4): 2001:860:de01:1101::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
prefix info option (3), length 32 (4): 2001:860:deff:1001::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
mtu option (5), length 8 (1): 1500
-
Hello, si ça en intéresse certains, ce problème qui est dû à une race condition (le kernel prend une IPv6 et passerelle via autoconf avant ifup) a été corrigé « récemment » dans ifupdown : https://salsa.debian.org/debian/ifupdown/-/commit/3fb794b2dc1f16da09409522826142ef5e226ddc.
Le commit est inclus dans ifupdown v0.8.36 qui n'est arrivé que dans Bullseye (https://packages.debian.org/bullseye/ifupdown).
Le problème avait été à moitié résolu (suppression de l'IPv6 d'autoconf mais pas de la passerelle) dans https://salsa.debian.org/debian/ifupdown/-/commit/fe9fb5882ab5d238122d986454b0d156477bc8d0.
@vivien, pas besoin de mettre accept_ra 0, c'est déjà fait par défaut quand tu spécifies la passerelle: https://salsa.debian.org/debian/ifupdown/-/commit/aa9b12d76a8cc3fb919fc64d624a45f3eca86444
Tu peux d'ailleurs le voir dans la sortie de ifup -v:
/sbin/sysctl -q -e -w net.ipv6.conf.eno0.accept_ra=0
/sbin/sysctl -q -e -w net.ipv6.conf.eno0.autoconf=0
-
Merci wobble pour le retour.
Les bugs qui ne sont pas reproduits systématiquement, ce sont les plus compliqués à corriger.
Le challenge pour faire un système d'exploitation de zéro est important.
Pourtant certains s'y essayent : https://linuxfr.org/news/haiku-r1-beta-3-haiku-a-20-ans