- mat-wg - mailman.ripe.net

New on RIPE Labs: Adding Interactivity to Embedded RIPEstat Widgets
by Mirjam Kuehne 01 Jun '12

01 Jun '12

Dear colleagues, It's been possible to embed RIPEstat widgets for some time. You can now also include a resource bar so that your site's visitors can query resources via RIPEstat on your website. Please find more information on RIPE Labs: https://labs.ripe.net/Members/becha/adding-interactivity-to-embeded-ripesta… Kind regards, Mirjam Kuehne RIPE NCC

1 0

new on RIPE Labs: RIPEstat DNS Widget for World IPv6 Launch
by Mirjam Kuehne 25 May '12

25 May '12

Dear colleagues, RIPEstat has a new DNS widget for World IPv6 Launch. The widget can be included in any website where you'd like viewers to be able to perform IPv6 (and IPv4) DNS lookups or view your site's DNS details. Please find more details on RIPE Labs: https://labs.ripe.net/Members/becha/ripestat-dns-widget-for-world-ipv6-laun… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New CIDR navigation in RIPEstat Address Space Hierarchy widget
by Mirjam Kuehne 23 May '12

23 May '12

Hello, Please find the new RIPEstat CIDR navigation feature in the Address Space Hierarchy widget. It is now documented on RIPE Labs: https://labs.ripe.net/Members/becha/ripestat-address-space-hierarchy-widget… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Ripe Probes and Android
by Stefan Wahl 16 May '12

16 May '12

Hi, as promised in Ripe64, I want to introduce Ingo Albrecht. He is the person, who is in charge and the owner of the project "Android and Atlas Probes". He sent me a paper called "inital-concept", which I would like to copy to the mailing-list. I hope that we will get a lot of feedback and make progress in defining and funding the project. greetings from Berlin Stefan Wahl Ingo Albrecht: GENERAL CONCEPT The client should implement a proper subset of the features present in the web interface, limiting itself to the most common and most operationally useful features. As such, emphasis should be given to "general" information that has use in network operations, as opposed to "specific" detailed information. Display should concentrate on displaying "current" information as opposed to browsing history, for which a laptop is much better suited. As an example, consider display of per-probe data. The client should display basic probe information and current/recent measurement results, not a whole set of graphs. Also, emphasis should be given to search as opposed to full-list browsing, facilitating ad-hoc use. DEVELOPMENT PROCESS Development would progress in monthly stages, accompanied by public release from the second stage on. The feature set specified in this document should be achievable within 3 to 5 such stages. This concept would be revised during each stage, allowing for integration of feedback. As the developer, I propose that the source code for the project, including history, be published via github or similar. FEATURES Base features: * Display of announcements * Display of "My Probes" list * Display as list * Display map of own probes * Search for probes by AS, IP4/IP6 prefix, country * Result display as list * Result display as map * Notification when a users own probes go down or stay down * Configurable "acceptable downtime" * Configurable "silent times" based on phone timezone * Probe view (reachable from probe lists and maps) * Display standing data * Display most recent measurements Basic browsing features: * View standard measurements (equivalent of "Maps" view) * Fixed destination measurements (reachability and RTT) * Limitable by probe AS and prefix * Limitable by destination * DNS measurements (instance choice and RTT) * Limitable by probe AS and prefix * Limitable by root instance continent * Limitable by specific root instance UDM features: * Display of configured UDMs * Adding/removing UDMs * Display of most recent UDM results * Possibly with history * Maybe with graphs Features not considered: Display of coverage information (not terribly useful ad-hoc).

7 6

New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas
by Mirjam Kuehne 09 May '12

09 May '12

[apologies for duplicate mails] Dear colleagues, You can now use RIPE Atlas to test your IPv6 reachability. This also works if you do not host a RIPE Atlas probe yourself. However, please note that this is only available to RIPE NCC members. Please find the details on RIPE Labs: https://labs.ripe.net/Members/becha/test-your-ipv6-reachability-using-ripe-… If you have any comments or questions, please let us know. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Introducing the Android Atlas Client and myself
by Ingo Albrecht 02 May '12

02 May '12

