BGPScout is assembled from public measurement projects, registry data and operator-contributed datasets. This page names every one of them and reproduces the attribution their licences require.
This Product utilizes data provided by RouteViews (www.routeviews.org). Use of this data is subject to the CC BY 4.0 license.
With contributions from network operators and volunteers all over the world, RouteViews collects BGP data by direct peering at Internet Exchange Points (IXPs) or multi-hop peering. Data are archived and made publicly available for download at archive.routeviews.org, lg.routeviews.org, and api.routeviews.org.
How BGPScout uses it: RouteViews MRT route collector dumps are parsed for the global routing table - the prefixes each ASN advertises, and the AS adjacencies observed in AS_PATHs. The vantage points are chosen for geographic and topological spread rather than raw count, because a network that peers regionally is disproportionately visible from a nearby one and invisible from a distant one.
RouteViews vantage points in the build that produced the data now being served (2026-09-14): route-views.chicago, route-views.eqix, route-views.linx, route-views.napafrica, route-views.sydney, route-views.wide, route-views2, route-views2.saopaulo.
What more vantage points do NOT do is turn the result into a peer census. A RIB dump carries only the best path per prefix per collector peer, so an adjacency that is never the best path anywhere - the normal case for settlement-free peering across an exchange route server - is absent from every collector, at any collector count.
The RIPE Routing Information Service (RIS) is a RIPE NCC service. With the help of network operators all over the world, RIS employs a globally distributed set of Remote Route Collectors (RRCs), typically located at Internet Exchange Points, to collect and store Internet routing data. Volunteers peer with the RRCs using the BGP protocol and RIS stores the update and withdraw messages. RIS data can be accessed via:
How BGPScout uses it: RIS route collector data contributes to the global routing table BGPScout reports on, alongside RouteViews. RIS collectors are in the AS-adjacency build to add vantage points RouteViews' own set does not have, particularly outside North America and Europe.
RIPE RIS vantage points in the build that produced the data now being served (2026-09-14): rrc00, rrc11, rrc19, rrc24.
What this is not: Neither RouteViews nor RIS labels a relationship. An AS_PATH records that two ASNs were adjacent along an observed route, which conflates transit, settlement-free peering, siblings and misconfigurations - it is not a peering agreement or a customer list, from us or from any other tool built on the same public data.
How BGPScout uses it: Traceroute measurements run from RIPE Atlas probes, and the published daily probe metadata archive, which supplies the source country of an Atlas-originated trace. Probe country codes are self-declared by the probe host and are not verified by the RIPE NCC.
The CAIDA UCSD PeeringDB Dataset, 2018-03-11 - 2026-07-01, https://www.caida.org/catalog/datasets/peeringdb/
How BGPScout uses it: CAIDA's archive of historical PeeringDB snapshots supplies the interconnection history that PeeringDB's own API cannot - which networks were present at which exchanges and facilities on a given date. The attribution above is required by CAIDA's Acceptable Use Agreement and the date range names exactly the snapshots loaded.
Free IP geolocation data provided by MaxMind, creator of GeoIP®.
This product includes GeoLite Data created by MaxMind, available from https://www.maxmind.com.
How BGPScout uses it: IP-to-location lookups for traceroute hops and announced address space. Geolocation is an estimate, never a measurement of where equipment physically is.
How BGPScout uses it: Interconnection data - exchange and facility membership, port capacity, network contact and traffic-level fields. All of it is operator self-reported; BGPScout presents it as such and does not treat it as measured.
bgp.tools
How BGPScout uses it: ASN names and the network-category tags (CDN, DDoS mitigation, anycast, RPKI-validating, hosting and others) shown on ASN pages and in search filters.
How BGPScout uses it: The record of which networks host CDN caches - Google GGC, Netflix OCA, Meta FNA, Akamai, Microsoft, Apple and AWS CloudFront - shown on ASN pages, on /cdns and in CDN search filters. His methodology identifies cache nodes by the TLS certificate common name presented on port 443.
Published as a research dataset with no stated licence. We are grateful for it, we have not modified the underlying observations, and we will remove or amend this on request.
How BGPScout uses it: Published delegated-extended statistics, transfer logs, RDAP and WHOIS - the allocation and transfer record for every ASN and IP block, and organisation names and addresses where a registry publishes them.
How BGPScout uses it: LACNIC publishes no organisation address for Brazilian networks. Nic.br's published ASN block file supplies the CNPJ company identifier, which is resolved against the Receita Federal business registry for a registered address. That is a company's fiscal address, which for a large operator may be a head office far from the network, and it is labelled as such wherever it is shown.
EMODnet Human Activities, Telecommunication and power cables, Actual Routes. Aggregated by Cogea for the European Commission (European Marine Observation and Data Network). Data originator: Cogea Srl.
EMODnet Human Activities is funded by the European Commission and brings marine data on human activity in EU waters into a single portal. The cables dataset aggregates surveyed routes published by national hydrographic offices - among them SHOM (France), BSH (Germany) and Rijkswaterstaat (Netherlands) - and is updated annually. Validation of each contribution remains with the originating office.
How BGPScout uses it: Surveyed submarine cable routes are drawn as a context layer beneath the observed city-to-city links on the traceroute maps. It is context, not a claim about our measurements: we observe traffic between two cities and never observe which cable carried it, so no link is attributed to a cable. Coverage is European waters only (with some French-territory routes further afield, via SHOM's remit), so a sea with no cable drawn on it is outside the dataset rather than empty. A small number of trans-oceanic links are additionally routed along a plausible cable's own surveyed path, where one lands close to both observed cities - checked against 4,418 trans-oceanic city pairs, this matched 33 (2026-08-22). Those links are drawn dashed and labelled illustrative wherever it is ambiguous between several cables; every other link keeps the plain great-circle path. See the map's own legend for detail - City-to-City Path Segments.
If you represent one of the projects above and this page does not meet your attribution requirements, tell us and we will fix it: [email protected]. Attribution is an obligation we would rather over-satisfy than get wrong.