From robert at ripe.net Mon Apr 2 09:45:55 2012 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 02 Apr 2012 09:45:55 +0200 Subject: [atlas] change ownership of probe In-Reply-To: References: Message-ID: <4F795933.2020704@ripe.net> On 2012.03.29. 21:45, Thanos Tsakalos wrote: > Hello to all, > > Is there a way to change the ownership of a probe? > > Will it be ok if the probe is re-registered under the new email address (mac > and pin are known) ? > > Or is there any other method to do it properly? > > Thank you, > > Triantafyllos Hello, Yes, it is possible to change the host of a probe, though it doesn't happen often. At the moment the simplest way of doing it is to write a mail to us to atlas at ripe.net and mention which probe it is and to whom it should be transferred to. Regards, Robert From atlas at ripe.net Mon Apr 2 10:18:13 2012 From: atlas at ripe.net (Alastair Strachan) Date: Mon, 2 Apr 2012 10:18:13 +0200 Subject: [atlas] [ripe.net #1047054] Re: Probe 2317 is down In-Reply-To: References: <20120331073002.27416.85460@Debian-50-lenny-64-minimal> Message-ID: Hello Colin, Thanks for your email. I will be happy to pass your feed back to our development team to see if this an enhancement that can be made. I can confirm the probe is online and reporting correctly. If you do have any further questions, please do not hesitate to contact us. Thank you for taking the time to host an Atlas probe. Kind Regards, Alastair RIPE Atlas Team ========================================================= === RIPE NCC Customer Satisfaction Survey ************************************* Tell us about your customer services experience by filling out the anonymous, three-question RIPE NCC customer satisfaction survey: https://www.ripe.net/contact/survey/satisfaction-cs/ ========================================================= ==== On Sat Mar 31 10:05:31 2012, colinj at mx5.org.uk wrote: > fixed internal network :) > > Can a request for enhancement be made for notification of probe goes > up to the owner email ? > > Colin > > On 31 Mar 2012, at 08:30, RIPE Atlas wrote: > > > Dear colin, > > > > Your probe 2317 is down since 2012-03-31 06:56:49 UTC > > > > This is an automatically generated email from RIPE Atlas. It was > sent to you because you asked to be notified if your probe goes is > down for more than 30 minutes. > > > > If you want to change this, or disable this notification altogether, > please go to https://atlas.ripe.net/atlas/myprobes.html, click on > probe 2317, in the opened tab select Probe's Settings -> > Notifications and change your settings. > > > > Atlas team > > From abarcomb at ripe.net Tue Apr 3 15:08:24 2012 From: abarcomb at ripe.net (Ann Barcomb) Date: Tue, 03 Apr 2012 15:08:24 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7AF0F1.10308@ripe.net> References: <4F7AF0F1.10308@ripe.net> Message-ID: <4F7AF648.1080506@ripe.net> Dear Atlas Hosts and Sponsors, We are pleased to announce our first roll-out of user-defined measurements (UDM) for RIPE Atlas. As of today, all hosts and sponsors on this mailing list are invited to run custom measurements. Over the coming weeks we will continue to roll out UDM to a wider audience. To access UDM, either click on the link at the top right when you are logged in to the RIPE Atlas website, or go directly to: https://atlas.ripe.net/atlas/udm.html For the time being, we have created a fairly low rate limit, which we expect to increase over time. More information about limits and other aspects of the UDM system can be found in the documentation: https://atlas.ripe.net/doc/udm Discussion and questions about UDM can be directed to this mailing list (ripe-atlas at ripe.net) or to atlas-dev at ripe.net. You may also be interested in joining us at the UDM "Birds of a Feather" (BoF) session at RIPE 64 in Ljubljana, on Thursday, 19 April after the Measurements, Analysis and Tools (MAT) Working Group session. https://ripe64.ripe.net/programme/meeting-plan/bof/ Happy measuring! - The RIPE Atlas team From marco.davids at sidn.nl Tue Apr 3 15:40:00 2012 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Tue, 3 Apr 2012 15:40:00 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7AF648.1080506@ripe.net> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> Message-ID: <4F7AFDB0.4050904@sidn.nl> On 04/03/12 15:08, Ann Barcomb wrote: > We are pleased to announce our first roll-out of user-defined > measurements (UDM) for RIPE Atlas. Cool! Wishlist: To be able to schedule DNS queries. -- Marco From tore.anderson at redpill-linpro.com Tue Apr 3 16:06:56 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 03 Apr 2012 16:06:56 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7AF648.1080506@ripe.net> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> Message-ID: <4F7B0400.3020900@redpill-linpro.com> * Ann Barcomb > We are pleased to announce our first roll-out of user-defined > measurements (UDM) for RIPE Atlas. As of today, all hosts and sponsors > on this mailing list are invited to run custom measurements. Over the > coming weeks we will continue to roll out UDM to a wider audience. Way cool! Some bugs/issues I noticed: 1) I first entered a traceroute UDM to olapaok.gr (ID 1001613). It got the description ?Traceroute to 87.238.36.36(olapaok.gr)?. The I entered a traceroute6 query to www.vg.no (ID 1001615). However, for some reason it ended up getting the same description as the first one. 2) One of the probes selected by the traceroute6 measurement (ID 863) does not have any IPv6 connectivity, if the info popup in the ?Participants for UDM: 1001615? map is to be believed. 3) We host two probes with near-100% uptime. If I understand the documentation correctly, you get 15 credits per minute of uptime per probe, which should result in an daily income of ~42000 credits. However, the daily income is consistently ~14398. (Not that it is a problem, considering the current usage cap of 15000 credits/day.) 4) It's been half an hour since I submitted the measurements but still no results (scheduled them as ASAP). It would be nice if results started coming back a bit quicker - especially if I'm submitting a UDM for the purpose of debugging some ongoing connectivity problem. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From tore.anderson at redpill-linpro.com Tue Apr 3 16:26:33 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 03 Apr 2012 16:26:33 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7B0400.3020900@redpill-linpro.com> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> Message-ID: <4F7B0899.6030605@redpill-linpro.com> * Tore Anderson > Way cool! > > Some bugs/issues I noticed: And now that some results came back in for ID 1001613, I see another issue - the test result is presented as a single line, with the word ?NEWLINE? appearing where you would expect there to be, well, an actual newline. There's also no way for me to scroll the browser frame horizontally in order to get to the end of the result, so I need to download the JSON file in order to view the full result. Also, the result suggests to me that UDP traceroute is being used. In my opinion, ICMP echo-request or even TCP/80 traceroutes are more useful these days, as they are more likely to reach their destination. Being able to select which type of packets are being used for tracerouting would be a nice feature to have. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From vnaumov at ripe.net Tue Apr 3 16:49:51 2012 From: vnaumov at ripe.net (Viktor Naumov) Date: Tue, 03 Apr 2012 16:49:51 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7B0899.6030605@redpill-linpro.com> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B0899.6030605@redpill-linpro.com> Message-ID: <4F7B0E0F.2010409@ripe.net> Hi Tore, On 4/3/12 4:26 PM, Tore Anderson wrote: > And now that some results came back in for ID 1001613, I see another > issue - the test result is presented as a single line, with the word > ?NEWLINE? appearing where you would expect there to be, well, an actual > newline. There's also no way for me to scroll the browser frame > horizontally in order to get to the end of the result, so I need to > download the JSON file in order to view the full result. Horizontal scrolling is enabled now. WBR viktor naumov From philip.homburg at ripe.net Tue Apr 3 16:54:25 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 03 Apr 2012 16:54:25 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7B0899.6030605@redpill-linpro.com> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B0899.6030605@redpill-linpro.com> Message-ID: <4F7B0F21.50909@ripe.net> On 4/3/12 16:26 , Tore Anderson wrote: > Also, the result suggests to me that UDP traceroute is being used. In > my opinion, ICMP echo-request or even TCP/80 traceroutes are more > useful these days, as they are more likely to reach their destination. > Being able to select which type of packets are being used for > tracerouting would be a nice feature to have. Best regards, ICMP-based traceroutes are on the way. It may take a while because it requires upgrading the probes' firmware. At the moment we don't have traceroutes based on TCP. From astrikos at ripe.net Tue Apr 3 16:58:45 2012 From: astrikos at ripe.net (Andreas Strikos) Date: Tue, 03 Apr 2012 16:58:45 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7B0400.3020900@redpill-linpro.com> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> Message-ID: <4F7B1025.1060500@ripe.net> Hi Tore, thanks for your fast feedback! See inline for answers. On 4/3/12 4:06 PM, Tore Anderson wrote: > * Ann Barcomb > >> We are pleased to announce our first roll-out of user-defined >> measurements (UDM) for RIPE Atlas. As of today, all hosts and sponsors >> on this mailing list are invited to run custom measurements. Over the >> coming weeks we will continue to roll out UDM to a wider audience. > Way cool! > > Some bugs/issues I noticed: > > 1) I first entered a traceroute UDM to olapaok.gr (ID 1001613). It got > the description ?Traceroute to 87.238.36.36(olapaok.gr)?. The I entered > a traceroute6 query to www.vg.no (ID 1001615). However, for some reason > it ended up getting the same description as the first one. Yes, if you had opened the form before some fields are cached and if you don't change them they will remain as they were before. We could try to change it if people don't want it at all. > 2) One of the probes selected by the traceroute6 measurement (ID 863) > does not have any IPv6 connectivity, if the info popup in the > ?Participants for UDM: 1001615? map is to be believed. This is a case where a probe for some reason has a v6 address but it not routed. Currently, if a probe has a v6 address we consider it as v6 enable. In the future we could be smarter and filter out these kind of cases. > 3) We host two probes with near-100% uptime. If I understand the > documentation correctly, you get 15 credits per minute of uptime per > probe, which should result in an daily income of ~42000 credits. > However, the daily income is consistently ~14398. (Not that it is a > problem, considering the current usage cap of 15000 credits/day.) This changed today, from tomorrow on all of you will get the credits that specified in documentation. > > 4) It's been half an hour since I submitted the measurements but still > no results (scheduled them as ASAP). It would be nice if results started > coming back a bit quicker - especially if I'm submitting a UDM for the > purpose of debugging some ongoing connectivity problem. We are aware of this. It's already in our to-do list. For now, you can specify smaller frequency of you measurement so you will get it a bit earlier. > > Best regards, Regards, Andreas From tore.anderson at redpill-linpro.com Tue Apr 3 22:35:46 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 03 Apr 2012 22:35:46 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7B1025.1060500@ripe.net> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> Message-ID: <4F7B5F22.8090603@redpill-linpro.com> * Andreas Strikos > On 4/3/12 4:06 PM, Tore Anderson wrote: >> 1) I first entered a traceroute UDM to olapaok.gr (ID 1001613). It got >> the description ?Traceroute to 87.238.36.36(olapaok.gr)?. The I entered >> a traceroute6 query to www.vg.no (ID 1001615). However, for some reason >> it ended up getting the same description as the first one. > Yes, if you had opened the form before some fields are cached and if you > don't change them they will remain as they were before. The UDM description appears to be generated by the system. There is, as far as I can can tell, nowhere I can set a custom description when creating the UDM, nor can I change it after the UDM has been created. >> 4) It's been half an hour since I submitted the measurements but still >> no results (scheduled them as ASAP). It would be nice if results started >> coming back a bit quicker - especially if I'm submitting a UDM for the >> purpose of debugging some ongoing connectivity problem. > We are aware of this. It's already in our to-do list. For now, you can > specify smaller frequency of you measurement so you will get it a bit > earlier. Another thing I came to think of here is that it would be nice with the possibility to do a one-off measurement. I tried playing around with setting the End field to the past or immediately in the future, and the Interval really low, but it wouldn't let me add it because it incorrectly calculates that it would cost too many credits - it appears to be rounding up the duration of the UDM to 24 hours, I think. Also, it would be nice with a facility to search for probes, at least by ASN and country, so that you can find the perfect probe(s) to run a UDM from when debugging a specific problem. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From olaf.maunz at me.com Tue Apr 3 23:22:39 2012 From: olaf.maunz at me.com (Olaf Maunz) Date: Tue, 03 Apr 2012 22:22:39 +0100 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7B5F22.8090603@redpill-linpro.com> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> <4F7B5F22.8090603@redpill-linpro.com> Message-ID: The new UDM is perfect. Thank you for that. I just would like to know if there is any security in place or planed to prevent the probe from connecting to sites that could bring me into trouble. Where I live this would only concern illegal sites/servers, but as we all know access to political sites are monitored in other countries by the government(e.g China). Olaf On 3 Apr 2012, at 21:35, Tore Anderson wrote: > * Andreas Strikos > >> On 4/3/12 4:06 PM, Tore Anderson wrote: >>> 1) I first entered a traceroute UDM to olapaok.gr (ID 1001613). It got >>> the description ?Traceroute to 87.238.36.36(olapaok.gr)?. The I entered >>> a traceroute6 query to www.vg.no (ID 1001615). However, for some reason >>> it ended up getting the same description as the first one. >> Yes, if you had opened the form before some fields are cached and if you >> don't change them they will remain as they were before. > > The UDM description appears to be generated by the system. There is, as > far as I can can tell, nowhere I can set a custom description when > creating the UDM, nor can I change it after the UDM has been created. > >>> 4) It's been half an hour since I submitted the measurements but still >>> no results (scheduled them as ASAP). It would be nice if results started >>> coming back a bit quicker - especially if I'm submitting a UDM for the >>> purpose of debugging some ongoing connectivity problem. >> We are aware of this. It's already in our to-do list. For now, you can >> specify smaller frequency of you measurement so you will get it a bit >> earlier. > > Another thing I came to think of here is that it would be nice with the > possibility to do a one-off measurement. I tried playing around with > setting the End field to the past or immediately in the future, and the > Interval really low, but it wouldn't let me add it because it > incorrectly calculates that it would cost too many credits - it appears > to be rounding up the duration of the UDM to 24 hours, I think. > > Also, it would be nice with a facility to search for probes, at least by > ASN and country, so that you can find the perfect probe(s) to run a UDM > from when debugging a specific problem. > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3668 bytes Desc: not available URL: From damkol at gmail.com Wed Apr 4 07:13:34 2012 From: damkol at gmail.com (damkol at gmail.com) Date: Wed, 4 Apr 2012 07:13:34 +0200 Subject: [atlas] labs.ripe.net dead? Message-ID: Hello. 29.03.2012 labs.ripe.net stopped respond to icmp. https://zpm02.atlas.ripe.net/atlas/rrd.png?prb_id=741&msm_id=1007&type=weekly&end=last >From other places with other internet connections also not respond to icmp. -- damkol at gmail.com From tore.anderson at redpill-linpro.com Wed Apr 4 08:31:38 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 04 Apr 2012 08:31:38 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> <4F7B5F22.8090603@redpill-linpro.com> Message-ID: <4F7BEACA.5040601@redpill-linpro.com> * Olaf Maunz > I just would like to know if there is any security in place or planed > to prevent the probe from connecting to sites that could bring me > into trouble. Where I live this would only concern illegal > sites/servers, but as we all know access to political sites are > monitored in other countries by the government(e.g China). As far as I can tell, TCP-based UDMs are currently not supported, so it is impossible to add a UDM that makes connections anywhere. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From inigo at infornografia.net Wed Apr 4 08:33:04 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Wed, 4 Apr 2012 08:33:04 +0200 Subject: [atlas] labs.ripe.net dead? In-Reply-To: References: Message-ID: Damkol, The website is perfecty working for me. Pings stoped working, though, on 29th. All my probes see the exact same pattern. Before 29th, labs.ripe.net was recording higher packet loss than other destinations (from my networks) due to ICMP rate limiting somewhere near the actual server(s). Robert Kisteleki pointed this out earlier on the list, you can find his comments on the archive. Have a nice day, El 04/04/2012 07:20, "damkol at gmail.com" escribi?: > Hello. > 29.03.2012 labs.ripe.net stopped respond to icmp. > > https://zpm02.atlas.ripe.net/atlas/rrd.png?prb_id=741&msm_id=1007&type=weekly&end=last > >From other places with other internet connections also not respond to > icmp. > > > -- > damkol at gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed Apr 4 08:50:26 2012 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 04 Apr 2012 08:50:26 +0200 Subject: [atlas] labs.ripe.net dead? In-Reply-To: References: Message-ID: <4F7BEF32.80407@ripe.net> Hi, Indeed, the Labs site is fine, but it has ICMP filtering in front of it. We'll remove this as a built-in measurement as it's not useful -- and can be deceiving. Regards, Robert On 2012.04.04. 8:33, I?igo Ortiz de Urbina wrote: > Damkol, > > The website is perfecty working for me. Pings stoped working, though, on > 29th. All my probes see the exact same pattern. > > Before 29th, labs.ripe.net was recording higher > packet loss than other destinations (from my networks) due to ICMP rate > limiting somewhere near the actual server(s). Robert Kisteleki pointed this > out earlier on the list, you can find his comments on the archive. > > Have a nice day, > > El 04/04/2012 07:20, "damkol at gmail.com " > > escribi?: > > Hello. > 29.03.2012 labs.ripe.net stopped respond to icmp. > https://zpm02.atlas.ripe.net/atlas/rrd.png?prb_id=741&msm_id=1007&type=weekly&end=last > > >From other places with other internet connections also not respond to icmp. > > > -- > damkol at gmail.com > From robert at ripe.net Wed Apr 4 08:54:05 2012 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 04 Apr 2012 08:54:05 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> <4F7B5F22.8090603@redpill-linpro.com> Message-ID: <4F7BF00D.5030908@ripe.net> On 2012.04.03. 23:22, Olaf Maunz wrote: > The new UDM is perfect. Thank you for that. > I just would like to know if there is any security in place or planed to prevent the probe from connecting to sites that could bring me into trouble. > Where I live this would only concern illegal sites/servers, but as we all know access to political sites are monitored in other countries by the government(e.g China). > > Olaf Hello, This makes me wonder if it would be useful to allow probe hosts to specify some kind of disclaimer for their probes? It would only make sense for public probes though. Another thing we have on our long-term todo list is to allow hosts to opt out from some measurement types / targets, so that the scheduler could take this into account when looking for vantage points for a UDM. I cannot give an ETA for this though. Regards, Robert From robert at ripe.net Wed Apr 4 08:55:22 2012 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 04 Apr 2012 08:55:22 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7AFDB0.4050904@sidn.nl> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7AFDB0.4050904@sidn.nl> Message-ID: <4F7BF05A.1060208@ripe.net> On 2012.04.03. 15:40, Marco Davids (SIDN) wrote: > On 04/03/12 15:08, Ann Barcomb wrote: > >> We are pleased to announce our first roll-out of user-defined >> measurements (UDM) for RIPE Atlas. > > Cool! > > Wishlist: > > To be able to schedule DNS queries. Rest assured, this is very high on our priority list! :-) Regards, Robert From astrikos at ripe.net Wed Apr 4 09:17:48 2012 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 04 Apr 2012 09:17:48 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7B5F22.8090603@redpill-linpro.com> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> <4F7B5F22.8090603@redpill-linpro.com> Message-ID: <4F7BF59C.7010705@ripe.net> On 4/3/12 10:35 PM, Tore Anderson wrote: > * Andreas Strikos > >> On 4/3/12 4:06 PM, Tore Anderson wrote: >>> 1) I first entered a traceroute UDM to olapaok.gr (ID 1001613). It got >>> the description ?Traceroute to 87.238.36.36(olapaok.gr)?. The I entered >>> a traceroute6 query to www.vg.no (ID 1001615). However, for some reason >>> it ended up getting the same description as the first one. >> Yes, if you had opened the form before some fields are cached and if you >> don't change them they will remain as they were before. > The UDM description appears to be generated by the system. There is, as > far as I can can tell, nowhere I can set a custom description when > creating the UDM, nor can I change it after the UDM has been created. > There is a last box in the form that allows you to edit and write your own description. Maybe is hidden because the form is too small for you. Try to maximize the UDM form and you will see it. >>> 4) It's been half an hour since I submitted the measurements but still >>> no results (scheduled them as ASAP). It would be nice if results started >>> coming back a bit quicker - especially if I'm submitting a UDM for the >>> purpose of debugging some ongoing connectivity problem. >> We are aware of this. It's already in our to-do list. For now, you can >> specify smaller frequency of you measurement so you will get it a bit >> earlier. > Another thing I came to think of here is that it would be nice with the > possibility to do a one-off measurement. I tried playing around with > setting the End field to the past or immediately in the future, and the > Interval really low, but it wouldn't let me add it because it > incorrectly calculates that it would cost too many credits - it appears > to be rounding up the duration of the UDM to 24 hours, I think. This is asked by several of you so we are already working on it. It should be out soon. > Also, it would be nice with a facility to search for probes, at least by > ASN and country, so that you can find the perfect probe(s) to run a UDM > from when debugging a specific problem. These pages might help you with this until we give a search option. https://atlas.ripe.net/contrib/coverage.html https://atlas.ripe.net/atlas/prb_coverage.html?asn_v6=[as number] Same logic for asn_v4,prefix_v4, prefix_v6, country But it's a good idea, it's worth implementing at some point. > > Best regards, Regards, Andreas From tore.anderson at redpill-linpro.com Wed Apr 4 10:02:53 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 04 Apr 2012 10:02:53 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7BF59C.7010705@ripe.net> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> <4F7B5F22.8090603@redpill-linpro.com> <4F7BF59C.7010705@ripe.net> Message-ID: <4F7C002D.7040400@redpill-linpro.com> * Andreas Strikos > There is a last box in the form that allows you to edit and write > your own description. Maybe is hidden because the form is too small > for you. Try to maximize the UDM form and you will see it. If I haven't gone blind, the last box in the form is ?Do not visualise?. See attachment. > These pages might help you with this until we give a search option. > https://atlas.ripe.net/contrib/coverage.html > https://atlas.ripe.net/atlas/prb_coverage.html?asn_v6=[as number] > Same logic for asn_v4,prefix_v4, prefix_v6, country Perfect, thanks! Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com -------------- next part -------------- A non-text attachment was scrubbed... Name: atlas-udm.png Type: image/png Size: 389678 bytes Desc: not available URL: From kyriacos at sakkas.eu Wed Apr 4 10:07:55 2012 From: kyriacos at sakkas.eu (Kyriacos Sakkas) Date: Wed, 04 Apr 2012 11:07:55 +0300 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7C002D.7040400@redpill-linpro.com> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> <4F7B5F22.8090603@redpill-linpro.com> <4F7BF59C.7010705@ripe.net> <4F7C002D.7040400@redpill-linpro.com> Message-ID: <4F7C015B.5020900@sakkas.eu> On 04/04/2012 11:02, Tore Anderson wrote: > * Andreas Strikos > >> There is a last box in the form that allows you to edit and write >> your own description. Maybe is hidden because the form is too small >> for you. Try to maximize the UDM form and you will see it. > If I haven't gone blind, the last box in the form is ?Do not visualise?. > See attachment. You have gone blind :P . Make the conf box bigger. Or you hit a browser dependent bug. > >> These pages might help you with this until we give a search option. >> https://atlas.ripe.net/contrib/coverage.html >> https://atlas.ripe.net/atlas/prb_coverage.html?asn_v6=[as number] >> Same logic for asn_v4,prefix_v4, prefix_v6, country > Perfect, thanks! > > Best regards, -------------- next part -------------- A non-text attachment was scrubbed... Name: atlas.png Type: image/png Size: 331599 bytes Desc: not available URL: From tore.anderson at redpill-linpro.com Wed Apr 4 10:26:02 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 04 Apr 2012 10:26:02 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7C015B.5020900@sakkas.eu> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> <4F7B5F22.8090603@redpill-linpro.com> <4F7BF59C.7010705@ripe.net> <4F7C002D.7040400@redpill-linpro.com> <4F7C015B.5020900@sakkas.eu> Message-ID: <4F7C059A.2010903@redpill-linpro.com> * Kyriacos Sakkas > You have gone blind :P . Make the conf box bigger. Or you hit a browser > dependent bug. Indeed. :-) I think this must be a browser-dependent bug. If I clear my cookies and cache and log in, and open the new measurement form, the default-sized box does not show the description field (even though my browser window is maximised and have ample vertical space). Also, there are no visual clues that would lead me to suspect that the default box isn't full-sized and that there are hidden fields that may be uncovered by resizing it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From abarcomb at ripe.net Wed Apr 4 11:41:22 2012 From: abarcomb at ripe.net (Ann Barcomb) Date: Wed, 04 Apr 2012 11:41:22 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7C059A.2010903@redpill-linpro.com> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> <4F7B5F22.8090603@redpill-linpro.com> <4F7BF59C.7010705@ripe.net> <4F7C002D.7040400@redpill-linpro.com> <4F7C015B.5020900@sakkas.eu> <4F7C059A.2010903@redpill-linpro.com> Message-ID: <4F7C1742.5040205@ripe.net> On /4/42012 10:26 , Tore Anderson wrote: > * Kyriacos Sakkas > >> You have gone blind :P . Make the conf box bigger. Or you hit a browser >> dependent bug. > > Indeed. :-) > > I think this must be a browser-dependent bug. If I clear my cookies and > cache and log in, and open the new measurement form, the default-sized > box does not show the description field (even though my browser window > is maximised and have ample vertical space). Also, there are no visual > clues that would lead me to suspect that the default box isn't > full-sized and that there are hidden fields that may be uncovered by > resizing it. > > Best regards, Hi, We've discovered that this does appear to be a browser-specific bug. I don't see the description in Firefox but I do see it in Chrome. As a temporary work-around, you can manually increase the length of the box. I have added details about this in the documentation to address the issue until we have the opportunity to solve the problem. Kind Regards, Ann -- Ann Barcomb RIPE NCC Community Builder http://www.ripe.net Measurements Community Building +31 20 535 4444 From tore.anderson at redpill-linpro.com Wed Apr 4 12:00:46 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 04 Apr 2012 12:00:46 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7C1742.5040205@ripe.net> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> <4F7B5F22.8090603@redpill-linpro.com> <4F7BF59C.7010705@ripe.net> <4F7C002D.7040400@redpill-linpro.com> <4F7C015B.5020900@sakkas.eu> <4F7C059A.2010903@redpill-linpro.com> <4F7C1742.5040205@ripe.net> Message-ID: <4F7C1BCE.5030702@redpill-linpro.com> * Ann Barcomb > We've discovered that this does appear to be a browser-specific bug. I > don't see the description in Firefox but I do see it in Chrome. As a > temporary work-around, you can manually increase the length of the box. Hi Ann, Actually, it was with Chrome (version 18.0.1025.142) I experienced this problem, not Firefox. I tried Firefox (verson 11.0) now, while the box is too small by default there too, the upper ~20% of the label and text input field is visible, so it is obvious that there's something there (unlike Chrome). I'm running Linux (Fedora 16), for what it's worth. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From abarcomb at ripe.net Wed Apr 4 12:21:15 2012 From: abarcomb at ripe.net (Ann Barcomb) Date: Wed, 04 Apr 2012 12:21:15 +0200 Subject: [atlas] RIPE Atlas User-Defined Measurements Are Here! In-Reply-To: <4F7C1BCE.5030702@redpill-linpro.com> References: <4F7AF0F1.10308@ripe.net> <4F7AF648.1080506@ripe.net> <4F7B0400.3020900@redpill-linpro.com> <4F7B1025.1060500@ripe.net> <4F7B5F22.8090603@redpill-linpro.com> <4F7BF59C.7010705@ripe.net> <4F7C002D.7040400@redpill-linpro.com> <4F7C015B.5020900@sakkas.eu> <4F7C059A.2010903@redpill-linpro.com> <4F7C1742.5040205@ripe.net> <4F7C1BCE.5030702@redpill-linpro.com> Message-ID: <4F7C209B.8060403@ripe.net> On /4/42012 12:00 , Tore Anderson wrote: > * Ann Barcomb > >> We've discovered that this does appear to be a browser-specific bug. I >> don't see the description in Firefox but I do see it in Chrome. As a >> temporary work-around, you can manually increase the length of the box. > > Hi Ann, > > Actually, it was with Chrome (version 18.0.1025.142) I experienced this > problem, not Firefox. I tried Firefox (verson 11.0) now, while the box > is too small by default there too, the upper ~20% of the label and text > input field is visible, so it is obvious that there's something there > (unlike Chrome). > > I'm running Linux (Fedora 16), for what it's worth. > > Best regards, In that case, I will mention that it is a problem with some browsers (in the documentation), and will leave it up to the developers to isolate the problem. Thanks for the update! - Ann -- Ann Barcomb RIPE NCC Community Builder http://www.ripe.net Measurements Community Building +31 20 535 4444 From daniel at sokolov.eu.org Tue Apr 10 09:51:45 2012 From: daniel at sokolov.eu.org (Daniel AJ Sokolov) Date: Tue, 10 Apr 2012 04:51:45 -0300 Subject: [atlas] Measure DNS resolve times Message-ID: <4F83E691.5090501@sokolov.eu.org> Hello, My ISP has changed something and as a result DNS lookups have slowed down considerably. How would I set up a User Defined Measurements to perform certain lookups on a nameserver and measure the response times? Thank you Daniel AJ -- Follow me on twitter @newstik http://twitter.com/newstik From robert at ripe.net Tue Apr 10 10:11:11 2012 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 10 Apr 2012 10:11:11 +0200 Subject: [atlas] Measure DNS resolve times In-Reply-To: <4F83E691.5090501@sokolov.eu.org> References: <4F83E691.5090501@sokolov.eu.org> Message-ID: <4F83EB1F.4060403@ripe.net> On 2012.04.10. 9:51, Daniel AJ Sokolov wrote: > Hello, > > My ISP has changed something and as a result DNS lookups have slowed > down considerably. > > How would I set up a User Defined Measurements to perform certain > lookups on a nameserver and measure the response times? > > Thank you > Daniel AJ Hello, DNS measurements in the UDM framework is one of the upcoming features that we are working on. All these will include measuring response times. Regards, Robert From inigo at infornografia.net Tue Apr 10 10:11:29 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Tue, 10 Apr 2012 10:11:29 +0200 Subject: [atlas] Measure DNS resolve times In-Reply-To: <4F83E691.5090501@sokolov.eu.org> References: <4F83E691.5090501@sokolov.eu.org> Message-ID: On Tue, Apr 10, 2012 at 9:51 AM, Daniel AJ Sokolov wrote: > Hello, > > My ISP has changed something and as a result DNS lookups have slowed > down considerably. > > How would I set up a User Defined Measurements to perform certain > lookups on a nameserver and measure the response times? > > AFAIK these are not currently available to end-users. There is however, a presentation by Robert Kisteleki in the upcoming RIPE meeting. Stay tuned :) https://ripe64.ripe.net/programme/meeting-plan/dns-wg/ > Thank you > Daniel AJ > > -- > Follow me on twitter @newstik http://twitter.com/newstik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Sat Apr 21 01:02:04 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 Apr 2012 16:02:04 -0700 Subject: [atlas] Request for RIPE Atlas probe DHCP change. Message-ID: <20120420230204.GA25252@ussenterprise.ufp.org> Could the RIPE Atlas probe DHCP client please be configured to send a ClientID, perhaps "RIPEAtlasProbe"? Many home gateways show a list of DHCP clients and list the client ID. It would make it much easier to identify which device is which using these tools. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From philip.homburg at ripe.net Sat Apr 21 12:18:35 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Sat, 21 Apr 2012 12:18:35 +0200 Subject: [atlas] Request for RIPE Atlas probe DHCP change. In-Reply-To: <20120420230204.GA25252@ussenterprise.ufp.org> References: <20120420230204.GA25252@ussenterprise.ufp.org> Message-ID: <4F92897B.8000905@ripe.net> On 4/21/12 1:02 , Leo Bicknell wrote: > Could the RIPE Atlas probe DHCP client please be configured to send > a ClientID, perhaps "RIPEAtlasProbe"? > > Many home gateways show a list of DHCP clients and list the client ID. > It would make it much easier to identify which device is which using > these tools. > Yes, that you be possible. I'll look into getting this changed. From me at anuragbhatia.com Sat Apr 21 15:08:16 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 21 Apr 2012 18:38:16 +0530 Subject: [atlas] Request for RIPE Atlas probe DHCP change. In-Reply-To: <4F92897B.8000905@ripe.net> References: <20120420230204.GA25252@ussenterprise.ufp.org> <4F92897B.8000905@ripe.net> Message-ID: Good idea! +1 (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Apr 21, 2012 3:48 PM, "Philip Homburg" wrote: > On 4/21/12 1:02 , Leo Bicknell wrote: > >> Could the RIPE Atlas probe DHCP client please be configured to send >> a ClientID, perhaps "RIPEAtlasProbe"? >> >> Many home gateways show a list of DHCP clients and list the client ID. >> It would make it much easier to identify which device is which using >> these tools. >> >> Yes, that you be possible. I'll look into getting this changed. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Sat Apr 21 16:00:42 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Sat, 21 Apr 2012 16:00:42 +0200 Subject: [atlas] Request for RIPE Atlas probe DHCP change. In-Reply-To: <4F92897B.8000905@ripe.net> References: <20120420230204.GA25252@ussenterprise.ufp.org> <4F92897B.8000905@ripe.net> Message-ID: +1 and if it is not too complicated include the probe-id please. Daniel host to more than 1 probe On 21.04.2012, at 12:18, Philip Homburg wrote: > On 4/21/12 1:02 , Leo Bicknell wrote: >> Could the RIPE Atlas probe DHCP client please be configured to send >> a ClientID, perhaps "RIPEAtlasProbe"? >> >> Many home gateways show a list of DHCP clients and list the client ID. >> It would make it much easier to identify which device is which using >> these tools. >> > Yes, that you be possible. I'll look into getting this changed. > > From aa at highloadlab.com Mon Apr 23 11:46:12 2012 From: aa at highloadlab.com (Alexander Asimov) Date: Mon, 23 Apr 2012 13:46:12 +0400 Subject: [atlas] ATLAS as mechanism for route policy discovery Message-ID: Hello. During last decade much attention was paid to topology discovery at inter-domain routing level. But most of these projects are only targeted on physical links discovery; at the same time there was little opportunity to check the real use of links by single AS. The knowledge of Autonomous System relationships from single AS view could be used in many cases. For example it could be used during designing AS or for traffic flow engineering purposes. In case to solve this problem we have invented several active probing algorithms for discovering real routing policy map from single AS view. One of them is based on using spoofed source IP. We send an echo request with record route option and source IP from our address space and as the result we can see the part of reverse trace from destination. This helps to understand which links are used by our AS. It is a kind of snapshot. This information is used in iteration process and the all data results in model of AS relationships which could be reversed to single view for every AS. At the current moment we cover with help of our nodes about 40% of transit AS, but with help of RIPE Atlas we will be able to cover more than 90%, and give back to community a tool for traffic flow prediction at interdomain routing level. Spoofing is obviously bad in most of cases, but not this time. We need opportunity to strictly spoof only one IP from our address space. The list technical requirements of our proposal: 1. 178.248.239.238 always will be used as spoofed address; 2. There will be about 15 experiments every day; 3. Each experiment will last not more than 10 minutes; 4. The total approximate packet generation activity from all nodes will be about 500 packets per second; 5. We need opportunity to have different measurement plans (list of destinations) on different nodes. We work with Planet Lab nodes in the same way: every day there is a new .gz archive with list of targets for all nodes, every node unpacks it and use then only a sublist of destinations, but the packet generation script is same on all nodes. We're open to discussion on procedures described above. Best regards, Alexader Asimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Mon Apr 23 15:31:48 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 23 Apr 2012 15:31:48 +0200 Subject: [atlas] Request for RIPE Atlas probe DHCP change. In-Reply-To: <20120420230204.GA25252@ussenterprise.ufp.org> References: <20120420230204.GA25252@ussenterprise.ufp.org> Message-ID: <4F9559C4.1030002@ripe.net> On 4/21/12 1:02 , Leo Bicknell wrote: > Could the RIPE Atlas probe DHCP client please be configured to send > a ClientID, perhaps "RIPEAtlasProbe"? > > Many home gateways show a list of DHCP clients and list the client ID. > It would make it much easier to identify which device is which using > these tools. > Looking into it. Client ID or Vendor Class? You are not supposed to set Client ID to something generic because it has to unique identify the device. Vendor Class is safe. For Daniel, I changed the Vendor Class for probe 19. From bicknell at ufp.org Mon Apr 23 15:59:15 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 23 Apr 2012 06:59:15 -0700 Subject: [atlas] Request for RIPE Atlas probe DHCP change. In-Reply-To: <4F9559C4.1030002@ripe.net> References: <20120420230204.GA25252@ussenterprise.ufp.org> <4F9559C4.1030002@ripe.net> Message-ID: <20120423135915.GA35854@ussenterprise.ufp.org> In a message written on Mon, Apr 23, 2012 at 03:31:48PM +0200, Philip Homburg wrote: > Looking into it. Client ID or Vendor Class? You are not supposed to set > Client ID to something generic because it has to unique identify the > device. Vendor Class is safe. Client ID is what most of the home gateways present. I can think of three ways it could be done: 1) Just use "ripeatlas" or a similar fixed string, and yes, there will be "collisions". Plenty of other devices use this method and they seem to work, although it's not the most RFC-complaint way to do things. 2) Use a fixed string and part of the MAC. I've seen a number of embedded devices use this method. "atlas-12:AB:56" or similar. 3) Actually set it based on the probe ID. I think this would be the coolest option. "atlas-1234" or similar. I would think this could be super-useful for folks setting up and testing more than one probe, since all of the UI references them by probe ID. I've never seen a home gateway display vendor class, but setting it properly would also be a nice thing to do. :) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From me at anuragbhatia.com Wed Apr 25 16:38:34 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 25 Apr 2012 20:08:34 +0530 Subject: [atlas] Routing glitch between BSNL and F Root Message-ID: Hello, There has been some routing glitch in the F root server instance running in Chennai, India by niXi AS 24049. Govt. owned BSNL AS9829 routers are not hearing any BGP announcements and thus F root does not works at all on BSNL. anurag at laptop ~ $ traceroute f.root-servers.net -A traceroute to f.root-servers.net (192.5.5.241), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) [AS8151/AS28513] 1.552 ms 2.040 ms * 2 117.207.48.1 (117.207.48.1) [AS9829] 26.010 ms 28.433 ms 31.136 ms 3 218.248.173.42 (218.248.173.42) [AS9829] 34.497 ms 35.968 ms 38.372 ms 4 218.248.250.86 (218.248.250.86) [AS9829] 91.784 ms 94.430 ms 96.794 ms 5 * * * 6 * * * 7 * * * 8 * * * I have been hosting RIPE Probe #1032 and here is F Root connectivity data from proble: [image: Inline image 1] As we can see root server is not accessible at all from Jan and even in Nov, Dec last year it was available with over 300ms latency which indicates network was not using Chennai anycast node since latency between this test probe placed in Haryana (North India) and Chennai (South India) should be around 70ms. Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rrd.png Type: image/png Size: 21731 bytes Desc: not available URL: -------------- next part -------------- -- This message has been scanned by Kaspersky Anti-Virus. For more information about data security please visit http://www.kaspersky.com and http://www.viruslist.com From rm at romanrm.ru Wed Apr 25 16:50:18 2012 From: rm at romanrm.ru (Roman Mamedov) Date: Wed, 25 Apr 2012 20:50:18 +0600 Subject: [atlas] Routing glitch between BSNL and F Root In-Reply-To: References: Message-ID: <20120425205018.603bf144@natsu> On Wed, 25 Apr 2012 20:08:34 +0530 Anurag Bhatia wrote: > Thanks. > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! ^^^^^^ You keep using that word. I don't think it means what you think it means. ;) -- With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: not available URL: -------------- next part -------------- -- This message has been scanned by Kaspersky Anti-Virus. For more information about data security please visit http://www.kaspersky.com and http://www.viruslist.com From bicknell at ufp.org Wed Apr 25 16:58:47 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 25 Apr 2012 09:58:47 -0500 Subject: [atlas] Routing glitch between BSNL and F Root In-Reply-To: References: Message-ID: <83B72707-9274-44AC-B25B-10B188BDB7DD@ufp.org> I've removed noc at isc.org, it's a ticketing system that shouldn't be on the rest of this thread. ISC has experienced a number of routing challenges at our Chennai node over the past year resulting in problems such as this one. We've been working with APNIC (the node Sponsor) and NIXI (the node host) to get these resolved. We've found the Indian market to be rather unique in the way various large ISP's chose to announce (or not announce, as the case may be) their routes at various exchanges. In this particular case it appears that the traffic is making it to our Chennai node, but not making it back. I will work with Anurag directly in the ticket to get this issue resolved. If anyone else is seeing issues in India please mail noc at isc.org to open a ticket. The more reports we have of problems the more attention we can get this issue with the various parties involved. On Apr 25, 2012, at 9:38 AM, Anurag Bhatia wrote: > Hello, > > > > There has been some routing glitch in the F root server instance running in Chennai, India by niXi AS 24049. > > Govt. owned BSNL AS9829 routers are not hearing any BGP announcements and thus F root does not works at all on BSNL. > > > anurag at laptop ~ $ traceroute f.root-servers.net -A > traceroute to f.root-servers.net (192.5.5.241), 30 hops max, 60 byte packets > 1 192.168.1.1 (192.168.1.1) [AS8151/AS28513] 1.552 ms 2.040 ms * > 2 117.207.48.1 (117.207.48.1) [AS9829] 26.010 ms 28.433 ms 31.136 ms > 3 218.248.173.42 (218.248.173.42) [AS9829] 34.497 ms 35.968 ms 38.372 ms > 4 218.248.250.86 (218.248.250.86) [AS9829] 91.784 ms 94.430 ms 96.794 ms > 5 * * * > 6 * * * > 7 * * * > 8 * * * > > > > I have been hosting RIPE Probe #1032 and here is F Root connectivity data from proble: > > > > > > As we can see root server is not accessible at all from Jan and even in Nov, Dec last year it was available with over 300ms latency which indicates network was not using Chennai anycast node since latency between this test probe placed in Haryana (North India) and Chennai (South India) should be around 70ms. > > > > Thanks. > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com > > > > -- > This message has been scanned by Kaspersky Anti-Virus. > For more information about data security please visit > http://www.kaspersky.com and http://www.viruslist.com > > -- > This message has been scanned by Kaspersky Anti-Virus. > For more information about data security please visit > http://www.kaspersky.com and http://www.viruslist.com -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at anuragbhatia.com Wed Apr 25 17:32:40 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 25 Apr 2012 21:02:40 +0530 Subject: [atlas] Routing glitch between BSNL and F Root In-Reply-To: <83B72707-9274-44AC-B25B-10B188BDB7DD@ufp.org> References: <83B72707-9274-44AC-B25B-10B188BDB7DD@ufp.org> Message-ID: Thanks for reply Leo Will look forward towards communication from your end. In case you need further data, let me know. Thanks (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Apr 25, 2012 8:28 PM, "Leo Bicknell" wrote: > > I've removed noc at isc.org, it's a ticketing system that shouldn't be on > the rest of this thread. > > ISC has experienced a number of routing challenges at our Chennai node > over the past year resulting in problems such as this one. We've been > working with APNIC (the node Sponsor) and NIXI (the node host) to get these > resolved. We've found the Indian market to be rather unique in the way > various large ISP's chose to announce (or not announce, as the case may be) > their routes at various exchanges. In this particular case it appears that > the traffic is making it to our Chennai node, but not making it back. > > I will work with Anurag directly in the ticket to get this issue resolved. > If anyone else is seeing issues in India please mail noc at isc.org to open > a ticket. The more reports we have of problems the more attention we can > get this issue with the various parties involved. > > On Apr 25, 2012, at 9:38 AM, Anurag Bhatia wrote: > > Hello, > > > > There has been some routing glitch in the F root server instance running > in Chennai, India by niXi AS 24049. > > Govt. owned BSNL AS9829 routers are not hearing any BGP announcements and > thus F root does not works at all on BSNL. > > > anurag at laptop ~ $ traceroute f.root-servers.net -A > traceroute to f.root-servers.net (192.5.5.241), 30 hops max, 60 byte > packets > 1 192.168.1.1 (192.168.1.1) [AS8151/AS28513] 1.552 ms 2.040 ms * > 2 117.207.48.1 (117.207.48.1) [AS9829] 26.010 ms 28.433 ms 31.136 ms > 3 218.248.173.42 (218.248.173.42) [AS9829] 34.497 ms 35.968 ms 38.372 > ms > 4 218.248.250.86 (218.248.250.86) [AS9829] 91.784 ms 94.430 ms 96.794 > ms > 5 * * * > 6 * * * > 7 * * * > 8 * * * > > > > I have been hosting RIPE Probe #1032 and here is F Root connectivity data > from proble: > > > > > > As we can see root server is not accessible at all from Jan and even in > Nov, Dec last year it was available with over 300ms latency which indicates > network was not using Chennai anycast node since latency between this test > probe placed in Haryana (North India) and Chennai (South India) should be > around 70ms. > > > > Thanks. > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com > > > > -- > This message has been scanned by Kaspersky Anti-Virus. > For more information about data security please visit > http://www.kaspersky.com and http://www.viruslist.com > > -- > This message has been scanned by Kaspersky Anti-Virus. > For more information about data security please visit > http://www.kaspersky.com and http://www.viruslist.com > > > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at anuragbhatia.com Thu Apr 26 04:49:23 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 26 Apr 2012 08:19:23 +0530 Subject: [atlas] Routing glitch between BSNL and F Root In-Reply-To: References: <83B72707-9274-44AC-B25B-10B188BDB7DD@ufp.org> Message-ID: I just got a check from my friend who is using BSNL in Chennai. F root is accessible via BSNL Chennai. Taking path to NIXI Chennai directly. So routers (in Chennai) get annoucement, while routers in North India fail. They seem holding different versions of routing table in this case. Is it like problem with IGP deployment of BSNL? Not really sure which protocols they are using on backbone. Thanks. On Wed, Apr 25, 2012 at 9:02 PM, Anurag Bhatia wrote: > Thanks for reply Leo > > Will look forward towards communication from your end. In case you need > further data, let me know. > > Thanks > > (Sent from my mobile device) > > Anurag Bhatia > http://anuragbhatia.com > On Apr 25, 2012 8:28 PM, "Leo Bicknell" wrote: > >> >> I've removed noc at isc.org, it's a ticketing system that shouldn't be on >> the rest of this thread. >> >> ISC has experienced a number of routing challenges at our Chennai node >> over the past year resulting in problems such as this one. We've been >> working with APNIC (the node Sponsor) and NIXI (the node host) to get these >> resolved. We've found the Indian market to be rather unique in the way >> various large ISP's chose to announce (or not announce, as the case may be) >> their routes at various exchanges. In this particular case it appears that >> the traffic is making it to our Chennai node, but not making it back. >> >> I will work with Anurag directly in the ticket to get this issue >> resolved. If anyone else is seeing issues in India please mail >> noc at isc.org to open a ticket. The more reports we have of problems the >> more attention we can get this issue with the various parties involved. >> >> On Apr 25, 2012, at 9:38 AM, Anurag Bhatia wrote: >> >> Hello, >> >> >> >> There has been some routing glitch in the F root server instance running >> in Chennai, India by niXi AS 24049. >> >> Govt. owned BSNL AS9829 routers are not hearing any BGP announcements and >> thus F root does not works at all on BSNL. >> >> >> anurag at laptop ~ $ traceroute f.root-servers.net -A >> traceroute to f.root-servers.net (192.5.5.241), 30 hops max, 60 byte >> packets >> 1 192.168.1.1 (192.168.1.1) [AS8151/AS28513] 1.552 ms 2.040 ms * >> 2 117.207.48.1 (117.207.48.1) [AS9829] 26.010 ms 28.433 ms 31.136 ms >> 3 218.248.173.42 (218.248.173.42) [AS9829] 34.497 ms 35.968 ms >> 38.372 ms >> 4 218.248.250.86 (218.248.250.86) [AS9829] 91.784 ms 94.430 ms >> 96.794 ms >> 5 * * * >> 6 * * * >> 7 * * * >> 8 * * * >> >> >> >> I have been hosting RIPE Probe #1032 and here is F Root connectivity data >> from proble: >> >> >> >> >> >> As we can see root server is not accessible at all from Jan and even in >> Nov, Dec last year it was available with over 300ms latency which indicates >> network was not using Chennai anycast node since latency between this test >> probe placed in Haryana (North India) and Chennai (South India) should be >> around 70ms. >> >> >> >> Thanks. >> >> -- >> >> Anurag Bhatia >> anuragbhatia.com >> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected >> network! >> >> Twitter: @anurag_bhatia >> Linkedin: http://linkedin.anuragbhatia.com >> >> >> >> -- >> This message has been scanned by Kaspersky Anti-Virus. >> For more information about data security please visit >> http://www.kaspersky.com and http://www.viruslist.com >> >> -- >> This message has been scanned by Kaspersky Anti-Virus. >> For more information about data security please visit >> http://www.kaspersky.com and http://www.viruslist.com >> >> >> >> -- >> Leo Bicknell - bicknell at ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ >> >> >> >> >> >> -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.mayrhofer at nic.at Fri Apr 27 12:20:59 2012 From: alexander.mayrhofer at nic.at (Alexander Mayrhofer) Date: Fri, 27 Apr 2012 10:20:59 +0000 Subject: [atlas] Feature-suggestion: "round-robin" probes Message-ID: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> Hello, i'm figuring how RIPE atlas could be most useful for assisting in monitoring our Ancast Network, and came up with the following idea: The Atlas network has a big advantage over other monitoring /measurement networks, which is obviously its sheer size (and topological diversity). Rather than using the Atlas network for pure performance measurements, i would love to be able to use Atlas for reachability measurements (and understand which Anycast location attracts traffic from which region, and how this changes over time). These reachability / topology discovery measurements do not need to be nearly as frequent as the performance measurements, but should utilize all available probes. So, instead of being able to use 10 probes to run a continous performance test (say, DNS query every 300 seconds), i would rather like to be able to use a very high number of probes (best case: "all"), but have each of the probe eg. perform just one traceroute per day (or, even once per week would be enough). This would give me an excellent overview about the topology, but is not possible using the current limits of the UDMs. However, instead of allowing users to allocate measurements to a much higher number of probes, this functionality would also be possible be adding some "probe round-robin" feature to the control infrastructure, for example "randomly allocate a new set of probes every xx seconds". If that feature would exist, i could implement the above reachability test with the following parameters: Test: traceroute Number of probes: 10 Measurement interval: 3600 Swap probe-set interval: 10800 (NEW feature) (which would re-allocate new probes every 3 hours, theoretically working through all 1500 probes about every month?). An obvious alternative would be functionality where i could "queue" "single-shot" measurements for the whole network (since chances are low i would get every probe if they are randomly assigned). comments? Suggestions? Alternatives? Alex Mayrhofer Head of R&D nic.at From marco.davids at sidn.nl Fri Apr 27 13:09:39 2012 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Fri, 27 Apr 2012 13:09:39 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> Message-ID: <4F9A7E73.2040604@sidn.nl> Hi Alexander, On 04/27/12 12:20, Alexander Mayrhofer wrote: > i'm figuring how RIPE atlas could be most useful for assisting in monitoring our Ancast Network Cool, So are we. :-) > comments? Suggestions? Alternatives? I suppose we would be interested in two parameters: A) get a generic sense of the overall global reachability B) knowing when one of the nodes has a problem For A) we would be fine with 'slow' measurements, performed with a large, or in any case representative amount of probes. For B) only a few, strategically located probes would work, but they should measure on a frequent, near real-time basis (and it would help if they are located on stable network-connections instead of a flaky home-user link). I have believed from the beginning that Atlas could be of use here, in one way or another. And we would be more than happy to discuss any further. We are also interested in doing other DNS research/measurements, namely to the amount of DNSSEC validating resolvers with ISP's. Not sure if the Atlas system could be of use there (don't really see why not though). As SamKnows been mentioned here? There's quite some resemblance between SamKnows and Atlas, and changes for synergy as well. https://www.samknows.eu/ -- Marco From philip.homburg at ripe.net Fri Apr 27 13:28:43 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 27 Apr 2012 13:28:43 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> Message-ID: <4F9A82EB.3040908@ripe.net> On 4/27/12 12:20 , Alexander Mayrhofer wrote: > So, instead of being able to use 10 probes to run a continous performance test (say, DNS query every 300 seconds), i would rather like to be able to use a very high number of probes (best case: "all"), but have each of the probe eg. perform just one traceroute per day (or, even once per week would be enough). This would give me an excellent overview about the topology, but is not possible using the current limits of the UDMs. Yes, I think this would be useful in many cases. Unfortunately, I've no idea when we will get around to actually implement it. From philip.homburg at ripe.net Fri Apr 27 13:34:14 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 27 Apr 2012 13:34:14 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <4F9A7E73.2040604@sidn.nl> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> <4F9A7E73.2040604@sidn.nl> Message-ID: <4F9A8436.3030005@ripe.net> On 4/27/12 13:09 , Marco Davids (SIDN) wrote: > > > For B) only a few, strategically located probes would work, but they > should measure on a frequent, near real-time basis (and it would help if > they are located on stable network-connections instead of a flaky > home-user link). There is a plan to install 'Atlas anchor' boxes that are very stable and can be used both as targets and as powerful Atlas probes. > > We are also interested in doing other DNS research/measurements, namely > to the amount of DNSSEC validating resolvers with ISP's. Not sure if the > Atlas system could be of use there (don't really see why not though). That should come relatively soon. We are almost done with firmware that can generate DNSSEC queries and send queries through the probes' local resolvers.