BGP Anycast: Announcing a Public Service From Several Sites

1. Not to be confused with internal anycast

The mechanism is identical — one address announced from several places, routing chooses — but the scope changes everything: prerequisites, cost, failover time, and what you are entitled to claim.

	Internal anycast	BGP anycast
Scope	The client's private network	The public internet
Protocol	OSPF or IS-IS	BGP
Prerequisites	No AS, no public prefix	An AS, an announceable prefix, transit providers
Failover	Immediate on link down, seconds otherwise	30 s tuned aggressively, 180 s by default

If your need is making a DNS resolver or a log collector reachable everywhere across a multi-site network, internal anycast is what you want, and it requires neither an AS nor transit. This page covers the other case: a public service served from several sites.

Advertisement scope is a parameter, not a property

The DNS root shows this better than any diagram. It has 13 identities, 12 independent operators and 2,004 instances^[1] in service as of 23/08/2026 — and its FAQ separates global instances, whose “route advertisement is permitted to spread throughout the Internet”, from local ones, whose advertisement “is limited to only nearby networks”.

The K-root operator describes the same arrangement plainly: the service is “provided by a set of distributed nodes using IPv4 and IPv6 anycast^[2]”, each node announcing the 193.0.14.0/23 prefix from AS25152. One address, dozens of sites, and nothing to change client-side.

In other words, the same technique serves one instance to the entire world or to a single network neighbourhood. That is exactly the lever behind internal anycast — except that there, only the local scope is kept, which is why it needs neither an AS nor transit.

2. Who runs it, and documents it

Anycast is no laboratory curiosity: it has carried the most critical service on the Internet for twenty years. The DNS root is 13 identities — a.root-servers.net through m. — run by 12 independent organisations^[3], Verisign being the only operator holding two.

Identity	Operator	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	—

Recorded on 23/08/2026: 2,004 instances in service^[1] in total. The per-identity counts are those published that day and change constantly; K, L and M could not be read from the same source. The point is not the exact figure, it is the spread: from 6 instances for B and G to 366 for F. Same identity, same service, deployment sizes with nothing in common — and the client only ever sees one address.

Other services that state it plainly

Service	What its documentation says
Google Public DNS 8.8.8.8	“Anycast routing directs your queries to the closest Google Public DNS server^[4]” — clients “are routed to the nearest location advertising the anycast address used”.
Quad9 9.9.9.9	“The systems are ‘anycast’, meaning that queries will automatically be routed to the closest operational system^[5]”, across 230+ resolver clusters in over 110 countries.
Cloudflare NTP time.cloudflare.com	Serves its public NTP from its “global anycast network^[6]”, behind just four addresses.

The opposite discipline matters just as much. Google documents anycast for its public DNS; for its public NTP the same company writes “our load balancers” and the word anycast never appears. Cloudflare owns it for its time service, yet its 1.1.1.1 resolver page speaks of “hundreds of cities” without using the term. Two services from the same operator can rest on different mechanisms: we do not credit anyone with an architecture they have not written down.

3. The real prerequisites

There are few of them, but each is blocking, and they are obtained in weeks rather than hours.

• An AS number. Obtained from the regional registry, justified by a need for independent routing — typically several transit providers.
• An announceable prefix. Owned outright, or made available by a provider for your AS: both work, and the second route lowers the barrier considerably. It is a poorly known point, often presented as impossible.
• Several transit providers, or presence at exchange points. Announcing a prefix through a single operator provides no resilience: that operator is the point of failure.
• BGP competence in house or at your provider. A badly filtered announcement does not only affect you.

Failover time is the real trade-off

With default timers it takes three minutes for a BGP session to be declared dead and the announcement to disappear. You can go down towards 30 seconds with aggressive tuning, at the cost of greater sensitivity to brief outages. Compared to the one to three seconds of a floating address, that is another order of magnitude — and it is the price of worldwide reach.

4. The case that illustrates it best: public NTP

This is the example that makes the subject concrete, and it has the merit of being counter-intuitive. On an internal network, putting NTP behind anycast degrades the service: an NTP client is designed to query several sources and discard the ones that lie, and a single address makes it believe it only has one.

The question is not whether NTP can be anycast

It is: what is anycast replacing?

