Internal Anycast: One Service, One IP, in Every VLAN and Every Site

1. The problem it solves

A company with several sites always ends up with duplicated infrastructure services: one DNS resolver per site, one log collector per site, one outbound proxy per site. And each of them is hard-coded into the network configuration of workstations — in the settings handed out by DHCP, VLAN by VLAN.

It works perfectly, until the day a site goes down. Workstations there may well have a second resolver declared, but it is often at the far end of the network and the timeout on the first one is paid on every query. And if you want to fail over cleanly, you have to revisit the settings of forty VLANs — during the incident.

Internal anycast inverts the problem. The service is declared once, under a single address, everywhere. It is the instances that move, not the clients' configuration. A site goes down: its instances stop announcing, routing sends traffic elsewhere, and nobody has anything to change.

2. The principle: one IP, several machines, routing decides

Several machines carry exactly the same address and each announces it to the network. Routers therefore receive several paths to that address and keep the shortest by their metric. Every client is thus served by the nearest instance in routing terms, without knowing it and without any particular configuration.

When an instance disappears, it simply stops announcing. Its route is withdrawn, routers keep the next one, and traffic goes elsewhere. There is no failover as such: there is just a path that becomes the best one because the previous one no longer exists. The reaction time is that of routing convergence, not that of an application timeout.

No internet, no transit, no AS number

This is the most common misunderstanding on the subject: anycast is associated with BGP and operators, and therefore assumed to be out of reach. But the mechanism does not depend on the protocol. On an enterprise network, OSPF (RFC 2328^[1]) or IS-IS (RFC 1195^[2]) do exactly the same job, on addresses taken from your own private addressing plan. Most multi-site networks already run one.

The example that explains everything: the DNS root servers

The global DNS rests on thirteen root server addresses. Thirteen addresses, but hundreds of machines spread across the planet: each address is announced from a great many sites, and your resolver reaches whichever is nearest without ever knowing which one. It is the same mechanism described here, at another scale. Operational best practice for an anycast service is documented in RFC 4786^[3] and RFC 7094^[4].

3. What we actually deploy

The setup comes down to three elements, and the third is the one everyone forgets.

1. One address per service, carried on loopback

A /32 in IPv4, a /128 in IPv6, configured on each instance's loopback interface — not on a physical one. That matters: the address stays reachable whichever network card is used, and it does not depend on the state of one particular link.

2. A routing daemon on each instance

FRRouting^[5] or BIRD^[6], participating in the network's IGP and announcing that prefix. The server becomes, for that one address, a router among the others.

3. An announcement conditioned on service health

This is the critical point, and where failed deployments are decided. The announcement must follow the service, not the machine. If the routing daemon keeps announcing while the resolver it is meant to serve is dead, routing dutifully sends traffic into a black hole. Nothing fails over, because from the network's point of view everything is fine — and that is far worse than a clean outage, because nobody notices. So we condition prefix redistribution on a real test of the service, exactly like the keepalived health-check block at level 2.

One address for the whole network, or one per VLAN?

We generally start from a single address: it is the simplest to deploy, to document and to hand over. We then segment where there is a reason — filtering more precisely, containing traffic within a sensitive perimeter, or guaranteeing that a site keeps its local service even if the network core is cut. Segmenting on principle multiplies configuration without adding anything.

4. The three failures it absorbs

Losing a node

The other instances at the same site absorb the load. The path changes by a few microseconds of metric; nobody sees a thing.

Losing a datacenter

The prefix disappears from that site and routing converges towards the others. Failover time is IGP convergence time — around a second on a well-tuned network — and no client has anything to reconfigure.

The trap nobody mentions: capacity

Failover takes seconds. Adding capacity takes weeks. If each site was sized for its own load — which is the default, since that is what each one handles day to day — then the survivors take on the lost site's load in addition to their own. With two sites that means doubling; with five the increase is gentler, but it arrives without notice. No error, no failover alert, just response times stretching and then requests dropping. Anycast is sized on residual capacity after removing the largest site, not on mere presence. It is the first calculation we run, and it is often the one that decides how many instances you need.

5. Geographic load distribution — and its limits

Anycast distributes load whether you ask for it or not: every client is served by the nearest instance, which naturally spreads traffic by routing zone and cuts latency. All of it with no client-side configuration, no virtual address to manage and no central component to make redundant.

What it does not do

