Determining the Cause and Frequency of Routing Instability with Anycast

  • James Hiebert
  • Peter Boothe
  • Randy Bush
  • Lucy Lynch
Part of the Lecture Notes in Computer Science book series (LNCS, volume 4311)


In this article we present a methodology by which an autonomous system (AS) can estimate the stability of their BGP routes without requiring access to restricted BGP data. We demonstrate a novel measurement approach using DNS anycast as an indicator of routing instability. Using this method, even end-users may monitor their ISP’s routing stability, something which was previously infeasible without the continual use of expensive ICMP traceroutes or access to generally restricted routing information. We then perform a case study from within a large ISP in order to quantify and determine the cause of the routing instability. To determine causation, we correlate external and internal BGP events with variations in the final anycast destination. We conclude that anycast is extremely sensitive to anomalous BGP events and that by monitoring anycast it may be possible for large networks to receive early warning of BGP instability.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Labovitz, C., Malan, G.R., Jahanian, F.: Internet routing instability. IEEE/ACM Transactions on Networking 6(5), 515–528 (1998), CrossRefGoogle Scholar
  2. 2.
    Rexford, J., Wang, J., Xiao, Z., Zhang, Y.: BGP routing stability of popular destinations. In: ACM SIGCOMM Internet Measurement Workshop (2002)Google Scholar
  3. 3.
    Wu, J., Mao, Z.M., Rexford, J., Wang, J.: Finding a needle in a haystack: Pinpointing significant BGP routing changes in an IP network. In: NSDI (2005)Google Scholar
  4. 4.
    Application of the Border Gateway Protocol in the Internet, Internet Engineering Task Force: RFC 1772 (March 1995), [Online], Available:
  5. 5.
    McPherson, D., Gill, V.: BGP MULTI_EXIT_DISC (MED) considerations. Internet Engineering Task Force: RFC 4451 (March 2006), [Online], Available:
  6. 6.
    Partridge, C., Mendez, T., Milliken, W.: Host anycasting service. IETF Request for Comments: 1546 (November 1993), [Online], Available:
  7. 7.
    Abley, J.: A software approach to distributing requests for DNS service using GNU Zebra, ISC BIND 9 and FreeBSD. Internet Systems Consortium, Inc., Tech. Rep. ISC-TN-2004-1 (March 2004), [Online], Available:
  8. 8.
    Abley, J.: Hierarchical anycast for global service distribution, Internet Systems Consortium, Inc., Tech. Rep. ISC-TN-2003-1 (2003), [Online], Available:
  9. 9.
    Sarat, S., Pappas, V., Terzis, A.: On the use of anycast in DNS. Johns Hopkins University, Tech. Rep. (December 2004)Google Scholar
  10. 10.
    Ballani, H., Francis, P.: Towards a global IP anycast service. In: SIGCOMM (2005)Google Scholar
  11. 11.
    Brownlee, N.: RTTs for anycast root nameservers. ISC Operations, Analysis, and Research Center, July 20, 2005, presentation given by KC Claffy on July 26 (2005)Google Scholar
  12. 12.
    Karrenberg, D.: DNS anycast stability: A closer look at DNSMON data. NANOG (presentation slides) (March 2005)Google Scholar
  13. 13.
    University of Oregon Route Views Project, 1997-present (1997) [Online], Available:
  14. 14.
    Li, J., Bush, R., Mao, Z., Griffin, T., Roughan, M., Stutzbach, D., Purpus, E.: Watching data streams toward a multi-homed sink under routing changes introduced by a BGP beacon. In: Proceedings of Passive and Active Measurement Conference 2006 (March 2006)Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2006

Authors and Affiliations

  • James Hiebert
    • 1
  • Peter Boothe
    • 1
  • Randy Bush
    • 2
  • Lucy Lynch
    • 3
  1. 1.Department of Computer and Information ScienceUniversity of OregonEugeneUSA
  2. 2.Internet InitiativeJapan
  3. 3.University of Oregon 

Personalised recommendations