On a public service the source was already single: one address, one name. Announcing it from several points of presence does not reduce the client's number of independent sources — it simply brings it closer to one of them. It gains lower latency, hence a tighter error bound, and survival of a site loss. Pure gain. That is why Cloudflare serves its public NTP from what its documentation calls its “global anycast network^[6]” — four addresses, two IPv4 and two IPv6, behind time.cloudflare.com — while you should never do the same thing internally.

What these operators document themselves

The topic resists sweeping claims: each of these services made a different choice, and says so. Recorded on 23 August 2026 from their respective documentation.

Service	What its documentation says	Model
Cloudflare time.cloudflare.com	Explicitly advertises a “global anycast network”, and publishes only four addresses: 162.159.200.1, 162.159.200.123 and two IPv6.	Anycast, stated
Google time.google.com	Writes that it built the service “with our load balancers^[7] and our fleet of atomic clocks in data centers around the world”. The word anycast does not appear.	Not documented
Netnod nts.netnod.se	Publishes ten distinct names^[8] — two per city, across five Swedish cities: Stockholm, Gothenburg, Malmö, Sundsvall, Luleå — plus one generic name.	Named sources

The lesson fits in one sentence: anycast must not be assumed. Google describes load balancers, not BGP announcements, and it would be dishonest to read one as the other. Three time-service operators, three different choices, three sets of documentation that own them — a sign that the right answer depends on scope, not on a general rule.

With NTS, the secured version of NTP, one more constraint appears: key establishment goes through a TLS session and the tokens issued are tied to the issuing server. The consequence is concrete: Netnod states that it runs “the NTS-KE and NTS timestamping phases on physically different machines”. This is not a blocker, but it is an entry cost — cryptographic state has to travel between the very machines anycast is meant to make interchangeable.

Conversely, a time-service operator with a national footprint such as Netnod exposes distinct sources, named per site — sth1, gbg2, lul1… The client then knows who it is talking to, can audit each source and keeps its majority — an argument that matters for time, which timestamps logs and validates certificates.

5. The capacity trap

It is identical to internal anycast's, and it remains the most expensive because it is silent. Failover takes seconds or minutes; adding capacity takes weeks.

If each site was sized for the load it handles day to day — which is the default — then removing one site makes the survivors absorb its load on top of their own. No error, no failover alert: just response times stretching, then requests dropping. Anycast is sized on residual capacity after removing the largest site, never on mere presence.

The other monitoring point is the same as internally: verify that each instance announces and answers, separately. An instance announcing without answering is a black hole that nothing flags, because from routing's point of view everything is fine.

6. What we describe, and what we do not claim

We run our own network and our own AS number, which lets us discuss BGP other than in theory — we contribute to the code of the routing daemon we deploy, as our open source contributions show.

But there is a limit we would rather write down

The prefix we announce is made available to us by our provider, it is not owned outright. So we can explain precisely how public anycast works and what large operators do — we do not sell it as a turnkey engagement. If your project requires it, we support you on the architecture and say plainly when a partner is needed.

And in most cases we encounter, the right answer is not here: it is internal anycast, which answers the same need across the scope that actually matters to an SMB or mid-market company, with no AS, no transit and no waiting period.

Frequently asked questions

Can you run BGP anycast without owning your own prefix?

Yes, and it is the least known point of the subject. A prefix can be made available by a provider to be announced from your own AS number: the mechanism works exactly the same way. What remains indispensable is the AS number itself and presence with several transit providers — without which the resilience you are after does not exist.

How long does a BGP failover take?

About three minutes with default timers, the time for a session to be declared dead and the announcement withdrawn. You can go down towards thirty seconds with aggressive tuning, at the cost of greater sensitivity to brief outages. That is two orders of magnitude above a floating address, and it is the price of worldwide reach.

Is BGP anycast suitable for a website?

Technically yes, and very large services work that way. But a TLS session that changes instance mid-flight dies and has to be re-established: as long as paths are stable, the impact is limited to rare reconnections. For an SMB, a CDN or a DNS service with health-check failover brings the same benefit without requiring an AS.

Do you need anycast to serve public NTP?

It depends on scope. On a worldwide service already served from a single source, anycast takes nothing away and brings the client closer: that is what large operators do. On an internal network it is the opposite — replacing several distinct sources with one address deprives the client of its ability to detect a false clock. Internally the right reflex is a pool configuration.

Do you really need to announce over BGP?

In most cases we encounter, internal anycast answers the same need with no AS and no transit. We say so before committing you to a process that takes weeks.

Get a quote

BGP anycast:
announcing a public service from several sites

Table of contents