[dns-operations] Anycast vs. unicast NS

David Miller dmiller at tiggee.com
Sun Mar 20 22:02:21 UTC 2011

Definitions of *Single point of failure* on the Web:

    * A Single Point of Failure, (SPOF), is a part of a system which, if
      it fails, will stop the entire system from working . They are
      undesirable in any system whose goal is high availability, be it a
      network, software application or other industrial system.
    * a component in a device, or a point in a network, that, if it were
      to fail would cause the entire device or network to fail; normally
      eliminated by adding redundancy
    * An element of a system for which no redundancy exists. A failure
      of such a component may disable the entire system.

On 3/20/2011 4:03 PM, Bill Woodcock wrote:
> Hash: SHA1
> On Mar 20, 2011, at 12:21 PM, Jim Reid wrote:
>> Extra complexity in server configuration

This depends on particular implementation choices and is not inherent to 
anycast itself.

For example, I can set up a network segment at a location (Location A) 
addressed as and place a server on this segment with an 
address of (Server A).  Server A has a single IP address and 
is configured with the exact same complexity as a unicast server.

I can also set up a network segment at another location (Location B) 
addressed as and place a server on this segment with an 
address of (Server B).  Server B has a single IP address and 
is configured with the exact same complexity as a unicast server.

Now, Server A and Server B service the anycast address from 
Location A and Location B with no extra complexity in server configuration.

In any case, complexity isn't a SPoF per se.

If the claim is that some admin could accidentally misconfigure a 
server, then unicast is much more susceptible to this.  If an anycast 
server is 'broken' then that anycast address is only 'down' for a 
particular region.  If a unicast server is 'broken' then that unicast 
address is 'down' for the entire internet.

Unicast, as opposed to anycast, has a designed in SPoF - i.e. one server 
on one address.  This SPoF can be mitigated, to some degree, by having 
additional servers that can service the unicast address with a failover 
mechanism to make that happen, but this requires adding in the 
complexity to the unicast configuration that you refer to above.

>> More complicated systems&  network management (procedures)
>> More complicated monitoring arrangements
>> More elaborate network operations and support (procedures)
> Aren't all of these differences dependent on the number of servers, rather than whether they're anycast or unicast?  I'd argue, actually, that these are all valid arguments against large unicast server networks, that hold _less_ true of similarly-sized anycast networks.  After all, unicast servers each have to be uniquely configured and have unique routing and be managed, to some degree, individually.  None of that is true of anycast server clouds.
> I think you're just arguing against having multiple servers, not against anycast.

Agreed, these are merely arguments against complexity (i.e. multiple 

Also, none of these are SPoFs inherent to anycast.

>> Extra complexity in router setups
>> "Special" filtering/peering treatment for anycast ASNs and prefixes
> I disagree with these two.  Routers don't need special configuration to deal with anycast, because they don't know the difference between anycast and unicast.  Therefore, no additional complexity on that front, nor any special treatment.

Agreed, the routers of the world don't know the difference between 
anycast and unicast routes.  There is nothing on a route as it exists in 
the DFZ that signals that a prefix is anycast or unicast.

The routers under the control of an anycast service provider could have 
knowledge of and provide different treatment to anycast prefixes, but 
this is a particular implementation decision and is not inherent to 
anycast itself.  Anycast requires nothing more than the exact same 
routing that is used to guide traffic to a unicast address.

>                                  -Bill
> Version: GnuPG v1.4.11 (Darwin)
> DzYAnA7bLM/T2ss9mbOlpJ9qxswzAeRB
> =eTmI
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

David Miller
Tiggee LLC
dmiller at tiggee.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20110320/74989af4/attachment.html>

More information about the dns-operations mailing list