- mat-wg - mailman.ripe.net

Planned Test Traffic Measurements Service Closure
by Romeo Zwart 05 Jun '14

05 Jun '14

Dear colleagues, The RIPE NCC’s Test Traffic Measurements (TTM) Service will be decommissioned at the end of June 2014. Most of the functionality offered by TTM is available as part of RIPE Atlas and we encourage you to take advantage of this service: https://atlas.ripe.net Handover of Responsibility of TTM Machines We will contact the individual TTM hosts during June to arrange the handover of responsibility for the remaining TTM systems. Many hosts asked us about the possibilities to keep the old hardware around as a stand-alone NTP server. We have a RIPE Labs article detailing the options to transition your TTM system to a dedicated NTP server. The article is available here: https://labs.ripe.net/Members/colin_petrie/how-to-convert-your-ttm-box-to-a… Availability of TTM Data - No new data will be collected via TTM once decommissioned - Current interface for TTM data visualisations will be available until at least the end of 2014 - Raw data from TTM measurements will be downloadable indefinitely Background For more information about the end of TTM, please read this RIPE Labs article by Kaveh Ranjbar posted last year: https://labs.ripe.net/Members/kranjbar/future-of-ripe-ncc-technical-services We delayed the decommissioning date mentioned in the article by six months to provide a smooth transition for the DNSMON service from TTM to RIPE Atlas. We also wanted to allow TTM users adequate time to start using RIPE Atlas or other tools. We invite your feedback regarding the above planning. Please send your comments directly to me (<romeo.zwart(a)ripe.net>) or to the MAT Working Group mailing list (<mat-wg(a)ripe.net>). Regards, Romeo Zwart RIPE NCC

1 0

Changes to the Distribution Model for RIPE Atlas Probes
by Vesna Manojlovic 03 Jun '14

03 Jun '14

Dear colleagues, we have made some adjustments in the distribution model of RIPE Atlas probes to ensure wider topological and geographical probe coverage. Please read more in this RIPE Labs article: https://labs.ripe.net/Members/fatemah_mafi/changes-to-the-distribution-mode… Regards, Vesna

1 0

New Article on RIPE Labs: ReFlow: Reports on Internet Flows
by Mirjam Kuehne 03 Jun '14

03 Jun '14

Dear colleagues, This new article on RIPE Labs is describing ReFlow - a public website containing statistics about general Internet traffic. The main goal of ReFlow is to maintain historical traffic data, allowing for comparisons and analysis of trends on Internet traffic This article has been contributed by Martijn Hoogesteger from the University of Twente: https://labs.ripe.net/Members/martijn_hoogesteger/reflow-reports-on-interne… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New article on RIPE Labs: Basic Evaluation of new IXP Peering Partners with RIPE Atlas and Zabbix
by Mirjam Kuehne 26 May '14

26 May '14

Dear colleagues, In this new article on RIPE Labs, Daniel Gomez explains how he used RIPE Atlas to evaluate new peering partners within an Internet Exchange Point and how this helped to improve customer services: https://labs.ripe.net/Members/daniel_gomez/basic-evaluation-of-new-ixp-peer… Kind regards, Mirjam Kuehne RIPE NCC

1 0

BEREC - Network Neutrality
by Gordon Lennox 20 May '14

20 May '14

