From robert at ripe.net Thu Jan 2 11:44:12 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 02 Jan 2014 11:44:12 +0100 Subject: [atlas] Firmware versions (was: Re: (no subject)) In-Reply-To: <2DD8FC12-9A6F-4311-96A2-D1B07990C65F@jacobs-university.de> References: <081E9415D79F9A469A4B6C79815FC0926E3158@SXCHMB01.jacobs.jacobs-university.de> <52B0A082.8040306@ripe.net> <2DD8FC12-9A6F-4311-96A2-D1B07990C65F@jacobs-university.de> Message-ID: <52C542FC.5070305@ripe.net> Hello, > Hello Robert, > > The question popped up at our end because we were looking at the plots > of measurement results generated by different probes. We wanted to make > sure these probes were comprised of the same hardware and that they run > the same firmware version. It?s great that each UDM attaches the > firmware version of the probe as a tag in its results. However: > > a) Although, the hardwares currently are capable of running the same > firmware revision, but as you mentioned, at times they diverge away. > > b) Would different hardwares always support the latest firmware > version? I ask because v3 is more capable than v1/v2, and I don?t know > if you plan to diverge away the firmware at some point to provide more > measurement capabilities for v3 probes. As a general rule, we keep the firmware versions in sync across hardware revisions in order to have the same capabilities available. The current situation is a bit of an exception, but that's only because we needed to deploy a new firmware for one hardware version only; functionally there's no difference. > Due to a) and b) would it make sense to also attach the hardware > version (v1, v2, v3) of the probe as a tag in each UDM result as well? > We don?t know if different hardwares have effects on the measurement > results. We can cross-confirm this if the UDMs attach a hardware > version in addition to the firmware revision. This would be possible, though (with some more documentation from our end [*]) one could also easily determine the hardware version from the probe ID. Regards, Robert [*] the quick version: - ID < 1500: v1 - 2000 < ID < 5000: v2 - 6000 < ID < 7000: anchor - ID > 10000: v3 > Thanks! > > Best, Vaibhav > > ----------------------------------------------------- Vaibhav Bajpai > > Research I, Room 86 Computer Networks and Distributed Systems (CNDS) > Lab School of Engineering and Sciences Jacobs University Bremen, > Germany > > www.vaibhavbajpai.com > From v.bajpai at jacobs-university.de Fri Jan 3 11:42:18 2014 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Fri, 3 Jan 2014 10:42:18 +0000 Subject: [atlas] Firmware versions (was: Re: (no subject)) In-Reply-To: <52C542FC.5070305@ripe.net> References: <081E9415D79F9A469A4B6C79815FC0926E3158@SXCHMB01.jacobs.jacobs-university.de> <52B0A082.8040306@ripe.net> <2DD8FC12-9A6F-4311-96A2-D1B07990C65F@jacobs-university.de> <52C542FC.5070305@ripe.net> Message-ID: <5619AA52-7466-4F07-8629-7067A5F942B6@jacobs-university.de> On 02 Jan 2014, at 11:44, Robert Kisteleki wrote: > [...] > > As a general rule, we keep the firmware versions in sync across hardware > revisions in order to have the same capabilities available. The current > situation is a bit of an exception, but that's only because we needed to > deploy a new firmware for one hardware version only; functionally there's > no difference. > >> Due to a) and b) would it make sense to also attach the hardware >> version (v1, v2, v3) of the probe as a tag in each UDM result as well? >> We don?t know if different hardwares have effects on the measurement >> results. We can cross-confirm this if the UDMs attach a hardware >> version in addition to the firmware revision. > > This would be possible, though (with some more documentation from our end > [*]) one could also easily determine the hardware version from the probe ID. > > Regards, > Robert > > [*] the quick version: > - ID < 1500: v1 > - 2000 < ID < 5000: v2 > - 6000 < ID < 7000: anchor > - ID > 10000: v3 Aha! This is useful. Thanks for sharing. Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From BECHA at ripe.net Wed Jan 8 18:44:51 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 08 Jan 2014 18:44:51 +0100 Subject: [atlas] Fwd: [service] Technical Outage Resolved In-Reply-To: <52CD8876.1050000@ripe.net> References: <52CD8876.1050000@ripe.net> Message-ID: <52CD8E93.7050803@ripe.net> Dear colleagues, RIPE NCC has experienced outage, and some RIPE Atlas probes were also affected. We will send more information tomorrow, as we assess the extent of the impact. Regards, Vesna -------- Original Message -------- Subject: [service] Technical Outage Resolved Date: Wed, 08 Jan 2014 18:18:46 +0100 From: Nick Hyrka To: ncc-announce at ripe.net CC: ripe-list at ripe.net Dear colleagues, At 15:45 Amsterdam time, the RIPE NCC experienced a technical outage affecting a number of our services. >From 16:15, we were able to recover some services and by 17:45 all were fully functional. We apologise for any inconvenience this may have caused. Regards, Nick Hyrka Communications Manager RIPE NCC From robert at ripe.net Thu Jan 9 10:05:59 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 09 Jan 2014 10:05:59 +0100 Subject: [atlas] Fwd: [service] Technical Outage Resolved In-Reply-To: <52CD8E93.7050803@ripe.net> References: <52CD8876.1050000@ripe.net> <52CD8E93.7050803@ripe.net> Message-ID: <52CE6677.6030502@ripe.net> Dear All, During the network outage about 25% of the probes got temporarily disconnected, and as a result, you may have received notification about this. Once the outage ended all probes connected again. Regards, Robert On 2014.01.08. 18:44, Vesna Manojlovic wrote: > Dear colleagues, > > RIPE NCC has experienced outage, and some RIPE Atlas probes were also affected. > > We will send more information tomorrow, as we assess the extent of the impact. > > Regards, > Vesna > > -------- Original Message -------- > Subject: [service] Technical Outage Resolved > Date: Wed, 08 Jan 2014 18:18:46 +0100 > From: Nick Hyrka > To: ncc-announce at ripe.net > CC: ripe-list at ripe.net > > Dear colleagues, > > At 15:45 Amsterdam time, the RIPE NCC experienced a technical outage > affecting a number of our services. > >> From 16:15, we were able to recover some services and by 17:45 all were > fully functional. > > We apologise for any inconvenience this may have caused. > > Regards, > > Nick Hyrka > Communications Manager > RIPE NCC > > > > > > From BECHA at ripe.net Thu Jan 9 16:22:48 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 09 Jan 2014 16:22:48 +0100 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <52B0344C.5080109@ripe.net> References: <52B0344C.5080109@ripe.net> Message-ID: <52CEBEC8.2080404@ripe.net> Dear colleagues, Three weeks ago, the RIPE NCC published a clarification about the current state of RIPE Atlas public measurement data and the privacy of probe data. We also proposed making some changes to the current situation. There has been some lively discussion about our proposal to make the probe and measurement data public for new and existing users starting at a future date. Most comments did not support this proposal. Some people are in favour of keeping the situation as it is (i.e. making it possible to opt out of making your measurements public), while others proposed an alternative solution of delaying the publication of measurement data for a day (or a week). We'd like to hear more opinions, either for or against any of these proposals, including your motivation or the use case you have in mind. Please take part in the discussion on the mailing list. We will consider your input and come up with an updated proposal in February. Regards, Vesna Measurements Community Building RIPE NCC On 17-dec.-13 12:23, Vesna Manojlovic wrote: > Dear colleagues, > > Sharing information about Internet performance is at the heart of > collaborative efforts such as RIPE Atlas. > > Most of the RIPE Atlas probes and RIPE Atlas measurements are already > public, and we'd now like to suggest opening up the publication of RIPE > Atlas data further. We also want to clarify exactly what is and isn't > public in the current system. We describe this in more detail in this > RIPE Labs article, where we also ask for community feedback about our > suggested plan to move forward: > https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public > > > Our proposed plan is to make all *new* measurements and technical > information about the *new* probes public from an agreed upon date > in the future. We propose implementing this change in mid-April. > > All probes and measurements that were not marked "public" by April 2014 > would remain non-"public". For a detailed description of what this > means, please see the RIPE Labs article (above). > > Although we believe that having public measurement data contributes to > the goal of RIPE Atlas, the RIPE NCC greatly values our users' privacy. > We want to ensure you that we will continue to protect our probe hosts' > personal information. > > We look forward to your feedback and comments on the MAT Working Group > Mailing List. > > Regards, > > Vesna Manojlovic > Senior Community Builder > Measurements Community Building > RIPE NCC > > > From gboonie at gmail.com Thu Jan 9 18:48:27 2014 From: gboonie at gmail.com (dave) Date: Thu, 9 Jan 2014 18:48:27 +0100 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <52CEBEC8.2080404@ripe.net> References: <52B0344C.5080109@ripe.net> <52CEBEC8.2080404@ripe.net> Message-ID: <3EF5F35F-0819-4E5A-A866-637688D37BD1@gmail.com> I'm in favor of keeping the option to have a measurement be private. As is. Thanks > Op 9 jan. 2014 om 16:22 heeft Vesna Manojlovic het volgende geschreven: > > Dear colleagues, > > Three weeks ago, the RIPE NCC published a clarification about the current state of RIPE Atlas public measurement data and the privacy of probe data. We also proposed making some changes to the current situation. > > There has been some lively discussion about our proposal to make the probe and measurement data public for new and existing users starting at a future date. > > Most comments did not support this proposal. Some people are in favour of keeping the situation as it is (i.e. making it possible to opt out of making your measurements public), while others proposed an alternative solution of delaying the publication of measurement data for a day (or a week). > > We'd like to hear more opinions, either for or against any of these proposals, including your motivation or the use case you have in mind. > > Please take part in the discussion on the mailing list. > > We will consider your input and come up with an updated proposal in February. > > Regards, > > Vesna > Measurements Community Building > RIPE NCC > > >> On 17-dec.-13 12:23, Vesna Manojlovic wrote: >> Dear colleagues, >> >> Sharing information about Internet performance is at the heart of >> collaborative efforts such as RIPE Atlas. >> >> Most of the RIPE Atlas probes and RIPE Atlas measurements are already >> public, and we'd now like to suggest opening up the publication of RIPE >> Atlas data further. We also want to clarify exactly what is and isn't >> public in the current system. We describe this in more detail in this >> RIPE Labs article, where we also ask for community feedback about our >> suggested plan to move forward: >> https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public >> >> >> Our proposed plan is to make all *new* measurements and technical >> information about the *new* probes public from an agreed upon date >> in the future. We propose implementing this change in mid-April. >> >> All probes and measurements that were not marked "public" by April 2014 >> would remain non-"public". For a detailed description of what this >> means, please see the RIPE Labs article (above). >> >> Although we believe that having public measurement data contributes to >> the goal of RIPE Atlas, the RIPE NCC greatly values our users' privacy. >> We want to ensure you that we will continue to protect our probe hosts' >> personal information. >> >> We look forward to your feedback and comments on the MAT Working Group >> Mailing List. >> >> Regards, >> >> Vesna Manojlovic >> Senior Community Builder >> Measurements Community Building >> RIPE NCC > From Woeber at CC.UniVie.ac.at Thu Jan 9 19:46:46 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 09 Jan 2014 19:46:46 +0100 Subject: [atlas] call for help or ptr to doc - saving graphs? Message-ID: <52CEEE96.80502@CC.UniVie.ac.at> Apologies, if this has been discussed before or should be obvious from some documentation... So here we go: In the "good old days" (no I prefer the current state :-) ) it was asy to get hold of the extended graphs by simply clicking onto the graph in the summary page and then do "save" or "save as". Since the (better, interactive,...) graphs are generated locally, I failed to come up with a method to "get hold" of the graph, for storing locally, printing, whatever. I just today tried to hit "print" in the browser, but the page seems to be inadequately structured/formatted for printing. The result is gaebage all over. Does anyone have a pointer or suggestion for me, sort of "better" than doing a screen shot and then work with the pixels? TIA, Wilfried From Woeber at CC.UniVie.ac.at Thu Jan 9 20:00:41 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 09 Jan 2014 20:00:41 +0100 Subject: [atlas] Atlas F.ROOT ping In-Reply-To: References: <20121113153411.GA22380@ussenterprise.ufp.org> Message-ID: <52CEF1D9.1000702@CC.UniVie.ac.at> Jim Martin wrote: [...] >>>The good folks at ISC would be quite happy if you opened a ticket >>>with them on this issue. Drop an e-mail to noc at isc.org to do so, >>>including traceroutes and such would help a lot. Actually, I started today to have a closer look (again) at connectivity to F from our neck in the woods[1]. Interestingly, the RTT for v4 and v6 are almost identical, but the packet drop over v4 sometimes is *significant*, while v6 seems to work like a charm :-) >>I did. I may do the same, after better understanding what the situation here is. It may be a local issue. > And we appreciate it :-) We'll look into the issue for F. > > - Jim (who's Ops at ISC, but is subscribed to this list from a personal account) Wilfried. [1] AA P-ID=6009 a-vie-as1853 From Woeber at CC.UniVie.ac.at Thu Jan 9 20:27:19 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 09 Jan 2014 20:27:19 +0100 Subject: [atlas] graph generation stopped on 9.1.2014 Message-ID: <52CEF817.20704@CC.UniVie.ac.at> It looks like the generation of graphs to be displayed on the summary page for my probes stopped at some point in time, today, Jan. 9. Before around noon it was working, now they are gone. Probes affected: 414, 466, 6009 Any hints? Wilfried From Woeber at CC.UniVie.ac.at Thu Jan 9 21:38:27 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 09 Jan 2014 21:38:27 +0100 Subject: [atlas] graph generation stopped on 9.1.2014 In-Reply-To: <52CEF817.20704@CC.UniVie.ac.at> References: <52CEF817.20704@CC.UniVie.ac.at> Message-ID: <52CF08C3.2050400@CC.UniVie.ac.at> Well, graphs are back for me at 20:38 UTC :-) -ww Wilfried Woeber wrote: > It looks like the generation of graphs to be displayed on the summary page > for my probes stopped at some point in time, today, Jan. 9. > > Before around noon it was working, now they are gone. > > Probes affected: 414, 466, 6009 > > Any hints? > Wilfried > From randy at psg.com Fri Jan 10 04:37:44 2014 From: randy at psg.com (Randy Bush) Date: Fri, 10 Jan 2014 12:37:44 +0900 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <3EF5F35F-0819-4E5A-A866-637688D37BD1@gmail.com> References: <52B0344C.5080109@ripe.net> <52CEBEC8.2080404@ripe.net> <3EF5F35F-0819-4E5A-A866-637688D37BD1@gmail.com> Message-ID: > I'm in favor of keeping the option to have a measurement be > private. As is. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available URL: From robert at ripe.net Fri Jan 10 09:49:14 2014 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 10 Jan 2014 09:49:14 +0100 Subject: [atlas] call for help or ptr to doc - saving graphs? In-Reply-To: <52CEEE96.80502@CC.UniVie.ac.at> References: <52CEEE96.80502@CC.UniVie.ac.at> Message-ID: <52CFB40A.7070807@ripe.net> Hello, The probe pages (list, details) as well as the UDMs are indeed a bit convoluted; as you also note they are not really suited for saving/printing/etc. We're close to releasing a reworked version of the probe pages with a much simplified layout. This will help a lot with saving/printing too. Regards, Robert On 2014.01.09. 19:46, Wilfried Woeber wrote: > Apologies, if this has been discussed before or should be obvious from > some documentation... > > So here we go: > In the "good old days" (no I prefer the current state :-) ) it was asy to > get hold of the extended graphs by simply clicking onto the graph in the > summary page and then do "save" or "save as". > > Since the (better, interactive,...) graphs are generated locally, I failed > to come up with a method to "get hold" of the graph, for storing locally, > printing, whatever. > > I just today tried to hit "print" in the browser, but the page seems to be > inadequately structured/formatted for printing. The result is gaebage all > over. > > Does anyone have a pointer or suggestion for me, sort of "better" than doing > a screen shot and then work with the pixels? > > TIA, > Wilfried > > From Woeber at CC.UniVie.ac.at Fri Jan 10 10:16:52 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Fri, 10 Jan 2014 10:16:52 +0100 Subject: [atlas] call for help or ptr to doc - saving graphs? / feature request In-Reply-To: <52CFB40A.7070807@ripe.net> References: <52CEEE96.80502@CC.UniVie.ac.at> <52CFB40A.7070807@ripe.net> Message-ID: <52CFBA84.7020002@CC.UniVie.ac.at> Thanks, Robert! I'll go on hold for a while and hope for the best :-) Ref. reworking, I'm having another xmas-wish... [please bear with me if this has already been discussed, I'm suffering from a mail backlog] You know, I am one of "those" who always try to compare v4 vs v6 "quality" for dual-stack destinations. Obvious candidates are dns root servers. Thus, going to the interactive detail graphs, and assuming that I will be able to save the display to a file, it would *really* be useful to have the graphs use the same scaling on the y-axis. So, unless you've got a better idea, I'd like to ask for a new "button" - similar to "zoom" -, which allows me to specify the (lower and) upper value boundary for the y-axis. Does this make sense? Wilfried. From trammell at tik.ee.ethz.ch Fri Jan 10 10:18:39 2014 From: trammell at tik.ee.ethz.ch (Brian Trammell) Date: Fri, 10 Jan 2014 10:18:39 +0100 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <52CEBEC8.2080404@ripe.net> References: <52B0344C.5080109@ripe.net> <52CEBEC8.2080404@ripe.net> Message-ID: <52CFBAEF.9010807@tik.ee.ethz.ch> hi Vesna, all, Another potential way to resolve the tension between public and "private" policies would be to allow each probe host to decide which of their probe(s) are available for non-public* measurements. Here, each probe has a "public-only bit". Probes with the public-only bit cleared can be used for public or non-public UDMs, and generate credits which can be used for public or non-public UDMs. Probes with the public-only bit set can only be used for public UDMs, and generate credits which can only be used for public UDMs. Probes default to having the public-only bit cleared; this allows probe hosts to opt out of allowing their probes to be used for non-public UDMs, but at the expense of being able to do non-public UDMs themselves. This arrangement would allow the whole community to decide for itself, in a decentralized manner. It would also require a bit of redesign, but so would measurements that would remain non-public for some escrow period. There are probably details I'm missing. For one, if we're going to allow non-public UDMs at all, all the anchors probably have to have their public-only bit cleared, otherwise the core of the network fragments. The default measurements for all probes must be public in all cases, as well. * I use "non-public" here as opposed to "private" intentionally, because the very notion of "private measurements" on a widely distributed volunteer active measurement network is somewhat dubious. It's trivially easy to find out what an Atlas probe is doing if you have access to the network it's on, so your measurements and results are leaking to a set of probe hosts even in the case of a some bit being set in the database. You cannot know the degree of collusion among Atlas probe hosts, so using the term "private" here gives an inaccurate impression of who can know what about non-public. If it's actually important that you can control who knows what about the measurements you're doing, what you want is a different architecture than Atlas provides. A non-public measurement is simply a measurement which can be later redacted from certain views of the database. And in the interests of disclosure, I'm one of the freeloading research types, so of course I want everything to be eventually public, and in return I agree not to care who knows that v6 connectivity to my web host could be better (https://atlas.ripe.net/atlas/udm.html?msm_id=1402190#!tab-probes1402190). I do large-scale, long term work, so it's less important to me that I can see all of today's UDMs today, and more important that I can see all the measurements from 2012 to 2017 in 2017, so a user-definable embargo period for UDMs would be a good solution too, if that addresses business-sensitivity concerns. Cheers, Brian Vesna Manojlovic wrote: > Dear colleagues, > > Three weeks ago, the RIPE NCC published a clarification about the > current state of RIPE Atlas public measurement data and the privacy of > probe data. We also proposed making some changes to the current situation. > > There has been some lively discussion about our proposal to make the > probe and measurement data public for new and existing users starting at > a future date. > > Most comments did not support this proposal. Some people are in favour > of keeping the situation as it is (i.e. making it possible to opt out of > making your measurements public), while others proposed an alternative > solution of delaying the publication of measurement data for a day (or a > week). > > We'd like to hear more opinions, either for or against any of these > proposals, including your motivation or the use case you have in mind. > > Please take part in the discussion on the mailing list. > > We will consider your input and come up with an updated proposal in > February. > > Regards, > > Vesna > Measurements Community Building > RIPE NCC > > > On 17-dec.-13 12:23, Vesna Manojlovic wrote: >> Dear colleagues, >> >> Sharing information about Internet performance is at the heart of >> collaborative efforts such as RIPE Atlas. >> >> Most of the RIPE Atlas probes and RIPE Atlas measurements are already >> public, and we'd now like to suggest opening up the publication of RIPE >> Atlas data further. We also want to clarify exactly what is and isn't >> public in the current system. We describe this in more detail in this >> RIPE Labs article, where we also ask for community feedback about our >> suggested plan to move forward: >> https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public >> >> >> >> Our proposed plan is to make all *new* measurements and technical >> information about the *new* probes public from an agreed upon date >> in the future. We propose implementing this change in mid-April. >> >> All probes and measurements that were not marked "public" by April 2014 >> would remain non-"public". For a detailed description of what this >> means, please see the RIPE Labs article (above). >> >> Although we believe that having public measurement data contributes to >> the goal of RIPE Atlas, the RIPE NCC greatly values our users' privacy. >> We want to ensure you that we will continue to protect our probe hosts' >> personal information. >> >> We look forward to your feedback and comments on the MAT Working Group >> Mailing List. >> >> Regards, >> >> Vesna Manojlovic >> Senior Community Builder >> Measurements Community Building >> RIPE NCC >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 600 bytes Desc: OpenPGP digital signature URL: From liman at netnod.se Fri Jan 10 10:30:47 2014 From: liman at netnod.se (Lars-Johan Liman) Date: Fri, 10 Jan 2014 10:30:47 +0100 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <3EF5F35F-0819-4E5A-A866-637688D37BD1@gmail.com> (dave's message of "Thu, 9 Jan 2014 18:48:27 +0100") References: <52B0344C.5080109@ripe.net> <52CEBEC8.2080404@ripe.net> <3EF5F35F-0819-4E5A-A866-637688D37BD1@gmail.com> Message-ID: <22bnzkchfc.fsf@ziptop.autonomica.net> gboonie at gmail.com: > I'm in favor of keeping the option to have a measurement be private. As is. +1 Cheers, /Liman #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman at netnod.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Netnod Internet Exchange, Stockholm ! http://www.netnod.se/ #---------------------------------------------------------------------- From bortzmeyer at nic.fr Fri Jan 10 15:57:51 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 10 Jan 2014 15:57:51 +0100 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <52CEBEC8.2080404@ripe.net> References: <52B0344C.5080109@ripe.net> <52CEBEC8.2080404@ripe.net> Message-ID: <20140110145751.GA25320@nic.fr> On Thu, Jan 09, 2014 at 04:22:48PM +0100, Vesna Manojlovic wrote a message of 71 lines which said: > There has been some lively discussion about our proposal to make the > probe and measurement data public for new and existing users > starting at a future date. I personally support the proposal (to make measurements public by default). I believe that the Atlas network is built for the public good and probe hosters would probably feel better if all the measurements performed were public. If some people want to do private measurements, they should use private systems. I understand the issue raised by Gilles Massen and Peter Koch (knowing that Acme corporation pings something.acme.com means there is a problem which may be an useful info for Acme's competitors) but I don't believe that intelligence agencies and private eyes will actually poll the Atlas database to see if there are interesting measurements going on, they have certainly better things to do. I have nothing against variants such as "only Atlas sponsors may request private measurements" [disclaimer: my employer is a sponsor] or "private measurements will become automatically public after N days" but, since one goal of the new proposal is to simplify the code, I wonder if they are worth the extra complexity. PS: is there a way to query the list of measurements with criteria such as "find me all the measurements involving something.acme.com and made in december 2013?" I don't think so. Such a search engine would be very useful for long-term analysis. On the other hand, it would increase the fears of spying. From mgalante at ripe.net Mon Jan 13 10:24:02 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 13 Jan 2014 10:24:02 +0100 Subject: [atlas] University of Tokyo/WIDE BB (JP) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called jp-tyo-as2500 and it is hosted by University of Tokyo/WIDE BB in Tokyo (Japan) on behalf of RIPE NCC since they are one of our RIS-RRC locations. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From mgalante at ripe.net Mon Jan 13 10:55:17 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 13 Jan 2014 10:55:17 +0100 Subject: [atlas] RIPE Atlas 2013: A Year in Review Message-ID: <9485AE14-6D01-4625-BCBF-DEC3E1F5BFDE@ripe.net> Dear colleagues, 2013 was an exciting year for RIPE Atlas. Take a look at what you helped us to achieve in 2013, in the new article on RIPE Labs: https://labs.ripe.net/Members/michela_galante/ripe-atlas-2013-year-in-review Kind regards, Michela Galante Measurements Community Building RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From alexsaroyan at gmail.com Mon Jan 13 14:13:44 2014 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Mon, 13 Jan 2014 17:13:44 +0400 Subject: [atlas] Measurement history "smoke ping style" Message-ID: <52D3E688.1050809@gmail.com> Hi, There is very useful "smoke ping style" RTT history for all Built-in measurements but I can't find such for User Defined Measurements (seismograph is not the same). I hope that such "smoke ping style" history/graph is available and I simply can't find it. If really no - then I desperately wish such feature to be implemented by Atlas team. -- Regards. /Alex Saroyan From mgalante at ripe.net Tue Jan 14 09:55:59 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 14 Jan 2014 09:55:59 +0100 Subject: [atlas] Poznan Supercomputing and Networking Center (PL) has joined RIPE Atlas anchors Message-ID: <3CFD40D7-1FA0-44DF-84CF-B8105C1C615A@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called pl-poz-as9112 and it is hosted by Poznan Supercomputing and Networking Center in Poznan (Poland) on behalf of RIPE NCC since they are one of our K-root hosts. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From calderm at usc.edu Tue Jan 14 22:07:58 2014 From: calderm at usc.edu (Matt Calder) Date: Tue, 14 Jan 2014 13:07:58 -0800 Subject: [atlas] measurement start_time and stop_time fields Message-ID: Hi, For the filter fields such as start_time__lt, stop_time__gte the API at https://atlas.ripe.net/docs/rest/ claims that a unix timestamp should be valid for these but I am seeing the error message "'1389655981' value has an invalid format. It must be in YYYY-MM-DD HH:MM[:ss[.uuuuuu]][TZ] format." I was trying with this query: https://atlas.ripe.net/api/v1/measurement/?limit=20&type=2&format=txt&use_iso_time=false&start_time__gte=1389619981&stop_time__lte=1389655981 Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Wed Jan 15 10:35:57 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 15 Jan 2014 10:35:57 +0100 Subject: [atlas] synch delay for Coverage Map? Message-ID: <52D6567D.4030408@CC.UniVie.ac.at> Hi folks, just out of curiosity, what are the intervals or the delay for updates to the "Global RIPE Atlas Network Coverage" map? [1] We just got the 1st probe connected in Cuba, thanks to the ambassador program, and I can see it as on-line. But it is not yet visible on the Coverage Map. Cheers, Wilfried [1] https://atlas.ripe.net/results/maps/network-coverage/ From BECHA at ripe.net Wed Jan 15 10:41:41 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 15 Jan 2014 10:41:41 +0100 Subject: [atlas] Newest RIPE Atlas features - seismograph improvements & more In-Reply-To: <52D65562.3070308@ripe.net> References: <52D65562.3070308@ripe.net> Message-ID: <52D657D5.5000800@ripe.net> Dear colleagues, We are proud to announce the latest features added to RIPE Atlas in the previous few months: - time selection in seismograph: zoom, and calendar menu; - filtering probe by country & ASN on maps & seismograph - one-off SSL measurements ... and much more! Please find out the details on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-update-january-2013 We are looking forward to your feedback! Regards, Vesna -- Measurements Community Building team RIPE NCC From BECHA at ripe.net Wed Jan 15 10:45:55 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 15 Jan 2014 10:45:55 +0100 Subject: [atlas] synch delay for Coverage Map? In-Reply-To: <52D6567D.4030408@CC.UniVie.ac.at> References: <52D6567D.4030408@CC.UniVie.ac.at> Message-ID: <52D658D3.60403@ripe.net> Hi Wilfried, On 15-jan.-14 10:35, Wilfried Woeber wrote: > Hi folks, > > just out of curiosity, what are the intervals or the delay for updates to > the "Global RIPE Atlas Network Coverage" map? [1] > > We just got the 1st probe connected in Cuba, thanks to the ambassador program, thank you very much for that! > and I can see it as on-line. But it is not yet visible on the Coverage Map. It is visible in RIPEstat already: https://stat.ripe.net/widget/atlas-probes#w.resource=CU & https://twitter.com/Ms_Multicolor/status/423388737116979200 Vesna From Woeber at CC.UniVie.ac.at Wed Jan 15 11:07:03 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 15 Jan 2014 11:07:03 +0100 Subject: [atlas] probe status "abandoned" - "garbage collect" attempt? Message-ID: <52D65DC7.3030001@CC.UniVie.ac.at> Dear community, as a side-effect of looking at maps and country-related info, I recognised that there's a considerable number of probes in our country which are marked as "abandoned". We may be able to follow up on some of them. Looking at https://stat.ripe.net/widget/atlas-probes#w.resource=AT and switching to table view, I'm missing the AS# column. Being able to search for "our" ASes would be nice. Thanks, Wilfried PS: a text / table version that can be saved locally and then subjected to a 'grep' would be nice, too. PPS: the sort function by address family is really nice! From robert at ripe.net Wed Jan 15 11:19:00 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 15 Jan 2014 11:19:00 +0100 Subject: [atlas] probe status "abandoned" - "garbage collect" attempt? In-Reply-To: <52D65DC7.3030001@CC.UniVie.ac.at> References: <52D65DC7.3030001@CC.UniVie.ac.at> Message-ID: <52D66094.5030705@ripe.net> On 2014.01.15. 11:07, Wilfried Woeber wrote: > Dear community, > > as a side-effect of looking at maps and country-related info, I recognised > that there's a considerable number of probes in our country which are marked > as "abandoned". We may be able to follow up on some of them. > > Looking at https://stat.ripe.net/widget/atlas-probes#w.resource=AT and switching > to table view, I'm missing the AS# column. Being able to search for "our" ASes > would be nice. > > Thanks, > Wilfried > > PS: a text / table version that can be saved locally and then subjected to > a 'grep' would be nice, too. > PPS: the sort function by address family is really nice! Hello Wilfried, Of course adin another column would not be a problem. In the meantime, you can get to the data used to make the map with two click (bottom left, "source data") -- this has all the information you need. https://stat.ripe.net/data/atlas-probes/data.json?resource=AT Regards, Robert From dquinn at ripe.net Wed Jan 15 11:24:25 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 15 Jan 2014 10:24:25 +0000 Subject: [atlas] synch delay for Coverage Map? In-Reply-To: <52D6567D.4030408@CC.UniVie.ac.at> References: <52D6567D.4030408@CC.UniVie.ac.at> Message-ID: <52D661D9.2040605@ripe.net> On 15/01/14 09:35, Wilfried Woeber wrote: > Just out of curiosity, what are the intervals or the delay for updates to > the "Global RIPE Atlas Network Coverage" map? Yup, there's a caching delay, though it was rather overzealous caching considering the work being done, so I've reduced it from 1 day to 1 hour. The change will be live once we make our next release. Sorry about the confusion! From Woeber at CC.UniVie.ac.at Wed Jan 15 11:36:15 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 15 Jan 2014 11:36:15 +0100 Subject: [atlas] synch delay for Coverage Map? In-Reply-To: <52D661D9.2040605@ripe.net> References: <52D6567D.4030408@CC.UniVie.ac.at> <52D661D9.2040605@ripe.net> Message-ID: <52D6649F.5030803@CC.UniVie.ac.at> Thanks, Daniel! No harm done :-) Wilfried Daniel Quinn wrote: > On 15/01/14 09:35, Wilfried Woeber wrote: > >>Just out of curiosity, what are the intervals or the delay for updates to >>the "Global RIPE Atlas Network Coverage" map? > > > Yup, there's a caching delay, though it was rather overzealous caching > considering the work being done, so I've reduced it from 1 day to 1 > hour. The change will be live once we make our next release. Sorry > about the confusion! From aftabs at cyber.net.pk Wed Jan 15 11:40:34 2014 From: aftabs at cyber.net.pk (Aftab A. Siddiqui) Date: Wed, 15 Jan 2014 15:40:34 +0500 Subject: [atlas] probe status "abandoned" - "garbage collect" attempt? In-Reply-To: <52D65DC7.3030001@CC.UniVie.ac.at> References: <52D65DC7.3030001@CC.UniVie.ac.at> Message-ID: <01fe01cf11de$3a95a010$afc0e030$@net.pk> On top of that... > as a side-effect of looking at maps and country-related info, I recognised that there's a considerable number of probes in our country which are marked as "abandoned". We may be able to follow up on some of them. Any policy to reclaim such "abandoned" probes and give it to someone willing to have it. Because they are down for considerable time even after regular notifications. Best Wishes, Aftab A. Siddiqui -----Original Message----- From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Wilfried Woeber Sent: Wednesday, January 15, 2014 3:07 PM To: ripe-atlas at ripe.net Subject: [atlas] probe status "abandoned" - "garbage collect" attempt? Dear community, Looking at https://stat.ripe.net/widget/atlas-probes#w.resource=AT and switching to table view, I'm missing the AS# column. Being able to search for "our" ASes would be nice. Thanks, Wilfried PS: a text / table version that can be saved locally and then subjected to a 'grep' would be nice, too. PPS: the sort function by address family is really nice! From mgalante at ripe.net Wed Jan 15 12:00:10 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 15 Jan 2014 12:00:10 +0100 Subject: [atlas] =?iso-8859-1?q?BelW=FC/Universit=E4t_Stuttgart_=28DE=29_h?= =?iso-8859-1?q?as_joined_RIPE_Atlas_anchors?= Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called de-str-as553 and it is hosted by BelW?/Universit?t Stuttgart in Stuttgart, Germany. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From dquinn at ripe.net Wed Jan 15 14:00:24 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 15 Jan 2014 13:00:24 +0000 Subject: [atlas] measurement start_time and stop_time fields In-Reply-To: References: Message-ID: <52D68668.7020609@ripe.net> I think that there might be some confusion here as to the use of the `use_iso_time` and `format` parameters, so I'd like to clear those up now. I've also patched the code to do what you need though, but one thing at a time. The `use_iso_time` flag *only changes the response* to use ISO timestamps rather than UNIX timestamps (the default). Additionally, as UNIX timestamps are the default, setting `use_iso_time=false` does nothing for you here. The `format` parameter is only useful for when you're fetching measurement results and not when you're requesting measurement metadata. The `=txt` stuff is a hack we built on top of standard REST practises in deference to the fact that result datasets can be very big and near impossible to parse as single JSON units. For all of the other calls, the API follows the same path as you'll see with other REST environments: JSON and XML. You can access these formats by using `format=json` and `format=xml` respectively. As for actually filtering your metadata by `start_time` and `stop_time` using UNIX timestamps instead of ISO ones, this was a limitation of the framework we're using. I've since burned a couple hours today overriding the default behaviour to allow for using *either* a UNIX timestamp or an ISO one. Go ahead and give it a spin. Let me know if it works as expected. From Woeber at CC.UniVie.ac.at Wed Jan 15 15:46:12 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 15 Jan 2014 15:46:12 +0100 Subject: [atlas] Firmware versions (anchors) In-Reply-To: <52C542FC.5070305@ripe.net> References: <081E9415D79F9A469A4B6C79815FC0926E3158@SXCHMB01.jacobs.jacobs-university.de> <52B0A082.8040306@ripe.net> <2DD8FC12-9A6F-4311-96A2-D1B07990C65F@jacobs-university.de> <52C542FC.5070305@ripe.net> Message-ID: <52D69F34.1030203@CC.UniVie.ac.at> Robert Kisteleki wrote: [...] given the "lazy" approach :-) > As a general rule, we keep the firmware versions in sync across hardware > revisions in order to have the same capabilities available. The current > situation is a bit of an exception, but that's only because we needed to > deploy a new firmware for one hardware version only; functionally there's > no difference. I just noticed that our (old tech) anchor is still more than one version behind. Is there some sort of schedule to make them load the update eventually, in case they do not disconnect "regularly". Which is sort of expected behaviour for Anchors, imho :-) Wilfried. From robert at ripe.net Wed Jan 15 16:05:04 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 15 Jan 2014 16:05:04 +0100 Subject: [atlas] Firmware versions (anchors) In-Reply-To: <52D69F34.1030203@CC.UniVie.ac.at> References: <081E9415D79F9A469A4B6C79815FC0926E3158@SXCHMB01.jacobs.jacobs-university.de> <52B0A082.8040306@ripe.net> <2DD8FC12-9A6F-4311-96A2-D1B07990C65F@jacobs-university.de> <52C542FC.5070305@ripe.net> <52D69F34.1030203@CC.UniVie.ac.at> Message-ID: <52D6A3A0.8020000@ripe.net> On 2014.01.15. 15:46, Wilfried Woeber wrote: > Robert Kisteleki wrote: > > [...] > > given the "lazy" approach :-) > >> As a general rule, we keep the firmware versions in sync across hardware >> revisions in order to have the same capabilities available. The current >> situation is a bit of an exception, but that's only because we needed to >> deploy a new firmware for one hardware version only; functionally there's >> no difference. > > I just noticed that our (old tech) anchor is still more than one version behind. > > Is there some sort of schedule to make them load the update eventually, in > case they do not disconnect "regularly". Which is sort of expected behaviour > for Anchors, imho :-) > > Wilfried. Yes, good point, we'll be a bit more aggressive with Anchors :-) (And the morhogenetic field seems to be strong today, I hear our engineers have discussed this just this afternoon...) Robert From ax at initrd.net Wed Jan 15 17:23:19 2014 From: ax at initrd.net (Imre Szvorenyi) Date: Wed, 15 Jan 2014 17:23:19 +0100 Subject: [atlas] Atlas credits Message-ID: Hey Guys, Just a small thing I've noticed recently. When I open the 'My Atlas -> Credits' submenu, the number of current credits with big blue numbers are different to (less than) the one that can be seen in the History->Balance lines under it. Please note that I have no running jobs or anything like that. I'm hosting 3 probes, and by the look of the history, my credits are updated after 2. Is this a bug or I just missed something, please? [image: Inline image 1] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: credits_atlas.jpg Type: image/jpeg Size: 90799 bytes Desc: not available URL: From dquinn at ripe.net Wed Jan 15 17:36:43 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 15 Jan 2014 16:36:43 +0000 Subject: [atlas] Atlas credits In-Reply-To: References: Message-ID: <52D6B91B.3080607@ripe.net> Hey thanks for catching this. It was a problem with one of the queries I had in there, but it's fixed now. From Woeber at CC.UniVie.ac.at Wed Jan 15 18:44:01 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 15 Jan 2014 18:44:01 +0100 Subject: [atlas] "funny" comment in pop-up display for a measurement? (v4/v6 addr mismatch) Message-ID: <52D6C8E1.3080906@CC.UniVie.ac.at> Some more digging and some more confusion? Logged in, looking at "My measurements", selecting 1033944, a traceroutev6. Bringing up the Map tab, clicking on the green balloon in Bremen (Probe ID 13255) with the *2* (hops) in it, pop-up comes up. Nice! But the *-comment at the bottom puzzles me, by saying: * The last address does not match the target IP (192.153.174.196) This is sort of obvious, as the address referred to is 2001:6f8:114e:4::1 What's the background for this behaviour? Wilfried From Woeber at CC.UniVie.ac.at Thu Jan 16 10:56:06 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 16 Jan 2014 10:56:06 +0100 Subject: [atlas] UDM display, session expiration Message-ID: <52D7ACB6.7020701@CC.UniVie.ac.at> Just an observation... I started a TR6 connectivity measurement against our Anchor, late in the evening yesterday and had the measurement panel open. Trying to reload today I was left with the "fan" spinning, not showing anything. It turns out, that my session was expired and trying to pull up the summary got me logged-in again. Then the reload for #1410005 also worked again. I am wondering, whether it would be possible to "force" a re-login by hitting the "reload" button on top-right of the measurement display panel? Cheers, Wilfried From robert at ripe.net Thu Jan 16 11:54:04 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 16 Jan 2014 11:54:04 +0100 Subject: [atlas] UDM display, session expiration In-Reply-To: <52D7ACB6.7020701@CC.UniVie.ac.at> References: <52D7ACB6.7020701@CC.UniVie.ac.at> Message-ID: <52D7BA4C.8020005@ripe.net> On 2014.01.16. 10:56, Wilfried Woeber wrote: > Just an observation... > > I started a TR6 connectivity measurement against our Anchor, late in the evening > yesterday and had the measurement panel open. Trying to reload today I was left > with the "fan" spinning, not showing anything. > > It turns out, that my session was expired and trying to pull up the summary > got me logged-in again. Then the reload for #1410005 also worked again. > > I am wondering, whether it would be possible to "force" a re-login by hitting > the "reload" button on top-right of the measurement display panel? > > Cheers, > Wilfried Wilfried, This can come as a by-product of us reviewing the layout of measurement list + details, which comes after the same thing for probes, which in turn will be released soon. So there's a solution in the pipeline already! Regards, Robert From philip.homburg at ripe.net Thu Jan 16 13:10:07 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 16 Jan 2014 13:10:07 +0100 Subject: [atlas] "funny" comment in pop-up display for a measurement? (v4/v6 addr mismatch) In-Reply-To: <52D6C8E1.3080906@CC.UniVie.ac.at> References: <52D6C8E1.3080906@CC.UniVie.ac.at> Message-ID: <52D7CC1F.9010004@ripe.net> Hi Wilfried, On 2014/01/15 18:44 , Wilfried Woeber wrote: > Some more digging and some more confusion? > > Logged in, looking at "My measurements", selecting 1033944, a traceroutev6. > Bringing up the Map tab, clicking on the green balloon in Bremen (Probe ID > 13255) with the *2* (hops) in it, pop-up comes up. Nice! > > But the *-comment at the bottom puzzles me, by saying: > > * The last address does not match the target IP (192.153.174.196) > > This is sort of obvious, as the address referred to is 2001:6f8:114e:4::1 > What's the background for this behaviour? The target of your measurement, wsww2.cc.univie.ac.at, has, as far as I can tell, only an IPv4 address. So an IPv6 measurement should fail. And in fact most probes reported: "result":[{"error":"name resolution failed: non-recoverable failure in name resolution"}] One question that comes up is how you were able to run this measurement in the first place. Because the system usually doesn't allow running measurement towards targets that don't have an address for the selected address family. This also why the UI complains about 192.153.174.196, because that is the IPv4 address of wsww2.cc.univie.ac.at. There were 3 probes where name resolution resulted in an IPv6 address. 2 of them have since changed their behavior and no longer resolve to an IPv6 address. One probe, 13255, is rather curious, because it resolved wsww2.cc.univie.ac.at to 2001:6f8:114e:3::c099:aec4, which is interesting because c099:aec4 is exactly equal to the IPv4 address of wsww2.cc.univie.ac.at. So I suspect that this probe is behind a resolver that does DNS64. Philip From Woeber at CC.UniVie.ac.at Thu Jan 16 13:18:02 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 16 Jan 2014 13:18:02 +0100 Subject: [atlas] "funny" comment in pop-up display for a measurement? (v4/v6 addr mismatch) In-Reply-To: <52D7CC1F.9010004@ripe.net> References: <52D6C8E1.3080906@CC.UniVie.ac.at> <52D7CC1F.9010004@ripe.net> Message-ID: <52D7CDFA.9060007@CC.UniVie.ac.at> Hi Philip thanks for the feedback! This was a very complex way to find out that I'm having a DNS (v6) config issue on my end. Sorry for the noise! Wilfried Philip Homburg wrote: > Hi Wilfried, > > On 2014/01/15 18:44 , Wilfried Woeber wrote: > >>Some more digging and some more confusion? >> >>Logged in, looking at "My measurements", selecting 1033944, a traceroutev6. >>Bringing up the Map tab, clicking on the green balloon in Bremen (Probe ID >>13255) with the *2* (hops) in it, pop-up comes up. Nice! >> >>But the *-comment at the bottom puzzles me, by saying: >> >>* The last address does not match the target IP (192.153.174.196) >> >>This is sort of obvious, as the address referred to is 2001:6f8:114e:4::1 >>What's the background for this behaviour? > > > The target of your measurement, wsww2.cc.univie.ac.at, has, as far as I > can tell, only an IPv4 address. So an IPv6 measurement should fail. And > in fact most probes reported: > > "result":[{"error":"name resolution failed: non-recoverable failure in > name resolution"}] > > One question that comes up is how you were able to run this measurement > in the first place. Because the system usually doesn't allow running > measurement towards targets that don't have an address for the selected > address family. > > This also why the UI complains about 192.153.174.196, because that is > the IPv4 address of wsww2.cc.univie.ac.at. > > There were 3 probes where name resolution resulted in an IPv6 address. 2 > of them have since changed their behavior and no longer resolve to an > IPv6 address. > > One probe, 13255, is rather curious, because it resolved > wsww2.cc.univie.ac.at to 2001:6f8:114e:3::c099:aec4, which is > interesting because c099:aec4 is exactly equal to the IPv4 address of > wsww2.cc.univie.ac.at. So I suspect that this probe is behind a resolver > that does DNS64. > > Philip > > From mgalante at ripe.net Thu Jan 16 14:25:04 2014 From: mgalante at ripe.net (Michela Galante) Date: Thu, 16 Jan 2014 14:25:04 +0100 Subject: [atlas] FICIX (FI) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called fi-hel-as3292 and it is hosted by FICIX in Helsinki, Finland on behalf of RIPE NCC since they are one of our K-root hosts. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From carsten at schiefner.de Thu Jan 16 15:11:23 2014 From: carsten at schiefner.de (Carsten Schiefner) Date: Thu, 16 Jan 2014 15:11:23 +0100 Subject: [atlas] "funny" comment in pop-up display for a measurement? (v4/v6 addr mismatch) In-Reply-To: <52D7CDFA.9060007@CC.UniVie.ac.at> References: <52D6C8E1.3080906@CC.UniVie.ac.at> <52D7CC1F.9010004@ripe.net> <52D7CDFA.9060007@CC.UniVie.ac.at> Message-ID: <52D7E88B.9070909@schiefner.de> Hi Wilfried, On 16.01.2014 13:18, Wilfried Woeber wrote: > [...] > > This was a very complex way to find out that I'm having a DNS (v6) config > issue on my end. isn't debugging one's own end also an ATLAS goal? ;-) Best, -C. From philip.homburg at ripe.net Thu Jan 16 15:35:23 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 16 Jan 2014 15:35:23 +0100 Subject: [atlas] "funny" comment in pop-up display for a measurement? (v4/v6 addr mismatch) In-Reply-To: <52D7CDFA.9060007@CC.UniVie.ac.at> References: <52D6C8E1.3080906@CC.UniVie.ac.at> <52D7CC1F.9010004@ripe.net> <52D7CDFA.9060007@CC.UniVie.ac.at> Message-ID: <52D7EE2B.4050103@ripe.net> On 2014/01/16 13:18 , Wilfried Woeber wrote: > This was a very complex way to find out that I'm having a DNS (v6) config > issue on my end. Well, the measurement was supposed to tell you that right away. But somehow we forgot to actually check for IPv6 addresses in this variation ('IPv6 Connectivity Test'). Philip From christian.teuschel at ripe.net Thu Jan 16 16:50:11 2014 From: christian.teuschel at ripe.net (Christian Teuschel) Date: Thu, 16 Jan 2014 16:50:11 +0100 Subject: [atlas] probe status "abandoned" - "garbage collect" attempt? In-Reply-To: <52D66094.5030705@ripe.net> References: <52D65DC7.3030001@CC.UniVie.ac.at> <52D66094.5030705@ripe.net> Message-ID: <52D7FFB3.3090604@ripe.net> Hi Wilfried, The missing ASN column is added, v4 and v6. As well as the two bugs in the fullscreen mode are fixed. Additionally the listed resources are now clickable. Schoene Gruesze, Christian On 15/01/14 11:19, Robert Kisteleki wrote: > On 2014.01.15. 11:07, Wilfried Woeber wrote: >> Dear community, >> >> as a side-effect of looking at maps and country-related info, I recognised >> that there's a considerable number of probes in our country which are marked >> as "abandoned". We may be able to follow up on some of them. >> >> Looking at https://stat.ripe.net/widget/atlas-probes#w.resource=AT and switching >> to table view, I'm missing the AS# column. Being able to search for "our" ASes >> would be nice. >> >> Thanks, >> Wilfried >> >> PS: a text / table version that can be saved locally and then subjected to >> a 'grep' would be nice, too. >> PPS: the sort function by address family is really nice! > > Hello Wilfried, > > Of course adin another column would not be a problem. In the meantime, you > can get to the data used to make the map with two click (bottom left, > "source data") -- this has all the information you need. > > https://stat.ripe.net/data/atlas-probes/data.json?resource=AT > > Regards, > Robert > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: christian_teuschel.vcf Type: text/x-vcard Size: 342 bytes Desc: not available URL: From Woeber at CC.UniVie.ac.at Thu Jan 16 22:18:00 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 16 Jan 2014 22:18:00 +0100 Subject: [atlas] probe status "abandoned" - "garbage collect" attempt? In-Reply-To: <52D7FFB3.3090604@ripe.net> References: <52D65DC7.3030001@CC.UniVie.ac.at> <52D66094.5030705@ripe.net> <52D7FFB3.3090604@ripe.net> Message-ID: <52D84C88.4020007@CC.UniVie.ac.at> Hi Christian, thanks a truckload :-) Servus, Wilfried. Christian Teuschel wrote: > Hi Wilfried, > > The missing ASN column is added, v4 and v6. As well as the two bugs in > the fullscreen mode are fixed. Additionally the listed resources are now > clickable. > > Schoene Gruesze, > Christian > > On 15/01/14 11:19, Robert Kisteleki wrote: > >> On 2014.01.15. 11:07, Wilfried Woeber wrote: >> >>> Dear community, >>> >>> as a side-effect of looking at maps and country-related info, I >>> recognised >>> that there's a considerable number of probes in our country which are >>> marked >>> as "abandoned". We may be able to follow up on some of them. >>> >>> Looking at https://stat.ripe.net/widget/atlas-probes#w.resource=AT >>> and switching >>> to table view, I'm missing the AS# column. Being able to search for >>> "our" ASes >>> would be nice. >>> >>> Thanks, >>> Wilfried >>> >>> PS: a text / table version that can be saved locally and then >>> subjected to >>> a 'grep' would be nice, too. >>> PPS: the sort function by address family is really nice! >> >> >> Hello Wilfried, >> >> Of course adin another column would not be a problem. In the meantime, >> you >> can get to the data used to make the map with two click (bottom left, >> "source data") -- this has all the information you need. >> >> https://stat.ripe.net/data/atlas-probes/data.json?resource=AT >> >> Regards, >> Robert >> >> >> From calderm at usc.edu Fri Jan 17 01:19:31 2014 From: calderm at usc.edu (Matt Calder) Date: Thu, 16 Jan 2014 16:19:31 -0800 Subject: [atlas] measurement start_time and stop_time fields In-Reply-To: <52D68668.7020609@ripe.net> References: <52D68668.7020609@ripe.net> Message-ID: Hi Daniel, Thank you for the clarification regarding the use_iso_time and format parameters. I tested out the metadata UNIX timestamp filtering and everything looks good to me. Very nice of you to implement that so quickly! Cheers, Matt On Wed, Jan 15, 2014 at 5:00 AM, Daniel Quinn wrote: > I think that there might be some confusion here as to the use of the > `use_iso_time` and `format` parameters, so I'd like to clear those up > now. I've also patched the code to do what you need though, but one > thing at a time. > > The `use_iso_time` flag *only changes the response* to use ISO > timestamps rather than UNIX timestamps (the default). Additionally, as > UNIX timestamps are the default, setting `use_iso_time=false` does > nothing for you here. > > The `format` parameter is only useful for when you're fetching > measurement results and not when you're requesting measurement > metadata. The `=txt` stuff is a hack we built on top of standard REST > practises in deference to the fact that result datasets can be very big > and near impossible to parse as single JSON units. For all of the > other calls, the API follows the same path as you'll see with other > REST environments: JSON and XML. You can access these formats by using > `format=json` and `format=xml` respectively. > > As for actually filtering your metadata by `start_time` and `stop_time` > using UNIX timestamps instead of ISO ones, this was a limitation of the > framework we're using. I've since burned a couple hours today > overriding the default behaviour to allow for using *either* a UNIX > timestamp or an ISO one. Go ahead and give it a spin. Let me know if > it works as expected. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgalante at ripe.net Tue Jan 21 14:21:12 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 21 Jan 2014 14:21:12 +0100 Subject: [atlas] Aivivid (SE) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called se-sto-as59521 and it is hosted by Aivivid in Stockholm, Sweden. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From mgalante at ripe.net Mon Jan 27 13:27:14 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 27 Jan 2014 13:27:14 +0100 Subject: [atlas] Rezopole/LyonIX (FR) has joined RIPE Atlas anchors Message-ID: <179BA85C-2C23-4968-A5DD-FDD20CD67D5C@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called fr-vbn-as199422 and it is hosted by Rezopole/LyonIX in Lyon, France. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From brak at gameservers.com Mon Jan 27 23:45:57 2014 From: brak at gameservers.com (Brian Rak) Date: Mon, 27 Jan 2014 17:45:57 -0500 Subject: [atlas] Linking to measurements? Message-ID: <52E6E1A5.2020304@gameservers.com> Is there any real way to send someone a link to a measurement? I've figured out how to send them links to individual RRD detail pages (https://udm01.atlas.ripe.net/atlas/udm_graph_history.html), but not a link to the overall public measurement. The UI is all AJAXy, so I haven't seen any obvious places to pull a link out of. From robert at ripe.net Tue Jan 28 09:11:43 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 28 Jan 2014 09:11:43 +0100 Subject: [atlas] Linking to measurements? In-Reply-To: <52E6E1A5.2020304@gameservers.com> References: <52E6E1A5.2020304@gameservers.com> Message-ID: <52E7663F.7070202@ripe.net> On 2014.01.27. 23:45, Brian Rak wrote: > Is there any real way to send someone a link to a measurement? I've figured > out how to send them links to individual RRD detail pages > (https://udm01.atlas.ripe.net/atlas/udm_graph_history.html), but not a link > to the overall public measurement. The UI is all AJAXy, so I haven't seen > any obvious places to pull a link out of. Hello, This probably helps: https://atlas.ripe.net/atlas/udm.html?msm_id=1000192 Regards, Robert From inigo at infornografia.net Tue Jan 28 10:20:49 2014 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Tue, 28 Jan 2014 10:20:49 +0100 Subject: [atlas] Linking to measurements? In-Reply-To: <52E6E1A5.2020304@gameservers.com> References: <52E6E1A5.2020304@gameservers.com> Message-ID: Hi Brian, On Mon, Jan 27, 2014 at 11:45 PM, Brian Rak wrote: > Is there any real way to send someone a link to a measurement? I've figured > out how to send them links to individual RRD detail pages > (https://udm01.atlas.ripe.net/atlas/udm_graph_history.html), but not a link > to the overall public measurement. The UI is all AJAXy, so I haven't seen > any obvious places to pull a link out of. > You might want to look at the RIPE Atlas API keys. Quoting the documentation [1]: " The two main reasons for using API keys are that they: Make it simpler to write scripts that use Atlas data, and Allow you to easily and securely share data with other people " Hope that helps. Cheers, I?igo Ortiz de Urbina Cazenave [1] https://atlas.ripe.net/docs/keys/ -- "If you want to go fast, go alone. If you want to go far, go together." From mgalante at ripe.net Tue Jan 28 11:31:51 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 28 Jan 2014 11:31:51 +0100 Subject: [atlas] BIX (HU) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called hu-bud-as12303 and it is hosted by BIX in Budapest, Hungary on behalf of RIPE NCC since they are one of our K-root hosts. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From brak at gameservers.com Tue Jan 28 14:45:31 2014 From: brak at gameservers.com (Brian Rak) Date: Tue, 28 Jan 2014 08:45:31 -0500 Subject: [atlas] Linking to measurements? In-Reply-To: <52E7663F.7070202@ripe.net> References: <52E6E1A5.2020304@gameservers.com> <52E7663F.7070202@ripe.net> Message-ID: <52E7B47B.8020105@gameservers.com> On 1/28/2014 3:11 AM, Robert Kisteleki wrote: > On 2014.01.27. 23:45, Brian Rak wrote: >> Is there any real way to send someone a link to a measurement? I've figured >> out how to send them links to individual RRD detail pages >> (https://udm01.atlas.ripe.net/atlas/udm_graph_history.html), but not a link >> to the overall public measurement. The UI is all AJAXy, so I haven't seen >> any obvious places to pull a link out of. > Hello, > > This probably helps: https://atlas.ripe.net/atlas/udm.html?msm_id=1000192 That's exactly what I was looking for, thanks! The API would be nice to use, but it's a lot of extra setup for what's currently a one-off measurement. From mgalante at ripe.net Wed Jan 29 16:34:55 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 29 Jan 2014 16:34:55 +0100 Subject: [atlas] New on RIPE Labs: Increased Reach of RIPE Atlas anchors Message-ID: <78E4B6BD-D8AA-4731-A2BB-B4FB1BE55CE6@ripe.net> Dear colleagues, Please take a look at the latest features and the new plans for RIPE Atlas anchors in the RIPE Labs article published today, "Increased Reach of RIPE Atlas anchors": https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-anchors-january-2014-update If you wish to apply for an anchor, the requirements and other useful information are available online at: https://atlas.ripe.net/get-involved/become-an-anchor-host/ Kind regards, Michela Galante Measurements Community Building RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: