MAnycast²: Using anycast to measure anycast

By on 15 Dec 2020

Category: Tech matters

Tags: , ,

Blog home

Manycast2

Since its introduction in 1993, anycast addressing (RFC 1546) has become a fundamental mechanism to increase the resilience and performance of Internet services.

One of the first and most popular deployments of anycast infrastructure was for Domain Name System (DNS) root servers. It has been proven to improve resolution time and resilience against Distributed Denial of Service (DDoS) attacks.

Following the example of the root servers, several other DNS operators started to provide their services on anycast networks, both for public resolvers and authoritative nameservers.

Anycast has also been adopted by several cloud providers, Content Delivery Networks (CDNs), and DDoS protection services, among others.

Read: Reducing latency at CDNs with Bidirectional Anycast/Unicast Probing

Why measure anycast?

Due to its growing popularity, identifying which addresses are anycasted and from where they are announced is becoming fundamentally important to provide a more accurate assessment of the Internet’s resilience.

Unfortunately, the IPv4 approach to anycast relies on the principle of assigning the same unicast address to multiple hosts and leveraging routing to implement the anycast addressing. Due to the opacity of routing, identifying which address is anycast is not straightforward.

Traditional methods of measuring anycast are based on the Great Circle Distance (GCD) technique. The basic idea behind GCD is that if two probes in the world reach a node with a latency that violates the speed of the light, the node must be anycast.

Read: Verfploeter: Broad and load-aware anycast mapping

The GCD approach has proven to be effective and results in a tool for anycast measurement called iGreedy.

However, the GCD approach has some disadvantages; it requires a significant number (~200) of geo-located probes in order to perform an accurate measurement, and has a relevant footprint in terms of generated traffic. RIPE Atlas offers a solution to this, however, this can be unsuitable for a long-term census of the entire Internet.

A new approach

In a recent study headed by the University of Twente, we proposed a new measurement and inference technique, MAnycast², which relies on an anycast testbed to efficiently detect anycast prefixes.

The idea behind MAnycast² is quite simple: We send ICMP echo-requests with our anycast IP address as a source, from all of the anycast nodes in our testbed. The traffic of the ICMP echo-responses to the anycast IP will be then routed back on a single node, if the target is unicast and on multiple nodes, in case the target is anycast.

World map showing the working principle of MAnycast².
Figure 1 — The working principle MAnycast². Anycast vantage points (VPs) are red, target IPs green, and arrows are probe and response, respectively. Responses arrive at a single VP if the target IP is unicast (dashed line), or at multiple VPs if the target IP is anycast (continuous line).

Compared to traditional anycast detection techniques, MAnycast² does not rely on latency measurements. Instead, it leverages the routing system to discriminate anycast deployments.

As part of a paper that we recently presented on at the Internet Measurement Conference (IMC 2020), we tested MAnycast² using two different anycast platforms — Tangled and PEERING. We were able to perform an anycast census of the entire ISI IPv4 hit-list in ∼2.5 hours, with only 10 pings per target IP address, demonstrating the lower traffic footprint and the speed of our methodology.

The results obtained in the census are promising. We validated the finding of MAnycast² with public ground-truth of anycast networks (for example, DNS root servers), reaching operators for confirmations and using a GCD-based tool (iGreedy) with RIPE Atlas.

The comparison shows low error rates, with some exceptions, which indicates some open challenges remain to further improve this methodology.

Fewer false positives

MAnycast² was able to classify 15,540 anycast /24 prefixes and 3,451,133 unicast /24 prefixes.

Table showing anycast census results
Table 1 — Anycast census results with breakdown of /24s by number of Tangled VPs that receive responses.

The comparison with iGreedy results shows low false-negative rates (anycast classified as unicast), and zero false-positive rates (unicast classified as anycast) when it comes to answers received on four or more anycast VPs. False positives often happen due to route instability where answers are received only on two or three anycast nodes.

The combination of the GCD and the MAnycast² approaches show promising results and let us map and confirm 5,987 anycast prefixes.

In the future, we will focus on increasing the accuracy of our methodology and on performing a regular census of the anycast deployment on the Internet.

Can I deploy MAnycast² on my anycast network?

MAnycast² uses VerfPloeter software to perform the distributed ICMP measurement. VerfPloeter is publicly available on GitHub.

Feel free to reach out to us for any information on how to deploy MAnycast² on your network.

Raffaele Sommese is a second-year PhD candidate at the University of Twente, The Netherlands.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

Top