Subject: [dnsop] Re: Anycast 101

From: Dean Anderson <[email-masked]>
Date: Fri, 17 Dec 2004 17:34:35 -0500 (EST)

On Fri, 17 Dec 2004, Iljitsch van Beijnum wrote:
> Nope. Consider:
> 
>             +-------+   +-------+
>             |ISPrtr1+---+ACinstA|
> +------+---+---+---+   +-------+
> |source|       |
> +------+---+---+---+   +-------+
>             |ISPrtr2+---+ACinstB|
>             +-------+   +-------+

The setup above is not that uncommon. Further, the outbound links between
source and both ISPrtr1 and ISPrtr2 going out are probably OSPF or RIP or
static default routes. BGP is not really crucial to the problem statement.

Real life examples:
========================
Many customers that have redundant connections to their ISP will have for 
example, 2 t1's, which go into different POP sites for their ISP. These 
links have default routes and PPLB going out.  

Many ISPs themselves have internal default routes going out to different
peering routers at potentially different physical locations, and some of
those may want PPLB exits.

Basically, anywhere you find an opportunity for an assymetric path, you 
have a problem with anycast.  

Let me restate and re-emphasize the rule for determining if an application 
is suitable for anycast:  

	If you can't guarentee a single path to the anycast server,
	the application must make use of some other solution, as 
	described in RFC 1546.

From RFC 1546 Page 6
=====================================================================
     In general, applications use anycast addresses like any other IP 
address. The only worrisome application use of anycasting is applications 
which try to maintain stateful connections over UDP and applications which 
try to maintain state across multiple TCP connections. Because anycasting 
is stateless and does not guarantee delivery of multiple anycast datagrams 
to the same system, an application cannot be sure that it is communicating 
with the same peer in two successive UDP transmissions or in two 
successive TCP connections to the same anycast address.

    The obvious solutions to these issues are to require applications 
which wish to maintain state to learn the unicast address of their peer on 
the first exchange of UDP datagrams or during the first TCP connection and 
use the unicast address in future conversations.
=====================================================================

Because per-packet assymetric paths can occur for a variety of reasons, 
Anycast can't be used for DNS TCP connections.

Work should begin on the possibilty of altering DNS protocol so that the
unicast address can be passed for a tcp connection.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: [email-masked]
Date: Fri, 17 Dec 2004 23:51:20 +0100

> Real life examples:

Maybe your customers are very different from mine. I have seen such
configurations many times with regular per-destination/source pair
load balancing. I have *never* seen such configurations used with
per-packet load balancing.

I agree with those who say that using PPLB in the above situation
(connections going to different POPs) is asking for trouble.

Steinar Haug, Nethelp consulting, [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 18 Dec 2004 08:41:18 +0900

> (connections going to different POPs) is asking for trouble.

Right. TCP, for example, suffers badly.

						Masataka Ohta

.