Résumé ultra-rapide : aujourd'hui, IPv6 par dhcp6 chez scaleway est encore planté ;-( suis-je le seul ?

Avec plus de baratin :
= préambule =
Je suis client scaleway/ex-Online.net chez qui j'ai quelques serveurs debian/Linux, et sur chacun plusieurs VM Linux dont certaines sont accessibles en ipv6.
Il y a de cela ~4 ans j'ai démarré un sujet sur leur outil https://community.scaleway.com afin de déterminer si l'instabilité de la connexion ipv6 que je rencontrais étais chronique, dû à à ma configuration ou dû à leur documentation très limitée de l'époque (c'est un euphémisme) ou les 3 à la fois !

J'ai eu là bas beaucoup s'échanges constructifs et des exemples de config à utiliser avec systemd avec /etc/network/interfaces pour profiter de leur config en DHCPv6-PD qui permet d'obtenir sur les VMs un bloc d'IPv6.

Hélas, l'éphémérité du net a frappé : ça devait pas faire assez "corporate" ou certaines choses se disaient qui ne plaisaient pas ou y'a eu un coup de flemme à maintenir un outils, ils sont passés à SLACK en mode non public et tout a été flingué (on m'a pas demandé si j'en voulais un export !)
Ils sont pas prêt de me revoir sur leur SLACK, j'ai pas envie que ma production de stats, retours d'expé, logs et scripts que je souhaitais partager soit flingué à nouveau, alors bonjour https://lafibre.info/scaleway/ !

= Merci =
Au passage, un grand merci à kgersen : https://lafibre.info/scaleway/comment-activer-lipv6-sur-son-serveur-dedie-chez-oneprovider-ubuntu-18/12/ qui a eu la présence d'esprit (et qui n'est pas naïf) d'avoir sauvé une partie des éléments de cette ancienne discussion.
Config que j'utilise encore aujourd'hui (systemd + dhclient6 sur debian 8/9/10)

D'ailleurs, ils ont mis à jour leur doc : https://documentation.online.net/en/dedicated-server/network/ipv6/prefix
pour inclure une configuration très similaire afin de lancer/relancer dhclient

= Mais ça reste instable =

Grâce à la config pré-cité et l'option systemd :
Restart=always
(
que j'ai finalement changée en :
Restart=on-abort( car lorsque le serveur dhcp de répondait pas au boot, systemd partait dans une boucle infinie du fait du always et certains services ne se lancent alors plus (genre postfix) car une dépendance au réseau insatisfaite les laissaient en carafe. )
Edit 11/02/2021 : que j'ai finalement abandonné dans l'autre sens, car quand tout remarche, ben systemd n'arrive pas à le relancer la première fois, c'est grâce au always que ça passe quand même, j'ai cherché dans la doc systemd, je pige pas ce que je dois faire pour que ça s'initialise correctement *après* que l'interface réseau soit bien up
)

J'ai pû obtenir une bien meilleure stabilité de la connectivité ipv6 car il arrivait à dhclient de se planter/bloquer et la lease dhcp finissait par expirer et la connexion se couper.

= Alors tout roule non  ? =

C'est mieux, mais je continue à avoir des problèmes. Parfois ça peut durer jusqu'a plusieurs mois, voire 1 an sans problèmes et puis, sans que je sache pourquoi précisément, ça ne marche plus.
J'en suis toujours donc à me demander :
- ma config est-elle bonne ?
- y'a-t-il une protection anti-flood chez eux qui banni trop de requêtes dhcp6 ?
- leur serveur dhcp6 est-il souvent planté et.... "c'est la vie !"
- y-a-t-il quelqu'un aux commandes de l'IPv6 chez Scaleway pour faire perdurer ce service d'ipv6 "failover" ou l'avenir est au cloud made in scaleway ou au SLAAC qui fourni une bloc figé par serveur ?