• No weighting. A site with a large machine gets the same share as a site with a small one, if the routing metrics are comparable.
• No application check on the network side. Routing does not know whether the service answers correctly, only whether the route exists — hence the critical point in §3.
• No session persistence. Nothing guarantees that two requests from the same client reach the same instance.

When those limits start to hurt, you change tools: a layer-4 balancer to weight and test, or layer 7 to route by URL and handle sticky sessions — that is the subject of our load balancing page — anycast then remains useful upstream, to make the balancer itself reachable from everywhere.

6. Which services fit — and which do not

Excellent

Stateless, short requests, immediate answer:

• Internal DNS resolvers
• Log collectors (syslog)
• RADIUS servers
• Outbound proxies

With care

Anything holding a session: HTTP over persistent connections, long-lived TLS. On a stable internal network, paths rarely change mid-connection and the impact is limited to an occasional reconnection. If paths oscillate, it is the wrong tool.

Excluded

Anything with data to replicate. Anycast replicates nothing: it directs traffic, full stop. Putting a database behind an anycast address gives you several independent databases that diverge, and a client with no idea which one it is querying.

7. The counter-example that surprises: NTP

NTP ticks every box in the "excellent" column: UDP, stateless, very short exchange. It is exactly the profile of a service you put behind anycast without thinking. And on an internal network, that is a mistake.

The right axis is not "whether NTP can be anycast"

It is: what is anycast replacing?

It spreads the sites of an already single source

The client had one source and still has one. Nothing changes in its model, and it gains proximity — hence a tighter error bound — plus survival of a site loss. Pure gain.

It replaces distinct sources with a single IP

There, you break the algorithm. An NTP client is designed to query several sources in parallel, compare them and discard the ones that lie. With a single address it believes it has only one source and loses its ability to detect a false clock. You degrade the service while thinking you are hardening it.

On an internal network you are almost always in the second case: there were several time servers declared, and you would replace them with one address. The right approach is therefore the opposite of anycast — a pool configuration, with several entries resolving to distinct addresses. Redundancy is handled on the client side, and the protocol does it better than routing does.

The NTS case

With NTS, the secured version of NTP, key establishment goes through a TLS session and the tokens issued are tied to the server that issued them. This is not an absolute blocker: large operators share and rotate master keys across their whole fleet, deliberately. But it is an entry cost — and that is precisely why smaller operators do not take it on.

Three operators, three models

Operator	Model	What the client sees
Netnod	Distinct sources, named per site — Stockholm, Gothenburg, Malmö, Sundsvall, Luleå, each in two instances	Several servers, majority preserved
Large public time-service operators	Anycast: one address announced from dozens of points of presence	One source, closer and more stable
RDEM Systems	Distributed pool, resolving in rotation across several addresses	Several servers, majority preserved

Taken from Netnod's public documentation, August 2026 — no mention of anycast, and server names explicitly tied to a site.

Where the line falls, and why it holds

Time-service operators with a national or regional footprint expose distinct sources; global ones anycast. And it is not only a matter of scale: with servers named per site, the client knows who it is talking to, can audit each source and keeps its majority. With an anycast address, it cannot know which instance answered. For time — which timestamps logs, validates certificates and serves as evidence — that verifiability is not a detail.

The tools at this level

Tool	What we say about it
FRRouting^[5]	The routing daemon we deploy for our clients — and that we run on our own network. We also fix its code: see our open source contributions.
BIRD^[6]	The lighter alternative, when all you need is to announce a prefix
OSPF^[1]	The most common interior protocol in enterprise networks
IS-IS^[2]	When the network already runs IS-IS, we do not change it for this

8. What it is not

• It is not a load balancer. No weighting, no application health check on the network side, no sticky sessions. The granularity is the routing table.
• It is not intercontinental geo-distribution. On an enterprise network, "multi-site" usually means a few buildings or a few datacenters — not several continents. The mechanism is the same, the scale is nothing like it.
• It is not replication. The most important point, and the one that produces the worst surprises: anycast directs traffic and synchronises nothing. Whatever must stay consistent between instances has to be replicated by something else.
• "Nearest" is not geographic. It is nearest by routing metric. A site three kilometres away can be further, in network terms, than one three hundred kilometres away — and that is sometimes the discovery of the first test.

9. What we operate afterwards

We have already deployed anycast DNS on private networks in production, across several multi-site client infrastructures. What experience teaches comes down to two monitoring points, and neither is provided by default.

