Anycasting: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Chris Day
(removing PropDel; author was qualified to write on this topic)
 
(31 intermediate revisions by 9 users not shown)
Line 1: Line 1:
{{subpages}}
{{subpages}}
{{TOC-right}}
'''Anycasting''' is an Internet Protocol routing technique in which the same IP address may exist at several points in the network, with the caveat that each instance of the address must provide exactly the same services. The technique is useful for load balancing, fault tolerance, and security against a Denial of service|DoS attack.
While the term '''anycast''' came into prominence with [[IPv6]] work,<ref name=RFC4291>{{citation
A typical application is a heavily-used database like DNS, where the same data can be provided from any number of identical servers.  Applications are not limited to "read-only" however. See the Sinkhole|sinkholes operational example below.
 
Traditionally, an IP address needed to be unique. This would be absolutely true in a single network with no segmentation.  The Internet, however, is a collection of networks linked by routers.  When the same address is claimed by servers on different networks, an upstream router simply assumes it is the same server as seen via different routes.  It picks the shortest path for its routing table, and ignores the rest.  A router supporting anycast keeps these routes available as alternatives.  Alternative routes may be selected randomly, in a cyclic pattern, or depending on external factors, such as the current load reported by each server.
 
While the term anycast came into prominence with IPv6 work,<ref name=RFC4291>{{citation
  | id = RFC 4291  
  | id = RFC 4291  
  | title = IP Version 6 Addressing Architecture.  
  | title = IP Version 6 Addressing Architecture.  
  | first1 =R.|last1=Hinden |first2= S. | last2=Deering.
  | first1 = R.|last1=Hinden |first2=S.|last2=Deering.
  | date = February 2006
  | date = February 2006}}</ref> it can be quite useful with IPv4. IPv4 has no infrastructure explicitly for anycast while IPv6 does, but the technique can be applied in both areas, with different address structures. Miller discusses "shared anycast",<ref name=>{{citation  
| url = http://www.ietf.org/rfc/rfc4291.txt}}</ref> it can be quite useful with IPv4. The technique, while somewhat counterintuitive, is useful for load distribution, fault tolerance, or both. IPv4 has no infrastructure explicitly for anycast while IPv6 does, but the technique can be applied in both areas, with different address structures. Miller discusses "shared anycast",<ref name=>{{citation  
  | url = http://www.net.cmu.edu/pres/anycast/Deploying%20IP%20Anycast.ppt
  | url = http://www.net.cmu.edu/pres/anycast/Deploying%20IP%20Anycast.ppt
  | title = Deploying IP Anycast
  | title = Deploying IP Anycast
  | first1 = Kevin | last1 = Miller
  | first1 = Kevin | last1 = Miller
  | date = NANOG 29 – October 2003}}</ref> which is different than the IPv6 specific work in RFC 4291, which superceded the RFC 3513 mentioned in the Miller paper.
  | date = NANOG 29 – October 2003}}</ref> which is different from the IPv6 specific work in <nowiki>RFC 4291</nowiki>, which superseded the <nowiki>RFC 3513</nowiki> mentioned in the Miller paper.
 
Traditionally, an IP address, inside a given routing/addressing domain, needed to be unique. In this discussion, assume the [[IPv4] address 3.1.1.1 belongs to a single 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:
The IPv6 architecture describes it as:
<blockquote>'''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).<ref name=RFC4291 /></blockquote>
<blockquote>'''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).<ref name=RFC4291 /></blockquote>
==Contrast to multicast==
==Contrast to multicast==
[[Multicasting]] is essentially a mirror image of anycasting. In multicasting, a source ''S'' sends to a group of recipients, ''G''. Broadcasting is a special case where G contains all possible recipients. It is assumed that G has more than one member.


An anycast source ''S'' sends to a destination address ''D'', which S believes to be a single recipient. In reality, there are multiple instances of D, any one of which can respond to the message addresed to ''D''.  
Anycasting is similar to Multicasting. In multicasting, a source '''S''' sends to a group '''G''' of recipients. Broadcasting is a special case where '''G''' contains all possible recipients. It is assumed that '''G''' has more than one member.
[[Image:Anycast-Load-Distribution.png|thumb|right|300px|Load distribution example]]
 
An anycast source '''S''' sends a data packet to a destination address '''D''', which '''S''' believes to be a single machine. In reality, there are multiple instances of '''D''', any one of which can receive the packet addressed to '''D'''.  
{{Image|Anycast-Load-Distribution.png|right|300px|Figure 1. Load distribution example}}
 