BEREC have just issued a press release commenting on the Parliament's modified proposal and recalling some of their concerns with the Commission's initial proposal. About network neutrality they write: <<BEREC supports the promotion of and the clear commitment of the European Parliament to the principle of net neutrality. This is in line with BEREC’s public position, and indeed BEREC has been deeply involved with the subject since 2010, since when it has developed a set of principles and guidelines that can be implemented and adapted by national regulatory authorities, under the existing framework. The internet has proven to be highly innovative, thanks to certain fundamental principles such as the separation of network and application layer, the best effort principle and universal connectivity. This innovation should be safeguarded, both on the edges and within the network. BEREC recognizes that guaranteeing an open internet is a challenging objective, not least given its complex and dynamic ecosystem. Yet, the Commission’s original proposal would turn a flexible and progressive regulatory regime (under the 2009 Framework) into a rigid regulatory system and the European Parliament has generally retained this approach. BEREC would instead prefer an approach based on principles rather than detailed rules and which provides NRAs with the necessary powers to ensure that those principles (such as the ones developed by BEREC on what constitutes reasonable traffic management and on the relationship between specialized services and internet access services) are respected. Under such an approach, national regulators would be pursuing the same objective and enforcing the same principles, but the specific triggers and thresholds for regulatory intervention in a given market could be adapted to address national circumstances. If a rules-based approach is nonetheless to be pursued, then further work would be required to ensure that the definitions and rules were legally precise, future-proof and enforceable in practice. While some of the language in the text adopted by European Parliament draws upon BEREC previous publications on the subject, improving the original Commission’s proposals, it does not yet meet these standards. A balanced approach to promoting net neutrality on the Internet in parallel to the provision of specialised services is a difficult challenge. BEREC considers that specialised services should be clearly separated (physically or virtually) from internet access services at the network layer, to ensure that sufficient safeguards prevent degradation of the internet access services. Therefore BEREC welcomes the European Parliament’s acknowledgement of this principle. However, some inconsistencies in the proposed rules and definitions still raise legal and policy concerns.>> http://berec.europa.eu/eng/news_consultations/whats_new/2203-berec-publishe… So if you want network neutrality then you need regulation? The only question left is what kind. One indication of where they see the limits can perhaps be found in the sentence "This innovation should be safeguarded, both on the edges and within the network." I feel this is a significant shift. I cannot remember regulators looking in detail at what happens within traditional networks. They limited themselves to the "edges". Gordon

1 0

BEREC
by Gordon Lennox 16 May '14

16 May '14

BEREC - the Body of European Regulators for Electronic Communications, http://berec.europa.eu - are interested in metrics and monitoring. They are looking in particular at how regulators can monitor QoS for Internet access services in the context of network neutrality. Indeed they just had a public consultation on: "Monitoring quality of services in the context of network neutrality" based on a draft report, a draft which I think is still worth reading. See: http://berec.europa.eu/eng/news_consultations/ongoing_public_consultations/… From there - still also accessible from their home page - you can access the draft report and the annex where Atlas is mentioned. They have published a number of other reports on this going back over the past few years. Lots of reading! I brought this up on the Cooperation List and was requested to made a short presentation at the Connect session. There was an initial discussion on where this could sit between Cooperation and Connect. But looking forward maybe a more natural home would be between Connect and MAT. I will leave that for others to decide. But I do think it would be good to get somebody from BEREC to present in London. I will share the contact details I have with the co-chairs. Regards, Gordon

1 0

RIPE Atlas use cases and more
by Vesna Manojlovic 13 May '14

13 May '14

Dear colleagues, There have been a lot of great examples recently of how RIPE Atlas can be used to investigate network events, troubleshoot problems, explore how the Internet behaves, and more. Some of the topics include: - Investigating customer complaints about slow servers - Comparing TCP and UDP Response Times of DNS Root Servers - Discovering Path MTU black holes on the Internet We’ve collected all of these user experiences, analyses, papers and presentations in one place on RIPE Labs, in order to make it easy to discover how others are making use of the RIPE Atlas network - and maybe spark some ideas about how you can, too. https://labs.ripe.net/atlas/user-experiences If you have your own story about how you’ve used RIPE Atlas, we want to hear from you! Please get in touch with us at atlas(a)ripe.net. Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC

1 0

Re: [mat-wg] Trimble GPS from old TTM
by George Michaelson 13 May '14

13 May '14

