Building network automation solutions

9 module online course

Start now!

Chasing Anycast IP Addresses

One of my readers sent me this question:

My job required me to determine if one IP address is unicast or anycast. Is it possible to get this information from the bgp dump?

TL&DR: Not with anything close to 100% reliability. An academic research paper (HT: Andrea di Donato) documents a false-positive rate of around 10%.

If you’re not familiar with IP anycast: it’s a brilliant idea of advertising the same prefix from multiple independent locations, or the same IP address from multiple servers. Works like a charm for UDP (that’s how all root DNS servers are built) and supposedly pretty well across distant-enough locations for TCP (with a long list of caveats when used within a data center).

Forgetting the trivial intra-DC case (analyze next hops on edge switches and figure out if the same IP prefix points to multiple servers), the question “is a prefix advertised from multiple locations (anycast), or is it just an AS advertising a single prefix from its global network (business-as-usual)” is impossible to answer by looking at BGP updates.

You could explore public BGP looking glasses, or parse public BGP feeds, and you’ll either:

  • Observe the IP prefix being announced from the same AS world-wide, which would be perfectly legal if the organization had a global network of their own.
  • Observe the IP prefix announced from multiple autonomous systems, which could indicate an anycast IP address, or a global organization too lazy to own an AS.

You could also look at geographical distribution of upstream AS, distance between upstream AS pairs, maximum distance of upstream AS… and still get a 10% false positive (see link above).

Years ago, someone got a great idea to use speed of light to answer the question. Deploy probes around the globe, and measure their RTT to the suspected anycast IP address. Assume you’re dealing with a single IP address, and see if you can break the speed of light (example: short RTT in Sidney and London).

Deploying the probes shouldn’t be a big deal. Even if you can’t use RIPE Atlas, it shouldn’t be a problem to deploy a few virtual machines in one of the large public clouds.

An even better idea is to send probes (example: pings, TCP SYNs) to the target IP address from a globe-spanning anycast network. If the destination is a unicast address, all responses will go to a single probing node (the one closest to the destination), if multiple probes receive the responses, you’re almost certainly dealing with an anycast destination. For more details, read this article (thanks a million to Alexander Grigorenko for posting the link in the comments).

Revision history

2021-03-06
Added a link to ‌Towards Passive Analysis of Anycast in Global Routing: Unintended Impact of Remote Peering article suggested by Andrea di Donato.
2021-03-05
Reworded the last paragraph together with a link to MAnycast² article.

7 comments:

  1. As you well said, I don't think there is a 100% reliable way to know, but one thing that could help is to look for the aggregator BGP attribute that, if present, and showing different IPs, might be an indication of the prefix being originated in different locations.

    Couple of examples:

    http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=1.1.1.1 http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=208.67.222.222

  2. @Alvaro: Thank you. However, in principle someone could propagate more specific BGP prefixes within their network and aggregate at egress routers, which would result in the same behavior.

  3. The idea is quite simple - use anycast to find anycast: https://blog.apnic.net/2020/12/15/manycast2-using-anycast-to-measure-anycast/
  4. @Alexander: Thanks a million - that's exactly what I've been looking for 👍

  5. Hi there,
    This is an interesting paper showing a passive/BGP approach.

    https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.eecis.udel.edu/~hnw/paper/sigcomm-ccr-2019.pdf&ved=2ahUKEwiP0ve2hJvvAhUWH-wKHU5iAUkQFjACegQIDxAC&usg=AOvVaw01z3HkM7fWDgBNp3_dSoNr

    Cheers/Ciao
    Andrea

  6. @Andrea: Thanks for the link. Now we can quantify my "not with anything close to 100% reliability" as "approximately 10% of false positives". Rewording the blog post.

  7. @Ivan: Pleasure, it's actually cited within the " RELATED WORK AND BACKGROUND" section of the MAnycast² paper (whose related APNIC blog link was provided by Alexander) @ https://www.caida.org/publications/papers/2020/manycast2/manycast2.pdf

    Cheers/Ciao
    Andrea

Add comment
Sidebar