The RIPE Atlas Monitor – Network Monitoring with RIPE Atlas

By on 8 Mar 2016

Category: Tech matters

Tags: , ,

Blog home

A new tool joins the family of applications whose goal it is to take full advantage of RIPE Atlas to monitor availability, consistency and reachability of networks and services: the RIPE Atlas Monitor.


The RIPE Atlas infrastructure provides a privileged observation point from where you can monitor Internet services. The wide geographical distribution of RIPE Atlas probes and the diversity of networks these probes are hosted in allows you to detect how target services are reached. This can be analyzed under circumstances that often can not be reproduced or even imagined by network operators.

Service providers (hopefully) make sure that their services follow a set of key performance indicators or metrics that reflect good user experiences, contractual obligations, or cost savings, or that those services can be reached with no geographical or other constraints and in a consistent manner. The tool that I have developed allows you to monitor and verify that these predefined indicators are matched by taking advantage of the powerful RIPE Atlas network.

How does it work?


  1. At first, we define some source probes and the expected values with regards to the kind of measurement we want to run and the condition we want to monitor. For example:
    1. An RTT threshold that must not be exceeded from a given set of countries
    2. A hostname that must be resolved always and everywhere in a predefined IP address or
    3. An AS path that must be traversed by hosts from a specific source ASN
  2. A RIPE Atlas measurement can then be run to gather results from the previously selected probes.
  3. Finally, the RIPE Atlas Monitor can be configured to process these results and verify that they match the expected values. We can also set optional alerts.

Of course, steps 1 and 2 can be inverted if you prefer to define expected values starting from results obtained by an already running measurement: to help with this job, the RIPE Atlas Monitor offers a measurement analyzer that can build a report based on a further elaboration of the results by aggregating the collected values on the basis of some heuristics that facilitate the identification of common patterns.

Configuration details

Monitors are the core of the program. Each monitor must contain the following things:

  • A set of rules that ties source probes together
  • Expected results
  • Actions in case the results match or don’t match.

Everything is wrapped up into a YAML file. An example is worth more than a thousand words:

descr: Check network reachability
- descr: Probes from France via AS64496
  src_country: FR
  expected_results: ViaAS64496
  actions: EMailToNOC
- descr: RTT from AS64499 and AS64500 below 50ms
  - 64499
  - 64500
  expected_results: LowRTT
  actions: EMailToNOC
    upstream_as: 64496
    rtt: 50
    kind: email
    subject: "ripe-atlas-monitor: unexpected results"
measurement-id: 123456789

The running of these monitors can be scheduled to periodically evaluate measurement results and verify if they match expectations.

Results streaming can also be used to process results in near real time while they are gathered by probes.


At the time of writing the RIPE Atlas Monitor is still in beta and actively developed, but it already supports the following checks (more details can be found in the official documentation):

  • RTT
  • Destination responded
  • Destination IP address
  • Destination ASN
  • Upstream ASN
  • AS path
  • SSL certificates fingerprints
  • DNS responses’ flags
  • EDNS support
  • NSID option
  • DNS answers (records of type A, AAAA, NS, CNAME)

What follows is a brief list of some application scenarios in which the RIPE Atlas Monitor can be used.

Consistency-focused monitoring

With the number of Internet censorship cases increasing, it may be useful to know which country or network applies restrictions on accessing a specific domain name. DNS responses can be matched against expected IP addresses to detect whether lying resolvers are serving answers that have been tampered with:

- descr: Any
  expected_results: RealIPAddress
  actions: Log
        - type: A
    kind: log
measurement-id: 2905528

(The example is based on the work done by Stéphane Bortzmeyer: DNS Censorship (DNS Lies) As Seen By RIPE Atlas.)

Fingerprints of SSL certificates seen by RIPE Atlas probes can also be checked to verify that TLS connections between probes and the target server are not subject to hijacks or man-in-the-middle attacks:

descr: SSL cert
- descr: Any probe
  expected_results: ValidSSLCertificate
  actions: Log
    - 6A:EF:0C:82:1F:B9:8E:13:AA:74:BF:F1:93:E9:C3:84:14:03:88:4D:48:2A:93:AC:BC:94:61:57:BB:4A:80:5C
    kind: log

Network operators

Network operators can already use existing tools to monitor their network’s health and receive alerts using RIPE Atlas, for example, the RIPE NCC Status Checks that can also be integrated with Icinga. The RIPE Atlas Monitor adds features such as traceroute analysis. You can also set different thresholds based on the probes’ properties such as source AS, source country, probe ID.

Traceroutes can be used, for example, to monitor direct peers from where traffic is expected either via a private interconnect or via an Internet Exchange Point:

- descr: AS64496 Private Interconnect
  - 64499
  - 64500
  expected_results: Direct
- descr: AS64496 IXP peerers
  - 64501
  - 64502
  expected_results: IXP
    as_path: S 64496
    as_path: S IX 64496

In the above example, the “S” and “IX” macros are expanded during rules processing and are used to represent the probe’s source AS and any Internet Exchange peering network respectively (info fetched from the PeeringDB 2.0 API).

For example, a measurement can be used to verify if the GeoDNS mapping of a CDN works as expected and to spot any anomalies:

descr: Traceroute to
measurement-id: 1983448
- descr: Any probe
  expected_results: DestinationResponded
  actions: AddLabel-DstResponded
  process_next: True
- descr: EU probes which received a response from target
  internal_labels: DstResponded
  - "AD"
  - "AL"
  - "AT"
  - ...
  - esams
  - ValidASPaths
  - Log
- descr: CA and US probes which received a response from target
  internal_labels: DstResponded
  - "CA"
  - "US"
  - ulsfo_or_eqiad
  - ValidASPaths
  - Log
    dst_responded: True
    descr: esams
    dst_as: 43821
    descr: ulsfo or eqiad
    dst_as: 14907
    - "13030 43821"
    - "1200 43821"
    - "1299 43821"
    - "1299 14907"
    - "2914 14907"
   - ...
      when: on_match
      kind: label
      op: add
      label_name: DstResponded
      kind: syslog

(The example is based on the work done by RIPE NCC staff and engineers from the Wikimedia Foundation: How RIPE Atlas Helped Wikipedia Users.)

Here, labels are used to mark those RIPE Atlas probes that received a response from the target in order to subsequently use them for further analysis.

Integration with RIPE Atlas CLI toolset (Magellan)

Among the actions that can be taken after the results have been processed, there is one that allows you to run an external program. It is particularly suited to integrate with another great tool, Magellan, the RIPE Atlas command line interface toolset:

    descr: Create new traceroute msm from the probe which missed expectations
    kind: run
    path: ripe-atlas
    - measure
    - traceroute
    - --target
    - --no-report
    - --from-probes
    - $ProbeID

In the above example, the RIPE Atlas tool is executed to create a new one-off traceroute measurement from the probe (the $ProbeID macro) where the reported result was not within the expected values (an API key is needed for this).

More details

The RIPE Atlas Monitor is an open source project and is available on GitHub. Check out the full documentation for more information. At the time of writing the program is still in beta version: contributions and suggestions from the community are very welcome.

This story originally appeared on RIPE Labs

Pier Carlo Chiodi is a system and network administrator based in Italy, whose area’s of interest include: IPv4 exhaustion and IPv6 transition mechanisms, infrastructure security, Internet measurement and network data analysis.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *