> 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/
