Anycast interne : un service, une IP, dans chaque VLAN et chaque site

1. Le problème que ça résout

Une entreprise à plusieurs sites finit toujours par avoir des services d'infrastructure dupliqués : un résolveur DNS par site, un collecteur de logs par site, un proxy sortant par site. Et chacun est déclaré en dur dans la configuration réseau des postes — dans les paramètres distribués par DHCP, VLAN par VLAN.

Ça fonctionne parfaitement, jusqu'au jour où un site tombe. Les postes de ce site ont beau avoir un second résolveur déclaré, il est souvent à l'autre bout du réseau et le délai d'attente sur le premier se paie sur chaque requête. Et si l'on veut basculer proprement, il faut reprendre les paramètres de quarante VLAN — pendant l'incident.

L'anycast interne inverse le problème. Le service est déclaré une fois, sous une adresse unique, partout. Ce sont les instances qui bougent, pas la configuration des clients. Un site tombe : ses instances cessent d'annoncer, le routage envoie ailleurs, et personne n'a rien à modifier.

2. Le principe : une IP, plusieurs machines, le routage choisit

Plusieurs machines portent exactement la même adresse et l'annoncent chacune au réseau. Les routeurs reçoivent donc plusieurs chemins vers cette adresse et retiennent le plus court selon leur métrique. Chaque client est ainsi servi par l'instance la plus proche au sens du routage, sans le savoir et sans configuration particulière.

Quand une instance disparaît, elle cesse simplement d'annoncer. Sa route s'efface, les routeurs retiennent la suivante, et le trafic part ailleurs. Il n'y a pas de bascule à proprement parler : il n'y a qu'un chemin qui devient le meilleur parce que le précédent n'existe plus. Le temps de réaction est celui de la convergence du routage, pas celui d'un délai applicatif.

Ni internet, ni transit, ni numéro d'AS

C'est le malentendu le plus courant sur le sujet : l'anycast est associé au BGP et aux opérateurs, donc réputé hors de portée. Or le mécanisme ne dépend pas du protocole. Sur un réseau d'entreprise, OSPF (RFC 2328^[1]) ou IS-IS (RFC 1195^[2]) font exactement le même travail, sur des adresses prises dans votre propre plan d'adressage privé. La plupart des réseaux multi-sites en font déjà tourner un.

L'exemple qui explique tout : les serveurs racine du DNS

Le DNS mondial repose sur treize adresses de serveurs racine. Treize adresses, mais des centaines de machines réparties sur la planète : chaque adresse est annoncée depuis de très nombreux sites, et votre résolveur atteint celle qui lui est la plus proche sans jamais savoir laquelle. C'est le même mécanisme que celui décrit ici, à une autre échelle. Les bonnes pratiques d'exploitation d'un service anycast sont documentées dans les RFC 4786^[3] et RFC 7094^[4].

3. Ce que nous déployons concrètement

Le montage tient en trois éléments, et le troisième est celui que tout le monde oublie.

1. Une adresse par service, portée en loopback

Un /32 en IPv4, un /128 en IPv6, configuré sur l'interface de bouclage de chaque instance — pas sur une interface physique. C'est important : l'adresse reste ainsi joignable quelle que soit la carte réseau empruntée, et elle ne dépend pas de l'état d'un lien particulier.

2. Un démon de routage sur chaque instance

FRRouting^[5] ou BIRD^[6], qui participe à l'IGP du réseau et annonce ce préfixe. Le serveur devient, pour cette seule adresse, un routeur parmi les autres.

3. Une annonce conditionnée à la santé du service

C'est le point critique, et c'est là que se jouent les déploiements ratés. L'annonce doit suivre le service, pas la machine. Si le démon de routage continue d'annoncer alors que le résolveur qu'il est censé servir est mort, le routage envoie consciencieusement du trafic dans un trou noir. Rien ne bascule, puisque du point de vue du réseau tout va bien — et c'est bien pire qu'une panne franche, parce que personne ne s'en aperçoit. On conditionne donc la redistribution du préfixe à un test réel du service, exactement comme le bloc de vérification de keepalived au niveau 2.

Une adresse pour tout le réseau, ou une par VLAN ?

Nous partons généralement d'une adresse unique : c'est le plus simple à déployer, à documenter et à reprendre. On segmente ensuite là où il y a une raison — filtrer plus finement, contenir le trafic d'un périmètre sensible, ou garantir qu'un site garde son service local même si le cœur de réseau est coupé. Segmenter par principe multiplie la configuration sans rien apporter.

4. Les trois pannes que ça absorbe

La perte d'un nœud

Les autres instances du même site absorbent la charge. Le chemin change de quelques microsecondes de métrique, personne ne voit rien.

