Skip to content

Anycast, Unicast and Multicast

The CDN article mentioned in passing that some CDNs skip DNS-based steering entirely and rely on "normal internet routing" to send each visitor to a nearby edge server, promising the mechanism in full later. This is that mechanism. It isn't a CDN-specific trick — it's one of three fundamentally different answers to a question every IP packet has to settle before it's sent: exactly how many destinations does this packet's address actually refer to?

Unicast: the default you've been using this entire course

Every example this course has shown so far — a ping to one host, a browser fetching one page, a TCP connection between one client and one server — has been unicast: one sender, one specific receiver, identified by one specific IP address that belongs to exactly one interface on exactly one machine. When you send a packet to 93.184.216.34, there is exactly one place in the world that address can legitimately deliver it, and every router along the path makes its forwarding decision on that same assumption. Unicast isn't a special mode you turn on — it's the default relationship between an IP address and a destination, and it's the only one this course has needed until now.

Multicast: one send, many specific receivers

Some traffic genuinely needs to reach a defined group of interested receivers at once, without the sender knowing or caring exactly who's currently in that group. A live video stream to a set of subscribed set-top boxes, or router-to-router protocol announcements that every router on a segment needs to hear simultaneously, are the classic cases. Sending a separate unicast copy to each receiver works, but it means the sender's own uplink carries N copies of identical data for N receivers — wasteful if N is large and the receivers share most of their network path.

Multicast solves this with a dedicated block of IP addresses, 224.0.0.0/4 in IPv4, where one address represents a group rather than a single host. A sender transmits one packet addressed to the group address; routers that support multicast replicate that packet only at the points in the network where the path to multiple subscribed receivers actually diverges, rather than the original sender doing the duplication itself.

Unicast to 3 receivers:                    Multicast to the same 3 receivers:

