Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Anycast Addressing on the Internet

By jtk in Internet
Fri Jan 02, 2004 at 09:34:10 AM EST
Tags: Technology (all tags)

Anycast addressing is a useful technique for providing redundancy and load sharing to specific types of network services on the Internet. Anycast addressing is nothing more than assigning a common IP address to multiple instances of the same service, which are located at strategic points in the overal network topology. By utilizing the underlying routing infrastructure of the Internet, IP packets are forwarded to the nearest instance of an anycast service. Common network services that can most easily take advantage of anycast addressing include DNS, multicast rendezvous points (RPs), syslog, network flow export, IPv6 to IPv4 relay routers and sink hole networks.

This article will briefly examine what anycast addressing is all about, where it is used and some of the technical considerations involved in an anycast deployment. The focus here is on anycast addressing as used by the IPv4 Internet. IPv6 provides a similar, but operationally unique service called anycast that will not be discussed here. The author's area of expertise is with internetworking and information security. He has experience in anycast addressing for RPs in multicast-enabled networks and has just begun to embark on a trial anycast DNS deployment.

Introduction to IP Addressing Types

Internet Protocol (IP) addresses are often overloaded to serve multiple purposes, such as a unique host identifier and locator. Most people are familiar with an IP address that is used as a unique identifier such as one assigned to a local PC's Ethernet or dial-up PPP interface. IP addresses assigned as a unique identifier to a host interface are referred to as unicast addresses. A unicast address can be used either as the source or destination address in an IP datagram. A sender inserts an assigned unicast address into the source address field of an IP datagram for packets sent onto the network. When packets are destined for a single host, a sender inserts a unicast address into the destination address field of an IP datagram, indicating who (and where) the packet should be delivered to. In some cases, hosts have multiple unicast address assignments. Often times in those cases, it usually means that the host has multiple network attachments with a unicast address assigned to each. Although in some special circumstances, multiple unicast addresses can be assigned to a single interface. An example of a unicast address is This is the unicast IP address that, at least as of this writing, is associated with the hostname www.kuro5hin.org.

Unicast addresses have historically been used to identify unique hosts or host interfaces. Knowing a unicast address usually meant knowing the actual, physical host the unicast address was associated with. This changes with anycast (and also with things like load balancers or IETF RFC 1918 addresses), but we'll come back to that part of the story shortly.

Broadcast addresses have been used to support discovery of services or hosts. Packets to an IP broadcast address are delivered to all hosts on a particular physical data link network or IP subnet. Broadcast addresses should only be used in the destination address field of an IP header, because it would be illogical for a unique packet to be sourced by a group of hosts or interfaces. IP broadcast addresses take the form of either the limited broadcast address ( or the directed broadcast address (the network ID plus all 1's in the host ID portion of the intended subnet).

There is also the concept of a group address and for this the term multicast is used. A multicast address is associated with a group of interested receivers. A group can consist of any number of hosts, including all hosts on the network. Therefore, a broadcast address is a subset address type within the concept of multicast addressing. Like the broadcast address, multicast addresses can only be used in the destination address field of an IP header. IP multicast addresses are allocated from the historic class D range of addresses ( in CIDR notation, or an address between and inclusive, for those of you unfamiliar with IP address netblock allocations).

Anycast addresses can be used as either a source or destination address, but no longer uniquely identify a single host or service. However, they do continue to act as a locator. Anycast addresses come from or are sent to the "nearest" host or service. The definition of "nearest" a) depends on the network topology, b) protocols used to make forwarding decisions and c) the associated administrative policies within the internetwork. Sometimes anycast addresses are referred to as group addresses, but unlike multicast, packets are delivered only to one member within the anycast group. Except for the 6to4 relay router specification, there is not an address range set aside for anycast use on the public IPv4 Internet today (see IETF RFC 3330). Individual organizations must allocate anycast addresses from an available unicast address netblock they have administrative control of.

