IPv6, Quagga, Gitoyen…

dans ipv6

Quand j’ai adhéré à FDN, j’ai dit un truc con, du genre “ah, oui, IPv6, ça me botte, je m’en charge”. Bon, ça devait être en 2005, après, j’ai redis (en 2006) que oui, j’allais mettre IPv6 dans Gitoyen, qui est l’opérateur sur lequel se base FDN

Quelle idée étrange j’avais eu là…

Alors bon, pour la peine que j’y ai passé du temps, si si, vous n’imaginez pas le temps qu’on peut perdre avec ces putains de logiciels opensources dont la seule documentation est le code source, vous me direz, mais y’a des docs, et des gens qui montrent ce qu’ils ont fait. Et je vous répondrait, oui, hum, y’a une belle doc de quagga, elle est a peu près équivalente à la commande “list” de quagga/bgpd/ospfd/ospf6d, vous savez, la commande qui liste toutes les commandes que vous pouvez utiliser, ce qui fait que ça vous aide si vous avez un léger trou de mémoire, mais pas vraiment si vous cherchez a partir de zéro… Ah, oui, les gens qui montrent ce qu’ils ont fait, alors, d’abord, en général, ils montrent ce qu’ils ont fait en disant que d’après la doc c’est censé être comme ça, mais que ça ne marche pas. Moi, je voulais un truc simple, du BGP avec IPv6 et de l’OSPF avec IPv6, ça, il faut croire, personne, jamais n’a essayé, en tout cas, personne n’a réussi, ou ceux qui ont réussi soit on les a enfermés dans des asiles d’aliénés, soit ils gardent bien secret tout ce qu’ils ont pu faire.

Tout ça pour dire que ben, faire de l’IPv6, ben, c’est tout un programme, parce que ceest documenté, nulle part.

J’avais, il y a quelques mois, fait un essai de BGP et d’OSPF pour voir ce que ça donnait, parce que ben, faut avouer qu’en attendant de pouvoir le faire en vrai une fois que Gitoyen aurait un transit IPv6, et j’avais rencontré plusieurs problèmes assez étranges, et comme, à l’époque, j’avais aussi autre chose a faire, j’ai laissé dans l’état, avec l’OSPF qui “marchait”, et le BGP qui ne marchait pas.

J’ai repris la semaine dernière, les grèves ont du bon, et, j’ai fini par dénicher, a coup de recherche très très sioux dans google, et de grep dans les sources, a peu près toutes les informations qui pouvaient me servir.

Pour l’OSPF, c’est assez simple, et du moment que tous les routeurs sont a la même heure (sisi, vraiment à la même heure, ntp obligatoire), tout va bien. La configuration est assez rapide.

Pour chaque interface passive, simplement :

interface em0.101
 ipv6 ospf6 passive

ospf6d va lui, rajouter une demi tonne de trucs, mais ce sont des valeurs par défaut, et y’a pas moyen de les faire disparaître, alors, le mieux est juste des les ignorer.

Ensuite, vient la configuration du routeur ospf6 lui même :

router ospf6
 router-id 0.0.0.1
 redistribute connected
 redistribute static
 interface em0.11 area 0.0.0.0

Tout ça, c’est facile, et ça marche tout seul. Il y a juste un truc, c’est qu’ils ont du penser qu’il était inutile d’ajouter une fonctionnalité basique, appelée default-information originate, vous savez la petite directive qui dit “moi, je sais comment aller ou si vous vous savez pas”. Faut croire qu’en ipv6 ça ne sert pas…

Maintenant, BGP, là, par contre, y’a une subtilité, qui n’est bien sur, pas vraiment documentée, et je l’ai découverte après plusieurs jours, alors que je n’avais plus aucun espoir, et que je cherchait autre chose, au détours d’un mail piégé. Donc, ça donne :

router bgp 20766
 neighbor 2001:910::16 remote-as 20766
 neighbor 2001:910::16 description ====== GIGA IPv6
 no neighbor 2001:910::16 activate
 !
 address-family ipv6
 neighbor 2001:910::16 activate
 neighbor 2001:910::16 next-hop-self
 neighbor 2001:910::16 soft-reconfiguration inbound
 exit-address-family

Alors, oui, y’a une subtilité, c’est le no neighbor 2001:910::16 activate qui dit gentiment que c’est juste pas la peine d’activer l’IPv4 sur ce peer et donc, pas la peine de lui balancer les centaines de milliers de préfixes IPv4, c’est celle là que j’ai cherché longtemps.

Posté par Mathieu Arnold le mercredi 21 novembre 2007 à 16:06

Rétroliens (0)

La discussion continue ailleurs…
Adresse du rétrolien : http://w.mat.cc/trackback/46

Commentaires

Le dimanche 2 janvier 2011 à 23:37, Arthur a écrit :
autre blague du genre : lorsque tu veux ajouter un peer v6, tu tappes un "conf t; router bgp XXXX; adress-family ipv6; neighbor A:B::C:D remote-as YYYY", et lorsque tu souhaites faire le "neighbor A:B::C:D peer-group MACHIN_V6" tu te rends compte que tu n'es plus dans la section adress-family, et du coup tu fais des conneries...
Le mercredi 6 février 2013 à 20:46, Mark a écrit :
Good points. I know in the Enterprise most netwrok teams I've worked involved with have had a difficult time understanding the entire netwrok as a system. This is why I believe it’s difficult for Application and Server Operations personnel to understand problems unique to the netwrok. MPLS solves a specific set of problems but as you stated when you move up the stack doesn't do as much for you. I can see your point at why content creators would be specifically interested.Like any new technology I think you will have to worry on vendor lock in if you are an early adopter. Once standards are accepted I think this will put pressure on netwrok vendors to innovate at the device level.This is my first introduction to OpenFlow technology. This post was a good introduction to the concept but I'll make sure to follow the link and see what types of problems Google is trying to solve.
Poster un commentaire
(facultatif)

« 無間道 - Infernal Affairs   Des gaufres, comme quand j’étais petit »