Internet Measurement: RIPE Atlas, Looking Glasses, and BGP Collectors

The internet has no central control point, no global dashboard showing its health, and no single organization responsible for monitoring it. Yet researchers, network operators, and security analysts constantly measure the internet's behavior: tracking routing changes, detecting outages, measuring latency from thousands of vantage points, and analyzing BGP stability. This guide explains the key tools and infrastructure used for internet measurement.

Why Internet Measurement Matters

Internet measurement serves several critical purposes:

• Outage detection — Identifying when a network or country is unreachable, including politically motivated shutdowns
• Performance benchmarking — Measuring latency, packet loss, and throughput across different network paths
• Routing analysis — Tracking BGP route announcements and withdrawals that affect how traffic flows
• Security research — Identifying route hijacks, BGP leaks, and other routing anomalies
• Protocol research — Measuring real-world deployment of new technologies (IPv6 adoption, DNSSEC signing, TLS versions)

RIPE Atlas: The World's Largest Measurement Network

RIPE Atlas is a distributed network of hardware probes deployed in homes, offices, and data centers around the world. Run by the RIPE NCC (the Regional Internet Registry for Europe and the Middle East), RIPE Atlas is a global public good — anyone can run measurements, and the data is publicly available.

The Hardware Probes

RIPE Atlas probes are small hardware devices — roughly the size of a USB drive or small router — that connect to a host's network. As of 2024, there are approximately 12,000 active probes in over 3,600 distinct networks (autonomous systems) across 190+ countries.

The probes continuously measure: - Ping — Round-trip time to fixed anchor targets - Traceroute — Path discovery and per-hop latency - DNS — Resolution time and correctness for root servers and other targets - SSL/TLS — Certificate validity and connection parameters - NTP — Time synchronization quality

Probes report results to RIPE Atlas infrastructure, which aggregates and makes data available via API and the RIPE Atlas web interface.

Running Measurements

Researchers and network operators can run custom measurements against any target on the internet. Measurements cost credits — RIPE Atlas uses a credit system where hosting a probe earns credits, which can be spent on custom measurements.

# RIPE Atlas measurements can be scheduled via API
# Example: Schedule a traceroute from 50 probes in the US to 8.8.8.8
curl -H "Authorization: Key <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "definitions": [{
      "target": "8.8.8.8",
      "type": "traceroute",
      "protocol": "TCP",
      "port": 80
    }],
    "probes": [{
      "type": "country",
      "value": "US",
      "requested": 50
    }],
    "one_off": true
  }' \
  https://atlas.ripe.net/api/v2/measurements/

The result is a measurement ID. You can retrieve results via the API or view them on the RIPE Atlas website.

RIPE Atlas Anchors

Beyond the small consumer probes, RIPE Atlas maintains approximately 900 anchors — more powerful, rack-mounted devices in Internet Exchange Points and data centers. Anchors serve as both probes and targets. Every probe runs regular measurements to the 20-30 nearest anchors, creating a dense mesh of latency measurements. This data is used to detect routing anomalies and network events.

Real-World Use Cases

Internet shutdown detection: When a government disconnects a country's internet, RIPE Atlas probes in that country stop responding. The IODA project (Internet Outage Detection and Analysis) and RIPE Atlas data are used by researchers and journalists to document internet shutdowns.

BGP route change impact: When a major ISP changes routing, the effect propagates across the internet and changes latency and path characteristics. RIPE Atlas traceroute data shows the before/after state from thousands of vantage points.

DNS anycast instance mapping: Researchers use RIPE Atlas traceroutes to map which DNS root server anycast instance responds to probes in different locations, revealing the geographic distribution of root server instances.

BGP Collectors: Watching the Routing Table

While RIPE Atlas measures data-plane behavior (actual packet forwarding), BGP collectors observe the control plane — the routing announcements that determine how traffic flows.

How BGP Collectors Work

A BGP collector is a server that peers with networks via BGP but does not forward traffic. It simply listens and records all BGP updates: new route announcements (ANNOUNCE), route withdrawals (WITHDRAW), and attribute changes. The collector stores this data in a format called MRT (Multi-Threaded Routing Toolkit), which can be replayed and analyzed.

By peering with many different networks, a BGP collector builds a picture of the global routing table as seen from multiple vantage points.

RIPE RIS (Routing Information Service)

The RIPE NCC operates the Routing Information Service (RIS), which deploys BGP collectors at Internet Exchange Points and co-location facilities around the world. RIS collectors peer with hundreds of networks at each IXP.

Data is available: - Live streams via the RIS Live WebSocket API - Historical dumps via the RIPE NCC FTP server (MRT format) - BGPlay — A web interface for visualizing routing history for any prefix

# Access live BGP data via RIS Live
# Use a WebSocket client to receive real-time BGP updates
wscat -c "wss://ris-live.ripe.net/v1/ws/?client=my-app"

# Subscribe to updates for a specific prefix
echo '{"type": "ris_subscribe", "data": {"type": "UPDATE", "prefix": "1.1.1.0/24"}}' | wscat -c "wss://ris-live.ripe.net/v1/ws/?client=test"

RouteViews