By definition, IPv4 anycast addressing assigns a common unicast address to multiple interfaces, hosts or services on an internetwork. In other words, duplicate IP addresses are purposefully configured into the IP internetwork. Assigning duplicate IP addresses can be a dangerous affair and in fact will often break (catastrophically in some cases) communications when used on the same physical data link network. Without special load balancing protocols or hardware, anycast IP addresses should not be duplicated on any one data link network.

While some may argue that any use of duplicate IP addressing is fundamentally a bad idea, for our purposes in this article we will ignore the philosophical debates. So how then, does the network figure out where to send packets to an anycast address when that address can be multiple places at once?

Anycast Routing

Routers advertise netblocks (also known as prefixes) serving anycast address space just as they would advertise netblocks for unicast or multicast prefixes. With anycast address space, routers advertise the address netblock from multiple origin points in the internetwork. From a routing topology perspective, a common anycast address netblock looks as if it is multi-homed to all points of origin. In practice, an anycast netblock is often just a host route (/32 in CIDR notation) within an autonomous system (AS). To network routers and routing protocols, nothing changes about their operation and there are no new anycast specific routing concepts to learn.

To illustrate how anycast address netblocks are used in an internetwork, we will use an example. Imagine an internetwork with routers in three cities, Chicago, Los Angeles and New York. Presume there are anycast service instances attached to the Los Angeles and New York routers. A client of the anycast service is attached to the Chicago router. Packets from the host in Chicago to the anycast address will be forwarded towards either New York or Los Angeles, arriving at a unique instance of the service at one city, but not both. The packets will be forwarded based on the routing topology as viewed from Chicago (and other routers in between).

Presume packets from Chicago to the anycast address in the previous example normally travel to the New York instance. What happens if the route to New York from Chicago changes such that Los Angeles looks closer from a topology perspective (as might happen when a link or router goes down)? As soon as the routing topology converges due to the change, packets would then transition to the Los Angeles path.

As an aside, one may be thinking, if the path changes in the middle of a conversation between the Chicago source and the anycast service in New York or Los Angeles, won't communications fail? Without complex mechanisms to maintain synchronization, the other anycast service instance will not know about the session that existed previously, right? Correct. This is why anycast is not well suited for communications that involve "state" or long-lived flows of traffic. This eliminates TCP-based protocols and and even some UDP-based applications from being deployed with anycast addressing reliably. We will come back to specific applications where anycast is most applicable in the next section.

How anycast address netblocks populate the routing topology and how the routing "metrics" are calculated can vary from site to site. In the simplest form, a static route can be set in a local router, pointing to an instance of an anycast service host. However, if the anycast host fails, the static route has to be manually removed so that packets to the anycast netblock can be forwarded to other instances on the network. The most popular way to inject and remove anycast address netblocks from the network routing tables is by running a routing process directly on the anycast service host. This enables the anycast service host to automatically control whether it is available or not if downtime or maintenance is to occur. It also allows the network to automatically age out routes, which may happen if an anycast host fails.

Packets travel to an anycast address based on the locality, from a routing perspective, between a client and anycast service host. This tends to keep network traffic within a well defined coverage area as long as anycast service hosts and the routing infrastructure remains stable. Through careful network design, traffic patterns and link loads can be greatly influenced by the deployment of anycast addressing. By leveraging the unicast routing system, redundancy, load balancing and attack resiliency can be designed into services utilizing anycast addressing. In the next section, we examine some of the applications that can take advantage of these properties.

Anycast Applications

While there is nothing to prevent someone from running any service using anycast addressing, even TCP-based ones, it may be sufficiently unwise to do so. If routing instabilities or host failures occur, communications will fail as they are re-routed to another anycast service instance. The new anycast service instance will not recognize session in progress without complex state-sharing mechanisms. In addition, it would be foolish to begin transitioning services to run as anycast services without thoroughly understanding all of the nuances that come into managing applications and hosts with non-unique IP addresses. In other words, anycast addressing is not for everyone and everything. It often doesn't make sense to go through the extra complexity in deploying a service with anycast addressing if it doesn't justify the benefit.