La perte d'un datacenter

Le préfixe disparaît de ce site, le routage converge vers les autres. Le temps de bascule est celui de la convergence de l'IGP — de l'ordre de la seconde sur un réseau bien réglé — et aucun client n'a rien à reconfigurer.

Le piège que personne ne mentionne : la capacité

La bascule se compte en secondes. La montée en capacité, en semaines. Si chaque site a été dimensionné pour sa propre charge — ce qui est le cas par défaut, puisque c'est ce que chacun traite au quotidien — alors les survivants se répartissent la charge du site perdu en plus de la leur. À deux sites, cela revient à doubler ; à cinq, l'augmentation est plus douce mais elle arrive sans préavis. Sans erreur, sans 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, pas en simple présence. C'est le premier calcul que nous faisons, et c'est souvent celui qui décide du nombre d'instances.

5. Répartition géographique de charge — et ses limites

L'anycast fait de la répartition de charge sans qu'on lui demande : chaque client est servi par l'instance la plus proche, ce qui répartit naturellement le trafic par zone de routage et réduit la latence. Le tout sans configuration côté client, sans adresse virtuelle à gérer et sans aucun composant central à redonder.

Ce qu'il ne fait pas

• Aucune pondération. Un site équipé d'une grosse machine reçoit la même part qu'un site avec une petite, si les métriques de routage sont comparables.
• Aucun test applicatif côté réseau. Le routage ne sait pas si le service répond correctement, seulement si la route existe — d'où le point critique du §3.
• Aucune persistance de session. Rien ne garantit que deux requêtes du même client atteignent la même instance.

Quand ces limites deviennent gênantes, on change d'outil : un répartiteur en couche 4 pour pondérer et tester, ou en couche 7 pour router selon l'URL et gérer les sessions collantes — c'est l'objet de notre page répartition de charge — l'anycast reste alors utile en amont, pour rendre le répartiteur lui-même joignable depuis partout.

6. Les services qui s'y prêtent — et ceux qui ne s'y prêtent pas

Excellents

Sans état, requêtes courtes, réponse immédiate :

• Résolveurs DNS internes
• Collecteurs de logs (syslog)
• Serveurs RADIUS
• Proxies sortants

Avec précaution

Tout ce qui tient une session : HTTP en connexion persistante, TLS de longue durée. Sur un réseau interne stable, les chemins changent rarement en cours de connexion et l'impact se limite à une reconnexion occasionnelle. Si les chemins oscillent, c'est le mauvais outil.

Exclus

Tout ce qui a des données à répliquer. L'anycast ne réplique rien : il dirige du trafic, point. Mettre une base de données derrière une adresse anycast donne plusieurs bases indépendantes qui divergent, et un client qui ne sait pas laquelle il interroge.

7. Le contre-exemple qui surprend : NTP

NTP coche toutes les cases de la colonne « excellents » : UDP, sans état, échange très court. C'est exactement le profil du service qu'on met en anycast sans réfléchir. Et en réseau interne, c'est une erreur.

Le bon axe n'est pas « NTP s'anycaste ou pas »

C'est : qu'est-ce que l'anycast remplace ?

Il répartit les sites d'une source déjà unique

Le client n'avait qu'une source, il en a toujours une. Rien ne change à son modèle, et il gagne de la proximité — donc une borne d'erreur plus serrée — et la survie à la perte d'un site. Que du gain.

Il remplace des sources distinctes par une seule IP

Là, on casse l'algorithme. Un client NTP est conçu pour interroger plusieurs sources en parallèle, les comparer et écarter celles qui mentent. Avec une adresse unique, il croit n'avoir qu'une source et perd sa capacité à détecter une horloge fausse. On dégrade le service en croyant le fiabiliser.

En réseau interne, on est presque toujours dans le second cas : il y avait plusieurs serveurs de temps déclarés, on les remplacerait par une adresse. La bonne approche est donc l'inverse de l'anycast — une configuration par pool, avec plusieurs entrées résolues sur des adresses distinctes. La redondance se joue côté client, et le protocole la gère mieux que le routage.

Le cas NTS

Avec NTS, la sécurisation de NTP, l'établissement de clé passe par une session TLS et les jetons délivrés sont liés au serveur qui les a émis. Ce n'est pas un empêchement absolu : les grands opérateurs partagent et font tourner les clés maîtresses sur toute leur flotte, délibérément. Mais c'est un coût d'entrée — et c'est précisément pour cela que les opérateurs de taille modeste ne s'y engagent pas.

Trois opérateurs, trois modèles

