Aller au contenu


Photo

IPv6 /48, dibbler et Debian 7


  • Please log in to reply
67 replies to this topic

#41 matt2xu

matt2xu

    Newbie

  • Members
  • Pip
  • 4 Messages :

Posté 27 juin 2014 - 10:03

Je reviendrai poster demain pour dire si cette manière de faire arrive à maintenir mon IPv6 en vie :-)

 

Bon et bien ça a l'air de marcher très bien tout ça ! D'après mes logs, dibbler rajoute le prefixe environ toutes les heures comme un grand. J'ai oublié de préciser mais dans le resolv.conf j'ai les adresses IPv4 et IPv6 des serveurs DNS de Online en dur, ça me permet de pouvoir faire du IPv6-only (et c'est toujours fun). Donc de mon côté pas besoin d'appeler dhclient en plus, visiblement ça ne sert à rien.

 

Online ont-ils conscience de ceci? Jusqu'à présent je n'ai vu personne de chez Online répondre aux questions de cet ordre...

 

Complètement d'accord, ce serait bien qu'ils puissent au moins confirmer la pertinence de ce qu'on propose ici, et si possible mettre à jour la documentation qui entre nous en a rudement besoin !



#42 mirtouf

mirtouf

    Advanced Member

  • Members
  • PipPipPip
  • 170 Messages :

Posté 27 juin 2014 - 12:25

Rappel, c'est dibbler-client OU dhclient, jamais les 2 !



#43 Le Joko

Le Joko

    Newbie

  • Members
  • Pip
  • 5 Messages :

Posté 27 juin 2014 - 13:15

 

 

Bon et bien ça a l'air de marcher très bien tout ça ! D'après mes logs, dibbler rajoute le prefixe environ toutes les heures comme un grand. J'ai oublié de préciser mais dans le resolv.conf j'ai les adresses IPv4 et IPv6 des serveurs DNS de Online en dur, ça me permet de pouvoir faire du IPv6-only (et c'est toujours fun). Donc de mon côté pas besoin d'appeler dhclient en plus, visiblement ça ne sert à rien.

 

Chez moi, avec dhclient, les problèmes viennent parfois au bout de plusieurs semaines... Je fais des tests depuis pas loin de six mois, et il est hors de question que je mette un truc comme ça en production. Sur un serveur internet, une adresse qui n'est pas parfaitement stable est pour moi un "big no no!!!"



#44 matt2xu

matt2xu

    Newbie

  • Members
  • Pip
  • 4 Messages :

Posté 27 juin 2014 - 13:39

Rappel, c'est dibbler-client OU dhclient, jamais les 2 !

 

Oui je m'en suis rendu compte, mais malheureusement ce n'est pas ce qui est indiqué dans la documentation http://documentation...au/prefixe_ipv6

"démarrer le client dibbler" (il n'est pas précisé qu'il faut que dibbler tourne en permanence)

puis

"A noter qu'il vous faut ensuite configurer votre ipv6 sur l'iface

Ligne de commande:
dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v eth0 (-D LL éventuellement selon version)"
 
Moi je le comprends (et visiblement je ne suis pas le seul) comme "il faut démarrer dibbler puis lancer dhclient".


#45 SebastienFM

SebastienFM

    Advanced Member

  • Staff Online.net
  • 145 Messages :

Posté 27 juin 2014 - 16:22

Hello,

On va devoir simplifier ça alors. :)

 

Merci pour le signalement de la raison de l'incompréhension.


--
L'assistance technique Online


#46 Le Joko

Le Joko

    Newbie

  • Members
  • Pip
  • 5 Messages :

Posté 27 juin 2014 - 17:42

Hello,

On va devoir simplifier ça alors. :)

 

Merci pour le signalement de la raison de l'incompréhension.

 

Il ne s'agit pas que de documentation. Les problèmes que j'ai remarqué sont:

