Anycasting: Difference between revisions
imported>Howard C. Berkowitz (New page: While the term '''anycast''' came into prominence with IPv6 work,<ref name=RFC4291>{{citation | id = RFC4291 | title = IP Version 6 Addressing Architecture. | author =R. Hinden, S...) |
imported>Howard C. Berkowitz No edit summary |
||
Line 1: | Line 1: | ||
{{subpages}} | |||
While the term '''anycast''' came into prominence with [[IPv6]] work,<ref name=RFC4291>{{citation | While the term '''anycast''' came into prominence with [[IPv6]] work,<ref name=RFC4291>{{citation | ||
| id = RFC4291 | | id = RFC4291 |
Revision as of 10:23, 25 August 2008
Please create the "Talk page". Just click this Talk page link and save the page.
While the term anycast came into prominence with IPv6 work,[1] it can be quite useful with IPv4. The technique, while somewhat counterintuitive, is useful for load distribution, fault tolerance, or both.
Traditionally, an IP address, inside a given routing/addressing domain, needed to be unique. In this discussion, assume 3.1.1.1 is the address of a server. That is indeed true in a "flat" address space of a single IP subnet (i.e., network prefix). When the environment is split by routers into logical subnets, remember that a router commonly receives different paths to what it assumes is the same address, picks the "best", and puts the associated prefix and outgoing address and puts that in its routing table. It was realized, however, that the router, unless very deliberate steps are taken, really does not know if two potential paths to an address are merely different ways to get to the same instance of an address, or if they represent unique paths to different instances of the address.
As long as the behavior of multiple instances of the address are identical, it makes no difference, to the requesting client, if server A, B, or C actually executes the request.
The IPv6 architecture describes it as:
Anycast: An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocols' measure of distance).[1]
Load balancing case
In the illustration to the left, there are three instances of a server, which carries out a read-only function; it makes no difference to the client which server actually satisfies its request.
The simplistic routing mechanism here adds up the costs of routes to a destination. From router 1, server A is closest. From router 3, server C has the least cost.
Fault tolerance case
Now, simplify the scenario to have but one host. As long as server A is up, router 1 will see a cost of 1 to reach server A. The routing process was aware of other routes to 3.1.1.1, but there was a cost of 2 to server B and a cost of 3 to server C. Router 1 only put the lowest-cost route into its routing table.
But what if server A fails? The router knows other paths to the same address, so it will install the path that goes through router 2. The client will still receive exactly the same service from exactly the same address.
Of course, if client 2 reconnected to Router 3, it would have the lowest cost path to server C as long as Server C stayed up. If Server C fails, router 3 would change its route to 3.1.1.1 to the path to Server B.
Operational examples
References
- ↑ 1.0 1.1 R. Hinden, S. Deering. (February 2006), IP Version 6 Addressing Architecture., RFC4291