Pour un /32, la question ne se pose pas puisque l’annonce ne sera PAS propagée à tout Internet. Pas de problème de dampening dans ce cas :)
Après, je connais pas les détails financiers du projet, mais un /24 ça s’achète environ 12k€, un /23 entre 20k€-25k€, c’est pas la fin du monde. > Le 24 nov. 2022 à 14:54, r...@no-log.org a écrit : > > Eh bien non, de ce que l'équipe de geek a présenté, ils pensent arrêter > d'annoncer un /32, pas un /24..... comme je ne suis pas expert mais que > j'avais un gros doute, je me suis permis de venir poser la question ici :) > > En interne, il y a toute la quincaillerie qui permet de faire fonctionner > ça mais sur une interconnexion privée etre deux DC en iBGP. > > La démo : on a un service qui tourne sur le site 1 et sur le site 2. On > stoppe le service sur le site 1, AnyCast-HealthChecker détecte que le > service ne répond plus, il envoie à Bird une suppression d'annonce en /32 > (c'était indiqué comme ça sur un de leur schéma...) et Bird propage au > coeur de routage, en iBGP, sur le site 1 et site 2 et par la magie du > réseau le flux est rerouté vers le site 2 ! > > La démo est chouette mais leur but c'est de maintenant propager la modif > sur les peers BGP opérateurs qui filtreront tout /32. > > Il semble que l'équipe qui propose ça n'a pas forcément saisie qu'on ne > bascule pas un service "unitairement" en anycast dès qu'on passe en eBGP. > > (j'espère être clair mais si je me trompe dans la forme ou dans le fond, > vous me corrigerez ;) ) > > Ce que tu indiques sur la fiabilité du script est très pertinent, surtout > sur les gardes fous à mettre en place, mais AMHA seulement dans le cas > d'un reroutage d'un /24, pas d'un /32... > >> -le script doit être archi-blindax quant aux citères qu?il utilise pour >> décider que le service n?est pas bon >> -le script ne doit PAS avoir le droit de rétablir l?annonce BGP s?il l?a >> retirée 1 min avant (dampening, tout ça??). Je dirais même qu?il ne doit >> plus avoir le droit de ré-annoncer avant 15 ou 30 min >> -mais comme les devs sont des humains et qu?ils vont foirer, c?est sûr, je >> pense que le service doit tourner dans un /24 dont l?annonce est anycast, >> mais qu?il devrait y avoir un préfixe plus court (/22 ou /23 donc) qui est >> annoncé en permanence par un site seulement peut-être, dans l?éventualité >> certaine que le /24 soit dampené massivement un jour >> > > Bon je pense que je vais aller les voir pour être sûr qu'ils ont tous les > éléments... ou alors j'ai raté un truc. > > Sinon je vais jeter un oeil sur ExaBGP ;) > > Encore merci > >> >>> Le 24 nov. 2022 à 11:53, r...@no-log.org a écrit : >>> >>> Hello David, >>> >>> Merci pour ta réponse. Sur le principe du filtrage par prefix, je m'en >>> doutais et du coup cela ne fonctionnera pas comme ils l'envisagent :-/ >>> >>> Par rapport au script python interconnecté à Bird pour faire les mises à >>> jour de route sur des coeurs de réseau BGP qui sont, eux même, >>> interconnectés à des opérateurs, je ne sais pas quoi penser de la >>> fiabilité? >> >> >> On parle bien de la même chose ? >> >> Un script python, par la méthode de son choix, vérifie qu?un service sur >> un POP du client répond mal. >> Si le service répond mal, le script dit à Bird d?arrêter d?annoncer >> X.X.X.X/24 au coeur de réseau de ce POP donc le /24 et n?est plus >> redistribué pas aux transits/peerings. >> Les clients qui étaient servis par ce POP se retrouvent donc acheminés >> vers le prochain POP le plus « proche » (proche = AS-PATH le plus court). >> >> Je ne vois pas de souci de fiabilité, SI (un grand SI): >> -le script doit être archi-blindax quant aux critères qu?il utilise pour >> décider que le service n?est pas bon >> -le script ne doit PAS avoir le droit de rétablir l?annonce BGP s?il l?a >> retirée 1 min avant (dampening, tout ça??). Je dirais même qu?il ne doit >> plus avoir le droit de ré-annoncer avant 15 ou 30 min >> -mais comme les devs sont des humains et qu?ils vont foirer, c?est sûr, je >> pense que le service doit tourner dans un /24 dont l?annonce est anycast, >> mais qu?il devrait y avoir un préfixe plus court (/22 ou /23 donc) qui est >> annoncé en permanence par un site seulement peut-être, dans l?éventualité >> certaine que le /24 soit dampené massivement un jour >> >> >> >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
