Anycast routing is an IP solution that allows packets to be routed to the topologically nearest server. Over the last years it has been commonly adopted to manage some services running on top of UDP, e.g., public DNS resolvers, multicast rendez-vous points, etc. However, recently the Internet have witnessed the growth of new Anycast-enabled Content Delivery Networks (A-CDNs) such as CloudFlare and EdgeCast, which provide their web services (i.e., TCP traffic) entirely through anycast. To the best of our knowledge, little is known in the literature about the nature and the dynamic of such traffic. For instance, since anycast depends on the routing, the question is how stable are the paths toward the nearest server. To bring some light on this question, in this work we provide a first look at A-CDNs traffic by combining active and passive measurements. In particular, building upon our previous work, we use active measurements to identify and geolocate A-CDNs caches starting from a large set of IP addresses related to the top-100k Alexa websites. We then look at the traffic of those caches in the wild using a large passive dataset collected from a European ISP. We find that several A-CDN servers are encountered on a daily basis when browsing the Internet. Routes to A-CDN servers are very stable, with few changes that are observed on a monthly-basis (in contrast to more the dynamic traffic policies of traditional CDNs). Overall, A-CDNs are a reality worth further investigations.
    Despite its growing use in critical infrastructure services, the performance of IP(v4) Anycast and its interaction with IP routing practices is not well understood. In this paper, we present the results of a detailed measurement study of IP Anycast. Our study uses a two-pronged approach. First, using a variant of known latency estimation techniques, we measure the performance of current commercially operational IP Anycast deployments from a large number (>20,000) of vantage points. Second, we deploy our own small-scale anycast service that allows us to perform controlled tests under different deployment and failure scenarios. To the best of our knowledge, our study represents the first large-scale evaluation of existing anycast services and the first evaluation of the behavior of IP Anycast under failure.We find that: (1) IP Anycast, if deployed in an ad-hoc manner, does not offer good latency-based proximity, (2) IP Anycast, if deployed in an ad-hoc manner, does not provide fast failover to clients, (3) IP Anycast typically offers good affinity to all clients with the exception of those that explicitly load balance traffic across multiple providers, (4) IP Anycast, by itself, is not effective in balancing client load across multiple sites. We thus propose and evaluate practical means by which anycast deployments can achieve good proximity, fast failover and control over the distribution of client load. Overall, our results suggest that an IP Anycast service, if deployed carefully, can offer good proximity, load balance, and failover behavior.    We present the initial results from our evaluation study on the performance implications of anycast in DNS, using four anycast servers deployed at top-level DNS zones. Our results show that 15 to 55 of the queries sent to an anycast group, are answered by the topologically closest server and at least 10 of the queries experience an additional delay in the order of 100ms. While increased availability is one of the supposed advantages of anycast, we found that outages can last up to multiple minutes, mainly due to slow BGP convergence. On the other hand, the number of outages observed was fairly small, suggesting that anycast provides a generally stable service. IP anycast, with its innate ability to find nearby resources in a robust and efficient fashion, has long been considered an important means of service discovery. The growth of P2P applications presents appealing new uses for IP anycast. Unfortunately, IP anycast suffers from serious problems: it is very hard to deploy globally, it scales poorly by the number of anycast groups, and it lacks important features like load-balancing. As a result, its use is limited to a few critical infrastructure services such as DNS root servers. The primary contribution of this paper is a new IP anycast architecture, PIAS, that overcomes these problems while largely maintaining the strengths of IP anycast. PIAS makes use of a proxy overlay that advertises IP anycast addresses on behalf of group members and tunnels anycast packets to those members. The paper presents a detailed design of PIAS and evaluates its scalability and efficiency through simulation. We also present preliminary measurement results on anycasted DNS root servers that suggest that IP anycast provides good affinity. Finally, we describe how PIAS supports two important P2P and overlay applications.   This paper proposes GIA, a scalable architecture for global IP-anycast. Existing designs for providing IP-anycast must either globally distribute routes to individual anycast groups, or confine each anycast group to a pre-configured topological region. The first approach does not scale because of excessive growth in the routing tables, whereas the second one severely limits the utility of the service. Our design scales by dividing inter-domain anycast routing into two components. The first component builds inexpensive default anycast routes that consume no bandwidth or storage space. The second component, controlled by the edge domains, generates enhanced anycast routes that are customized according to the beneficiary domain's interests. We evaluate the performance of our design using simulation, and prove its practicality by implementing it in the Multi-threaded Routing Toolkit.   IP anycast is a central part of production DNS. While prior work has explored proximity, affinity and load balancing for some anycast services, there has been little attention to third-party discovery and enumeration of components of an anycast service. Enumeration can reveal abnormal service configurations, benign masquerading or hostile hijacking of anycast services, and help characterize anycast deployment. In this paper, we discuss two methods to identify and characterize anycast nodes. The first uses an existing anycast diagnosis method based on CHAOS-class DNS records but augments it with traceroute to resolve ambiguities. The second proposes Internet-class DNS records which permit accurate discovery through the use of existing recursive DNS infrastructure. We validate these two methods against three widely-used anycast DNS services, using a very large number (60k and 300k) of vantage points, and show that they can provide excellent precision and recall. Finally, we use these methods to evaluate anycast deployments in top-level domains (TLDs), and find one case where a third-party operates a server masquerading as a root DNS anycast node as well as a noticeable proportion of unusual DNS proxies. We also show that, across all TLDs, up to 72 use anycast.  