Si on compare avec un anycast interne à un FAI (ex : les DNS récursifs d'un FAI), on ne va pas annoncer les routes en BGP au sein de son propre AS, autant utiliser l'IGP pour ça. Donc, on va avoir la /32 portant le service DNS qui va être annoncé plusieurs fois dans OSPF/ISIS. Sur quoi on peut jouer pour connaitre le site qui a originé la route en IGP, ou pour modifier la façon dont sera vu cette route sur certain PE ? A priori, juste sur la métrique de cet IGP, et éventuellement les tags pour l'origine.
Pour du globaly anycast, vu qu'on parle maintenant d'annonce de route en BGP, effectivement l'idée la plus rapide serait d'adapter cette vision avec AS PATH et des communautés. Utiliser un ASPATH pour chaque site d'origine, c'est bien, surtout maintenant que les AS sur 32bits sont supportés sur les plateformes récentes, mais c'est pas super logique avec la notion d'AS déjà, et on connait les limitations d'un champ sur 32bit... Les communautés, comme le souligne Olivier, ont tendance à être toujours écrasées en entrée car, voyons les choses en face, c'est généralement de la tambouille interne à l'AS : est-ce que c'est bien ou pas de le faire, c'est une excellente question, mais le fait est que c'est comme ça, donc il faut faire avec. En clair, il faudrait une communauté, type SOO (site of origin), mappée sur un paramètre physique *normé* afin que tout le monde utilise la même chose (code aéroport du site, coordonnées GPS, age du capitaine), et avec un transit "mandatory" (MUST), ie non écrasable sur une annonce BGP. J'aime bien les coordonnées GPS, ça ferait des beaux plugins "googlemap" dans les outils de traceroute :D En attendant une éventuelle RFC normalisant ça, le n° d'AS différent par site semble le seul truc déployable rapidement. Sinon, pour troller dès le lundi : http://www.ietf.org/mail-archive/web/lisp/current/msg00398.html http://www.ietf.org/mail-archive/web/lisp/current/msg00420.html Effectivement, on pourrait alors mapper par exemple une communauté SOO sur le RLOC de l'ITR sur lequel est présent l'EID anycasté (désolé pour les acronymes pour ceux qui n'ont pas lu la doc sur LISP...) De cette manière, les couples EID/RLOC étant eux bien définis sur le réseaux (un EID pouvant être présent sur plusieurs RLOC), on a résolu le problème. Je crois même avoir lu quelque part que le RLOC peut être une @IP, une @MAC, et même des coordonnées GPS ... Mais bon là c'est bel et bien de la science-fiction :D Le 25 octobre 2011 12:41, Olivier Benghozi <olivier.bengh...@wifirst.fr> a écrit : > Les communautés BGP, c'est vrai que c'est "transitif optionnel", mais c'est > très fréquemment écrasé en entrée ou en sortie d'un AS, voire tout > simplement pas transmis par défaut (IOS par exemple). > Du coup, pas trop utilisable pour cet usage. > > Une autre possibilité serait d'avoir un AS unique prépendé un certain > nombre de fois sur chaque site d'annonce, ce nombre identifiant le site > d'origine. Mais ça serait crade, illisible, et rapidement limité/foireux vu > que l'AS path, au delà de 255, ça se passe mal dans une bonne partie > d'Internet. Donc non en fait :) > > > > Le 25 oct. 2011 à 11:48, Stephane Bortzmeyer a écrit : > > >> Mais cette politique a aussi des défauts : lorsqu'un routeur BGP > >> voit arriver une annonce pour un préfixe "anycasté", il ne sait pas > >> exactement de quel noeud elle vient. Cela peut compliquer le > >> déboguage des problèmes. > > > > Une question pour les experts BGP. Pour identifier l'origine d'une > > annonce d'un service anycasté, plutôt que d'avoir un numéro d'AS par > > site, comme le propose le RFC, pourquoi ne pas ajouter une communauté > > identifiant ladite origine ? > > > > Je ne vois qu'un seul inconvénient, le risque que certaines « looking > > glasses » (par exemple la passerelle DNS de routeviews.org) affichent > > l'AS path mais pas les communautés. > > > > > > --------------------------- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > -- Cordialement, Guillaume BARROT