Opérateur	Modèle	Ce que voit le client
Netnod	Sources distinctes, nommées par site — Stockholm, Göteborg, Malmö, Sundsvall, Luleå, chacune en deux exemplaires	Plusieurs serveurs, majorité préservée
Grands opérateurs mondiaux	Anycast : une adresse annoncée depuis des dizaines de points de présence	Une source, plus proche et plus stable
RDEM Systems	Pool distribué, résolution en rotation sur plusieurs adresses	Plusieurs serveurs, majorité préservée

Relevé sur la documentation publique de Netnod, août 2026 — aucune mention d'anycast, et des noms de serveurs explicitement rattachés à un site.

La ligne de partage, et pourquoi elle tient

Les opérateurs de temps à périmètre national ou régional exposent des sources distinctes ; les opérateurs mondiaux anycastent. Ce n'est pas seulement une affaire d'échelle : avec des serveurs nommés par site, le client sait à qui il parle, peut auditer chaque source et conserve sa majorité. Avec une adresse anycast, il ne peut pas savoir quelle instance lui a répondu. Pour du temps — qui horodate des journaux, valide des certificats et sert de preuve — cette vérifiabilité n'est pas un détail.

Les outils de ce niveau

Outil	Ce qu'on en dit
FRRouting^[5]	Le démon de routage que nous déployons chez nos clients — et que nous utilisons pour notre propre réseau. Nous en corrigeons aussi le code : voir nos contributions open source.
BIRD^[6]	L'alternative, plus légère, quand on n'a besoin que d'annoncer un préfixe
OSPF^[1]	Le protocole interne le plus courant en entreprise
IS-IS^[2]	Quand le réseau est déjà en IS-IS, on ne le change pas pour ça

8. Ce que ça n'est pas

• Ce n'est pas un répartiteur de charge. Pas de pondération, pas de health-check applicatif côté réseau, pas de session collante. La granularité, c'est la table de routage.
• Ce n'est pas de la géo-répartition intercontinentale. Sur un réseau d'entreprise, « multi-site » veut généralement dire quelques bâtiments ou quelques datacenters — pas plusieurs continents. Le mécanisme est le même, l'échelle n'a rien à voir.
• Ce n'est pas de la réplication. Point le plus important, et celui qui produit les pires surprises : l'anycast dirige du trafic et ne synchronise rien. Ce qui doit être cohérent entre les instances doit être répliqué par autre chose.
• Le « plus proche » n'est pas géographique. C'est le plus proche selon les métriques du routage. Un site à trois kilomètres peut être plus loin, au sens du réseau, qu'un site à trois cents — et c'est parfois la découverte du premier test.

9. Ce que nous exploitons ensuite

Nous avons déjà déployé du DNS anycast en réseau privé en production, sur plusieurs infrastructures clientes multi-sites. Ce que l'expérience apprend tient en deux points de supervision, et ni l'un ni l'autre n'est fourni par défaut.

• Surveiller que chaque instance annonce ET répond. Les deux séparément, et la cohérence entre les deux. Une instance qui annonce sans répondre est un trou noir ; une instance qui répond sans annoncer est une capacité payée et inutilisée. Les deux situations sont silencieuses.
• Surveiller la capacité résiduelle. Combien de sites peut-on perdre avant que les survivants saturent ? Cette valeur bouge à chaque ajout de VLAN ou de population, et personne ne la recalcule spontanément.
• Tester le retrait volontaire. Retirer une instance de l'annonce et vérifier que le trafic bascule proprement, en mesurant le temps réel. C'est la seule façon de savoir ce que vaut la convergence sur ce réseau précis.

Tout cela relève de l'exploitation courante, incluse dans nos forfaits d'infogérance, avec l'astreinte 24/7 pour ce que l'automatisme ne sait pas traiter.

10. Quand une bascule DNS suffit

L'alternative honnête, et elle convient à beaucoup de situations : un enregistrement DNS avec plusieurs adresses et un test de santé qui retire celles qui ne répondent plus. C'est moins élégant, ça ne demande aucune compétence réseau, et le délai de bascule est celui de la durée de vie de l'enregistrement — quelques dizaines de secondes à quelques minutes.

La bascule DNS suffit si…

• Une minute d'indisponibilité est tolérable
• Le réseau n'a pas d'IGP, ou l'équipe ne le maîtrise pas
• Les clients respectent les durées de vie annoncées
• Il n'y a que deux ou trois sites

L'anycast se justifie si…

• Le service est déclaré en dur dans de nombreux VLAN
• La bascule doit être invisible et immédiate
• La proximité compte pour la latence
• Un IGP tourne déjà et l'équipe sait l'exploiter

Dans le doute, nous commençons par la bascule DNS. Elle se met en place en une journée, elle est réversible, et elle donne une mesure réelle de ce que la bascule coûte avant d'investir dans une architecture plus élaborée.

