Auteur Sujet: Ubuntu serveur utilise l'IPv6 HS du RA à la place de /etc/network/interfaces  (Lu 15341 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 088
    • Twitter LaFibre.info
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.

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

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #1 le: 11 mars 2018 à 12:10:59 »
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

vivien

  • Administrateur
  • *
  • Messages: 47 088
    • Twitter LaFibre.info
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #2 le: 11 mars 2018 à 12:22:38 »
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 ?

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #3 le: 11 mars 2018 à 12:23:30 »
Fort probable, dans le doute, j'en fous 15, ça m'a tellement gavé ce truc.

vivien

  • Administrateur
  • *
  • Messages: 47 088
    • Twitter LaFibre.info
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #4 le: 11 mars 2018 à 12:29:11 »
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

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.

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #5 le: 11 mars 2018 à 12:33:42 »
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"...

vivien

  • Administrateur
  • *
  • Messages: 47 088
    • Twitter LaFibre.info
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #6 le: 11 mars 2018 à 13:44:32 »
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 ?

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #7 le: 11 mars 2018 à 13:49:19 »
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.

vivien

  • Administrateur
  • *
  • Messages: 47 088
    • Twitter LaFibre.info
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #8 le: 11 mars 2018 à 16:02:54 »
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

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #9 le: 11 mars 2018 à 16:04:16 »
C'était peut-être pour ça que j'ai mis les trois, finalement  ;D

vivien

  • Administrateur
  • *
  • Messages: 47 088
    • Twitter LaFibre.info
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #10 le: 11 mars 2018 à 16:22:27 »
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 = 0
C'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)

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Ubuntu serveur : Pb de perte d'IPv6 après un reboot
« Réponse #11 le: 11 mars 2018 à 18:39:58 »
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.