- instabilité des clients DHCPV6, en particulier les clients standards de plusieurs distributions Linux majeures (personnellement testé avec dhclient et un backport de dibbler sur Ubuntu 12.04 mais d'autres horror stories ont été rapportées sur ce forum aussi bien avec dhclient que dibbler, je vais sans doute bientôt tester avec Ubuntu 14.04)

- La configuration recommandée nécessite l'installation de logiciels non standards sur plusieurs OS/distributions (dibbler)

- Mauvaise intégration de ces clients avec le fonctionnement standard de certaines distributions (ex: problèmes de resolv.conf, mauvaise intégration aux fichiers de config standard, etc.)

- absence de client correct sous Windows

- le principe même du DHCPV6 avec prefix delegation est déjà en soi complexe.

 

 

Votre architecture est très ingénieuse et à, en théorie, de nombreuses qualité. Sauf qu'elle est inutilisable en production sans efforts importants. Votre ancienne architecture avait au moins un mérite: elle marchait sans qu'on ai à se poser de questions...

 

Dit autrement: tant qu'on ne pourra pas installer une Dedibox avec une IPV6 aussi simplement qu'avec une IPV4, cela voudra dire que l'infrastructure IPV6 d'Online n'est pas tout à fait au point. Je rappelle que les concepteurs d'IPV6 avaient dans l'idée de rendre son utilisation plus simple que celle d'IPV4. Ça n'est, pour le moment, pas le cas chez Online.



#47 mirtouf

mirtouf

    Advanced Member

  • Members
  • PipPipPip
  • 170 Messages :

Posté 27 juin 2014 - 22:45

Au choix on peut avoir :

- statique

- SLAAC

- stateless + DHCP v6

- stateful (DHCP v6)

 

Pour des raisons évidentes de sécurité, il faut que Online soit au courant des associations MAC / adresse IP sur son réseau et il faut pouvoir conserver la possibilité d'obtenir une délégation sur chaque bloc sinon à quoi bon avoir un bloc /48. En prenant en compte cela, l'adressage statique apparaît bien trop rigide car trop peu adapté aux machines virtuelles et trop contraignant dans sa gestion, SLAAC autrefois utilisé est trop limité.

On tombe clairement face, non pas face à un problème d'architecture réseau, mais bien face à un problème logiciel et là c'est le peu d'entrain à adopter IPv6 qui se fait ressentir.



#48 regar42

regar42

    Newbie

  • Members
  • Pip
  • 2 Messages :

Posté 28 juin 2014 - 13:50

Hello,

On va devoir simplifier ça alors. :)

 

Merci pour le signalement de la raison de l'incompréhension.

 

Ce que vous pouvez ajouter aussi c'est ça :

 

http://forum.online....de-ubuntu-1404/

 

à savoir la correction d'un problème de segfault sous Ubuntu 14.04

 

Du coup depuis, mon dibbler tourne sans problèmes, depuis déjà quelques semaines. C'est stable.

Avant j'avais dhclient et c'est vrai que c'était vraiment pas top, crashs fréquents et aléatoires...



#49 jtreves

jtreves

    Advanced Member

  • Members
  • PipPipPip
  • 1 039 Messages :

Posté 28 juin 2014 - 14:06

Il y a une solution très simple pour que IPV6 soit simple à utiliser en conservant l'architecture actuelle : au lieu d'utiliser un DUID généré aléatoirement comme cela a l'air le cas actuellement, il suffirait de laisser la possibilité de rentrer son propre DUID (celui qui a été généré aléatoirement aussi mais par l'OS). C'est le fonctionnement normal d'un serveur, d'après la documentation IPV6 l'utilisation d'un DUID externe est un mécanisme pour les routeurs. Sous Windows il est impossible de modifier le DUID généré même si en fait il apparaît dans une clef du registre. C'est pareil sous MacOS. Il n'y a que Linux qui accepte (plu ou moins facilement) de modifier le DUID.



#50 duncane

duncane

    Newbie

  • Members
  • Pip
  • 3 Messages :

