Vous annoncez 203.0.113.53 depuis Toulouse. Vous annoncez le même 203.0.113.53 depuis Bordeaux. Et Paris. Trois sites, une seule adresse IP. Un client à Madrid tape cette IP : BGP l'envoie sur le POP qui lui paraît le plus proche, sans qu'aucun load-balancer ne soit dans la boucle, sans DNS round-robin, sans bascule à orchestrer. C'est anycast. La table de routage globale fait le travail de répartition géographique, gratuitement.
Le principe tient en une phrase : un même préfixe annoncé depuis N endroits, et chaque routeur d'Internet choisit la sortie qui lui coûte le moins cher selon ses propres critères BGP. Ce n'est pas de la magie, c'est le comportement normal du protocole appliqué à dessein. Les serveurs racine du DNS tournent là-dessus depuis le milieu des années 2000, les gros résolveurs publics aussi, et les CDN en ont fait leur colonne vertébrale.
Comment BGP choisit le POP
Quand plusieurs POP annoncent le même préfixe, chaque routeur tiers reçoit plusieurs chemins vers cette destination et n'en garde qu'un. Le critère dominant en pratique, c'est la longueur d'AS_PATH : le chemin qui traverse le moins d'AS gagne. À AS_PATH égal, entrent en jeu la préférence locale, le MED, puis le tie-break IGP, le fameux hot-potato qui fait sortir le trafic par le point de sortie le plus proche dans le réseau de l'opérateur. La RFC 7094 détaille les implications architecturales de ce modèle : « le plus proche » au sens BGP n'est pas le plus proche géographiquement, c'est le plus proche topologiquement. Un client physiquement à 50 km d'un POP peut très bien être routé vers un POP à 800 km si son opérateur a un meilleur chemin AS vers ce dernier. On ne contrôle pas la décision des AS tiers, on l'influence.
Le failover, lui, est natif et c'est là que l'élégance opère. Un POP tombe ? Il cesse d'annoncer le préfixe. Sa session BGP retire la route, les voisins reconvergent, et le trafic qui partait vers ce POP se reporte sur les autres POP qui annoncent toujours. Aucune intervention, aucun script de bascule à déclencher. La convergence BGP se mesure en secondes à dizaines de secondes selon la topologie, pas en minutes. C'est le mécanisme de retrait d'annonce, décrit côté exploitation par la RFC 4786, qui donne à anycast sa résilience.
UDP idéal, TCP avec une nuance
Anycast adore les protocoles sans session. DNS sur UDP, c'est le cas d'école : une requête, une réponse, chaque paquet est indépendant. Si le routage change entre deux requêtes, on s'en fiche, la requête suivante part simplement vers un autre POP. Aucune notion d'état à préserver. C'est pour ça que le DNS a été le premier gros usage d'anycast et qu'il reste le plus naturel.
TCP marche aussi, mais il y a un piège qu'il faut comprendre avant de l'ignorer. Une session TCP a un état, partagé entre le client et un POP précis. Si, en cours de session, le routage bascule et que les paquets du même flux commencent à arriver sur un autre POP, ce POP ne connaît pas la session, il répond par un RST, et la connexion casse. Le scénario existe. Mais en pratique il est rare, pour deux raisons. D'abord la table de routage globale est stable sur l'échelle de temps d'une session HTTP : on ne reconverge pas toutes les trente secondes. Ensuite l'ECMP, quand un routeur a plusieurs chemins de coût égal, répartit les flux par hachage du 5-tuple (la RFC 2991 décrit ces mécanismes de sélection multipath), donc un flux donné reste collé au même next-hop tant que l'ensemble ECMP ne change pas.
Le risque réel de coupure TCP survient lors d'un changement de topologie : un POP qui apparaît, un lien qui tombe, une reconvergence qui redistribue les flux. À ce moment, les sessions en cours qui se font réaffecter cassent. Pour du HTTP court (une requête, une réponse, connexion fermée), c'est invisible : le client rejoue, atterrit sur le nouveau POP, terminé. Pour une session longue (un long polling, un upload de plusieurs minutes, une connexion persistante), une reconvergence en plein milieu coupe. La règle qu'on applique : anycast pour DNS et pour du HTTP stateless, sans hésiter ; pour des sessions longues stateful, on garde anycast pour atteindre le POP puis on bascule la session sur une IP unicast propre au POP, ou on accepte le reconnect côté applicatif.
Le health-check qui pilote l'annonce
Le failover natif de BGP a une limite brutale : il ne réagit qu'à la mort du POP ou de sa session BGP. Si le routeur du POP est vivant et continue d'annoncer le préfixe, mais que le service derrière (le résolveur DNS, le serveur web) est planté, BGP n'en sait rien. Il continue d'attirer du trafic vers un POP qui répond par des erreurs. Le trou noir applicatif.
La parade : coupler l'annonce BGP à l'état réel du service. Un health-check teste le service localement et pilote l'annonce. Service up, on annonce. Service down, on retire l'annonce, et le trafic se reporte sur les autres POP exactement comme si le POP était mort. C'est ce couplage qui transforme anycast d'un répartiteur géographique en une vraie haute dispo.
Deux outils dominent. ExaBGP, qui parle BGP et exécute des scripts arbitraires pour décider d'annoncer ou de retirer. Et BIRD plus un script de supervision, l'approche retenue par des outils dédiés comme anycast-healthchecker. Le principe est le même : un check périodique, et selon son résultat la route est exportée ou non vers les voisins. Avec ExaBGP, le squelette ressemble à ça :
#!/usr/bin/env python3
# Health-check piloté par ExaBGP : annonce si le service répond
import sys, time, subprocess
PREFIX = "203.0.113.53/32 next-hop self"
def service_ok():
r = subprocess.run(["dig", "+short", "+time=1", "+tries=1",
"@127.0.0.1", "id.server", "CH", "TXT"],
capture_output=True)
return r.returncode == 0 and r.stdout.strip() != b""
announced = False
while True:
if service_ok() and not announced:
sys.stdout.write(f"announce route {PREFIX}\n"); sys.stdout.flush()
announced = True
elif not service_ok() and announced:
sys.stdout.write(f"withdraw route {PREFIX}\n"); sys.stdout.flush()
announced = False
time.sleep(2)
Le détail qui compte : il faut de l'hystérésis. Un service qui clignote (up, down, up, down) provoquerait un flapping de route, et le flapping BGP, c'est le mal absolu, ça se propage et ça peut déclencher du route-flap-damping chez les voisins, qui vous mettent au coin pendant des minutes. La discipline à tenir : plusieurs checks consécutifs réussis avant de réannoncer, on retire vite mais on revient lentement. La logique de health-check qui pilote une bascule, on la retrouve dans la haute disponibilité par VRRP avec Keepalived, à ceci près qu'anycast joue à l'échelle inter-sites quand VRRP joue dans un même LAN.
Le drain propre, pour la maintenance
Couper un POP d'un coup pour une maintenance, c'est faisable mais sale : les sessions TCP en cours cassent net. Le drain propre consiste à dévier le trafic en douceur avant d'éteindre. Trois techniques, par ordre de finesse.
La plus simple, l'AS-path prepend : on rallonge artificiellement l'AS_PATH annoncé par le POP qu'on veut vider (on répète son propre ASN deux ou trois fois). Le chemin devient moins attractif, les routeurs tiers préfèrent les autres POP, le trafic se déplace progressivement. La plus précise, les BGP communities : si votre transitaire les supporte, vous signalez « ne préfère pas ce POP » via une community convenue, et le contrôle est chirurgical. La plus radicale, le withdraw pur : on retire l'annonce, point. À combiner avec une fenêtre de drain où on attend que les sessions existantes se terminent (on surveille avec ss) avant de couper le service.
L'ordre qu'on applique pour une maintenance planifiée : prepend ou community d'abord pour dévier le nouveau trafic, on laisse les sessions en cours se vider quelques minutes, puis withdraw, puis on touche au service. Pour gérer ces annonces à l'échelle et garder une trace versionnée des configs BGP de chaque POP, la sauvegarde automatisée des configurations réseau avec Oxidized évite de redécouvrir à la main ce qui était annoncé où.
Ce qu'il faut avoir avant de commencer
Anycast n'est pas un truc qu'on bricole sur une IP de VPS. Il faut des ressources à soi. Un ASN, d'abord, le vôtre, attribué par votre RIR. Des préfixes à vous ensuite, et pas n'importe lesquels : en IPv4, le /24 est la limite plancher acceptée sur Internet. La RFC 7454 (BCP 194) rappelle que les préfixes plus spécifiques qu'un /24 sont généralement filtrés et n'atteignent pas la table globale. Donc pour faire de l'anycast IPv4, vous immobilisez un /24 entier par service anycasté, ou vous le partagez intelligemment. En IPv6, c'est le /48 qui sert de plancher. Sans ASN ni préfixes propres, pas d'anycast : vous ne pouvez pas annoncer la même IP depuis plusieurs endroits si cette IP appartient à l'espace de votre hébergeur.
Et il faut être multi-site avec du BGP partout. Chaque POP doit avoir une session BGP, idéalement vers plusieurs transitaires ou points d'échange, pour que le retrait d'annonce d'un POP soit vu largement et vite. Un anycast à deux POP mal connectés, c'est moins résilient qu'un seul POP bien connecté. Pour le montage des sessions sur chaque site, l'article sur le routeur BGP avec FRRouting couvre la configuration des voisins et des filtres qui encadrent vos annonces anycast.
Verdict
Anycast est la bonne réponse quand vous voulez de la proximité géographique et un failover sans orchestration, sur un service qui supporte le sans-session ou le reconnect. DNS faisant autorité, résolveurs, endpoints HTTP stateless, distribution de contenu : faites de l'anycast, c'est fait pour ça. Pour des sessions longues stateful, ne forcez pas : anycast pour entrer, unicast pour la session, ou reconnect applicatif assumé. Et n'annoncez jamais un préfixe anycast sans health-check couplé à l'annonce, sinon vous remplacez la panne franche par le trou noir applicatif, qui est pire parce qu'il ne se voit pas.
Annoncer un service depuis plusieurs points de l'AS41652 avec retrait piloté par l'état réel du service, c'est ce qu'on fait depuis les deux DC France où nous sommes implantés, Toulouse (Fullsave) et Bordeaux (TDF), plus le PoP de Paris. Si vous voulez bâtir de l'anycast et qu'il vous manque l'ASN, les préfixes ou le transit multi-site pour le porter, on opère du transit IP sur lequel poser vos annonces.
Côté résolution, anycast et DNS forment un couple naturel : héberger un résolveur ou un faisant-autorité en anycast suppose une stack DNS propre, voir la mise en place de PowerDNS avec dnsdist pour la partie service derrière l'IP anycastée.
Sources
- RFC 7094, Architectural Considerations of IP Anycast : modèle anycast, notion de proximité topologique et limites.
- RFC 4786, Operation of Anycast Services : bonnes pratiques d'exploitation, retrait d'annonce et failover.
- RFC 2991, Multipath Issues in Unicast and Multicast Next-Hop Selection : ECMP, hachage de flux et stabilité des sessions.
- RFC 7454, BGP Operations and Security (BCP 194) : filtrage de préfixes, plancher /24 IPv4 et /48 IPv6.
- Turning on Anycast on B-Root, RIPE Labs : retour concret d'anycast sur un serveur racine DNS.
- Healthcheck Module, ExaBGP Wiki : couplage annonce BGP et état du service, drain et hystérésis.