That said, anycast addressing is currently used successfully by a number of organizations and for a number of applications. We will focus our discussion of application usage on DNS and multicast rendezvous points (RPs), while offering a glimpse into other applications that are most likely candidates for anycast addressing deployments.

Domain Name System (DNS)

Perhaps the most widely publicized use of anycast addressing today is in large DNS deployments, most notably by a handful of the Internet's root DNS server operators. Nearly all exchanges between a DNS client and a DNS server are a single UDP client query request and sole UDP message server response. In this mode of operation, anycast addressing is well suited. Its been measured that this simple exchange accounts for over 99% of all legitimate DNS traffic between DNS clients and root DNS servers. As a result of the enormous load required by DNS root servers and the stateless nature of DNS communications, root servers are perfect candidates for leveraging anycast addressing.

Those familiar with DNS protocol operations may know that DNS messages can and sometimes do use TCP instead of UDP. Isn't this going to be a problem if anycast routes or anycast services are unstable? Potentially yes, but practically no. Root server operators have measured typical, legitimate DNS traffic and found very little TCP-based communications. In addition, since the routes and hosts are generally stable, risk due to transition to other instances of an anycast address are very low. Even if there was a transition, it would have to fall within a very short window, since even TCP-based DNS queries are relatively short-lived.

The F root nameserver operated by ISC was the first root nameserver to deploy anycast addressing and they have been doing so since November, 2002. Root nameservers such as F root have been on the receiving end of many powerful and coordinated denial of service attacks. It is widely recognized that anycasting of some servers has been glaringly helpful in mitigating the impact of those attacks. Primarily to deal with offered load, due to valid requests, misconfigured or attack traffic, anycast addressing has proven to greatly enhance DNS root server survivability.

Multicast Rendezvous Points (RPs)

One of the first and most widely used applications of anycast addressing was for protocol independent multicast sparse-mode (PIM-SM) rendezvous focal point, bringing together multicast senders and interested receivers within a multicast domain. IETF RFC 2362, the PIM-SM specification originally stipulated a single RP for any particular group. For large and geographically diverse networks, this can imply a significant single point of failure, an unruly traffic load aggregation point, large amounts of group state maintenance or all of the above. Anycast addressing has been used to create multiple instances of RPs for common groups within a PIM domain. IETF RFC 3446 has recently been written to update the original PIM-SM specification, allowing for multiple RPs per group through the use of anycast addressing.

In anycast RP environments, multicast group registration is delivered to the nearest RP. However, because an RP must know about all sources for any particular group it is an RP for, multiple anycast RPs must share group registrations they each know about. This is currently achieved through the use of multicast source discovery protocol (MSDP) peering between the RPs. Anycast RP is now widely believed to be the "current best practice" for PIM-SM deployments.

Other Anycast Applications

Dozens of other custom or standard applications can potentially be deployed with anycast addressing techniques. Syslog servers, which collect UDP based messages from remote hosts are a good example, because the traditional Syslog server implementations never send messages in response to received log messages. Traffic flow collectors, such as Cisco's Netflow architecture or the freely implemented collectors like cflowd are also candidates for anycast addressing deployments. Sinkhole networks, which are designed to route "bogon" netblocks off production networks and are sometimes used to monitor bogus address space usage for later analysis are also good candidates for anycast deployment. The Simple Network Time Protocol (SNTP) would work with anycast, but NTP could be a problem. SNTP uses a single request and reply message exchange, but NTP generally requires at least two packets from both the client and server to exchange time information properly. IPv6 to IPv4 relay routers as defined in IETF RFC 3068 have their own netblock, which acts as an anycast service for IPv6 networks to talk to IPv4 networks. These 6to4 relay routers use anycast to help ease network management of IPv4 to IPv6 protocol transition. SNMP trap managers could also be configured for anycast addressing, because SNMP managers do not generally respond to received traps. Although if used as a full two-way SNMP manager, the SNMP manager should use a globally unique unicast address for SNMP management.