Posté 09 juillet 2014 - 15:38

Je te remercie pour ton message, je suis encore obligé d'annoncer ma gw (je vais faire un tour dans les options de dhclient pour voir le cas des interfaces bridgées à cause de la gestion du RA) mais au moins je n'ai plus à me soucier d'un segfault de dibler-client pour le moment.

 

En cherchant, j'ai trouvé ce topic : http://forum.online....eway-pour-ipv6/

 

qui dit en substance : Pour avoir le forwarding et le router advertisement sur l'hôte, il fait mettre accept_ra à 2.

http://www.mattb.net...ing-is-enabled/ 



#51 Le Joko

Le Joko

    Newbie

  • Members
  • Pip
  • 5 Messages :

Posté 09 juillet 2014 - 15:56

Au choix on peut avoir :

- statique

- SLAAC

- stateless + DHCP v6

- stateful (DHCP v6)

 

Pour des raisons évidentes de sécurité, il faut que Online soit au courant des associations MAC / adresse IP sur son réseau et il faut pouvoir conserver la possibilité d'obtenir une délégation sur chaque bloc sinon à quoi bon avoir un bloc /48. En prenant en compte cela, l'adressage statique apparaît bien trop rigide car trop peu adapté aux machines virtuelles et trop contraignant dans sa gestion, SLAAC autrefois utilisé est trop limité.

On tombe clairement face, non pas face à un problème d'architecture réseau, mais bien face à un problème logiciel et là c'est le peu d'entrain à adopter IPv6 qui se fait ressentir.

 

Il faut admettre qu'on est en train de parler d'une technologie encore jeune et (trop) peu déployée. Il n'est donc pas surprenant de rencontrer des difficultés. Mais dans le cas d'Online, je pense que la plupart d'entre elles pourraient être évitées ou contournée.

 

D'un autre coté, mettre le problème sur le dos des outils ne tient pas la route commercialement. Si les outils ont un problème ou que le service n'est configurable que par des experts, il faudrait que ça soit annoncé et/ou documenté. Actuellement, IPv6 est vendu au même niveau qu'IPv4. Ça génère forcément des énervements et des déceptions. Ça ne serait pas le cas si c'était vendu comme une fonction expérimentale, ou réservée à des spécialistes.

 

Ensuite DHCPv6 c'est super sur le papier, mais c'est compliqué a comprendre, à mettre en place, et les outils ont souvent des problèmes. Donc pourquoi ne pas conserver du SLAAC en même temps, qui fonctionne très bien sans avoir à rien faire? Le SLAAC pourrait être activé par défaut avec une seule IP attribuée, et le DHCPv6 serait une option "avancée" pour ceux qui souhaitent expérimenter ou en ont besoin pour leurs VM et ont le temps et les compétences pour le gérer?

 

La situation  actuelle est d'autant plus dommage que ça ne correspond pas aux standards habituels d'Online. J'ai pour habitude qu'Online fournisse des services fonctionnant parfaitement en standard et de temps en temps sorte un truc "avancé" en le proposant d'abord en "expérimental" avant de le déployer complètement.



#52 pfoo

pfoo

    Advanced Member

  • Members
  • PipPipPip
  • 147 Messages :

Posté 12 juillet 2014 - 08:28

Il faut admettre qu'on est en train de parler d'une technologie encore jeune et (trop) peu déployée. Il n'est donc pas surprenant de rencontrer des difficultés. 

http://www.ietf.org/rfc/rfc2460.txt :D

Jeune non, peu (voir non) déployé oui.

C'est justement parce que personne ne se mouille depuis des années que ipv6 traine (et qu'on nous parle de CGN etc).

Il arrive exactement ce que certains avaient prédit depuis des années : quand on aura besoin d'ipv6, les outils auront été si peu utilisé qu'ils ne seront qu'en phase de béta. Ca vaut pour dibbler et dhclient, mais aussi pour cisco & cie ...

 

 

 

