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/