It is possible to configure any application using anycast addressing, but practically it may be unwise to do so. An unstable network may interrupt long lived sessions. Coupled with the difficulty in troubleshooting broken connections, many applications will often call for alternative solutions.

Anycast Service Management

When duplicate IP addresses are used, how does a network manager monitor each instance of the anycast service? There are at least two ways. First, the monitoring tools could be placed in proximity to each instance of the anycast service, so that probe packets will arrive at each anycast service instance. Second, a remote monitoring station could be located remotely, but could tunnel management packets to a unique address in close proximity to the anycast service to be managed. In this way, when the probe packets reach the end of the tunnel, they will be forwarded to the nearest anycast service. However, when the response is sent back to the centralized management station, which by the way does not need to be tunneled, how does the central management station know which instance of the anycast service is responding? This is left as an exercise for the reader.

Most anycast services are deployed along with a global, unique unicast address for management and state-based communications. So for instance, a DNS server may receive and reply to DNS queries using the anycast address, but it will receive and reply to zone transfers and remote management messages on a separate, unique unicast address (possibly on the same interface as that of the anycast address). Implementing a unique unicast address for management purposes isn't strictly required, but it is such a good idea that it should be. Usually the anycast address is implemented as a virtual interface on the anycast service host, such as in the form of a loopback address and the unique unicast management address is associated with an actual physical data link interface.

Since an anycast service, such as DNS, is separate from the underlying routing infrastructure that makes the service available through anycast netblock routing updates, what happens when the anycast service fails, but the route to its anycast address is still in the routing topology? Typically there is no strong coupling of application service to address route announcement, which means a failure in application service does not induce a route withdrawal to its instance of the anycast address from the network's routing tables. To get closer to a solution, the host running the anycast service can run a distributed routing protocol process locally and inject route updates to its local router for inclusion in the local AS or global Internet routing tables. If the host crashes, its anycast address route will eventually time-out, resulting in a route withdrawal for that instance of the anycast address netblock. However, what if only the application fails, but not the entire host? How does the local routing process know to withdraw the route for the unavailable anycast service? Today, the answer is "it probably doesn't". For most anycast applications anyway, there is typically not going to be a strong coupling between the application service and the local routing process. However, the host can be carefully configured to monitor its running anycast service. If the anycast service exits, crashes or becomes unresponsive, a local process can send an alert to an administrator and even automatically restart the anycast process. If the process exits and cannot be restarted, a local process can be configured to shutdown the local routing process or withdraw the anycast address netblock.


As used in IPv4 networks, anycast addressing is the strategic use of duplicate unicast IP addressing to provide localization for services and hosts in order to obtain robustness, redundancy and resiliency. While anycast addressing is a useful technique, it is not suitable for all applications or environments. Anycast addressing is not a panacea to scaling, redundancy or security problems in the IPv4 Internet. It, like many other techniques, is just one tool that if carefully considered and applied can be advantageous in certain scenarios. For many problems, other solutions may be preferable and any network designer or engineer should carefully consider options and trade-offs.



Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Kuro5hin
o IETF RFC 1918
o IETF RFC 3330
o F root
o IETF RFC 2362
o IETF RFC 3446
o cflowd
o IETF RFC 3068
o ISC Technical Note: Hierarchical Anycast for Global Service Distribution
o Deploying IP Anycast, Carnegie Mellon
o Also by jtk