Hello! Just as Stefan Wahl wrote, I am the guy who initially came forward with the idea of implementing an Android client for the RIPE Atlas. My professional background is as a programmer of various media systems with a lot of experience in mobile applications, high-profile showroom and media installations as well as related topics. Beyond that, being a jack of many trades, I also have experience in network operations and service hosting, both professionally and in various voluntary contexts such as open source projects. Having heard of RIPE Atlas and knowing a lot of people from the network community, I decided to step forward and offer to implement an Android application that allows proper mobile use of the Atlas. Stefan Wahl of ECIX was so kind as to announce my project at RIPE64. I am now hoping to collect further feedback. For further discussion, I have pasted my initial draft concept below. Feel free to comment, propose features and discuss. If you wish, you can also contact me directly about this project. Greetings Ingo ========================================================================= RIPE Atlas Android Client - Concept Proposal (C) 2012 Ingo Albrecht <prom(a)berlin.ccc.de> Revision 2012-04-16 21:00 CEST GENERAL CONCEPT The client should implement a proper subset of the features present in the web interface, limiting itself to the most common and most operationally useful features. As such, emphasis should be given to "general" information that has use in network operations, as opposed to "specific" detailed information. Display should concentrate on displaying "current" information as opposed to browsing history, for which a laptop is much better suited. As an example, consider display of per-probe data. The client should display basic probe information and current/recent measurement results, not a whole set of graphs. Also, emphasis should be given to search as opposed to full-list browsing, facilitating ad-hoc use. DEVELOPMENT PROCESS Development would progress in monthly stages, accompanied by public release from the second stage on. The feature set specified in this document should be achievable within 3 to 5 such stages. This concept would be revised during each stage, allowing for integration of feedback. As the developer, I propose that the source code for the project, including history, be published via github or similar. FEATURES Base features: * Display of announcements * Display of "My Probes" list * Display as list * Display map of own probes * Search for probes by AS, IP4/IP6 prefix, country * Result display as list * Result display as map * Notification when a users own probes go down or stay down * Configurable "acceptable downtime" * Configurable "silent times" based on phone timezone * Probe view (reachable from probe lists and maps) * Display standing data * Display most recent measurements Basic browsing features: * View standard measurements (equivalent of "Maps" view) * Fixed destination measurements (reachability and RTT) * Limitable by probe AS and prefix * Limitable by destination * DNS measurements (instance choice and RTT) * Limitable by probe AS and prefix * Limitable by root instance continent * Limitable by specific root instance UDM features: * Display of configured UDMs * Adding/removing UDMs * Display of most recent UDM results * Possibly with history * Maybe with graphs Features not considered: Display of coverage information (not terribly useful ad-hoc).

1 0

RIPE Atlas JSON traceroutes
by Paul Hoogsteder 19 Apr '12

19 Apr '12

Hi, has anyone written or found a tool to convert JSON output to a more human readable format, like traditional traceroute? INPUT: { "from": "80.123.123.123", "fw": 1, "msm_id": 1234567, "prb_id": 12345, "result": "traceroute to 91.228.151.2 (91.228.151.2), 30 hops max, 38 byte packets NEWLINE 1 192.168.123.123 2.087 ms 1.732 ms 1.928 ms NEWLINE 2 194.109.123.123 16.650 ms 16.570 ms 17.072 ms NEWLINE", "timestamp": 1234567890 }, OUTPUT: traceroute to 91.228.151.2 (91.228.151.2), 30 hops max, 38 byte packets 1 192.168.123.123 2.087 ms 1.732 ms 1.928 ms 2 194.109.123.123 16.650 ms 16.570 ms 17.072 ms etc. I'm hopeless as a programmer, otherwise I would have written something myself... Best regards, Paul Hoogsteder

3 2

RIPE Atlas JSON traceroutes
by Paul Hoogsteder 19 Apr '12

19 Apr '12

Hi, has anyone written or found a tool to convert JSON output to a more human readable format, like traditional traceroute? INPUT: { "from": "80.123.123.123", "fw": 1, "msm_id": 1234567, "prb_id": 12345, "result": "traceroute to 91.228.151.2 (91.228.151.2), 30 hops max, 38 byte packets NEWLINE 1 192.168.123.123 2.087 ms 1.732 ms 1.928 ms NEWLINE 2 194.109.123.123 16.650 ms 16.570 ms 17.072 ms NEWLINE", "timestamp": 1234567890 }, OUTPUT: traceroute to 91.228.151.2 (91.228.151.2), 30 hops max, 38 byte packets 1 192.168.123.123 2.087 ms 1.732 ms 1.928 ms 2 194.109.123.123 16.650 ms 16.570 ms 17.072 ms etc. I'm hopeless as a programmer, otherwise I would have written something myself... Best regards, Paul Hoogsteder.

1 0

on DNSMON
by Gilles Massen 19 Apr '12

19 Apr '12

Hello, Later this afternoon Daniel is presenting on the (non-)future of TTM and specifically DNSMON. Unfortunately I'm unable to attend even remotely, so here are a few comments on our use of DNSMON which might be useful to the discussion. While we have been hosting a TTM box for a long time, DNSMON is basically the only derived servie we have been using. We are operating a TLD, and DNSMON is currently the only way we have to monitor the overall quality and reachability of our DNS service, specifically as many of the nameservers are anycast clouds. DNSMON is used from casual checking if everything is still green, down to specific debugging of local issues, even using the raw data from time to time. So what matters to us is: - easily interpreted graphs and overviews, with the ability to drill down on servers or probes - historical information (whithin the graphs) - detailed (raw) data I have a few ideas what could be added, but these are really the functions that would be dearly missed if DNSMON were to disappear. If the data is collected by ATLAS probes or TTM boxes does obviously not matter very much. The ease of access to the information however is important. Have a nice meeting! Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473

1 0

New article on RIPE Labs: RIPEstat Address Hierarchy Widget
by Mirjam Kuehne 19 Apr '12

19 Apr '12

Dear colleagues, Please find a new article on RIPE Labs describing the Address Space Hierarchy Widget that is now available in RIPEstat: https://labs.ripe.net/Members/becha/ripestat-address-space-hierarchy-widget Kind Regards, Mirjam Kuehne RIPE NCC

1 0