Home ›

IPv4 Anycast with Linux and Quagga

Issue 187

From Issue #187
November 2009

Nov 01, 2009  By Philip Martin
 in
Ease configuration headaches and improve availability with anycast.
Monitoring and Automatic Route Withdrawal

As I mentioned previously, the fact that a host is up does not mean that the service that host provides is up. When a host running Quagga goes down, any routes that host inserted into OSPF will be withdrawn. We need to do the same thing when a service does down. Any piece of monitoring software that can run a handler script in response to a monitoring event can be used for this task. The basic idea is to execute a test against the anycast IP from each anycast endpoint. If a test fails, you need to run ifdown lo:0 on the failed endpoint. Quagga will detect the downed interface and withdraw the route to that interface from OSPF. Administrators then can fix the box at their leisure and place the box back into service with a simple ifup lo.

Application/Router Configuration Notes

1. Adjusting the cost of a link can be a great way to prepare an endpoint for removal gracefully. Using any other method, especially in a high-traffic environment, can result in dropped connections and other transient issues until OSPF reconverges. Setting the link cost very high before removal, on the other hand, avoids any transient problems during the brief reconvergence period. Once the endpoint in question is no longer receiving traffic, you can disable the anycast loopback and do whatever work needs to be done. Adjust the cost of a link on the router connected to your server with the following commands (in the example above that would be R1 or R2): 

interface WHATEVER-INTERFACE-CONNECTS-THE-ROUTER-TO-QUAGGA
  ip ospf cost NUMBER

Replace {number} with some large number that is greater than the cost of the replacement anycast endpoint.

2. Make sure nonresponse traffic is not sourced from the anycast address. One example is in configuring DNS. You want DNS replies to come from the anycast IP address, but you do not want DNS zone transfers to come from or go to anycast IP addresses. In the case of a caching nameserver, you also don't want recursive queries originated from the server to be sourced from the anycast address.

3. Applications that maintain state in some way are not good candidates for anycast addressing, even if the underlying transport protocol is stateless. The exception to that rule would be if all the anycast endpoints got their application-level state information from the same place.

4. UDP is the de facto standard for the anycast transport-layer protocol. Use any other transport-layer protocol at your own risk. See Resources for a detailed review of issues associated with using other transport-layer protocols.

Conclusion

Anycast is a great technique to enhance the reliability and fault tolerance of applications and services on your network. When designing your anycast topology, keep several rules and guidelines in mind. I've shown a very basic use case and deployment of anycast here. You can take the same concepts covered in this article, along with a fair bit of networking knowledge, and scale them to a worldwide deployment. If you do it right, you can have redundancy without nearly as many idle machines sitting around.

Resources

root-servers.org: www.root-servers.org

OpenBGPD: www.openbgpd.org

GNU Zebra: www.zebra.org

“IP Routing Primer, Part One”: www.networkcomputing.com/netdesign/1122ipr.html

“Cisco administration 101: What you need to know about OSPF”: articles.techrepublic.com.com/5100-10878_11-6132046.html

“Open Shortest Path First (OSPF)”: www.cisco.com/en/US/docs/internetworking/technology/handbook/OSPF.html

“Architectural Considerations of IP Anycast”: tools.ietf.org/html/draft-mcpherson-anycast-arch-implications-00

Philip Martin has been working and playing with Linux for about ten years and is currently a Systems Engineer for a large on-line retailer. When he is not working with computers, he spends his days trying to be more like Alton Brown and in an ongoing quest to get invited to an Iron Chef America filming. He can be reached at phillip.martin@gmail.com.

______________________

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions