Pier Carlo Chiodi

The RIPE Atlas Monitor - Network Monitoring with RIPE Atlas

Pier Carlo Chiodi

10 min read

0 You have liked this article 0 times.
1

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.


Introduction

The RIPE Atlas infrastructure provides a privileged observation point where you can monitor Internet services from . 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 analysed 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?

Overview

  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
 
matching_rules:
- descr: Probes from France via AS64496
  src_country: FR
  expected_results: ViaAS64496
  actions: EMailToNOC
- descr: RTT from AS64499 and AS64500 below 50ms
  src_as:
  - 64499
  - 64500
  expected_results: LowRTT
  actions: EMailToNOC
expected_results:
  ViaAS64496:
    upstream_as: 64496
  LowRTT:
    rtt: 50
actions:
  EMailToNOC:
    kind: email
    to_addr:  noc@example.org
    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.

Applications

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 on 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: www.etha.com.tr
 
matching_rules:
- descr: Any
  expected_results: RealIPAddress
  actions: Log
expected_results:
  RealIPAddress:
    dns_answers:
      answers:
        - type: A
          address: 176.9.34.7
actions:
  Log:
    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: www.ripe.net SSL cert
  
matching_rules:
- descr: Any probe
  expected_results: ValidSSLCertificate
  actions: Log
expected_results:
  ValidSSLCertificate:
    cert_fp:
    - 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
actions:
  Log:
    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:

 matching_rules:
 
- descr: AS64496 Private Interconnect
  src_as:
  - 64499
  - 64500
  expected_results: Direct
- descr: AS64496 IXP peerers
  src_as:
  - 64501
  - 64502
  expected_results: IXP
expected_results:
  Direct:
    as_path: S 64496
  IXP:
    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 wikipedia.org
 
measurement-id: 1983448
matching_rules:
- descr: Any probe
  expected_results: DestinationResponded
  actions: AddLabel-DstResponded
  process_next: True
- descr: EU probes which received a response from target
  internal_labels: DstResponded
  src_country:
  - "AD"
  - "AL"
  - "AT"
  - ...
  expected_results:
  - esams
  - ValidASPaths
  actions:
  - Log
- descr: CA and US probes which received a response from target
  internal_labels: DstResponded
  src_country:
  - "CA"
  - "US"
  expected_results:
  - ulsfo_or_eqiad
  - ValidASPaths
  actions:
  - Log
expected_results:
  DestinationResponded:
    dst_responded: True
  esams:
    descr: esams
    dst_ip:
    -  91.198.174.0/24
    -  185.15.56.0/22
    dst_as: 43821
  ulsfo_or_eqiad:
    descr: ulsfo or eqiad
    dst_ip:
    -  208.80.152.0/22
    -  198.35.26.0/23
    -  198.73.209.0/24
    dst_as: 14907
  ValidASPaths:
    as_path:
    - "13030 43821"
    - "1200 43821"
    - "1299 43821"
    - "1299 14907"
    - "2914 14907"
  - ...
actions:
    AddLabel-DstResponded:
      when: on_match
      kind: label
      op: add
      label_name: DstResponded
    Log:
      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:

  actions:
  
  RunRIPEAtlasTraceroute:
    descr: Create new traceroute msm from the probe which missed expectations
    kind: run
    path: ripe-atlas
    args:
    - measure
    - traceroute
    - --target
    -  www.example.com
    - --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.

0 You have liked this article 0 times.
1

You may also like

View more

About the author

Pier Carlo Chiodi Based in Italy

System and network administrator, I started working in the IT/ICT during the late '90s. Area of interest: IPv4 exhaustion and IPv6 transition mechanisms, Internet measurement and network data analysis, infrastructure security.

Comments 1