Putting the ANY into Cisco IPv6 Anycast
Who Needs Fault Tolerance?
One of the popular themes in computers and networking his fault tolerance. It basically boils down to the ability for a system to have a single fault, and tolerate it or survive it.
We can have fault tolerance with our physical disks by having two of them. We can have fault tolerance with our network devices, by having two of them. The same is true for our connectivity between switches, where we would have parallel paths and have spanning tree protocol prevent the negative impacts of loops.
Let’s say we have multiple DNS servers that we want to be fault tolerant for the benefit of our users. How exactly would we implement them? We could place the two servers next to each other, and have one act as the primary DNS server for everyone, and have the second server only kick in if the first server is no longer available. Another option would be to have the two servers side-by-side performing load balancing and taking an equal hit regarding serving clients their DNS responses. If we did have a catastrophic failure of that portion of the network, it is possible that both DNS servers would not be reachable.
Anycast, as a Fault-Tolerant Solution
One solution we can use to implement fault tolerant servers, is to implement the concept of using Anycast IP destination for a resource. The Anycast game seems like a mean trick to a typical network, because with Anycast were going to have the same exact IP address and or the same exact networks in more than just one place. By advertising these Anycast networks from more than one location, it will be up to the routers to decide the best path to reach a given Anycast address based on its routing tables. In the diagram below, the green represent the same “Anycast” IP address in use (on multiple DNS servers, as an example), and the client who wants to access the resource identified by the Anycast address is in red. The routers between the client and the Anycast addressed servers will forward the packets to the closest server using the Anycast address, based on the routing tables on those routers.
Practical Example of Anycast in Action
Let’s use the diagram below as live example.
In this network we have two DNS servers, one of the top and another at the bottom of our topology. R2 at the top, has an directly connected network of 2001:22::/64, and R3 (at the bottom of the diagram) has a directly connected network of 2001:33::/64
Clients will be configured or auto-configured with the information of a DNS server, being given the one IPv6 address at 2345::9 (this is the Anycast address, used by both DNS servers). The two DNS servers are configured with this exact address, which is the key behind Anycast. We are using the same IP address in more than one place, and now we need to train the rest of the network on how to reach the 2345::9 hosts. We can do this by adding the Anycast network address to both R2 and R3. On R2, with both the network address and the anycast address, the interface would be configured as:
On R3, the configuration would be similar, with the exception of the different 2001:33::/64 address space and a different OSPF area:
The main purpose of adding the anycast IP addresses, is so that we can advertise them in our routing protocol, and let the rest of the world know how to reach those networks. In the examples above, OSPF is enabled on each of the interfaces, and so the anycast network address of 2345::/64 is now being advertised into the network.
Which Server Will Clients End Up Reaching?
So how will this effect the rest of the network? Lets take a look from R1’s perspective. R1 is learning about the 2345::/64 network via OSPF, and his routing table looks like this:
R1 has only 1 interface towards the cloud, so the DNS server R1 will reach will depend on the routing tables within the cloud, and we should reach the “closest” DNS server, based on those routing tables.
Verifying the Anycast is Working
We can verify which Anycast destination we are connecting to, via a traceroute.
Based on the network trace, our packets being sent towards the Anycast address of 2345::9 are being directed to DNS-2, connected to R2. If we shut R2’s interface down, so that it was no longer available, or increased the OSPF cost on that interface, R1's packets destined for the same Anycast address would be directed to the DNS-3 server connected to R3.
Change the Route, Change the Destination of our Packets
Lets modify the cost of the Fa1/1 interface on R2, to make its metric look less attractive to OSPF.
Now with the cost of the link being worse through R2, if we do the same trace from R1 to the DNS server’s Anycast address, we should reach the DNS server off of R3.
If R2 had a complete failure, and was no longer functioning on the network, we would still have access to the DNS-3 server connected to R3, due to its Anycast address in use, and that network address still being advertised to the network via R3.
In Summary
One of the benefits of using Anycast, is that not only do we have fault tolerance, but based on routing, users will be directed to the closest Anycast address, based on the routing tables of the network or Internet.
Here is a video I created, that reinforces the topics in this blog post:
Thanks for reading,
Keith Barker