En outre, le déplacement de VM d'un serveur à l'autre, ce qui devrait normalement être géré en dhcp6 + DUID pose toujours problème (je dois attendre plusieurs heures pour que le routage s'active vers la nouvelle place de la VM)

= Détail technique du jour 10/02/2021 =

La coupure semble avoir eu lieu vers 13h00 ce jour 10/02 : de manière simultané, j'ai 2 VM et un serveur qui ont perdu la connectivité ipv6.
Si je tente de relancer à la main "systemctl start dhclient6.service", mon /var/log/syslog indique :
Feb 10 19:28:54 ns2 systemd[1]: Starting ISC DHCP client to send DUID for IPv6 and add IPv6 to interface...
Feb 10 19:28:54 ns2 dhclient[1945]: Internet Systems Consortium DHCP Client 4.3.5
Feb 10 19:28:54 ns2 dhclient[1945]: Internet Systems Consortium DHCP Client 4.3.5
Feb 10 19:28:54 ns2 dhclient[1945]: Copyright 2004-2016 Internet Systems Consortium.
Feb 10 19:28:54 ns2 dhclient[1945]: All rights reserved.
Feb 10 19:28:54 ns2 dhclient[1945]: For info, please visit https://www.isc.org/software/dhcp/
Feb 10 19:28:54 ns2 dhclient[1945]: Copyright 2004-2016 Internet Systems Consortium.
Feb 10 19:28:54 ns2 dhclient[1945]: Listening on Socket/eth0
Feb 10 19:28:54 ns2 dhclient[1945]: Sending on   Socket/eth0
Feb 10 19:28:54 ns2 dhclient[1945]: PRC: Soliciting for leases (INIT).
Feb 10 19:28:54 ns2 dhclient[1945]: All rights reserved.
Feb 10 19:28:54 ns2 dhclient[1945]: For info, please visit https://www.isc.org/software/dhcp/
Feb 10 19:28:54 ns2 dhclient[1945]:
Feb 10 19:28:54 ns2 dhclient[1945]: Listening on Socket/eth0
Feb 10 19:28:54 ns2 dhclient[1945]: Sending on   Socket/eth0
Feb 10 19:28:55 ns2 dhclient[1945]: XMT: Forming Solicit, 0 ms elapsed.
Feb 10 19:28:55 ns2 dhclient[1945]: XMT:  X-- IA_PD 56:00:5a:e1
Feb 10 19:28:55 ns2 dhclient[1945]: XMT:  | X-- Request renew in  +3600
Feb 10 19:28:55 ns2 dhclient[1945]: XMT:  | X-- Request rebind in +5400
Feb 10 19:28:55 ns2 dhclient[1945]: XMT:  | X-- Request prefix 2001:bc8:37ca:102::/64.
Feb 10 19:28:55 ns2 dhclient[1945]: XMT:  | | X-- Request preferred in +7200
Feb 10 19:28:55 ns2 dhclient[1945]: XMT:  | | X-- Request valid in     +10800
Feb 10 19:28:55 ns2 dhclient[1945]: XMT: Solicit on eth0, interval 1020ms.
Feb 10 19:28:55 ns2 dhclient[1945]: XMT: Solicit on eth0, interval 1020ms.
Feb 10 19:28:55 ns2 dhclient[1945]: RCV: Advertise message on eth0 from 2001:bc8:6010:204::1.
Feb 10 19:28:55 ns2 dhclient[1945]: RCV: Advertise message on eth0 from 2001:bc8:6010:204::1.
Feb 10 19:28:55 ns2 dhclient[1945]: RCV:  X-- Preference 255.
Feb 10 19:28:55 ns2 dhclient[1945]: RCV:  X-- IA_PD 56:00:5a:e1
Feb 10 19:28:55 ns2 dhclient[1945]: RCV:  | X-- starts 1612981735
Feb 10 19:28:55 ns2 dhclient[1945]: RCV:  | X-- t1 - renew  +10800
Feb 10 19:28:55 ns2 dhclient[1945]: RCV:  | X-- t2 - rebind +172800
Feb 10 19:28:55 ns2 dhclient[1945]: RCV:  | X-- [Options]
Feb 10 19:28:55 ns2 dhclient[1945]: RCV:  | !-- Status code of no prefix, IA_PD discarded.
Feb 10 19:28:55 ns2 dhclient[1945]: RCV:  X-- Server ID: 00:01:00:01:1b:ac:bc:2d:10:60:4b:9b:0a:f4
Feb 10 19:28:55 ns2 dhclient[1945]: PRC: Lease failed to satisfy.

A noter que le routage semble toujours actif puisque si j'ajoute manuellement l'IP de la VM :

ip addr add 2001:bc8:37ca:102::1 dev eth0

la connectivité revient.

Bref, dur dur l'ipv6 chez scaleway, faut être motivé

Résumé ultra-rapide : aujourd'hui, IPv6 par dhcp6 chez scaleway est encore planté ;-( suis-je le seul ?

Je peux confirmer que j'ai aussi le problème sur ams1, j'ai ouvert un ticket hier.
Dans un sens ça me rassure ne de pas être le seul, je n'ai pas touché à ma config sur une debian 8 depuis septembre 2019, je me demandais si une update avait pu casser un truc.

Et bien c'est revenu ce matin autour de 9h30, le routage semble avoir cessé et un restart du dhclient à rétabli la connectivité.

Il vaut mieux utiliser dhcpcd5 et tout configurer en statique. Mais oui il y a encore eu une couille dans leur système, plus de réponse du serveur dhcp pendant presque 24 heures, donc une perte totale de la connectivité v6...

Dans mon cas ce n'est revenu qu'à 11h20.

Je me suis trompé tout à l'heure en lisant mes logs d'alertes, c'est vers 10h50 que c'est revenu et non 9h30.
Ce qui colle bien avec le ticket cité.

Espérons que ça les motives pour mettre une sonde de surveillance avec alertes, 20h pour détecter un problème c'est pas ultra rapide (et si ça se trouve c'est ton ticket qui les a réveillé !)
ça prouve encore que ipv6 est un peu le parent pauvre, si le routage ipv4 avait été coupé 20h on en aurait entendu brailler !

Oui, si un flood est détecté depuis le port réseau de ton dédié, le port est shutté / le trafic est null routé.

Intéressant, tu as plus de détails sur les conditions ?
tu dis "le port est shutté" tu veux dire quoi par là ?

Le port est coupé

pardon, j'ai pas été précis : "shutté", c'est le mot que j'avais compris, c'est "port" qui est ambigu.
Est-ce qu'il a voulu dire que si le nombre de requête dhcpv6 était trop important les paquets IP/UDP de port 547 ne sont plus routé vers leur serveur dhcp ?
Où est-ce lié au broadcast initial ?

Si c'est une des causes possibles alors ça vaut le coup que leur doc le mentionne, les clients dhcp ont évidement des options de retry, donc il faudrait être paramétré en dessous.
M'enfin tout ça est louche car je ne l'ai jamais constaté