==Load balancing case==
==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.   
In Figure 1, there are two clients and three servers, all with the same IP address 3.1.1.1.  It makes no difference to either client which server satisfies its request.
[[Image:Anycast-before-failure.png|thumb|right|300px|Single client with all servers working]]
 
The traditional routing algorithm adds up the costs of links along the available routes to a destination and always picks the lowest cost route. From client '''1''', server '''A''' is closest (cost=1) and server '''3''' is furthest (cost=3). Therefore, client '''1''' always connects to server '''A''', and client 2 always connects to server '''C'''.
 
An anycast router can balance the load among all routes, rapidly switching from one to another.  A packet from Client 1 can be routed just as easily to Server C as to Server A.<ref>
There is some doubt about this statementSee the talk page.
</ref>
{{Image|Anycast-before-failure.png|right|300px|Figure 2. Single client with all servers working}}


==Fault tolerance case==
==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.
[[Image:Anycast-after-failure.png|right|300px|thumb|Single client after failure]]
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.
Now, simplify the scenario to have but one client (Figure 2). 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''' put only the lowest-cost route into its routing table.
{{Image|Anycast-after-failure.png|right|300px|Figure 3. Single client after failure}}
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.<ref>
Fault tolerance occurs as a result of normal router action, nothing special about anycasting.
</ref>
It is a standard rule of router configuration, based on the end-to-end assumption of Internet protocol routing, that IP addresses are unique. Anycasting, however, creates multiple instances of the same address, breaking this rule but in a controlled manner. Some of the constraints on an anycast configuration is that the different instances of the same address must be on separate routers.


==Operational examples==
==Operational examples==
Anycast works well for any application that is read-only and where the relevant servers have a common database. One common application is the root servers for the [[Domain Name Service]].<ref name=RootServer>{{citation
Anycast works well for applications that do not require perfect synchronization of changes at the servers and do not need to keep track of sessions or user state.  An application requiring the user to log in, for example, might get confused if the session was suddenly switched to a machine on which the user is not logged in.
| title = Root Server Anycast Status
 
| url = http://gac.icann.org/web/meetings/mtg22/RootServerAnycastStatus.ppt}}</ref> Another application is in [[Internet Protocol]] infrastructure security. Large operators may have multiple [[sinkhole]]s <ref>{{citation |
One common application of anycast is the root servers for the Domain Name System. While the official list has thirteen named servers, there are actually hundreds of geographically distributed machines.
|url = http://www.arbornetworks.com/downloads/Sinkhole_Tutorial_June03.pdf
 
| title = Sinkholes: A Swiss Army Knife ISP Security Tool Version 1.8
Another application is an active defense against Denial of service|DoS attacks. Instead of just providing more capacity to absorb the attack, or even null-routing it, it is possible to divert the attack to a set of Sinkhole|sinkholes that analyze the traffic, and perhaps even engage with the attacker, trying to elicit traceback information, or even tarpit the attacker's machines.
| first1 = Barry Raveendran | last1 = Greene | first2 = Danny | last2 = Macpherson}}</ref> for analyzing hostile traffic; the sinkhole nearest the ingress router does the analysis of a single-stream denial of service (DoS) attack, while anycast-addressed sinkholes respond well under distributed denial of service (DDoS) attack.
 
When an attack is detected, the server under attack would be useless due to overload, so its address is reassigned as an anycast address of a set of sinkholes. For a single-stream attack, the sinkhole nearest the ingress router does the analysis. For a distributed denial of service (DDoS) attack, the entire set of sinkholes may engage the attack flow, multiplying processing power through loose parallelism.


Router interface addresses that are unicast need more care in configuration, but are still feasible.<ref name=Kristoff>{{citation
| author = John Kristoff
| title = Anycast Addressing on the Internet
| date = January 2, 2004
| contribution = Anycast Routing
| url =https://www.kuro5hin.org/story/2003/12/31/173152/86 }}</ref> When using anycast with routers, it is best to use a routing protocol, such as the [[Border Gateway Protocol]] or [[Open Shortest Path First]], that has an explicit router identifier that can disambiguate different announcements of the same address.
==References==
==References==
 
{{reflist}}
{{reflist|2}}

Latest revision as of 09:02, 25 October 2024

This article has a Citable Version.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article has an approved citable version (see its Citable Version subpage). While we have done conscientious work, we cannot guarantee that this Main Article, or its citable version, is wholly free of mistakes. By helping to improve this editable Main Article, you will help the process of generating a new, improved citable version.

Anycasting is an Internet Protocol routing technique in which the same IP address may exist at several points in the network, with the caveat that each instance of the address must provide exactly the same services. The technique is useful for load balancing, fault tolerance, and security against a Denial of service|DoS attack. A typical application is a heavily-used database like DNS, where the same data can be provided from any number of identical servers. Applications are not limited to "read-only" however. See the Sinkhole|sinkholes operational example below.

Traditionally, an IP address needed to be unique. This would be absolutely true in a single network with no segmentation. The Internet, however, is a collection of networks linked by routers. When the same address is claimed by servers on different networks, an upstream router simply assumes it is the same server as seen via different routes. It picks the shortest path for its routing table, and ignores the rest. A router supporting anycast keeps these routes available as alternatives. Alternative routes may be selected randomly, in a cyclic pattern, or depending on external factors, such as the current load reported by each server.

While the term anycast came into prominence with IPv6 work,[1] it can be quite useful with IPv4. IPv4 has no infrastructure explicitly for anycast while IPv6 does, but the technique can be applied in both areas, with different address structures. Miller discusses "shared anycast",[2] which is different from the IPv6 specific work in RFC 4291, which superseded the RFC 3513 mentioned in the Miller paper.

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]

Contrast to multicast

Anycasting is similar to Multicasting. In multicasting, a source S sends to a group G of recipients. Broadcasting is a special case where G contains all possible recipients. It is assumed that G has more than one member.

An anycast source S sends a data packet to a destination address D, which S believes to be a single machine. In reality, there are multiple instances of D, any one of which can receive the packet addressed to D.

(CC) Image: Howard C. Berkowitz
Figure 1. Load distribution example

Load balancing case

In Figure 1, there are two clients and three servers, all with the same IP address 3.1.1.1. It makes no difference to either client which server satisfies its request.

The traditional routing algorithm adds up the costs of links along the available routes to a destination and always picks the lowest cost route. From client 1, server A is closest (cost=1) and server 3 is furthest (cost=3). Therefore, client 1 always connects to server A, and client 2 always connects to server C.

An anycast router can balance the load among all routes, rapidly switching from one to another. A packet from Client 1 can be routed just as easily to Server C as to Server A.[3]

(CC) Image: Howard C. Berkowitz
Figure 2. Single client with all servers working

Fault tolerance case

Now, simplify the scenario to have but one client (Figure 2). 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 put only the lowest-cost route into its routing table.

(CC) Image: Howard C. Berkowitz
Figure 3. Single client after failure

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.[4] It is a standard rule of router configuration, based on the end-to-end assumption of Internet protocol routing, that IP addresses are unique. Anycasting, however, creates multiple instances of the same address, breaking this rule but in a controlled manner. Some of the constraints on an anycast configuration is that the different instances of the same address must be on separate routers.

Operational examples

Anycast works well for applications that do not require perfect synchronization of changes at the servers and do not need to keep track of sessions or user state. An application requiring the user to log in, for example, might get confused if the session was suddenly switched to a machine on which the user is not logged in.

One common application of anycast is the root servers for the Domain Name System. While the official list has thirteen named servers, there are actually hundreds of geographically distributed machines.

Another application is an active defense against Denial of service|DoS attacks. Instead of just providing more capacity to absorb the attack, or even null-routing it, it is possible to divert the attack to a set of Sinkhole|sinkholes that analyze the traffic, and perhaps even engage with the attacker, trying to elicit traceback information, or even tarpit the attacker's machines.

When an attack is detected, the server under attack would be useless due to overload, so its address is reassigned as an anycast address of a set of sinkholes. For a single-stream attack, the sinkhole nearest the ingress router does the analysis. For a distributed denial of service (DDoS) attack, the entire set of sinkholes may engage the attack flow, multiplying processing power through loose parallelism.

References

  1. 1.0 1.1 Hinden, R. & S. Deering. (February 2006), IP Version 6 Addressing Architecture., RFC 4291
  2. Miller, Kevin (NANOG 29 – October 2003), Deploying IP Anycast
  3. There is some doubt about this statement. See the talk page.
  4. Fault tolerance occurs as a result of normal router action, nothing special about anycasting.