• Watch that each instance announces AND answers. Both separately, and the consistency between them. An instance announcing without answering is a black hole; an instance answering without announcing is capacity paid for and unused. Both situations are silent.
• Watch residual capacity. How many sites can you lose before the survivors saturate? That figure moves with every added VLAN or user population, and nobody recalculates it spontaneously.
• Test deliberate withdrawal. Remove an instance from the announcement and check that traffic moves cleanly, measuring the real time taken. It is the only way to know what convergence is worth on that particular network.

All of this is routine operation, included in our managed services plans, with 24/7 on-call for whatever automation cannot handle.

10. When DNS failover is enough

The honest alternative, and it suits plenty of situations: a DNS record with several addresses and a health check that removes the ones that stop answering. It is less elegant, it demands no network skills, and the failover delay is the record's time to live — a few tens of seconds to a few minutes.

DNS failover is enough if…

• A minute of unavailability is tolerable
• The network has no IGP, or the team does not run one
• Clients honour the advertised time to live
• There are only two or three sites

Anycast earns its place if…

• The service is hard-coded across many VLANs
• Failover must be invisible and immediate
• Proximity matters for latency
• An IGP already runs and the team can operate it

When in doubt, we start with DNS failover. It goes in within a day, it is reversible, and it gives a real measure of what failover costs before investing in a more elaborate architecture.

Frequently asked questions

What is the difference between anycast and load balancing?

A load balancer is a component that receives every request, decides where to send it, and can weight its choices or check the application health of its targets. Anycast receives nothing: there is no central component, it is the routing table that directs traffic to the nearest instance in routing terms. You therefore get distribution, but with no weighting, no session persistence and no application check. It is more robust because there is nothing to make redundant, and far less precise.

Can you run anycast without an AS number or public prefix?

Yes, and that is the whole subject of this page. Public anycast on the internet requires an AS number, an announceable prefix and BGP. Internal anycast requires none of that: an interior routing protocol is enough, OSPF or IS-IS, which most multi-site enterprise networks already run. You announce a prefix taken from your own private addressing plan, and the mechanism is identical.

Which services can you put behind internal anycast?

Those with no state to keep between exchanges and with short requests: internal DNS resolvers, log collectors, RADIUS servers, outbound proxies. Conversely, anything that holds a session or owns data to replicate is a poor fit, because anycast replicates nothing at all — it merely directs traffic. A stateful service behind anycast gives you an infrastructure that works right up to the first path change.

Does anycast work for an HTTPS website?

On a stable internal network, in practice yes, because paths rarely change mid-connection. But it is a use to handle with care: a TLS connection is state shared between the client and one specific instance, and if routing switches in the middle, the session dies and has to be re-established. As long as path changes remain rare events, the impact is limited to a reconnection. If paths oscillate, it is the wrong tool.

One anycast address per VLAN, or a single one for the whole network?

It depends on what you want to control. A single address for the whole network is the simplest to deploy and document, and routing takes care of directing everyone to the nearest instance. One address per VLAN costs more configuration but lets you contain traffic within a perimeter, filter more precisely, and keep a local service even if the network core is cut. We generally start from a single address and only segment where filtering or containment justifies it.

What happens if an instance announces but stops answering?

That is the worst scenario in this architecture, and it is a silent one. Routing sends traffic to an instance that accepts it and does not process it: a black hole. Nothing fails over, because from the network's point of view everything is fine. The answer is structural: the announcement must be conditioned on the real health of the service, so that a dead daemon causes the route to be withdrawn. It is the first thing we check on an existing deployment.

What happens if an entire datacenter disappears?

The instances at that site stop announcing, routing converges, and traffic goes to the remaining sites. The failover is clean and requires no client-side reconfiguration. The trap is elsewhere: failover takes seconds, adding capacity does not. If each site was sized for its own load, the survivors take on the lost site's load in addition to their own and saturate without a sound. Anycast is sized on residual capacity, not merely on presence.

Should you put your NTP server behind anycast?

On an internal network, no — and the reasoning is counter-intuitive. An NTP client is designed to query several sources in parallel, compare them and discard the ones that lie. Replacing distinct sources with a single anycast address makes it believe it only has one source: it loses the very property that makes it reliable. The right internal approach is a pool configuration with several distinct addresses. On a public service already served from a single source, however, anycast takes nothing away and adds proximity: that is what the large time operators do.

How many VLANs would you have to reconfigure if one of your sites went down?

If the answer is "a lot", internal anycast is worth evaluating. We audit the existing network and say plainly whether it is worth the effort.

Request an audit

Table of contents