You know when in the morning you wake up and a thought flashes across your mind? One of these mornings I had this: how many RIPE Atlas probes are on a NAT64/DNS64 scenario? RFC7050 can help to answer this question.
A post I wrote for RIPE Labs has been published today: The RIPE Atlas Monitor – Network Monitoring with RIPE Atlas.
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: firstname.lastname@example.org subject: "ripe-atlas-monitor: unexpected results" measurement-id: 123456789
Contributions and suggestions from the community are very welcome!
I released a new version of my web application RIPE Atlas Tracepath: v0.3.0. It reads results from RIPE Atlas traceroute measurements and shows Autonomous Systems that probes go through to reach the target.
UPDATE: new versions have been released since this post, with new features and bug fixes: please take a look at the project’s page on GitHub.
In the beginning it was a simple Python script/CGI; the new release has been totally rewritten, it’s now based on the D3.js visualization library and uses a more elegant Python backend based on Flask/WSGI.
Among the new features, probes are also displayed and linked to their origin AS; for those that completed the traceroute toward the target the avg RTT is also rendered in form of a scale of colors. Multiple Autonomous Systems can now be selected and moved together on the graph, in order to obtain the layout that best describes the analyzed scenario.
A demo can be found here. It only shows results from measurement ID 1674977, a traceroute from 50 probes all over the world toward www.ripe.net:
More details can be found on the GitHub page; feel free to use/edit/fork/improve it as you whish!
A couple of days ago CloudFlare announced its public alpha release of their DNSSEC implementation. Since they are using the “recent” Elliptic Curve ECDSA P-256 (RFC6605) I wondered how many resolvers can have problems with signatures validation so I wanted to take a peek at the current situation as seen by the RIPE Atlas probes network.
Yesterday RIPE Labs announced a new test to measure propagation of longer than /24 IPv4 prefixes. The scope of these prefixes is to allow small allocations from the 23.128/10 net block that ARIN reserved to facilitate IPv6 deployment, but it could be impaired by filters and routing policies commonly deployed all around the net.
While looking forward to the RIPE results I couldn’t help glancing at the current situation as seen by a bunch of RIPE Atlas probes, so I performed some small tests on my own.