D'un autre coté, mettre le problème sur le dos des outils ne tient pas la route commercialement. Si les outils ont un problème ou que le service n'est configurable que par des experts, il faudrait que ça soit annoncé et/ou documenté. Actuellement, IPv6 est vendu au même niveau qu'IPv4. Ça génère forcément des énervements et des déceptions. Ça ne serait pas le cas si c'était vendu comme une fonction expérimentale, ou réservée à des spécialistes.

Je comprend le point de vue, mais je ne suis pas d'accord. Online vend du matériel et de l'accès réseau, basé sur des technologies tout a fait valable (voir même de référence). 

Côté online, c'est stable, c'est côté client que ça merdouille (et coté client software).

 

Après, pour faire extrémiste, je préfère que online laisse dhcpv6 sans ajouter de SLAAC pour une raison très simple : ça va pousser au déploiement et a la stabilisation de dhcpv6 (votre client plante ? libre a vous de remonter des logs et trace aux devs, ou encore mieux, jeter vous même un doigt ou deux au code source).

 

Reste la question de la documentation. Les choses seraient bien plus simple si online fournissait une doc de type wiki éditable par la communauté (quitte à avoir un système de droit afin de ne laisser que les clients depuis X mois éditer la doc, etc)



#53 BMenez

BMenez

    Newbie

  • Members
  • Pip
  • 3 Messages :

Posté 21 juillet 2014 - 17:59


jeter vous même un doigt ou deux au code source

 

C'est ce que j'ai fait.

Je ne sais pas si c'est mon patch/emplatre ou une modif coté Online mais la stabilité semble au rendez-vous depuis 1 mois.



#54 pfoo

pfoo

    Advanced Member

  • Members
  • PipPipPip
  • 147 Messages :

Posté 28 juillet 2014 - 15:16

C'est ce que j'ai fait.

Je ne sais pas si c'est mon patch/emplatre ou une modif coté Online mais la stabilité semble au rendez-vous depuis 1 mois.

dibbler ou isc ?

dibbler tu devrais réussir a pousser le patch chez le dev du projet sans pb



#55 BMenez

BMenez

    Newbie

  • Members
  • Pip
  • 3 Messages :

Posté 28 juillet 2014 - 19:24

dibbler ou isc ?

dibbler tu devrais réussir a pousser le patch chez le dev du projet sans pb

 

ISC :

--- dhcp-4.3.0/client/dhc6.c    2014-01-31 20:20:49.000000000 +0100
+++ dhcp-4.3.0-mod/client/dhc6.c    2014-06-21 16:42:36.670293375 +0200
@@ -4022,8 +4022,18 @@
 
             break;
         }
+
+              case S_REBINDING:
+                /* For now, we rebind up until the last lease expires.  In
+                 * the future, we might want to start SOLICITing when we've
+                 * depreffed an address.
+                 */
+                client->MRD = hi_expire - cur_time;
+                break;
+
         /* FALL THROUGH */
