> While that setup may have worked well, it's not an anycast implementation > I would suggest that others follow. Having the same set of servers > announcing multiple IP addresses (assuming those addresses are both in the > same set of addresses given out to those doing dns lookups) leaves you > open to a failure mode where a single server stops responding to queries > but doesn't withdraw its routing announcement. If a user sees that server > as the closest instance of both DNS server IP addresses, they will see > that as a failure of "both" of their DNS servers.
Agreed, that's a possibility. In practice it hasn't really turned out to be a problem for us. > A more reliable way of doing this is to have multiple anycast clouds with > their own servers, each serving a single service address. That way, an > incomplete failure (on query response but no route withdrawl) of a local > server for one service address won't have any effect on access to the > second service address. Yes, we have been doing some of this also. Part of the problem is the desire to spread the load among the servers: Some of this comes naturally from the different server locations in our network - but with 2 addresses per server we can also balance the load somewhat by announcing either one or two addresses per server. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]