BGP anycast :
annoncer un service public depuis plusieurs sites
Même mécanisme que l'anycast interne, périmètre radicalement différent : il faut un AS, un préfixe annonçable et plusieurs transitaires — et la bascule se compte en dizaines de secondes, pas en secondes.
Sommaire
1. Ne pas confondre avec l'anycast interne
Le mécanisme est identique — une adresse annoncée depuis plusieurs endroits, le routage choisit — mais le périmètre change tout : les prérequis, le coût, le temps de bascule et ce qu'on a le droit d'en dire.
| Anycast interne | BGP anycast | |
|---|---|---|
| Périmètre | Le réseau privé du client | L'internet public |
| Protocole | OSPF ou IS-IS | BGP |
| Prérequis | Aucun AS, aucun préfixe public | Un AS, un préfixe annonçable, des transitaires |
| Bascule | Immédiate si un lien tombe, quelques secondes sinon | 30 s en configuration agressive, 180 s par défaut |
Si votre besoin est de rendre un résolveur DNS ou un collecteur de logs joignable partout dans un réseau multi-sites, c'est l'anycast interne qu'il vous faut, et il ne demande ni AS ni transit. Cette page traite l'autre cas : un service public servi depuis plusieurs sites.
La portée d'annonce est un paramètre, pas une propriété
La racine du DNS le montre mieux que n'importe quel schéma. Elle compte 13 identités, 12 opérateurs indépendants et 2 004 instances[1] en service au 23/08/2026 — et son FAQ distingue les instances globales, dont « l'annonce de route est autorisée à se propager sur tout l'Internet », des instances locales, dont l'annonce « est limitée aux réseaux proches ».
L'opérateur de K-root décrit le même montage en clair : le service est « assuré par un ensemble de nœuds distribués en anycast IPv4 et IPv6[2] », chaque nœud annonçant le préfixe 193.0.14.0/23 depuis l'AS25152. Une seule adresse, des dizaines de sites, et rien à changer côté client.
Autrement dit, la même technique sert une instance au monde entier ou à un seul voisinage réseau. C'est exactement le levier de l'anycast interne, à ceci près qu'on n'y garde que la portée locale — et c'est pour ça qu'il se monte sans AS ni transit.
2. Qui le pratique, et le documente
L'anycast n'est pas une curiosité de laboratoire : il porte le service le plus critique de
l'Internet depuis vingt ans. La racine du DNS, ce sont 13 identités — de
a.root-servers.net à m. — exploitées par
12 organisations indépendantes[3], Verisign étant le seul opérateur à en
porter deux.
| Identité | Opérateur | Instances |
|---|---|---|
| A | Verisign | 56 |
| B | University of Southern California, ISI | 6 |
| C | Cogent Communications | 13 |
| D | University of Maryland | 231 |
| E | NASA (Ames Research Center) | 328 |
| F | Internet Systems Consortium | 366 |
| G | US Department of Defense (NIC) | 6 |
| H | US Army (Research Lab) | 12 |
| I | Netnod | 91 |
| J | Verisign | 147 |
| K | RIPE NCC | — |
| L | ICANN | — |
| M | WIDE Project | — |
Relevé le 23/08/2026 : 2 004 instances en service[1] au total. Les compteurs par identité sont ceux publiés ce jour-là et bougent en permanence ; ceux de K, L et M n'ont pas pu être relevés à la même source. Le point n'est pas le chiffre exact, c'est l'écart : de 6 instances pour B et G à 366 pour F. La même identité, le même service, des tailles de déploiement sans commune mesure — et le client ne voit qu'une adresse.
D'autres services qui l'annoncent noir sur blanc
| Service | Ce que dit sa documentation |
|---|---|
| Google Public DNS 8.8.8.8 |
« Le routage anycast dirige vos requêtes vers le serveur Google Public DNS le plus proche[4] » — les clients « sont routés vers l'emplacement le plus proche qui annonce l'adresse anycast utilisée ». |
| Quad9 9.9.9.9 |
« Les systèmes sont « anycast », ce qui signifie que les requêtes seront automatiquement routées vers le système opérationnel le plus proche[5] », sur plus de 230 grappes de résolveurs dans plus de 110 pays. |
| Cloudflare NTP time.cloudflare.com |
Sert son NTP public depuis son « réseau anycast mondial[6] », derrière quatre adresses seulement. |
Et la discipline inverse compte autant. Google documente l'anycast pour son DNS public ; pour son NTP public, la même entreprise écrit « nos répartiteurs de charge » et le mot anycast n'apparaît pas. Cloudflare l'assume pour son service de temps, mais sa page sur le résolveur 1.1.1.1 parle de « centaines de villes » sans employer le terme. Deux services du même opérateur peuvent donc reposer sur des mécanismes différents : nous ne prêtons à personne une architecture qu'il n'a pas écrite.
3. Les prérequis réels
Ils sont peu nombreux mais chacun est bloquant, et ils s'obtiennent en semaines, pas en heures.
- • Un numéro d'AS. Il s'obtient auprès du registre régional, en justifiant d'un besoin de routage indépendant — typiquement plusieurs transitaires.
- • Un préfixe annonçable. Détenu en propre, ou mis à disposition par un fournisseur pour votre AS : les deux fonctionnent, et la seconde voie abaisse nettement la barrière d'entrée. C'est un point mal connu, souvent présenté comme impossible.
- • Plusieurs transitaires, ou une présence sur des points d'échange. Annoncer un préfixe depuis un seul opérateur ne donne aucune résilience : c'est lui le point de panne.
- • La compétence BGP en interne ou chez votre prestataire. Une annonce mal filtrée n'affecte pas que vous.
Le temps de bascule est le vrai compromis
Avec les temporisateurs par défaut, il faut trois minutes pour qu'une session BGP soit déclarée morte et que l'annonce disparaisse. On peut descendre vers 30 secondes en réglant plus agressivement, au prix d'une sensibilité accrue aux micro-coupures. Comparé aux une à trois secondes d'une adresse flottante, c'est un autre ordre de grandeur — et c'est le prix de la portée mondiale.
4. Le cas qui l'illustre le mieux : le NTP public
C'est l'exemple qui rend le sujet concret, et il a l'intérêt d'être contre-intuitif. Sur un réseau interne, mettre NTP en anycast dégrade le service : un client NTP est conçu pour interroger plusieurs sources et écarter celles qui mentent, et une adresse unique lui fait croire qu'il n'en a qu'une.
La question n'est pas « NTP s'anycaste ou pas »
C'est : qu'est-ce que l'anycast remplace ?
Sur un service public, la source était déjà unique : une adresse, un nom. L'annoncer
depuis plusieurs points de présence ne réduit pas le nombre de sources indépendantes du client —
cela le rapproche simplement de l'une d'elles. Il y gagne une latence plus faible, donc une
borne d'erreur plus serrée, et la survie à la perte d'un site. Que du gain.
C'est pour cela que Cloudflare sert son NTP public depuis ce que sa documentation appelle
son « réseau anycast
mondial[6] » — quatre adresses, deux en IPv4 et deux en IPv6, derrière
time.cloudflare.com — alors qu'il ne faut surtout
pas faire la même chose en interne.
Ce que ces opérateurs documentent eux-mêmes
Le sujet se prête mal à l'affirmation générale : chacun de ces services a fait un choix différent, et le dit. Relevé le 23 août 2026 sur leurs documentations respectives.
| Service | Ce que dit sa documentation | Modèle |
|---|---|---|
| Cloudflare time.cloudflare.com |
Annonce explicitement un « réseau anycast mondial », et ne publie que quatre adresses : 162.159.200.1, 162.159.200.123 et deux en IPv6. | Anycast assumé |
| Google time.google.com |
Écrit avoir bâti le service « avec nos répartiteurs de charge[7] et notre flotte d'horloges atomiques dans des centres de données partout dans le monde ». Le mot anycast n'y figure pas. | Non documenté |
| Netnod nts.netnod.se |
Publie dix noms distincts[8] — deux par ville, sur cinq villes suédoises : Stockholm, Göteborg, Malmö, Sundsvall, Luleå — plus un nom générique. | Sources nommées |
L'enseignement tient en une phrase : l'anycast ne se présume pas. Google décrit des répartiteurs de charge, pas des annonces BGP, et il serait malhonnête de lui prêter l'un pour l'autre. Trois opérateurs de temps, trois choix différents, trois documentations qui les assument — c'est le signe que la bonne réponse dépend du périmètre, pas d'une règle générale.
Avec NTS, la version sécurisée de NTP, s'ajoute une contrainte : l'établissement de clé passe par une session TLS et les jetons délivrés sont liés au serveur émetteur. La conséquence est concrète : Netnod indique faire tourner « les phases NTS-KE et d'horodatage sur des machines physiquement différentes ». Ce n'est pas un empêchement, mais c'est un coût d'entrée — il faut faire circuler un état cryptographique entre des machines que l'anycast est justement censé rendre interchangeables.
À l'inverse, un opérateur de temps à périmètre national comme Netnod expose des
sources distinctes, nommées par site — sth1,
gbg2, lul1… Le client sait alors à qui il parle, peut
auditer chaque source et conserve sa majorité — un argument qui compte pour du temps, qui horodate
des journaux et valide des certificats.
5. Le piège de la capacité
Il est identique à celui de l'anycast interne, et il reste le plus coûteux parce qu'il est silencieux. La bascule se compte en secondes ou en minutes ; la montée en capacité, en semaines.
Si chaque site a été dimensionné pour la charge qu'il traite au quotidien — ce qui est le cas par défaut — alors le retrait d'un site fait absorber sa charge par les survivants, en plus de la leur. Aucune erreur, aucune alerte de bascule : juste des temps de réponse qui s'allongent, puis des requêtes perdues. Un anycast se dimensionne en capacité résiduelle après retrait du plus gros site, jamais en simple présence.
L'autre point de surveillance est le même qu'en interne : vérifier que chaque instance annonce et répond, séparément. Une instance qui annonce sans répondre est un trou noir que rien ne signale, puisque du point de vue du routage tout va bien.
6. Ce qu'on décrit, et ce qu'on ne revendique pas
Nous opérons notre propre réseau et notre propre numéro d'AS, ce qui nous permet de parler de BGP autrement qu'en théorie — nous contribuons d'ailleurs au code du démon de routage que nous déployons, comme le montrent nos contributions open source.
Mais il y a une limite que nous préférons écrire
Le préfixe que nous annonçons nous est mis à disposition par notre fournisseur, il n'est pas détenu en propre. Nous pouvons donc expliquer précisément comment fonctionne l'anycast public et ce que font les grands opérateurs — nous ne le vendons pas comme une prestation clé en main. Si votre projet l'exige, nous vous accompagnons sur l'architecture et nous le disons franchement quand un partenaire est nécessaire.
Et dans la plupart des cas que nous rencontrons, la bonne réponse n'est pas là : c'est l'anycast interne, qui répond au même besoin sur le périmètre qui compte réellement pour une PME ou une ETI, sans AS, sans transit et sans délai d'obtention.
Questions fréquentes
Peut-on faire de l'anycast BGP sans posséder son propre préfixe ?
Oui, et c'est le point le moins connu du sujet. Un préfixe peut être mis à disposition par un fournisseur pour être annoncé depuis votre numéro d'AS : le mécanisme fonctionne exactement de la même façon. Ce qui reste indispensable, c'est le numéro d'AS lui-même et une présence chez plusieurs transitaires — sans quoi la résilience recherchée n'existe pas.
Combien de temps met une bascule BGP ?
Environ trois minutes avec les temporisateurs par défaut, le temps qu'une session soit déclarée morte et que l'annonce se retire. On peut descendre vers trente secondes en réglant plus agressivement, au prix d'une sensibilité accrue aux micro-coupures. C'est deux ordres de grandeur au-dessus d'une adresse flottante, et c'est le prix de la portée mondiale.
L'anycast BGP convient-il à un site web ?
Techniquement oui, et de très grands services fonctionnent ainsi. Mais il faut savoir qu'une session TLS qui change d'instance en cours de route meurt et doit être rétablie : tant que les chemins sont stables, l'impact se limite à des reconnexions rares. Pour une PME, un CDN ou un service DNS avec bascule sur test de santé apporte le même bénéfice sans exiger d'AS.
Faut-il de l'anycast pour servir du NTP public ?
Cela dépend du périmètre. Sur un service mondial servi depuis une source déjà unique, l'anycast n'enlève rien et rapproche le client : c'est ce que font les grands opérateurs. Sur un réseau interne, c'est l'inverse — remplacer plusieurs sources distinctes par une adresse unique prive le client de sa capacité à détecter une horloge fausse. Le bon réflexe en interne est une configuration par pool.
Sources
Les principales affirmations techniques de cette page sont étayées par les normes et documentations primaires suivantes. Liens consultés le 23 août 2026.
- [1] Racine du DNS — 13 identités, 12 opérateurs, nombre d’instances et portée globale / locale des annonces
- [2] K-root — « service assuré par un ensemble de nœuds distribués en anycast IPv4 et IPv6 », préfixe 193.0.14.0/23 annoncé depuis l’AS25152
- [3] IANA — liste officielle des 13 serveurs racine et de leurs opérateurs
- [4] Google Public DNS — « le routage anycast dirige vos requêtes vers le serveur le plus proche »
- [5] Quad9 — « les systèmes sont anycast », 230+ grappes de résolveurs dans 110+ pays
- [6] Time Services — NTP servi sur le « réseau anycast mondial », quatre adresses
- [7] Google Public NTP — « nos répartiteurs de charge », le mot anycast n’y figure pas
- [8] NTS — dix noms de serveurs distincts sur cinq villes ; NTS-KE et horodatage sur des machines séparées
Avez-vous vraiment besoin d'annoncer en BGP ?
Dans la plupart des cas que nous rencontrons, l'anycast interne répond au même besoin sans AS ni transit. Nous le disons avant de vous engager dans une démarche de plusieurs semaines.
Demander un devis