-          case S_RENEWING:
+          default:
+        
         /* While actively renewing, MRD is bounded by the time
          * we stop renewing and start rebinding.  This helps us
          * process the state change on time.
@@ -4040,17 +4050,6 @@
             add_timeout(&tv, start_rebind6, client, NULL, NULL);
         }
         break;
-
-          case S_REBINDING:
-        /* For now, we rebind up until the last lease expires.  In
-         * the future, we might want to start SOLICITing when we've
-         * depreffed an address.
-         */
-        client->MRD = hi_expire - cur_time;
-        break;
-
-          default:
-        log_fatal("Impossible condition at %s:%d.", MDL);
     }
 
     /* Separately, set a time at which we will depref and expire



#56 AnonymousCoward

AnonymousCoward

    Advanced Member

  • Members
  • PipPipPip
  • 41 Messages :

Posté 29 juillet 2014 - 15:05

Merci BEAUCOUP pour ce patch.

 

Par contre, le forum met le bazar dans les tabulations et un simple copier/coller du texte dans un fichier refusera de s'appliquer. Mettre le patch sur un pastebin-like serait super.

 

 --

AnonymousCoward



#57 phrenq

phrenq

    Member

  • Members
  • PipPip
  • 17 Messages :

Posté 29 juillet 2014 - 16:20

Merci BEAUCOUP pour ce patch.

 

Par contre, le forum met le bazar dans les tabulations et un simple copier/coller du texte dans un fichier refusera de s'appliquer. Mettre le patch sur un pastebin-like serait super.

Réussi à le faire fonctionner (je n'ai pas compilé, juste patché)



#58 AnonymousCoward

AnonymousCoward

    Advanced Member

  • Members
  • PipPipPip
  • 41 Messages :

Posté 29 juillet 2014 - 16:58

Y'a pas à dire, l'ISC, à mélanger les tabulations et les espaces pour l'indentation de leur code source, c'est des vicieux !

 

 --

AnonymousCoward



#59 coke

coke

    Newbie

  • Members
  • Pip
  • 4 Messages :

Posté 30 juillet 2014 - 09:34

Hello,

 

Depuis la mise à jour de isc-dhcp (4.3.0+dfsg-2) unstable (sid), je n'ai plus l'erreur "Impossible condition at dhc6.c:4111.", ça fait deux semaines que le process dhclient6 tourne.

Pourtant aucune référence de la correction du bug #745455 dans le changelog.

isc-dhcp-client:
  Installed: 4.3.0+dfsg-2
  Candidate: 4.3.0+dfsg-2
  Version table:
 *** 4.3.0+dfsg-2 0
        500 http://ftp.u-picardie.fr/mirror/debian/ sid/main amd64 Packages



#60 maethor

maethor

    Newbie

  • Members
  • Pip
  • 1 Messages :

Posté 06 août 2014 - 20:35

J'utilise depuis plusieurs mois dibbler 0.8.2 sur Debian Wheezy, sur des dedibox et des VM KVM, en prod et même avec des VM ipv6 only, le tout sans aucun soucis notable. À part quelques bugs quand il faut redémarrer le daemon, ça marche vraiment nickel.

 

Par contre, j'ai l'impression qu'il y a des soucis au niveau des routeurs de Online. Je suis entrain de faire des tests de live migration de VM au sein d'un cluster Ganeti. Après la migration d'une VM (vm01) d'un hôte (kvm01) à un autre (kvm02), celle-ci récupère très vite son préfixe via dibbler. Elle redevient assez rapidement accessible en IPv6 depuis l'extérieur d'Online. Par contre, certaines Dedibox, notamment kvm01 et les autres VM qu'elle héberge, peuvent mettre plusieurs heures avant d'arriver à joindre vm01 à nouveau.

 

En effet, les paquets en provenance de kvm01 se perdent au niveau du premier routeur qu'ils rencontrent. Ma théorie, c'est que ce routeur, qui servait de gateway à vm01 avant sa migration, contient toujours l'ancienne route vers l'ipv6 de vm01, et qu'il drope les paquets pour éviter de créer des boucles.

 

Quelqu'un a-t-il réussi à résoudre ce problème ?

 

Pour contourner le problème, j'ai essayé de configurer dibbler pour qu'il suggère des valeurs T1 et T2 plus petites aux routeurs d'Online, mais ça n'a pas l'air de fonctionner; le routeur d'Online me renvoie toujours les mêmes valeurs :

2014.08.06 21:12:34 Client Debug     RENEW will be sent (T1) after 3600, REBIND (T2) after 7200 seconds.

Mon client.conf :

inactive-mode
log-level 8
duid-type duid-ll

iface eth0 {
    preferred-lifetime 600
    valid-lifetime 1200
    pd {
        T1 600
        T2 1200
    }
}





0 utilisateur(s) en train de lire ce sujet

0 membre(s), 0 invité(s), 0 utilisateur(s) anonyme(s)