La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
Scaleway => Discussion démarrée par: sly_ le 10 février 2021 à 19:51:38
-
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é
-
Une configuration où un préfixe /64 serait routé en dur éviterait en effet ce type de problèmes, en cas de problèmes DHCPv6-PD.
-
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é.
-
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.
-
Tout est revenu chez moi.
Pour info : https://status.scaleway.com/incidents/d7zcxgx60bj2
-
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 !
-
- y'a-t-il une protection anti-flood chez eux qui banni trop de requêtes dhcp6 ?
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é.
Je me suis fait piéger deux ou trois fois par cette protection sur ma dedibox.
ça prouve encore que ipv6 est un peu le parent pauvre, si le routage ipv4 avait été coupé 20h on en aurait entendu brailler !
Comme chez beaucoup d'autres providers...
-
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é
-
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é
-
Le port est coupé
ca couperait IPv4 aussi , ca me parait excessif.
-
Si si, faut passer par le support Online pour demander le no shut...
-
Pour info une partie de l'infra DHCPv6 Dedibox a été refacto/upgrade mi Mars donc ça devrait être mieux.
Et effectivement le port est shut en cas de flood DHCPv6 important (en général automatiquement)
-
Merci Kedare.
Il travaille pour Scaleway, je viens de modifier son profil.
-
Merci Kedare pour votre retour technique, ça change des élucubrations commerciales qui vous vendent monts et merveilles.
Il est sans doute un peu tôt pour le confirmer, mais sans rien changer de mon coté, depuis mon problème de février je n'ai à déplorer aucune perte de connectivité. Je vais également lancer un test de déplacement de VM entre datacenter, après tout, c'est aussi ça l'intérêt du dhcp...
-
Le changement qui a eu lieux en Mars ne concerne que le DHCPv6 pour Dedibox, si tu parles de VM sur Scaleway Elements c'est une infra complètement différente géré par une autre équipe.
Si tu parles d'un déplacement de VM sur des hosts Dedibox, pense bien a release ton prefix avant de le re-request si tu es sur un host différent.
-
Le changement qui a eu lieux en Mars ne concerne que le DHCPv6 pour Dedibox
of course, c'est bien de cela qu'il s'agit ici.
Si tu parles d'un déplacement de VM sur des hosts Dedibox, pense bien a release ton prefix avant de le re-request si tu es sur un host différent.
ha ! Et bien pour ce point, on est alors similaire avec le comportement d'avant. J'avais en effet remarqué qu'un release permettait d'accélérer la bascule du routage vers un host différent. Sauf qu'on a pas toujours le loisir de faire un release. Quand c'est planifié à l'avance oui, mais quand on est face à la perte d'un noeud physique, la procédure de reprise devrait permettre d'imposer le routage vers l'hôte de reprise.
Bon, je continue mes tests...
-
Après quelques tests de déplacement de VM d'un host à l'autre/reprise d'IPv6, le résultat est un peu étrange.
En suivant bien l'ordre :
- validation que le routage ipv6 marche avec VM1 sur host1 sur DC2
- stop et release par le client dhcpv6
- déplacement VM1 sur host2 (AMS1)
- migration de la failover ipv4 et de la MAC associée
- boot de la VM1 sur host2
Résultat en quelques secondes : connectivé ipv4 et ipv6 impeccable
Pour jouer, opération inverse en suivant le même ordre et retour sur host1
Résultat : connectivé ipv4 en quelques secondes, ipv6 KO
reboot, restart de dhcpv6 rien n'y fait.
(...)
Jun 1 14:53:11 test2 dhclient[1085]: XMT: Forming Request, 0 ms elapsed.
Jun 1 14:53:11 test2 dhclient[1085]: XMT: X-- IA_PD 00:00:e7:f8
Jun 1 14:53:11 test2 dhclient[1085]: XMT: | X-- Requested renew +3600
Jun 1 14:53:11 test2 dhclient[1085]: XMT: | X-- Requested rebind +5400
Jun 1 14:53:11 test2 dhclient[1085]: XMT: | | X-- IAPREFIX 2001:bc8:37ca:106::/64
Jun 1 14:53:11 test2 dhclient[1085]: XMT: | | | X-- Preferred lifetime +7200
Jun 1 14:53:11 test2 dhclient[1085]: XMT: | | | X-- Max lifetime +7500
Jun 1 14:53:11 test2 dhclient[1085]: XMT: V IA_PD appended.
Jun 1 14:53:11 test2 dhclient[1085]: XMT: Request on enp0s3, interval 950ms.
Jun 1 14:53:11 test2 dhclient[1086]: XMT: Request on enp0s3, interval 950ms.
Jun 1 14:53:11 test2 dhclient[1086]: RCV: Reply message on enp0s3 from 2001:bc8:6010:204::1.
Jun 1 14:53:11 test2 dhclient[1085]: RCV: Reply message on enp0s3 from 2001:bc8:6010:204::1.
Jun 1 14:53:11 test2 dhclient[1085]: RCV: X-- Preference 255.
Jun 1 14:53:11 test2 dhclient[1085]: RCV: X-- IA_PD 00:00:e7:f8
Jun 1 14:53:11 test2 dhclient[1085]: RCV: | X-- starts 1622551991
Jun 1 14:53:11 test2 dhclient[1085]: RCV: | X-- t1 - renew +10800
Jun 1 14:53:11 test2 dhclient[1085]: RCV: | X-- t2 - rebind +172800
Jun 1 14:53:11 test2 dhclient[1085]: RCV: | X-- [Options]
Jun 1 14:53:11 test2 dhclient[1085]: RCV: | | X-- IAPREFIX 2001:bc8:37ca:106::/64
Jun 1 14:53:11 test2 dhclient[1085]: RCV: | | | X-- Preferred lifetime 7200.
Jun 1 14:53:11 test2 dhclient[1085]: RCV: | | | X-- Max lifetime 86400.
Jun 1 14:53:11 test2 dhclient[1085]: RCV: X-- Server ID: 00:01:00:01:27:c2:56:0a:52:54:00:ac:49:df
Jun 1 14:53:11 test2 dhclient[1085]: PRC: Bound to lease 00:01:00:01:27:c2:56:0a:52:54:00:ac:49:df.
Le client dhcp prétend avoir reçu une lease mais le routage ne le fait pas. Après, j'ai joué à l'apprenti sorcier en tentant de remplace l'adresse MAC rien de mieux. J'ai supprimer le sous réseau /64 pour le re-créer avec nouveau duuid toujours pas.
Si je tente avec un autre sous réseau /64 et nouveau duuid là ouf, j'ai pas tout planté ;-)
Mais ça perd un peu d'intérêt si je ne peux pas garder les IPv6
ça marche 1 fois si on relase bien la lease, sinon, ben, faut attendre je ne sais pas quel expiration de je ne sais quel composant de la chaîne...
-
ha ! Et bien pour ce point, on est alors similaire avec le comportement d'avant. J'avais en effet remarqué qu'un release permettait d'accélérer la bascule du routage vers un host différent. Sauf qu'on a pas toujours le loisir de faire un release. Quand c'est planifié à l'avance oui, mais quand on est face à la perte d'un noeud physique, la procédure de reprise devrait permettre d'imposer le routage vers l'hôte de reprise.
Le release peut être fait depuis un autre host, il faut juste que le prefix et duid match avec le précédent pour déclencher la suppression de la route
Pour ton soucis je vais regarder, ce n'est pas normal.
Tu confirme que ce soucis c'est quand tu release ?
Quand tu ne release pas c'est normal (mais tu doit le release depuis ton nouveau host)
-
Il y a effectivement un soucis quand le préfixe doit bouger.
Le workaround actuel :
- Lancer une requête dhcpv6 sur le nouveau serveur (si non dhclient ne permet pas de release sans lease)
- Lancer un premier release sur le nouveau serveur (ca va supprimer l'ancienne route et kill dhcpclient du nouveau serveur)
- Lancer un deuxieme release sur le nouveau server (ca va supprimer la nouvelle route)
- Lancer une dernière requête dhcpv6 sur le nouveau serveur (ca reconfigure la nouvelle route et lancer le dhclient)
On a corrigé le code mais on a vu quelques routes clientes en double, triple, etc... qu'on doit prévenir avant si jamais c'est quelque chose de volontaire de leur part (pseudo-anycast) avant de pousser le code en production.
Une fois le fix push en production, une requête dhcpv6 va rajouter une route vers le serveur qui envoie la requête et retirer toutes les autres routes éventuelles du même prefixe
-
Bon ben je n'arrive pas à mettre en oeuvre le workaround.
J'ai pu constater que le routage ipv6 qui ne marchait pas mardi remarche ce matin sans avoir rien changé de mon coté, le routage de l'IP de test que j'ai mis sur ma VM 2001:bc8:37ca:106::1 fonctionnait à nouveau correctement (la route a fini par expirer/se mettre à jour)
Je retente le déplacement de la VM vers l'autre host autre DC, je relance dhclient6 -> nikel, le routage fonctionne vers le nouvel host.
je re-re déplace la VM vers l'host initial, je relance dhclient, il me dit obtenir une nouvelle lease :
Jun 3 15:02:09 test2 dhclient[2074]: XMT: Forming Request, 0 ms elapsed.
Jun 3 15:02:09 test2 dhclient[2074]: XMT: X-- IA_PD 00:00:e7:f8
Jun 3 15:02:09 test2 dhclient[2074]: XMT: | X-- Requested renew +3600
Jun 3 15:02:09 test2 dhclient[2074]: XMT: | X-- Requested rebind +5400
Jun 3 15:02:09 test2 dhclient[2074]: XMT: | | X-- IAPREFIX 2001:bc8:37ca:106::/64
Jun 3 15:02:09 test2 dhclient[2074]: XMT: | | | X-- Preferred lifetime +7200
Jun 3 15:02:09 test2 dhclient[2074]: XMT: | | | X-- Max lifetime +7500
Jun 3 15:02:09 test2 dhclient[2074]: XMT: V IA_PD appended.
Jun 3 15:02:09 test2 dhclient[2074]: XMT: Request on enp0s3, interval 910ms.
Jun 3 15:02:09 test2 dhclient[2076]: XMT: Request on enp0s3, interval 910ms.
Jun 3 15:02:09 test2 dhclient[2076]: RCV: Reply message on enp0s3 from 2001:bc8:6010:204::1.
Jun 3 15:02:09 test2 dhclient[2074]: RCV: Reply message on enp0s3 from 2001:bc8:6010:204::1.
Jun 3 15:02:09 test2 dhclient[2074]: RCV: X-- Preference 255.
Jun 3 15:02:09 test2 dhclient[2074]: RCV: X-- IA_PD 00:00:e7:f8
Jun 3 15:02:09 test2 dhclient[2074]: RCV: | X-- starts 1622725329
Jun 3 15:02:09 test2 dhclient[2074]: RCV: | X-- t1 - renew +10800
Jun 3 15:02:09 test2 dhclient[2074]: RCV: | X-- t2 - rebind +172800
Jun 3 15:02:09 test2 dhclient[2074]: RCV: | X-- [Options]
Jun 3 15:02:09 test2 dhclient[2074]: RCV: | | X-- IAPREFIX 2001:bc8:37ca:106::/64
Jun 3 15:02:09 test2 dhclient[2074]: RCV: | | | X-- Preferred lifetime 7200.
Jun 3 15:02:09 test2 dhclient[2074]: RCV: | | | X-- Max lifetime 86400.
Jun 3 15:02:09 test2 dhclient[2074]: RCV: X-- Server ID: 00:01:00:01:27:c2:56:0a:52:54:00:ac:49:df
Jun 3 15:02:09 test2 dhclient[2074]: PRC: Bound to lease 00:01:00:01:27:c2:56:0a:52:54:00:ac:49:df.
mais pas de routage.
Je release :
Jun 3 15:09:04 test2 dhclient[2158]: Listening on Socket/enp0s3
Jun 3 15:09:04 test2 dhclient[2158]: Sending on Socket/enp0s3
Jun 3 15:09:04 test2 dhclient[2158]: XMT: Forming Release, 0 ms elapsed.
Jun 3 15:09:04 test2 dhclient[2158]: XMT: Release on enp0s3, interval 1050ms.
Jun 3 15:09:04 test2 dhclient[2158]: XMT: Release on enp0s3, interval 1050ms.
je relance :
Jun 3 15:09:44 test2 dhclient[2171]: XMT: Forming Request, 0 ms elapsed.
Jun 3 15:09:44 test2 dhclient[2171]: XMT: X-- IA_PD 00:00:e7:f8
Jun 3 15:09:44 test2 dhclient[2171]: XMT: | X-- Requested renew +3600
Jun 3 15:09:44 test2 dhclient[2171]: XMT: | X-- Requested rebind +5400
Jun 3 15:09:44 test2 dhclient[2171]: XMT: | | X-- IAPREFIX 2001:bc8:37ca:106::/64
Jun 3 15:09:44 test2 dhclient[2171]: XMT: | | | X-- Preferred lifetime +7200
Jun 3 15:09:44 test2 dhclient[2171]: XMT: | | | X-- Max lifetime +7500
Jun 3 15:09:44 test2 dhclient[2171]: XMT: V IA_PD appended.
Jun 3 15:09:44 test2 dhclient[2171]: XMT: Request on enp0s3, interval 910ms.
Jun 3 15:09:44 test2 dhclient[2172]: XMT: Request on enp0s3, interval 910ms.
Jun 3 15:09:44 test2 dhclient[2172]: RCV: Reply message on enp0s3 from 2001:bc8:6010:204::1.
Jun 3 15:09:44 test2 dhclient[2171]: RCV: Reply message on enp0s3 from 2001:bc8:6010:204::1.
Jun 3 15:09:44 test2 dhclient[2171]: RCV: X-- Preference 255.
Jun 3 15:09:44 test2 dhclient[2171]: RCV: X-- IA_PD 00:00:e7:f8
Jun 3 15:09:44 test2 dhclient[2171]: RCV: | X-- starts 1622725784
Jun 3 15:09:44 test2 dhclient[2171]: RCV: | X-- t1 - renew +10800
Jun 3 15:09:44 test2 dhclient[2171]: RCV: | X-- t2 - rebind +172800
Jun 3 15:09:44 test2 dhclient[2171]: RCV: | X-- [Options]
Jun 3 15:09:44 test2 dhclient[2171]: RCV: | | X-- IAPREFIX 2001:bc8:37ca:106::/64
Jun 3 15:09:44 test2 dhclient[2171]: RCV: | | | X-- Preferred lifetime 7200.
Jun 3 15:09:44 test2 dhclient[2171]: RCV: | | | X-- Max lifetime 86400.
Jun 3 15:09:44 test2 dhclient[2171]: RCV: X-- Server ID: 00:01:00:01:27:c2:56:0a:52:54:00:ac:49:df
Jun 3 15:09:44 test2 dhclient[2171]: PRC: Bound to lease 00:01:00:01:27:c2:56:0a:52:54:00:ac:49:df.
Rien n'y fait, toujours pas de routage.
Je rebouge ma VM sur l'host + MAC vers lequel je suppose que ça route toujours, je ne lance pas dhclient6 et me contente de :
ip a add 2001:bc8:37ca:106::1 dev enp0s3
la connectivité ipv6 revient
je restart dhclient, je release ma lease
je re-re-re bouge la VM vers le nouvel host
je bouge la failover ipv4
je start puis stop puis start dhclient6
ça ne route toujours pas en ipv6.
P'tet que je vais simplement attendre le nouveau fix ;-)
-
Tu fais biens les 2 releases ?
De mon coté je vois 2 routes active vers ton préfixe donc on dirait que ca n'a pas été bien release (ce qui est normal si tu n'a lancé que 1 release).
Mais effectivement c'est le genre de chose qui ne sera plus possible une fois le fix poussé.
-
j'en ai tenté 2, 3 voire tout un tas. Mais peut-être que je ne fais pas comme il faut, ou alors c'est l'ancienne route que j'aurais dû supprimer autrement ?
En manuel, je fais ça plusieurs fois :
/sbin/dhclient -r -d -v -pf /run/dhclient6.pid -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.leases -6 enp0s3
(blabla)
Sending on Socket/enp0s3
XMT: Forming Release, 0 ms elapsed.
XMT: Release on enp0s3, interval 980ms.
# /sbin/dhclient -d -1 -v -pf /run/dhclient6.pid -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.leases -6 -P enp0s3
(blabla)
RCV: Reply message on enp0s3 from 2001:bc8:6010:204::1.
RCV: X-- Preference 255.
RCV: X-- IA_PD 00:00:e7:f8
RCV: | X-- starts 1622733811
RCV: | X-- t1 - renew +10800
RCV: | X-- t2 - rebind +172800
RCV: | X-- [Options]
RCV: | | X-- IAPREFIX 2001:bc8:37ca:106::/64
RCV: | | | X-- Preferred lifetime 7200.
RCV: | | | X-- Max lifetime 86400.
RCV: X-- Server ID: 00:01:00:01:27:c2:56:0a:52:54:00:ac:49:df
PRC: Bound to lease 00:01:00:01:27:c2:56:0a:52:54:00:ac:49:df.
PRC: Renewal event scheduled in 10800 seconds, to run for 162000 seconds.
PRC: Depreference scheduled in 7200 seconds.
PRC: Expiration scheduled in 86400 seconds.
ip addr add 2001:bc8:37ca:106::1 dev enp0s3
-> niet
-
Pour info on a poussé pas mal de correctifs sur DHCPv6 cet après midi, si tu veux retenter, le move d'IP devrait mieux fonctionner.
Aussi, le déplacement de préfixe n'est possible que si tes serveurs sont derrière des Nexus et pas des Catalyst (en L3),
Les Catalyst sont autonomes la dessus donc on a aucun moyen d'expirer les leases (alors que la partie Nexus passe par notre code pour la gestion du routage vers le prefixes), mais c'est surtout sur les serveurs plus ancien (toutes les nouvelles infras sont derrière du Nexus depuis quelques années)
-
Nope, rien a changé.
Toujours le même comportement, je release, je bascule la FO sur le serveur B, je restart dhclient, et tout fonctionne nikel.
Je fais le chemin inverse pour retourner sur l'ancien serveur A, pas de connectivité ipv6
(si je reviens sur le serveur B, ça remarche)
Pour ajouter un peu d'eau, si j'envoi des requêtes icmp au départ de la VM (serveur A) et que je snif le trafic coté destinataire, les paquets arrivent :
16:18:08.910840 IP6 2001:bc8:37ca:106::1 > ns1.gplservice.net: ICMP6, echo request, seq 202, length 64
16:18:08.910873 IP6 ns1.gplservice.net > 2001:bc8:37ca:106::1: ICMP6, echo reply, seq 202, length 64
Mais la réponse n'est pas reçue par A.
Comment fait-on pour savoir si on est derrière un Nexus ?
-
En général si tu fais un traceroute vers ton serveur, tu as un reverse dns sur la dernière IP avant ton serveur qui t'indique si c'est un nexus (nXk) ou un Catalyst (45).
Si non, envoi moi en MP les ID de tes serveurs et je check en interne.
-
Je ne vois pas de reverse sur l'IP avant d'arriver à mes serveurs :
$ traceroute nanael
....
12 51.158.8.170 (51.158.8.170) 20.386 ms 51.158.8.25 (51.158.8.25) 20.263 ms 51.158.8.168 (51.158.8.168) 22.787 ms
13 195.154.2.121 (195.154.2.121) 22.538 ms 195.154.2.119 (195.154.2.119) 19.842 ms 195.154.2.121 (195.154.2.121) 21.359 ms
14 nanael.gplservice.net (51.15.18.4) 21.063 ms 20.963 ms 19.042 ms
$ traceroute sitael
....
11 pni-th2-a9k1.th2.poneytelecom.eu (195.154.1.37) 13.343 ms 12.247 ms 51.158.8.183 (51.158.8.183) 12.500 ms
12 51.158.8.53 (51.158.8.53) 13.197 ms 13.442 ms 51.158.8.55 (51.158.8.55) 11.888 ms
13 sitael.gplservice.net (163.172.103.241) 10.491 ms 11.401 ms 11.131 ms
ID sitael : 114892
ID nanael : 138182
La VM de test actuellement active est sur 195.154.38.30, 2001:bc8:37ca:106::1
-
Effectivement, tu es derrière un Nexus,
Je crois avoir trouvé le soucis, peux tu retenter ?
-
!! ça marche !!
La dernière modif a été la bonne, cette fois c'est bon, je peux passer une VM d'un serveur à un autre et en quelques secondes le routage est actif sur le nouveau prefix.
J'ai essayé avec et sans release préalable : l'un comme l'autre fonctionne, c'est le dernier qui demande avec le bon DUID qui l'emporte, ce qui, pour moi semble la méthode la plus cohérente. Mon use case est donc adressé : En cas de bascule d'une VM d'un noeud à un autre, la connectivité ipv6 suit automatiquement.
Merci Kedare
-
Génial :)
En fait dans ton cas c'est le fait d'utiliser une IPFO qui posait soucis (comme la MAC est réutilisée) dans l'ancienne version on se basait sur la MAC et le préfixe pour savoir si on devait expirer une route, dans ton cas comme les deux étaient identiques la route n'étaient pas retirée (alors que ça marchait quand le dhclient tournait directement sur l'interface réel du serveur comme les MAC sont uniques dans ce cas là), j'ai ajouté le peer (l'IPv6 coté Nexus donc) dans la comparaison pour que ça fonctionne. (combiné aux autres améliorations qu'on a poussé du coup, comme enforcer l'unicité d'une route (faire une requête sur un serveur va retirer l'ancienne route), et quelques améliorations de scaling sur le système)
-
Merci Kedare et sly_ de votre acharnement pour avoir fait progresser IPv6.