MAPPING INTERNET ROUTING WITH ANYCAST AND UTILIZING SUCH MAPS FOR DEPLOYING AND OPERATING ANYCAST POINTS OF PRESENCE (PoPs)
20220353236 · 2022-11-03
Assignee
Inventors
Cpc classification
H04L67/1008
ELECTRICITY
International classification
Abstract
Generally, aspects of the invention involve creating a data structure (a map) that reflects routing of Internet traffic to Anycast prefixes. Assume, for example, that each Anycast prefix is associated with two or more deployments (Points of Presence or PoPs) that can provide a service such as DNS, content delivery (e.g., via proxy servers, as in a CDN), distributed network storage, compute, or otherwise. The map is built in such a way as to identify portions of the Internet (e.g., in IP address space) that are consistently routed with one another, i.e., always to the same PoP as one another, regardless of how the Anycast prefixes are deployed. Aspects of the invention also involve the use of this map, once created. The map can be applied in a variety of ways to assist and/or improve the operation of Anycast deployments and thus represents an improvement to computer networking technology.
Claims
1.-23. (canceled)
24. A method of creating a network map, comprising: providing a plurality of Anycast deployments on the Internet to deliver one or more services to clients, the plurality of Anycast deployments comprising a plurality of servers; determining a set of two or more IP addresses that are consistently routed across the plurality of Anycast deployments; selecting a particular IP address from the set of two or more IP addresses to represent the set of two or more IP addresses in a test; and, based at least in part on a result of the test, taking an action to improve the delivery of the one or more services.
25. The method of claim 24, wherein the test comprises running network probe against the particular IP address.
26. The method of claim 24, wherein the test comprises any of load measurement and latency estimation.
27. The method of claim 24, the action comprising any of load balancing, performance optimization, and deployment planning, with respect to at least one Anycast deployment
28. The method of claim 24, the action comprising changing an Anycast prefix advertisement.
29. A non-transitory computer-readable medium storing program instructions for execution one or more processors or one or more computers, said program instructions comprising instructions to cause the one or more computers to: provide a plurality of Anycast deployments on the Internet to deliver one or more services to clients, the plurality of Anycast deployments comprising a plurality of servers; determine a set of two or more IP addresses that are consistently routed across the plurality of Anycast deployments; select a particular IP address from the set of two or more IP addresses to represent the set of two or more IP addresses in a test; and, based at least in part on a result of the test, take an action to improve the delivery of the one or more services.
30. The non-transitory computer-readable medium of claim 29, wherein the test comprises running network probe against the particular IP address.
31. The non-transitory computer-readable medium of claim 29, wherein the test comprises any of load measurement and latency estimation.
32. The non-transitory computer-readable medium of claim 29, the action comprising any of load balancing, performance optimization, and deployment planning, with respect to at least one Anycast deployment
33. The non-transitory computer-readable medium of claim 29, the action comprising changing an Anycast prefix advertisement.
34. A computer system comprising circuitry forming one or more processors and memory storing instructions for execution on the one or more processors, upon execution the instructions causing the computer system to: provide a plurality of Anycast deployments on the Internet to deliver one or more services to clients, the plurality of Anycast deployments comprising a plurality of servers; determine a set of two or more IP addresses that are consistently routed across the plurality of Anycast deployments; select a particular IP address from the set of two or more IP addresses to represent the set of two or more IP addresses in a test; and, based at least in part on a result of the test, take an action to improve the delivery of the one or more services.
35. The computer system of claim 34, wherein the test comprises running network probe against the particular IP address.
36. The computer system of claim 34, wherein the test comprises any of load measurement and latency estimation.
37. The computer system of claim 34, the action comprising any of load balancing, performance optimization, and deployment planning, with respect to at least one Anycast deployment
38. The computer system of claim 34, the action comprising changing an Anycast prefix advertisement.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0026] The invention will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which:
[0027]
[0028]
[0029]
[0030]
[0031]
[0032]
[0033]
[0034] Numerical labels are provided in some FIGURES solely to assist in identifying components being discussed in the text; no significance should be attributed to the numbering unless explicitly stated otherwise.
DETAILED DESCRIPTION
[0035] The following description sets forth embodiments of the invention to provide an overall understanding of the principles of the structure, function, manufacture, and use of the methods and apparatus disclosed herein. The systems, methods and apparatus described in this application and illustrated in the accompanying drawings are non-limiting examples; the claims alone define the scope of protection that is sought.
[0036] 1.0 Concept
[0037] Anycast deployments split the Internet into catchments. The catchments of a given deployment are a function of the deployment itself and routing on the Internet. We combine the catchment information from multiple anycast deployments to learn about the underlying Internet topology and routing policies that cause partitions of IP-space to be routed differently from one another. By combining the catchment information from enough anycast deployments, we create a map of the fault lines of the Internet where routing changes occur. In other words, we create a mapping of IP addresses into partitions where the IP addresses within a partition are always part of the same catchment regardless of anycast deployment.
[0038] First, consider a single anycast prefix a.sub.1 advertised from two PoPs, l.sub.1 and l.sub.2. We use two PoPs for ease of exposition, but the method can generalize to any number of PoPs. Using any technique available, traffic is induced from all of IP-space to the anycast prefix splitting the Internet into two partitions, the portion that is the catchment for l.sub.1 and the portion that is the catchment for l.sub.2, P.sub.a1.fwdarw.l1 and P.sub.a1.fwdarw.l2, respectively. Note that the two catchments need not be composed of contiguous IP-space. Next, take a second anycast prefix a.sub.2 again advertised from two different PoPs, l.sub.3 and l.sub.4. Again, the Internet is split into two sections: P.sub.a2.fwdarw.ld and P.sub.a2.fwdarw.l4. When considered together, a.sub.1 and a.sub.2 split the Internet into 4 possible partitions: P.sub.a1.fwdarw.l1, a2.fwdarw.l3, P.sub.a1.fwdarw.l2, a2.fwdarw.l3, P.sub.a1.fwdarw.l1, a2.fwdarw.l4, and P.sub.a1.fwdarw.l2, a2.fwdarw.l4. Any partitions that are empty can trivially be ignored.
[0039] Using n anycast prefixes, a.sub.1, a.sub.2, a.sub.3, . . . , a.sub.n, the Internet is split into up to 2.sup.n partitions. As n.fwdarw.∞, the number of partitions is bounded by the number of IP addresses on the Internet. Practically, however, we expect the number of partitions to be far less as many hosts on the Internet experience the same routing due to residing in the same topological location and having the same routing policies applied to them. We call the discovered partitions “consistently routed” because all IP addresses within the partition are always routed to the same PoP regardless of the anycast deployment in question.
[0040] Because all IP addresses (“IPs”) within a partition are consistently routed, the routing of any IP address within a partition is representative of all IPs in the partition. Thus, a landmark IP address may be selected from within the partition and used in measurements with the understanding that the observed results apply to the entire partition.
[0041] Note that many types of network routing changes caused by traffic engineering will not perturb the map. For example, traffic being re-routed from one path to another does not invalidate the map because the map indicates that partitions of IP-space should be routed together, not to where they are routed.
[0042] 2.0 Implementation
[0043] In this section, we describe a method to generate the map using real world data from a production system and discuss algorithmic adjustments to the theory needed to address real world problems.
[0044] 2.1 Dataset
[0045] To create a map as described previously, we can use logs captured from an anycast authoritative DNS service. The DNS service uses 22 IPv4 anycast prefixes, each used for authoritative hosting of a wide variety of DNS zones and advertised from a distinct set of PoPs distributed around the entire globe. Log lines from the authoritative nameservers include the source IP address and the destination IP address—which is from one of the 22 anycast prefixes—of the DNS query. From the nameserver that logs the query, we can infer the catchment of the source IP address for the anycast prefix identified by the destination address. We use DNS traffic logs to create the map, but note that a map could be generated from logs for other types of Anycast traffic, including web access.
[0046] We collect 5 days of logs and summarize the data in Table 1, 2018-06-14 through 2019-02-21. R2019-02-21 dataset is collected from recursive resolvers and discussed in Section 3.4. In addition to the number of DNS queries in each dataset and the number of source IP addresses, we compute the number of /24 blocks that the source IP addresses are within, use Team Cymru [7] to determine the ASN, and use the commercially available geolocation service EdgeScape [2] to determine the country code of each source IP address in our datasets. All 5 days have similar properties.
TABLE-US-00001 TABLE 1 Datasets used in this paper Date Queries Source IPs /24 Blocks ASNs Countries 2018 Jun. 14 138 B 5.8M 1.6M 47K 238 2019 Feb. 7 129 B 5.1M 1.5M 44K 240 2019 Feb. 8 139 B 5.0M 1.5M 41K 243 2019 Feb. 14 158 B 5.5M 1.6M 42K 243 2019 Feb. 21 168 B 5.4M 1.6M 44K 240 R2019 Feb. 21 2.26 B 385K 107K 2952 84
[0047] Since our theoretical approach expects complete data from all IP addresses on the Internet, we attempt to estimate how complete our datasets are. First, in terms of IP addresses, our datasets cover roughly 0.1% of the approximately 3.7B total IPv4 addresses excluding reserved space [25] and 0.5% of the 1.1B IPv4 addresses estimated to be in use as of 2014 Clearly, our datasets are not exhaustive. However, the number of active /24 blocks on the Internet is estimated as 4.8M in 2013 [15] and 6.3M in 2014 [31] of which our datasets cover 31% and 24%, respectively. Further, 65K ASNs appear in routing tables [10] and our datasets cover 63-72% of that number. Finally, EdgeScape recognizes 248 country codes of which 96-98% are covered in our datasets. Thus, we conclude that, while our data is incomplete, the coverage of our datasets is sufficient to produce interesting and meaningful results with some error, We attempt to quantify the error in a later section,
[0048] 2.2 Algorithm
[0049] In this section, we describe the method of generating a map. The input to our algorithm is the total hits (DNS queries) arriving at each PoP from each IP address to each anycast prefix over a 24 hour period. We use a time window of one day to avoid missing parts of the globe due to diurnal patterns. First, we deal with each anycast prefix individually in Algorithm 1 to find maximum block covering IP addresses with the constraint that all of the IP addresses covered are in the same catchment. Using a greedy approach, the algorithm loops through each IP address in turn and then using the IP address as a root, the algorithm attempts to find a covering block of the root IP address where (i) all covered IP addresses are routed to the same PoP, (ii) none of the covered IP addresses are already covered by another covering block, and (iii) the covering block cannot be further expanded without violating (i) or (ii). In this way, we identify the partitions of IP-space created by a single anycast deployment. While not yet tested experimentally, any one of the standard approaches used in vector clustering (such as DBSCAN) may be tried, tuned, and if suitable used as an alternative to the greedy approach, as long as the approach achieves the goal of clustering IP addresses that are routed to the same PoP together.
[0050] In the 2019-02-07 dataset, we observe that 890K (17%) IP addresses are routed to multiple PoPs for the same anycast prefix over the 24 hour period. One potential cause is route instability that, while rare, does occur [23, 29, 30]. Because our data is aggregated over a day, the routing changes observed may be due to a variety of other causes as well, some long time scale and some short. These include: [0051] Maintenance events both in the PoPs and in networks along the path can cause all traffic routed to one PoP to shift to another for time periods ranging from minutes to hours. [0052] The data is DNS queries from (predominantly) recursive resolvers that use an ephemeral port number for each query [27]. Thus, traffic engineering techniques that hash the port numbers (e.g., equal-cost multi-path) may spread traffic from a single IP address among multiple PoPs on a packet-by-packet basis. [0053] Other traffic engineering that causes traffic to shift between routes at specific times, e.g., due to traffic volume increases during peak times.
[0054] We make no attempt to distinguish between these causes of routing changes, noting they are all possible in production traffic. Thus, practical implementations of our methodology must contend with all sources of route changes and we design our algorithm to explicitly take them into account as shown in
[0055] A simplified pseudocode of the above
[0056] Instead of looking for covering blocks where all covered IP addresses are routed to a single PoP, we relax the constraint by looking for covering blocks where all covered IP addresses are routed to the same set of PoPs over the day. Thus, if the root switches sink from A to B during the 24 hours, we look for other IP addresses that have also switched between the same two sinks during the day. Further, because 44% of IP addresses in the 2019-02-07 dataset sent less than 10 DNS queries to at least one anycast prefix, we cannot be confident that we observe all routing changes that impacted these IP addresses throughout the 24 hour period. Thus, we may only have samples in our dataset from when the IP address was in the catchment of A or B and not both. So, the algorithm iterates through IP addresses in order of descending total hits to build covering blocks based upon root IP addresses where we have higher confidence in our Observations due to abundant samples. Next, the covering block is expanded to cover IP addresses if the set of PoPs that they are routed to intersects with the set of PoPs to which the root IP address is routed. Finally, we add a threshold minimum number of hits within a covering block and keep expanding the block if below the threshold. The threshold value limits the generation of small max blocks that represent very few samples. In practice, we find a low threshold value of 10 is sufficient and produces reasonable results.
[0057] After finding the maximum blocks for each anycast prefix, we merge them together to form the map. If there is a conflict between the maximum blocks of different anycast prefixes, the more specific one wins. For example, in the scenario where 1.2.3.0/24 and 1.2.3.0/26 both appear in the merger, 1.2.3.0/26 appears in the map while the rest of 1.2.3.0/24 is split into two blocks: 1.2.3.64/26 and 1.2.3.128/25. Then, merged blocks that are routed to the same PoPs per each anycast prefix are combined into a single partition. In a last step, we add the partition /0 to cover any IP-address space that is not covered by any other partition.
[0058] 3.0 Analysis
[0059] The map created from the 2019-02-07 dataset contains 484K prefixes.
[0060] In all, we find the map contains 212K partitions after merging the prefixes. We explore the consistency of the partitions by computing the number of ASNs each partition covers and find that 94% of partitions consist of IPs from a single ASN. Another 6.8K (4%) partitions consist of exactly two ASNs. We expect different ASNs to have different routing policies and this result agrees with that intuition. Conversely, the IP-space of 37% of ASNs is split across multiple partitions, higher than observed in [17] likely due to the larger number of PoPs in our study. This result is also expected as it is common for ASNs to use multiple peering links as in the /32 blocks example above.
[0061] 3.1 Is 22 Anycast Prefixes Enough?
[0062] In Section 1 (Concept), we proposed the use of a potentially infinite number of anycast prefixes to create a map. Practically, however, the number of anycast prefixes is a finite number and we have data from 22. To answer whether 22 anycast prefixes is sufficient to produce a map with the desired properties, we create maps with subsets of the 22 anycast prefixes where the set size varies from 1 to 21 anycast prefixes.
[0063] 3.2 Error in Map
[0064] The method of generating the map in the presence of routing changes described in Section 2 necessarily causes some error in the map. However, measuring the error in the map is not straightforward. Recall that the map indicates that all IP addresses in a partition should be consistently routed, not to which sink they are routed. Therefore, we define error as follows. For each partition in the map, first calculate the most frequent set of sinks in terms of hits (i.e., in terms of DNS queries). Any IP addresses routed to a different set is error. Summing the number of erroneous IP addresses across partitions and dividing by the total IP addresses gives a metric for error in terms of IPs. However, since the volume of hits per IP address is skewed, we also calculate error in terms of traffic by summing the erroneous hits across partitions and dividing by the total hits in the dataset. In the 2019-02-07 dataset, the map error on the training data is 0.15% in IPs and 0.03% in traffic. Our method for dealing with dealing with routing changes adds little error. Next, we perform cross validation to estimate the predictive capability of the map on data not part of the training set. Note that 34% of the IP addresses in the 2019-02-07 dataset only ever sent DNS queries to a single anycast prefix. Thus, we perform cross validation by withholding data for one any-cast prefix at a time, generate a map using the remaining 21 anycast prefixes, and then calculate the error of the map on the withheld data. The resulting errors per left out anycast prefix are shown in
[0065] However, part of the predictive power of an Internet map is the ability to generate it at time t and then use it to anticipate behavior at time t+Δ. We investigate the error in the map over time by using the other datasets in Table 1.
[0066] 3.3 Alternative Methods
[0067] Above, we demonstrate the error present in a map generated using our technique. However, without comparison it is impossible to determine whether the reported error rate is good. As to the best of our knowledge there is no previous work aimed at predicting consistent routing, we compare our method using a one week Δ to two alternative rudimentary methods: (i) partition the Internet by /24 blocks assuming each block is consistently routed and (ii) use the prefixes visible in BGP route tables obtained via Team Cymru [7]. The latter uses the reachability information advertised by other ASNs to split the Internet up accordingly. To compare the methods we must consider both error rate and map size as there is a trivial solution with zero error when the map consists of entirely /32 blocks. Table 2 shows the three methods in order of descending map size. Partitioning the Internet into /24 blocks produces low error but at the cost of a very large map size meaning that it takes more IP addresses (and measurements) to represent the Internet. Prefixes appearing in BGP routing tables creates a smaller map but the error is very large. This should be expected as routing tables contain routes to an IP address whereas our goal is to estimate routing from the IP address. Of the three methods, our map created using anycast prefixes generates the smallest map with the lowest error.
[0068] 3.4 Cross-Domains Use
[0069] Our map is generated from authoritative DNS server logs where the majority of clients can be inferred to be recursive resolvers. Most hosts on the Internet, however, are not recursive resolvers as evidenced by our low IP coverage in Section 2.1, Thus, our map may be specific to recursive resolvers and have less utility for hosts in other domains.
[0070] To explore this notion, we use a dataset of DNS logs from an anycast recursive resolver service where the clients are stub resolvers, likely located in edge networks or home networks. Shown in Table 1 as R2019-02-21, the dataset is much smaller than the other datasets, between 1 and 2 orders of magnitude smaller depending upon metric. Comparing to the 2019-02-14 dataset so that Δ=1 week, we check the overlap between the datasets. As expected, we find that only 6% of IP addresses and 35% of their covering /24 blocks in R2019-02-21 are also in the 2019-02-14 dataset. For comparison, fully 60% of IP addresses and 83% of /24 blocks in the 2019-02-21 dataset are also in the 2019-02-J4 dataset. The computed error on the recursive dataset is 8% in IPs and 3% in traffic, much higher than the 0.13% and 0.04%, respectively, reported in Table 2 for the same value of Δ. Thus, we conclude that the domain of the data used to create the map and the domain in which the map is used should match. For example, the map produced from authoritative DNS logs is appropriate for analyzing the catchments of recursive resolvers; to analyze the catchments of end-users, a map should be generated from end-user anycast traffic.
TABLE-US-00002 TABLE 2 Comparison with alternative mapping methods Method Map Size Error (IPs) Error (Traffic) /24 Blocks 1.55M prefixes 0.77% 0.44% BGP Prefixes 229K prefixes 5.46% 6.70% Anycast Map 212K partitions 0.13% 0.04%
[0071] Section 4.0 Considerations
[0072] Here, we lay out some considerations in generating a map from anycast traffic. Real world implementations should be aware of these details and properly account for them in their use case.
[0073] IP address spoofing can lead to an erroneous map as the IP spoofing misleads as to which catchment an IP address belongs. Of course, this is not unique to our technique and any technique that uses source IP address of Internet traffic, particularly in connectionless protocols, is vulnerable. We are confident that IP spoofing is a sample portion of our datasets, but any use of our technique should discard suspicious traffic (e.g., attacks).
[0074] Multiple anycast prefixes were available to us for our analysis, however multiple anycast prefixes is not inherently necessary to produce a map. It is conceivable to use a single anycast prefix iterated through multiple deployments instead. This may allow use of many more than the 22 anycast deployments in this document which, as noted in Section 3.1, is too few to perfectly reproduce all fault lines. It will not, however, replace the need for distinct physical deployments.
[0075] Section 5.0 Conclusion & Future Work
[0076] In this document, we describe a technique for creating a map of the Internet using existing anycast catchments and show that it is possible to measure the routing of landmarks chosen from the map that are each representative of routing for partitions of IP-space. We present an algorithm for merging the catchments of multiple anycast deployments together creating a map partitions the Internet where each partition is consistently routed, i.e., all IPs in the partition are part of the same catchment regardless of anycast deployment. We show that the resulting map can predict consistent routing with low error even up to 2 weeks after the map was generated. Finally, in comparison to alternative methods, we demonstrate that the map generated from anycast catchments is both smaller and lower error.
[0077] We highlight the following areas for future work. (i) As noted in Section 3.4, the maps created from authoritative DNS server logs perform poorly on anycast traffic from other domains. The effectiveness of our technique in other domains (e.g., anycast content delivery) needs study. (ii) IPv6 is ripe for similar analysis. We study IPv4 only due to dataset limitations. However, our technique is not inherently IP version specific. Further, we posit our methodology will be more beneficial in IPv6 than IPv4 because of the impracticality of scanning the much larger IPv6-space. (iii) Routing changes in the training data pose a problem for our methodology. We propose a technique described in Section 2.2 to deal with routing changes and empirically observe good results using it (see Section 3). However, other solutions producing better results may exist. (iv) We focus on the use of the map for predicting anycast catchments. But knowing the fault lines in IP-space where routing changes is likely beneficial in other measurements as well. Although not explored in this document, we believe our method may be a fruitful in other areas of measurement.
[0078] Use in Content Delivery Networks (CDNs)
[0079] The teachings hereof can be applied (without limitation) to PoPs in a content delivery networks (CDNs). The teachings of the following US patents are hereby incorporated by reference in their entireties: U.S. Pat. Nos. 6,108,703; 7,293,093; 7,096,263; 7,096,266; 7,484,002; 7,523,181; 7,574,499; 7,240,100; 7,725,602; 7,716,367; 7,996,531; 7,925,713; 7,058,706; 7,251,688; 7,274,658; 7,912,978; 8,195,831.
[0080] Computer Based Implementation
[0081] The teachings hereof may be implemented using conventional computer systems, but modified by the teachings hereof, with the components and /or functional characteristics described above realized in special-purpose hardware, general-purpose hardware configured by software stored therein for special purposes, or a combination thereof, as modified by the teachings hereof.
[0082] Software may include one or several discrete programs. Any given function may comprise part of any given module, process, execution thread, or other such programming construct. Generalizing, each function described above may be implemented as computer code, namely, as a set of computer instructions, executable in one or more microprocessors to provide a special purpose machine. The code may be executed using an apparatus—such as a microprocessor in a computer, digital data processing device, or other computing apparatus—as modified by the teachings hereof. In one embodiment, such software may be implemented in a programming language that runs in conjunction with a proxy on a standard Intel hardware platform running an operating system such as Linux. The functionality may be built into the proxy code, or it may be executed as an adjunct to that code.
[0083] While in some cases above a particular order of operations performed by certain embodiments is set forth, it should be understood that such order is exemplary and that they may be performed in a different order, combined, or the like. Moreover, some of the functions may be combined or shared in given instructions, program sequences, code portions, and the like. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic.
[0084]
[0085] Computer system 500 includes a microprocessor 504 coupled to bus 501. In some systems, multiple processors and /or processor cores may be employed. Computer system 500 further includes a main memory 510, such as a random access memory (RAM) or other storage device, coupled to the bus 501 for storing information and instructions to be executed by processor 504. A read only memory (ROM) 508 is coupled to the bus 501 for storing information and instructions for processor 504. A non-volatile storage device 506, such as a magnetic disk, solid state memory (e.g., flash memory), or optical disk, is provided and coupled to bus 501 for storing information and instructions. Other application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or circuitry may be included in the computer system 500 to perform functions described herein.
[0086] A peripheral interface 512 communicatively couples computer system 500 to a user display 514 that displays the output of software executing on the computer system, and an input device 515 (e.g., a keyboard, mouse, trackpad, touchscreen) that communicates user input and instructions to the computer system 500. Note that the computer system 500 may be operated remotely and need not have a local user interface. The peripheral interface 512 may include interface circuitry, control and /or level-shifting logic for local buses such as RS-485, Universal Serial Bus (USB), IEEE 1394, or other communication links.
[0087] Computer system 500 is coupled to a communication interface 516 that provides a link (e.g., at a physical layer, data link layer,) between the system bus 501 and an external communication link. The communication interface 516 provides a network link 518. The communication interface 516 may represent an Ethernet or other network interface card (NIC), a wireless interface, modem, an optical interface, or other kind of input/output interface.
[0088] Network link 518 provides data communication through one or more networks to other devices. Such devices include other computer systems that are part of a local area network (LAN) 526. Furthermore, the network link 518 provides a link, via an internet service provider (ISP) 520, to the Internet 522. In turn, the Internet 522 may provide a link to other computing systems such as a remote server 530 and /or a remote client 531. Network link 518 and such networks may transmit data using packet-switched, circuit-switched, or other data-transmission approaches.
[0089] In operation, the computer system 500 may implement the functionality described herein as a result of the processor executing code. Such code may be read from or stored on a non-transitory computer-readable medium, such as memory 510, ROM 508, or storage device 506. Other forms of non-transitory computer-readable media include disks, tapes, magnetic media, SSD, CD-ROMs, optical media, RAM, PROM, EPROM, and EEPROM, flash memory.
[0090] Any other non-transitory computer-readable medium may be employed. Executing code may also be read from network link 518 (e.g., following storage in an interface buffer, local memory, or other circuitry).
[0091] It should be understood that the foregoing has presented certain embodiments of the invention that should not be construed as limiting. For example, certain language, syntax, and instructions have been presented above for illustrative purposes, and they should not be construed as limiting. It is contemplated that those skilled in the art will recognize other possible implementations in view of this disclosure and in accordance with its scope and spirit. The appended claims define the subject matter for which protection is sought, and are incorporated by reference herein as part of the disclosure of this patent document.
[0092] It is noted that trademarks appearing herein are the property of their respective owners and used for identification and descriptive purposes only, given the nature of the subject matter at issue, and not to imply endorsement or affiliation in any way.
REFERENCES
[0093] [1] Cloudflare 1.1.1.1. Public Recursive Resolver, Retrieved June 2019 from https://1.1.1.1/ [0094] [2] Akamai EdgeScape. Retrieved June 2019 from https://developer.akamai.com/edgescape [0095] [3] CloudFlare. Retrieved June 2019 from https://www.cloudflare.com/ [0096] [4] Google Public DNS. Retrieved June 2019 from https://developers.google.com/speed/public-dns/ [0097] [5] Limelight Networks. Retrieved June 2019 from https://www.limelight.com/ [0098] [6] Quad9. Retrieved June 2019 from https://www.quad9.net/ [0099] [7] Team Cymru—IP to ASN Mapping. Retrieved June 2019 from http://www.team-cymru.com/IP-ASN-mapping.html [0100] [8] Joe Abley and K Lindqvist. 2006. Operation of anycast services. RFC 4786. https://tools.ietf.org/html/rfc4786 [0101] [9] Hitesh Ballani, Paul Francis, and Sylvia Ratnasamy. 2006. A measurement-based deployment proposal for IP anycast. In ACM Internet Measurement Conference. [0102] [10] Tony Bates, Philip Smith, and Geoff Huston. [n. d.]. CIDR Report. ([n. d.]). Retrieved June 2019 from http://www.cidr-report.org/as2.0/ [0103] [11] Matthew Caesar and Jennifer Rexford. 2005. BGP routing policies in ISP networks. IEEE Network 19, 6 (2005), 5-11. [0104] [12] Danilo Cicalese, Jordan Augé, Diana Joumblatt, Timur Friedman, and Dario Rossi. 2015. Characterizing IPv4 anycast adoption and deployment. In ACM Conference on emerging Networking EXperiments and Technologies. [0105] [13] Danilo Cicalese, Diana Joumblatt, Dario Rossi, Marc-Olivier Buob, Jordan Augé, and Timur Friedman. 2015. A fistful of pings: Accurate and lightweight anycast enumeration and geolocation. In IEEE Conference on Computer Communications. [0106] [14] Kimberly Claffy, Young Hyun, Ken Keys, Marina Fomenkov, and Dmitri Krioukov. 2009. Internet mapping: from art to science. In IEEE Cybersecurity Applications & Technology Conference for Homeland Security. [0107] [15] Alberto Dainotti, Karyn Benson, Alistair King, Michael Kallitsis, Eduard Glatz, Xenofontas Dimitropoulos, et al. 2013. Estimating Internet address space usage through passive measurements. ACM SIGCOMM Computer Communication Review 44, 1 (2013), 42-49. [0108] [16] Ricardo de Oliveira Schmidt, John Heidemann, and Jan Harm Kuipers. 2017. Anycast latency: How many sites are enough?. In Passive and Active Measurement Conference. [0109] [17] Wouter B De Vries, Ricardo de O Schmidt, Wes Hardaker, John Heidemann, Pieter-Tjerk de Boer, and Aiko Pras. 2017. Broad and load-aware anycast mapping with verfploeter. In ACM Internet Measurement Conference. [0110] [18] Zakir Durumeric, Eric Wustrow, and J Alex Halderman. 2013. ZMap: Fast Internet-wide scanning and its security applications. In USENIX Security Symposium. [0111] [19] Xun Fan and John Heidemann. 2010. Selecting representative IP ad-dresses for Internet topology studies. In ACM Internet Measurement Conference. [0112] [20] Danilo Giordano, Danilo Cicalese, Alessandro Finamore, Marco Mellia, Maurizio M Munafò, Diana Zeaiter Joumblatt, and Dario Rossi. 2016. A First Characterization of Anycast Traffic from Passive Traces. In Network Traffic Measurement and Analysis Conference. [0113] [21] Ramesh Govindan and Hongsuda Tangmunarunkit. 2000. Heuristics for Internet map discovery. In IEEE International Conference on Computer Communications. [0114] [22] John Heidemann, Yuri Pradkin, Ramesh Govindan, Christos Papadopoulos, Genevieve Bartlett, and Joseph Bannister. 2008. Census and survey of the visible Internet. In ACM Internet Measurement Conference. [0115] [23] James Hiebert, Peter Boothe, Randy Bush, and Lucy Lynch. 2006. Determining the cause and frequency of routing instability with anycast. In Asian Internet Engineering Conference. [0116] [24] Bradley Huffaker, Marina Fomenkov, Daniel J Plummer, David Moore, Kimberly Claffy, et al. 2002. Distance metrics in the Internet. In IEEE International Telecommunications Symposium. [0117] [25] Internet Assigned Numbers Authority. [n. d.]. IPv4 Address Space Registry. ([n. d.]). Retrieved June 2019 from https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml [0118] [26] Yakov Rekhter, Tony Li, and Susan Hares. 2006. A Border Gateway Protocol 4 (BGP-4). RFC 4271. https://tools.ietforg/html/rfc4271 [0119] [27] Kyle Schomp, Tom Callahan, Michael Rabinovich, and Mark Allman. 2014. Assessing DNS Vulnerability to Record Injection. In Passive and Active Measurement Conference. [0120] [28] Neil Spring, Ratul Mahajan, and David Wetherall. 2002. Measuring ISP topologies with Rocketfuel. In ACM SIGCOMM Computer Communication Review, Vol. 32. 133-145. [0121] [29] Lan Wei and John Heidemann. 2017. Does anycast hang up on you? In Network Traffic Measurement and Analysis Conference. [0122] [30] Yang Richard Yang, Haiyong Xie, Hao Wang, Avi Silberschatz, Arvind Krishnamurthy, Yanbin Liu, and Li Erran Li. 2005. On route selection for interdomain traffic engineering. IEEE Network 19, 6 (2005), 20-27. [0123] [31] Sebastian Zander, Lachlan L H Andrew, and Grenville Armitage. 2014. Capturing ghosts: Predicting the used IPv4 space by inferring unobserved addresses. In ACM Internet Measurement Conference. [0124] [32] Sermpezis, P. and Kotronis, V. Inferring Catchment in Internet Routing, Proceedings of the ACM Measurement and Analysis of Computing Systems Vol. 3 Issue 2 (June 2019)