Sender ──copy 1──▶ Receiver A              Sender ──1 packet──▶ Router
Sender ──copy 2──▶ Receiver B                                     ├──▶ Receiver A
Sender ──copy 3──▶ Receiver C                                     ├──▶ Receiver B
(3x the sender's own bandwidth used)                               └──▶ Receiver C
                                            (1x the sender's bandwidth; router duplicates downstream)

Hosts join a multicast group using IGMP (Internet Group Management Protocol), telling their local router "I want traffic sent to this group address" — the router then knows to forward, or stop forwarding, that group's traffic down a given link depending on whether anyone downstream is still asking for it. Multicast never saw wide adoption on the public internet, mostly because it requires every router along a path to cooperate, and ISPs generally don't enable it across their boundaries with each other — routing decisions that respect group membership are more complex to coordinate globally than plain unicast forwarding, and the commercial incentive to solve that coordination problem never matched IPTV and streaming providers' willingness to just use dedicated, provider-controlled networks instead. Multicast is genuinely common and useful inside a network one operator controls end to end — corporate video conferencing infrastructure, IPTV within an ISP's own last-mile network, stock market data feeds within a trading firm's own network — precisely the same kind of single-administrator condition that made QoS markings reliable on a LAN and unenforceable across the open internet.

Anycast: many places, one address, and routing decides

Anycast takes a different approach to a different problem: not "reach a defined group," but "reach any one of several servers that are all equally capable of answering, whichever happens to be closest or cheapest to reach right now." The trick is genuinely simple to state and a little surprising the first time you see it: the exact same IP address is announced from multiple physical locations at once, and ordinary unicast routing — not any special multicast-aware mechanism — delivers each individual packet to whichever announcing location the network currently considers nearest, in routing terms, to the sender.

Address 192.0.2.53 announced from:
  - Location A (Frankfurt)
  - Location B (Singapore)
  - Location C (São Paulo)

Client in Berlin sends to 192.0.2.53  ──▶  routing delivers it to Frankfurt (topologically closest)
Client in Jakarta sends to 192.0.2.53 ──▶  routing delivers it to Singapore (topologically closest)

This works because of how BGP propagates route announcements between networks: when Frankfurt, Singapore, and São Paulo all announce reachability for the same 192.0.2.0/24 block, every other network on the internet ends up with multiple candidate routes to that block, and ordinary BGP path selection — which generally favors the shortest AS path, among other criteria — picks whichever announcement looks closest from that network's own vantage point. "Closest" here means topologically nearest in terms of BGP's own path-selection criteria, not geographic distance measured in kilometers, and RFC 4786 is explicit that the two don't reliably track each other: topological nearness within the routing system doesn't, in general, correlate with round-trip performance, and in some cases a client can end up routed to a topologically "nearer" instance that's actually slower to reach than a geographically closer one would have been.

The best-known real-world anycast deployment is the DNS root server system: the thirteen root server "letters" this course's DNS resolution article described are each, in practice, dozens to hundreds of physical machines worldwide, all reachable at the same handful of IP addresses through anycast, which is exactly why a dig query to a root server responds quickly from nearly anywhere on the internet despite there being only thirteen logical root addresses to reach.

dig +short CHAOS TXT hostname.bind @198.41.0.4

"a.root-servers.net"

The address 198.41.0.4 is one of the thirteen root server addresses — reachable from anywhere, but this specific diagnostic query, which asks the responding instance to identify itself, would return a different hostname string depending on which of the many physical anycast instances behind that one address actually answered your particular query, because each physical instance runs with its own local identity even though they all share the same announced address.

Anycast and multicast solve opposite problems with a superficially similar trick of "one address, multiple machines": multicast delivers one packet to many receivers who all get an identical copy; anycast delivers one packet to exactly one receiver, chosen by routing, out of many candidates capable of answering.

Comparing the three side by side

Unicast Multicast Anycast
Receivers per packet Exactly one A joined group, potentially many Exactly one, routing-selected
Address scope One specific host 224.0.0.0/4, a group A normal unicast-looking address, announced from many places
Who decides the receiver The address itself (fixed) Group membership (IGMP) BGP path selection, dynamically
Public internet support Universal Rare, mostly LAN/single-operator Widely used (DNS roots, CDNs, DDoS-resilient services)

Practical scenario: an anycast IP that "works everywhere except this one office"

A company deploys an anycast-based DDoS protection service in front of their public API, and it works correctly for essentially every client — except one branch office, where every request to the protected API times out completely, while the same office reaches every other internet service normally.

mtr -rw -c 5 <anycast-service-ip>

HOST: branch-office-router               Loss%   Snt   Last   Avg  Best  Wrst
  1. isp-edge-router.example.net          0.0%     5    2.1   2.3   2.0   3.1
  2. isp-core-3.example.net             100.0%     5    0.0   0.0   0.0   0.0

The trace dies completely at the ISP's second hop, which strongly suggests this specific ISP either doesn't carry a route to the anycast block at all, or has a route that's silently black-holing it — a real and recurring category of anycast failure mode, distinct from ordinary unicast reachability problems, because it depends entirely on whether every network between the client and every anycast announcement point has actually accepted and propagated that route. A unicast service either has a working route from a given network or it doesn't, uniformly; an anycast service can be perfectly reachable from most of the internet while being unreachable from one specific network whose BGP configuration or peering relationships happen not to carry a route to any of the announcing locations.

The fix isn't something the client-side office can solve on their end — it requires the anycast service provider to investigate their own BGP announcements and peering arrangements with that specific ISP, since BGP, the next article's subject, is exactly the layer where this kind of selective, network-specific unreachability actually gets decided.

Practice exercises

  1. A company wants to broadcast a company-wide video town hall to every employee's desktop simultaneously, all on the same corporate LAN the company fully controls. Using the trade-offs above, would you recommend unicast, multicast, or anycast, and why?
  2. Explain, using the DNS root server example above, why querying the address 198.41.0.4 from two different countries can return correct, fast answers from what are actually two entirely different physical machines.
  3. A CDN edge network wants every visitor worldwide to reach "the nearest edge PoP" using the same IP address, with no DNS-based steering involved at all. Which of the three delivery models does this describe, and what does that imply about how the CDN's edge PoPs need to announce their own address block to the rest of the internet?

Anycast's whole trick depends on one thing this article deliberately left unexplained: how a network actually decides which of several competing route announcements for the same address block counts as "closest." That decision, made independently by every autonomous system on the internet, is the entire subject of the protocol the next article covers.

Sources