Questions fréquentes

Quelle différence entre anycast et répartition de charge ?

Un répartiteur de charge est un composant qui reçoit chaque requête, décide où l'envoyer et peut pondérer ses choix ou vérifier la santé applicative de ses cibles. L'anycast ne reçoit rien : il n'existe pas de composant central, c'est la table de routage qui dirige le trafic vers l'instance la plus proche au sens du routage. On obtient donc une répartition, mais sans pondération, sans persistance de session et sans test applicatif. C'est plus robuste parce qu'il n'y a rien à redonder, et beaucoup moins fin.

Peut-on faire de l'anycast sans numéro d'AS ni préfixe public ?

Oui, et c'est tout le sujet de cette page. L'anycast public sur internet demande un numéro d'AS, un préfixe annonçable et du BGP. L'anycast interne ne demande rien de tout cela : il suffit d'un protocole de routage interne, OSPF ou IS-IS, que la plupart des réseaux d'entreprise multi-sites font déjà tourner. On y annonce un préfixe pris dans son propre plan d'adressage privé, et le mécanisme est identique.

Quels services peut-on mettre en anycast interne ?

Ceux qui n'ont pas d'état à conserver entre deux échanges et dont les requêtes sont courtes : résolveurs DNS internes, collecteurs de logs, serveurs RADIUS, proxies sortants. À l'inverse, tout ce qui maintient une session ou détient des données à répliquer s'y prête mal, parce que l'anycast ne réplique rien du tout — il se contente de diriger le trafic. Un service à état mis en anycast donne une infrastructure qui fonctionne jusqu'au premier changement de chemin.

L'anycast fonctionne-t-il pour un site web en HTTPS ?

Sur un réseau interne stable, en pratique oui, parce que les chemins changent rarement en cours de connexion. Mais c'est un usage à manier avec précaution : une connexion TLS est un état partagé entre le client et une instance précise, et si le routage bascule au milieu, la session meurt et doit être rétablie. Tant que les bascules restent des événements rares, l'impact se limite à une reconnexion. Si les chemins oscillent, c'est le mauvais outil.

Faut-il un anycast par VLAN ou un seul pour tout le réseau ?

Cela dépend de ce que vous voulez maîtriser. Une adresse unique pour tout le réseau est la plus simple à déployer et à documenter, et le routage se charge de diriger chacun vers l'instance la plus proche. Une adresse par VLAN coûte plus de configuration mais permet de contenir le trafic dans un périmètre, de filtrer plus finement et de garder un service local même si le cœur de réseau est coupé. Nous partons généralement d'une adresse unique et nous ne segmentons que là où le filtrage ou le confinement le justifie.

Que se passe-t-il si une instance annonce mais ne répond plus ?

C'est le scénario le plus grave de cette architecture, et il est silencieux. Le routage envoie du trafic vers une instance qui l'accepte et ne le traite pas : un trou noir. Rien ne bascule, puisque du point de vue du réseau tout va bien. La réponse est structurelle : l'annonce doit être conditionnée à la santé réelle du service, de sorte qu'un démon mort entraîne le retrait de la route. C'est le point que nous vérifions en premier sur un déploiement existant.

Que se passe-t-il si un datacenter entier disparaît ?

Les instances de ce site cessent d'annoncer, le routage converge, et le trafic part vers les sites restants. La bascule est propre et ne demande aucune reconfiguration côté client. Le piège est ailleurs : la bascule se compte en secondes, la montée en capacité non. Si chaque site a été dimensionné pour sa propre charge, les survivants absorbent celle du site perdu en plus de la leur et saturent sans bruit. Un anycast se dimensionne en capacité résiduelle, pas seulement en présence.

Faut-il mettre son serveur NTP en anycast ?

En réseau interne, non — et le raisonnement est contre-intuitif. Un client NTP est conçu pour interroger plusieurs sources en parallèle, les comparer et écarter celles qui mentent. Remplacer des sources distinctes par une seule adresse anycast lui fait croire qu'il n'a qu'une source : il perd la propriété qui fait sa fiabilité. La bonne approche en interne est une configuration par pool, avec plusieurs adresses distinctes. En revanche, sur un service public déjà servi depuis une source unique, l'anycast n'enlève rien et apporte de la proximité : c'est ce que font les grands opérateurs de temps.

Combien de VLAN faudrait-il reconfigurer si un de vos sites tombait ?

Si la réponse est « beaucoup », l'anycast interne mérite d'être évalué. Nous auditons le réseau existant et nous disons franchement si le jeu en vaut la chandelle.

Demander un audit

Sommaire