The University of Oregon Route Views Project operates a parallel BGP collection infrastructure. Route Views maintains collector servers at major IXPs worldwide and provides MRT dumps for research. The Route Views archive extends back to 1997, making it one of the longest historical BGP datasets available.

Accessing Route Views data:

# Download a recent BGP full-table dump
wget http://archive.routeviews.org/bgpdata/2024.01/RIBS/rib.20240101.0000.bz2

# Parse with bgpdump
bgpdump -m rib.20240101.0000.bz2 | head -20

# Or use the PyBGPStream library
pip install pybgpstream

BGP Anomaly Detection

BGP collector data is used to detect routing incidents:

Route hijacks: A malicious or misconfigured AS announces a prefix it does not legitimately own. The announcement appears in BGP collector data as an unexpected origin AS for a well-known prefix. For example, in 2018, an ISP in Nigeria announced Amazon's route 63.1.0.0/24, briefly hijacking traffic.

BGP leaks: A network accidentally re-announces routes it learned from one peer to another peer, violating routing policies. A famous example: in 2019, a small ISP in Pennsylvania accidentally leaked routes through Verizon, causing widespread internet disruption.

Prefix deaggregation: A network that normally announces a /20 starts announcing individual /24s, which may indicate a DDoS mitigation response or a network misconfiguration.

Tools like BGPMon, Kentik, and Radar from Cloudflare provide automated alerts when routing anomalies are detected.

Looking Glass Servers

A looking glass is a web interface or command-line tool that lets you run routing commands (traceroute, ping, BGP show commands) from inside a network operator's infrastructure. Looking glasses allow you to see the internet from a vantage point inside a specific network — useful for debugging routing issues and understanding how traffic flows.

What Looking Glasses Show

From a carrier's looking glass, you can run:

show ip bgp 8.8.8.8
# → Shows the BGP path that carrier uses to reach 8.8.8.8
# → Reveals AS path, next hop, local preference, MED

traceroute 8.8.8.8
# → Shows the packet path from inside the carrier's network
# → Reveals inter-carrier handoffs and latency at each hop

ping 8.8.8.8
# → Tests reachability and round-trip time from the carrier's perspective

Finding Looking Glasses

Looking glasses are operated by individual ISPs and are scattered across the internet. Aggregator sites maintain directories:

• lg.he.net — Hurricane Electric's looking glass (excellent global coverage)
• lg.cogentco.com — Cogent backbone looking glass
• lookinglass.org — Directory of looking glasses by country and AS
• bgp.he.net — Hurricane Electric's BGP toolkit (combines BGP info, prefix lookup, and looking glass)

Practical Debugging with Looking Glasses

Scenario: Your users in Germany are reporting slow access to your website hosted in us-east-1. You suspect a suboptimal routing path.

1. Look up your server's IP on bgp.he.net to find your AS number and prefix.
2. Use a German-based looking glass (e.g., Deutsche Telekom's looking glass) to run show bgp <your-prefix>.
3. Review the AS path. If traffic from Germany is routing through New York before reaching your Virginia data center (i.e., going east to west to east), there may be a missing direct peering relationship.
4. Contact your hosting provider or CDN to see if they peer with major German networks.

Traceroute and Its Limitations

Traceroute is the most commonly used network measurement tool — available on every operating system — but understanding its limitations is essential for interpreting results correctly.

Traceroute works by sending packets with incrementally increasing TTL (Time To Live) values. Each router that receives a packet decrements the TTL by 1. When TTL reaches 0, the router discards the packet and sends back an ICMP "Time Exceeded" message. Traceroute records the source IP of each ICMP message and the round-trip time.

Common Misinterpretations

High latency at a single hop does not indicate congestion. Routers often apply rate limiting to ICMP responses. If a router is configured to respond to only 100 ICMP messages per second, your traceroute probe may sit in a queue and show high latency — but transit traffic is flowing through that router at full speed.

Asymmetric routing. The path your probe takes outbound may be completely different from the path return traffic takes. Latency measurements in traceroute reflect the outbound path plus the return path — they do not isolate per-hop one-way latency.

* * * does not mean packet loss. Some routers simply do not respond to ICMP TTL-exceeded messages at all. Traffic is still forwarding through the router; it just doesn't generate the ICMP response.

Better Traceroute Tools

# mtr: combines traceroute and ping, shows statistics over time
mtr -n 8.8.8.8

# TCP traceroute: bypasses firewalls that block UDP/ICMP
traceroute -T -p 80 google.com

# Paris traceroute: avoids per-flow ECMP inconsistency
paris-traceroute google.com

IODA and Outage Detection

The Internet Outage Detection and Analysis (IODA) project at Georgia Tech and CAIDA combines multiple data sources to detect internet outages at country and AS level:

• BGP: Monitoring for sudden withdrawal of routes from a country or AS
• Active probing: Continuous ping to a large list of IP addresses
• Internet traffic telescope: Monitoring background radiation traffic (unsolicited packets) — when a region goes offline, these packets stop arriving

IODA provides a real-time dashboard at ioda.live showing detected outages globally. This data has been used to document internet shutdowns in Iran, Russia, Myanmar, and dozens of other countries.

The combination of passive BGP monitoring, active probing from distributed networks like RIPE Atlas, and traffic telescopes gives researchers a comprehensive picture of internet health — without requiring access to any single carrier's internal systems.