We just upgraded BSD to 10 and it seems to be fne, but I haven't completed the cutover. Certainly, the driver ID for the 127.x.x.x instance is still in the BSD port codebase. -G On Tue, May 13, 2014 at 9:39 AM, Romeo Zwart <romeo.zwart(a)ripe.net> wrote: > Hi Antonio, > > On 14/05/13 00:44 , Antonio M. Moreiras wrote: > > Hello, we are trying to reuse the trimble GPS from our old TTM server in > > a Linux NTP machine, and it is not working. > > We have been doing some testing in the RIPE NCC with some linux > flavours. A RIPE Labs article with details is in preparation and will be > shared with this list soon. > > We will contact you off line to share our experience. > > Regards, > Romeo > > > We can read some trash with a "cat /dev/ttyS0" (what means that the GPS > > is sending information), and we can use PPS driver (127.127.22.0) to > > read correctly the PPS signal. But the driver from RIPE (127.127.43.0) > > doesn't work. > > > > We compiled the ntpd (version 4.2.6p5) with the following options: > > > > ./configure --with-openssl-libdir=/usr/lib/x86_64-linux-gnu > > --with-openssl-incdir=/usr/include --enable-RIPENCC > > > > Our Linux is: > > > > # uname -a > > Linux monitor 3.11.0-20-generic #35~precise1-Ubuntu SMP Fri May 2 > > 21:32:55 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > > > # lsb_release -a > > No LSB modules are available. > > Distributor ID: Ubuntu > > Description: Ubuntu 12.04.4 LTS > > Release: 12.04 > > Codename: precise > > > > Only after follow the recommendations at > > http://linuxpps.org/wiki/index.php/LinuxPPS_NTPD_support, the driver > > 127.127.43.0 is loaded by NTP, and appears in the list of peers, but no > > sync, just zeros. > > > > Does anyone in this list have any tips? > > > > Regards, > > Moreiras. > > > > > > > >

2 2

Prevention of NTP reflection attacks using TTM systems
by Romeo Zwart 13 May '14

13 May '14

Dear colleagues, During the evening of Wednesday 8 January, the RIPE NCC received initial reports about the abuse of some of our Test Traffic Measurement (TTM) systems, specifically about the use of NTP in reflection attacks. Within 24 hours of receiving the first report, we adapted the NTP configuration on all our TTM hosts so that this specific type of attack is no longer possible using the TTM infrastructure. We would like to thank Gert Doering (SpaceNet) and Michael Hausding (SWITCH-CERT) for reporting the abuse to us. We’d also like to share this resource about securing NTP servers that you may find useful: http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html We are taking this opportunity to remind you that we are nearing end of service for TTM. As we announced previously, TTM shutdown is scheduled for the end of Q1, 2014. RIPE Atlas, and specifically RIPE Atlas anchors, will provide much of the functionality of TTM. More details, including information about hosting a RIPE Atlas anchor, are available at: https://atlas.ripe.net/about/anchors/ Kind regards, Romeo Zwart RIPE NCC

4 4

Five more RIPE Atlas anchors in the previous month
by Vesna Manojlovic 07 May '14

07 May '14

Dear colleagues, We are proud to announce that five new RIPE Atlas anchors have been activated since my previous announcement last month: - uy-mvd-as28000, hosted by LACNIC in Montevideo, Uruguay. (This is the first anchor in Latin America and the first one hosted by an RIR on behalf of the RIPE NCC. ) - au-bne-as4608, hosted by APNIC in Brisbane, Australia - cz-prg-as39392, hosted by SuperNetwork in Prague, Czech Republic - fr-tin-as196670, hosted by ADP in Pantin, France - be-lln-as2611 by the Université catholique de Louvain in Belgium This brings the total number of anchors to 55. All RIPE Atlas anchors can be seen on this list, where logged-in users can access each anchor's measurements: https://atlas.ripe.net/anchors/list/ We are still accepting new applications from individuals and organisations interested in hosting a RIPE Atlas anchor. We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa, in order to add more geographical diversity to the measurement data. Learn more about RIPE Atlas anchors and the benefits of hosting an anchor at: https://atlas.ripe.net/about/anchors/ For detailed announcements and updates about RIPE Atlas, please join the RIPE Atlas mailing list: https://www.ripe.net/mailman/listinfo/ripe-atlas Kind regards, Vesna Manojlovic Measurements Community Building Team RIPE NCC

1 0