Display: Sort:
Anycast Addressing on the Internet | 45 comments (32 topical, 13 editorial, 5 hidden)
Problems with BGP anycast (2.75 / 4) (#21)
by dbt on Fri Jan 02, 2004 at 12:31:13 PM EST

Note that there are many types of anycast.  BGP-based anycast is the only one that works on a global network, but IPv6 has some builtin support for intra-domain anycast.  A host that supports a particular service can register with a router and the router will send packets to it for that service address when it's closest.  (There is some work going on with the multicast discovery protocols to make them work for anycast as well, as the "hey router, here I am" protocol).

However, back to BGP anycast -- there are some serious problems that BGP anycast has, namely, that BGP listeners expect to see fairly stable remote networks.  If a particular BGP domain ends up with the same or similar metrics to two announcers, or if one announcer has some problems and goes down and comes back up a couple of times, listeners will think this network is flapping (well ... it is flapping) and the network will be dropped completely for a period of time, until it stabilizes.  

For example, the .ORG TLD is run by a company called UltraDNS, which uses BGP anycast to maintain their servers.  There has been at least one major outage across most (not all) of the internet since they went live with this system, because one of their announcers flapped a couple of times and so their upstream networks dropped the announcement and quashed it.

(The reasons for this are many, but basically in 1995 there was a huge cross-internet outage caused by a single router announcing and dropping much of the internet, which caused most inter-domain routers to fail because of excessive CPU load and BGP traffic, so these are anti-DoS provisions built into routers).

So is this a frequent problem? (none / 1) (#31)
by McMick on Sat Jan 03, 2004 at 02:54:49 AM EST

I mean, it sounds like you're saying that this .org outage occured back in 1995. It's 2004 now. So like, I think that sounds like actually a very good track record (assuming UltraDNS hasn't had any similar problems with the .ORG TLD since this one).

[ Parent ]
actually.... (none / 1) (#37)
by dbt on Sun Jan 04, 2004 at 09:15:42 PM EST

UltraDNS has been running ORG for about a year, and this happened about 4 months ago.

[ Parent ]
So we can use anycast addresses to mirror k5... (1.60 / 5) (#23)
by johwsun on Fri Jan 02, 2004 at 05:03:31 PM EST


No, TCP is the underlying problem (1.80 / 5) (#24)
by jtk on Fri Jan 02, 2004 at 05:42:31 PM EST

Since Kuro5hin is a web server running on top of TCP, anycast would probably be the wrong approach. There are other mirroring and load balancing solutions available for that sort of application. There is also something like Akamai, which many sizeable content sites find useful.

The problem is the "statefulness" of TCP and the potential for long lived connections. Anycast as described in the article is best for one-way or single request/response packet applications (which generally applies only to UDP on top of IPv4 with today's apps).


[ Parent ]
Statefulness not a problem. (none / 2) (#25)
by mindstrm on Fri Jan 02, 2004 at 07:56:45 PM EST

IT's not like you will hit a different destination machine every time... it's just that from different origins, you may get a different machine with the same address.

It's a trick of routing... nothing more.

[ Parent ]

It is a state problem (none / 2) (#26)
by jtk on Fri Jan 02, 2004 at 08:17:51 PM EST

If you don't reach the same destination every time, state defeats you. Packets to another anycast service host will (in the case of TCP) generate a RST back, because there was no state between those two hosts. If that is not a state problem, what is it?

On a micro-level, most communications may never see this, but because it is possible (and probably likely in most packet switched networks over time), anycast as described in the article using stateful communications without complex synchronization mechanisms is unreliable.


[ Parent ]
Yes... (none / 1) (#27)
by mindstrm on Fri Jan 02, 2004 at 09:16:07 PM EST

That's correct. Of course if the true destination host changes, state will break.. but that won't happen normally... like with 6to4 anycast.. you will generally always end up at the same target machine, as which real machine you get is dependant on routing.

[ Parent ]
we can post messages to k5 using anycast... (none / 1) (#32)
by johwsun on Sat Jan 03, 2004 at 09:04:15 AM EST

..then receive the result using unicast...

[ Parent ]
So, jtk, you think this is not possible? (none / 1) (#34)
by johwsun on Sun Jan 04, 2004 at 10:37:13 AM EST

What if k5 is a host X with 2 interfaces, one anycast and the other unicast.
I use the anycast interface to post my k5 messages to the host X (or to any other k5 host with the same anycast address).
Then I use the unicast address of the host X to read the posted messages.

So, we read k5 using unicast address, but we post on k5 using a single anycast address.

So jtk, you think this is not possible? What are the problems of that senarion?

thank you for you answer ...

[ Parent ]

It is not impossible, but... (none / 1) (#35)
by jtk on Sun Jan 04, 2004 at 11:44:02 AM EST

First of all, if I understand what you're asking, you are trying to improve either the load or reliability by splitting the functions between posting and reading. Generally articles, comments or other submissions are going to be much more frequently read than posted, so you probably want to provide the reliability and load sharing to that function, which means reversing your proposal.

Second of all, this just wouldn't be very practical. Besides the potential for problems already mentioned, this would be difficult to manage and synchronize. What you'd being trying to implement is a distributed database. Ensuring that this distributed database, where articles and comments much be synchronized to all the other servers, is much easier said than done. Studying past attempts at network systems and protocols that have attempted this shows lots of problems in making them work and probably worst of all, catastrophic failures when they don't (e.g. directory services such as Novell's NDS, the Internet's DNS and routing protocols such as OSPF).

Sorry for just rating your previous comment down outright. I'll re-rate.


[ Parent ]
Reading and posting synchronization (none / 1) (#39)
by johwsun on Tue Jan 06, 2004 at 03:42:08 AM EST

The problem of synchronized reading has been somehow solved, using various mirror techniques (like gnu rsync). The problem of a global synchronized posting has not been solved yet.

So I think I will not reverse my proposition, I still believe that a single anycast address must be used for posting.

What I have in my mind is mutliple unicast IP addresses for reading k5, but a single anycast IP address for posting to all k5 mirrors.

In order to use the well known http protocol for posting, the post http method must include as a variable the nearest host you want to be http redirected immediatly after posting your message, in order to check that your just posted message has been published at least to your nearest read_k5 mirror.

Then you are waiting for the routers to carry the anycast IP packets and synchronize the k5 reading mirrored servers.

I hope I understand well your anycast addresses idea ... Note that posting a message should be somehow synchronized, but a delay of some secconds on this synchronization is not critical.

(Out of subject: Whats wrong with OSPF?)

[ Parent ]

An effort in futility? (1.12 / 8) (#41)
by jtk on Tue Jan 06, 2004 at 07:43:53 AM EST

You're free to try to implement what you are proposing, but in my opinion, you are unlikely to find many people following you down this path. As I said, this is probably not a good application for anycast. At least not with today's use of the technology and available alternatives. Whatever Kuro5hin's response problems are, there are probably better ways at solving them than with anycast.

Nothing is really wrong (in any major technical way) with OSPF today, but when it was originally being developed, like many distributed database systems in their early life, there were problems making it work properly. Just take a look at the OSPFv2 RFC, over 200 pages. It can be hard to make something as complex as that operate correctly. In fact, if I recall correctly, OSPFv1 was never really deployed in practice except in a few isolated cases largely because it wasn't fully baked at the time.


[ Parent ]
I am not trying to solve k5 response time... (none / 1) (#42)
by johwsun on Tue Jan 06, 2004 at 12:23:01 PM EST

I am trying to created multiple mirrored k5 forums, in order to take the power from rutsy god's hands.

And I am not going to implement anything. I am first waiting for rusty to built the k5 knowledge tree, where all initial decisions and values of kuro5hin forum will be presented and voted.

On that tree, I will post my proposition, along with the appropriate code to implement it.

Then I will wait for k5 community to vote for my proposition.

If my proposition will be accepted in the knowledge tree, rusty god will be forced to allow the creation of various k5 mirrors.

Every mirror will be administrated by another person, thus the so called "rusty benevolent dictator" period will end.

[ Parent ]

So anycast is not a good solution for my problem (none / 1) (#43)
by johwsun on Wed Jan 07, 2004 at 11:09:29 AM EST

..thanks jtk for your opinion...

[ Parent ]
the above is a question.... (none / 1) (#44)
by johwsun on Wed Jan 07, 2004 at 11:11:19 AM EST

[ Parent ]
I am not tottaly convinced... (none / 1) (#45)
by johwsun on Wed Jan 07, 2004 at 11:50:04 AM EST

..I still have the feeling that by giving a single anycast address as the post address of k5, and using multiple unicast addresses as read addresses, may be a good idea towards the "end_of_the_k5_rusty_dictatorship" goal...

But I am not sure...I am not also sure that I understand anycast well.

..thanks anyway jtk..

[ Parent ]

proxy (none / 1) (#28)
by pyro9 on Fri Jan 02, 2004 at 11:45:50 PM EST

The best thing would be a squid proxy service on anycast. Although there is the possibility of connections breaking, as long as the local target of the anycast doesn't change very often, it'll be OK. After all, web connections are transient, even with keepalive, and easily re-established.

The future isn't what it used to be
[ Parent ]
Web Proxy + IPv4 Anycast = Bad Juju (none / 1) (#30)
by jtk on Sat Jan 03, 2004 at 12:58:11 AM EST

In my opinion it would be misguided to implement anycast for web proxies also. If you're looking for redundancy, there are probably better and simpler solutions to these sorts of applications. People have implemented the shared IPv4 anycast model with some TCP applications, most notably, HTTP, but I'm in the camp that it is unwise to do so in the long term.

FYI... one potential way to get around most of the potential problems with state-based or long-lived applications would be for the initial connection to be made to the anycast address. Then once the connection is established, the server informs the client of a its unique unicast address. The client then proceeds to switch to the unique unicast address on the server. In that way, anycast is used only to locate and discover the nearest service. The unique unicast is used for the duration of the connection (or until something fails at the ends or in between). This gets you load sharing, with less reliability, but the trade-off is probably OK and results in a lot fewer problems than if using the anycast address for the entire connection. I think this technique would be an acceptable approach to deploying anycast, but know that this way is not without some corner case problems as well.

To reiterate what was said in the article, anycast is not for everyone and everything. It is not a panacea.

For more, search through some of the IETF archives, particular some of the RFCS, internet-drafts and mailing lists where anycast is being discussed.


[ Parent ]
probably better to use DNS load balancing (none / 0) (#38)
by m a r c on Sun Jan 04, 2004 at 11:44:24 PM EST

For load balancing between servers its probably a better idea to use DNS load balancing. Just have a DNS name resolve to multiple IP addresses and the client will resolve to one and use this server for its connection.

With anycasting (and DNS server load balancing for that matter) you will have a problem if the connection is terminated. The reason for this is that you require a cookie to log on and if you are disconnected the anycast server/load balanced server that you reconnect to will most likely not be the same one which the cookie was sent from.
I got a dog and named him "Stay". Now, I go "Come here, Stay!". After a while, the dog went insane and wouldn't move at all.
[ Parent ]

cookies authentication (none / 1) (#40)
by johwsun on Tue Jan 06, 2004 at 06:21:12 AM EST

As can be seen in another comment in this thread, I am proposing a two_interfaces k5 host, one anycast interface for posting messages, and another unicast interface for reading messages.

We have to find alternative ways to do the posting authentication in order to support this scheme.

Cookies authentication can still take place when reading messages, but when posting messages to k5 using the above two interfaces scheme, you may have to be authentication on each post, as long as this will be a (severe) anycast post that will go to all k5 mirrors.

Of course, if the http post method includes as a variable the prefered unicast read_k5 address that we want to be automatically redirected after posting the message, then we can be authenticated using the cookie that this k5_read unicast address has offered to us.

[ Parent ]

Anycast Addressing on the Internet | 45 comments (32 topical, 13 editorial, 5 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!