To:
Robert Elz <kre@munnari.OZ.AU>
cc:
dnsop@cafax.se
From:
Bruce Campbell <bruce.campbell@ripe.net>
Date:
Tue, 5 Nov 2002 14:11:04 +0100 (CET)
In-Reply-To:
<6030.1036494224@munnari.OZ.AU>
Sender:
owner-dnsop@cafax.se
Subject:
Re: quibbles about what is anycast.
On Tue, 5 Nov 2002, Robert Elz wrote:
> Date: Tue, 5 Nov 2002 09:53:44 +0100 (CET)
> From: Bruce Campbell <bruce.campbell@ripe.net>
> Message-ID: <Pine.LNX.4.44.0211050928420.28812-100000@x22.ripe.net>
>
> | So Brad, what is 'true anycast' ?
>
> Not Brad, but:
>
> Multiple (different) systems with the same IP address, where you cannot
> predict in advance which system a packet to the address will arrive at
> (that is, it all depends upon the state of the net at the precise instant
> the packet is routed).
Right. I've got two services that the RIPE NCC provides (www.ripe.net and
k.root-servers.net) which use local load-balancing or clustering to direct
UDP and TCP SYN packets in round-robin fashion to multiple back-end
servers ( continuation of a TCP stream goes to the same back-end server
for obvious reasons ).
With these two, I cannot predict ahead of time which back-end server will
handle a particular packet, with the notable exception of TCP streams as
described above.
There is a third service which the NCC also provides which also meets your
above criteria, being a server in the AS112 project. Ahead of time, I
cannot predict where a packet destined for blackhole-1.iana.org (or
blackhole-2.iana.org) will end up, unless I have knowledge of the routing
table in effect for that portion of the Internet.
This is implemented using what you call 'route hijacking', where multiple
entities masquarade as origin AS 112, and advertise reachability to
192.175.48.0/24 (where the above-mentioned servers reside). In practice,
routers keep track of the 'best' path for that prefix (since all the
advertisements are the same prefix and from the same origin AS, the
shortest path wins) and direct all packets down that best path.
> If you know that all the packets to address X from Y will (always) go to Z,
> that isn't anycast, regardless of whether or not someone else's packets
> to address X go somewhere different.
Ok, let us assume AS112 advertisers X, Y and Z, ISPs A, B and C and
transit ASes of the rest of the alphabet.
Assume that routers at ISP A see the following path:
192.175.48.0/24 T U V W X 112
* 192.175.48.0/24 T Y 112
Then ISP A will always choose the 'best' path of T, Y, 112 . This isn't
anycast by your definition.
ISP B sees:
192.175.48.0/24 H I J X 112 (received 1036501521)
192.175.48.0/24 L M N Y 112 (received 1036501654)
* 192.175.48.0/24 P Q R Z 112 (received 1036500032)
With some routers, the last path would be used since it was received
first, other routers might use the last path (second listed) received
instead, and still others might start doing path selection based on the
lowest-numbered AS of the first hop (the first path).
Without knowing the router used and when the route announcements came in,
I don't know which path packets would use, thus this contrived uncertainty
meets your definition of anycast.
ISP C sees:
192.175.48.0/24 E F G Y 112 (flapping)
192.175.48.0/24 H I J X 112 (flapping)
192.175.48.0/24 H Q R Z 112 (flapping)
192.175.48.0/24 P Q R Z 112 (flapping)
192.175.48.0/24 L M N Y 112 (flapping)
In which case I don't know which path ISP C will use, as all of its routes
are unstable (in practice, the router would choose the 'most stable',
which is dependent on timing of route flaps). This (again contrived)
instability would also be anycast by your definition.
--
Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations/Security
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.