A successful test from your laptop confirms one source network at one moment. It does not tell you whether users on another access network can reach your prefix, or whether IPv6 follows a different path.
RIPE Atlas provides outside vantage points for that investigation. Use it to answer a narrow question, such as “can probes in these customer networks reach my new service address over IPv6?” The value comes from choosing the sources and preserving the test conditions, not from collecting the largest possible map of dots.
Define the test before selecting probes
Start with one destination you control and one question. Keep the original IP address when comparing routing before and after a change. A hostname that resolves differently can quietly turn the comparison into a test of two different endpoints.
| Question | Starting measurement | What else you need |
|---|---|---|
| Does the address reply? | Ping | An application check if ICMP is filtered |
| Where does the visible path change? | Traceroute | End-to-end results and the reverse-path context |
| Does this nameserver answer correctly? | DNS to its address | Expected records and response flags |
| Which anycast node answered? | DNS with a node identifier, if supported | A documented mapping from identifiers to nodes |
An outside measurement complements the BGP troubleshooting sequence. It cannot tell you which local export filter rejected a route, or prove that a remote router accepted it into BGP.
Start small and check the credit estimate
Sign in to RIPE Atlas and open the measurement-creation form. Choose the measurement type, target, and address family; select probes; then choose a one-off run. Review the displayed cost before submitting. The user-defined measurement guide documents that workflow.
Use a handful of probes for the first run. Expand only once the target and settings are correct. Credits and account quotas constrain measurements; check the account's credit page rather than assuming a long-running test is free. The credit guide explains ways to obtain credits, including probe hosting and eligible account grants.
For recurring monitoring, specify an end time and check the projected spend. More frequent samples are useful only if you will inspect or alert on them.
Select networks that represent your users
Start with the countries and access ASNs that matter to the service, then add a few independent comparison networks. Several probes in one ASN are not equivalent to several independent routing perspectives.
Keep a small working set such as:
| Group | Why include it? |
|---|---|
| Affected access network | Reproduce the reported problem |
| Another access network in the same country | Separate geography from operator policy |
| A distant network | Check whether the fault is broader |
| A previously working probe | Compare against a known baseline |
Reuse the same probe set after a routing change. Check which probes actually returned results; an unavailable probe is missing evidence, not automatically a failed destination. Keep IPv4 and IPv6 results separate, and note when the available probe sets differ.
Avoid selecting only sources close to the VPS. The purpose is to test the networks sending traffic to it.
Compare reachability before interpreting hops
Run an IPv4 ping to the service address, then a separate IPv6 measurement to its IPv6 address. Record the measurement IDs, target addresses, probe IDs, and UTC window.
If a subset fails, run traceroutes from those sources and from a working comparison source. Keep the protocol and settings consistent across before-and-after tests.
A silent intermediate hop is not enough to identify a forwarding fault. Routers can limit responses to probes while continuing to carry traffic. Look for loss or delay that persists to the destination and agrees with an application symptom. A path is directional, so it does not establish the route your reply takes. The latency and packet-loss guide covers those interpretation traps.
Atlas also has TLS measurements, but it is not a general replacement for HTTP application monitoring. HTTP measurements have restricted availability, as described in the measurement guide. Keep a separate check for your application's response and dependencies.
Test authoritative DNS deliberately
For a direct authoritative test, the DNS measurement's target is the nameserver's address, while its query argument is the name you want answered. Choose the query type and disable recursion desired for that direct test. Testing the probe's local resolver answers a different question. These fields are explained in the DNS measurement options.
For the two-location DNS setup, create a measurement for each nameserver. Ask for the zone's SOA and compare the serial, response code, and authoritative flag. Repeat over TCP as well as UDP when investigating transport-specific failures.
For anycast DNS, an optional NSID response can help identify the answering node if the service is configured to supply one. Document those identifiers in advance. Do not infer a server location from latency alone.
Save results you can compare later
Keep the result export alongside your change notes. For a public measurement, the latest-results endpoint is convenient for a quick snapshot:
ATLAS_MSM_ID='YOUR_MEASUREMENT_ID'
curl --fail --silent --show-error \
"https://atlas.ripe.net/api/v2/measurements/${ATLAS_MSM_ID}/latest/" \
--output atlas-latest.json
Replace the placeholder with the measurement ID from your run. A latest-results snapshot can contain different timestamps for different probes. For a bounded before-and-after window, use the results endpoint with explicit start and stop timestamps instead. See the Atlas measurements API.
Preserve the original JSON. Result formats depend on probe firmware, so downstream scripts should handle missing values and errors rather than treating every entry as a successful response. RIPE publishes the result-format reference.
Turn observations into a useful routing report
A report should let another operator repeat your comparison. Include:
- The exact target address, address family, and test protocol.
- Measurement IDs, probe IDs, source ASNs, and UTC timestamps.
- A working source and a failing source, with the same measurement settings.
- The observed application symptom, alongside ping or traceroute results.
- What changed, when it changed, and whether rollback restored the result.
Describe the scope honestly: “these probes failed during this window” is supported by the evidence. “The prefix is unreachable everywhere” usually is not.
For anycast changes, repeat from the same sources after a withdrawal and check which node responds. A restored ping does not establish that a stateful application session survived the path change. Keep the network result and the application result as separate observations.