From ripe at brite.cz Mon Jun 10 12:21:50 2019 From: ripe at brite.cz (ripe at brite.cz) Date: Mon, 10 Jun 2019 12:21:50 +0200 Subject: [atlas] =?utf-8?q?Web_interface_for_Create_New_Measurements_does?= =?utf-8?q?_not_work_for_me?= Message-ID: <20190610122150.4D4DA1A7@centrum.cz> https://atlas.ripe.net/measurements/form/ when I click Traceroute and enter an IP address, then "Create My Measurements" button on the bottom does not do anything, no error message. Tried various settings and Firefox, Edge, Chrome. Is it error on my side? Any idea? Thank you Jiri From gponikie at akamai.com Mon Jun 10 16:08:43 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Mon, 10 Jun 2019 14:08:43 +0000 Subject: [atlas] Web interface for Create New Measurements does not work for me In-Reply-To: <20190610122150.4D4DA1A7@centrum.cz> References: <20190610122150.4D4DA1A7@centrum.cz> Message-ID: <5CF086FE-0F5E-4047-835F-A23E25044503@akamai.com> I see the same. It doesn't matter what type of measurement or options are selected. Thankfully, API works perfectly fine so measurements can be still executed with atraceroute from ripe-atlas toolkit. Regards, Grzegorz From: "ripe at brite.cz" Date: Monday 2019-06-10 at 12:23 To: "ripe-atlas at ripe.net" Subject: [atlas] Web interface for Create New Measurements does not work for me https://atlas.ripe.net/measurements/form/ when I click Traceroute and enter an IP address, then "Create My Measurements" button on the bottom does not do anything, no error message. Tried various settings and Firefox, Edge, Chrome. Is it error on my side? Any idea? Thank you Jiri -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Tue Jun 11 11:01:42 2019 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 11 Jun 2019 11:01:42 +0200 Subject: [atlas] Web interface for Create New Measurements does not work for me In-Reply-To: <20190610122150.4D4DA1A7@centrum.cz> References: <20190610122150.4D4DA1A7@centrum.cz> Message-ID: On 2019-06-10 12:21, ripe at brite.cz wrote: > https://atlas.ripe.net/measurements/form/ when I click Traceroute and enter an IP address, then "Create My Measurements" button on the bottom does not do anything, no error message. Tried various settings and Firefox, Edge, Chrome. Is it error on my side? Any idea? > > Thank you > Jiri Hello, We're looking into the issue at the moment. We'll get back to you once we can find and fix it. Regards, Robert From robert at ripe.net Tue Jun 11 14:21:34 2019 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 11 Jun 2019 14:21:34 +0200 Subject: [atlas] Web interface for Create New Measurements does not work for me In-Reply-To: References: <20190610122150.4D4DA1A7@centrum.cz> Message-ID: > On 2019-06-10 12:21, ripe at brite.cz wrote: >> https://atlas.ripe.net/measurements/form/ when I click Traceroute and enter an IP address, then "Create My Measurements" button on the bottom does not do anything, no error message. Tried various settings and Firefox, Edge, Chrome. Is it error on my side? Any idea? >> >> Thank you >> Jiri > > Hello, > > We're looking into the issue at the moment. We'll get back to you once > we can find and fix it. > > Regards, > Robert Hello again, This issue should now be resolved. The reason was a broken authorisation check which in some cases prevented users (via the UI) from scheduling measurements. I believe this affected about 2% of measurement requests. Sorry for the inconvenience this may have caused, and as usual please let us know if you see unexpected behaviour. Regards, Robert From afshar.milad89 at gmail.com Sun Jun 16 12:36:33 2019 From: afshar.milad89 at gmail.com (Milad Afshari) Date: Sun, 16 Jun 2019 15:06:33 +0430 Subject: [atlas] Periodic Probes Outage Message-ID: Dear all, Hi Within past days I am experiencing some periodic outage of many probes here in Iran, since I have checked all my probes and their network connections status, I guess they have some issue for connecting to the RIPE Atlas infrastructure. https://atlas.ripe.net/probes/?public=4&status=&country=IR&search=&order=__status__&af=#tab-public please let me know your thoughts and opinions. Many thanks Milad -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hans.Mayer at iiasa.ac.at Mon Jun 17 09:06:16 2019 From: Hans.Mayer at iiasa.ac.at (Mayer Hans) Date: Mon, 17 Jun 2019 07:06:16 +0000 Subject: [atlas] Periodic Probes Outage In-Reply-To: References: Message-ID: <4606bcbe08294ac4ad3a822a4efc28cf@RHONE.iiasa.ac.at> Dear Miland, As you mentioned your country Iran I searched for probes in Iran. There are 8 probes, 6 of them have a connection status of more than 1 year. Two of them have only some minutes. I would guess it is not a general issue with Inter connectivity to Iran. But this you know maybe already. // Hans From: ripe-atlas On Behalf Of Milad Afshari Sent: Sunday, June 16, 2019 12:37 PM To: ripe-atlas at ripe.net Subject: [atlas] Periodic Probes Outage Dear all, Hi Within past days I am experiencing some periodic outage of many probes here in Iran, since I have checked all my probes and their network connections status, I guess they have some issue for connecting to the RIPE Atlas infrastructure. https://atlas.ripe.net/probes/?public=4&status=&country=IR&search=&order=__status__&af=#tab-public please let me know your thoughts and opinions. Many thanks Milad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jterbeest at ripe.net Mon Jun 17 11:28:40 2019 From: jterbeest at ripe.net (Johan ter Beest) Date: Mon, 17 Jun 2019 11:28:40 +0200 Subject: [atlas] Periodic Probes Outage In-Reply-To: <4606bcbe08294ac4ad3a822a4efc28cf@RHONE.iiasa.ac.at> References: <4606bcbe08294ac4ad3a822a4efc28cf@RHONE.iiasa.ac.at> Message-ID: <55EE23F3-4B46-48FF-8EF3-0348AB3EB3E1@ripe.net> Hi Hans, > On 17 Jun 2019, at 09:06, Mayer Hans wrote: > > > Dear Miland, > > As you mentioned your country Iran I searched for probes in Iran. There are 8 probes, 6 of them have a connection status of more than 1 year. Two of them have only some minutes. I would guess it is not a general issue with Inter connectivity to Iran. But this you know maybe already. > I don?t know where you got those numbers from but according to our probe archives, we had 140 probes connected in Iran on 2019-06-16 I do see some more volatility in the connection rates recently, not sure what is causing that. Kind regards, Johan ter Beest > > // Hans > > > > From: ripe-atlas On Behalf Of Milad Afshari > Sent: Sunday, June 16, 2019 12:37 PM > To: ripe-atlas at ripe.net > Subject: [atlas] Periodic Probes Outage > > Dear all, > Hi > > Within past days I am experiencing some periodic outage of many probes here in Iran, since I have checked all my probes and their network connections status, I guess they have some issue for connecting to the RIPE Atlas infrastructure. > > https://atlas.ripe.net/probes/?public=4&status=&country=IR&search=&order=__status__&af=#tab-public > > please let me know your thoughts and opinions. > > Many thanks > Milad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2634 bytes Desc: not available URL: From adavies at ripe.net Mon Jun 17 11:40:26 2019 From: adavies at ripe.net (Alun Davies) Date: Mon, 17 Jun 2019 11:40:26 +0200 Subject: [atlas] RIPE Atlas Software Probes Survey Message-ID: Dear colleagues, We are working on making the RIPE Atlas measurement software available as an installable package so you can run RIPE Atlas probes entirely in software without the need of a dedicated physical device. We are interested in your feedback regarding this feature, and we are also looking for volunteers willing to partner with us and help package the software for various operating systems and platforms. Please send your feedback and let us know if you can support RIPE Atlas software probes by filling in this short survey: https://www.ripe.net/participate/forms/apply/atlas-probes/ Kind regards, Alun Davies RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2627 bytes Desc: not available URL: From abscoco at gmail.com Mon Jun 17 12:45:01 2019 From: abscoco at gmail.com (Sylvain BAYA) Date: Mon, 17 Jun 2019 11:45:01 +0100 Subject: [atlas] Periodic Probes Outage In-Reply-To: <4606bcbe08294ac4ad3a822a4efc28cf@RHONE.iiasa.ac.at> References: <4606bcbe08294ac4ad3a822a4efc28cf@RHONE.iiasa.ac.at> Message-ID: <4661e7cc-29a8-16d6-901a-d156ea238b87@gmail.com> Hi all, Le lundi 17 juin 2019, Mayer Hans > a ?crit?: ? Dear Miland, ? As you mentioned your country Iran I searched for probes in Iran. There are 8 probes, 6 of them have a connection status of more than 1 year.? Right now, i see [1] 381 probes, where 81 are connected [2] (top2: 1month2weeks & 1month), and 206 disconnected [3], with practicaly 150 down for more than a month. It seams as there is a real issue since more than a month...or maybe it is just a probe (online) survival [4] local reality ? :-/ __ [1]:?https://atlas.ripe.net/probes/?public=4&status=&country=IR&search=&order=__status__&af=#tab-public [2]:?https://atlas.ripe.net/probes/?status=1&country=IR&search=&af=&order=__status__#!tab-public [3]:?https://atlas.ripe.net/probes/?public=6&status=2&country=IR&search=&order=-__status__&af=#tab-public [4]: 136, of the disconnected probes, have the status abandoned ? https://atlas.ripe.net/probes/?public=3&status=3&country=IR&search=&order=-__status__&af=#tab-public Regards, --sb. http://www.chretiennement.org Two of them have only some minutes. I would guess it is not a general issue with Inter connectivity to Iran. But this you know maybe already. ? ? // Hans ? ? ? *From:* ripe-atlas > *On Behalf Of *Milad Afshari *Sent:* Sunday, June 16, 2019 12:37 PM *To:* ripe-atlas at ripe.net *Subject:* [atlas] Periodic Probes Outage ? Dear all, Hi Within past days I am experiencing some periodic outage of many probes here in Iran, since I have checked all my probes and their network connections status, I guess they have some issue for connecting to the RIPE Atlas infrastructure. ? https://atlas.ripe.net/probes/?public=4&status=&country=IR&search=&order=__status__&af=#tab-public ? ? please let me know your thoughts and opinions. ? Many thanks Milad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x0387408365AC8594.asc Type: application/pgp-keys Size: 4826 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From w.b.devries at utwente.nl Tue Jun 18 20:08:23 2019 From: w.b.devries at utwente.nl (Wouter de Vries) Date: Tue, 18 Jun 2019 20:08:23 +0200 Subject: [atlas] When to consider a measurement finished Message-ID: <20190618180823.GA7783@wfstore.wbdv.nl> Hi all, I am currently trying to do some measurements according to the following steps: 1. create a one-off measurement 2. wait for it to finish, by periodically polling the msmid and checking the status. 3. fetch the results However, the system takes a pretty long time to set the status to finished, even when all results are already in (maybe 10 minutes?). What heuristics/method do you recommend to determine whether to consider a measurement as finished? One option I consider is to periodically fetch all results for a given msmid and checking if the number of results matches the number of probes assigned to the measurement. However, I suspect that causes a much higher load on the infrastructure. Best regards, Wouter de Vries From anandb at ripe.net Wed Jun 19 14:13:43 2019 From: anandb at ripe.net (Anand Buddhdev) Date: Wed, 19 Jun 2019 14:13:43 +0200 Subject: [atlas] RIPE Atlas anchor resolver update Message-ID: <4c8255da-3e19-a2cf-94f9-6f02a7f3f7f5@ripe.net> Dear colleagues, All the RIPE Atlas anchors run a caching DNS resolver. This resolver is used to look up names when a measurement requests name resolution using a probe's resolver. We have been running an older version of BIND for this service. In the coming days, we will be upgrading the version of BIND to the latest stable version (9.14). This version has dropped many work-arounds for various forms of brokenness in other DNS implementations. The effect of this is that a small number of domains hosted on broken DNS implementations cannot be looked up by this newer version of BIND. If you are running a measurement that uses an anchor's local resolver, and you find that some domain names are failing to resolve, it may be caused by this upgrade. Regards, Anand Buddhdev RIPE NCC From vnaumov at ripe.net Wed Jun 19 15:42:33 2019 From: vnaumov at ripe.net (Viktor Naumov) Date: Wed, 19 Jun 2019 15:42:33 +0200 Subject: [atlas] When to consider a measurement finished In-Reply-To: <20190618180823.GA7783@wfstore.wbdv.nl> References: <20190618180823.GA7783@wfstore.wbdv.nl> Message-ID: Hi Wouter, The status of one-offs is not related to results collected. The stopped status is set by the timer after max 15 minutes. Since the measurement scheduling is based on the best effort approach there cannot be 100% guarantee that all the probes respond with the results so it becomes quite difficult to set the stopped status when all probes finish measuring. Moreover an additional lag can be introduced due to the cluster processing. We saw situations when a measurement had the stopped status but the results were coming. So the workflow would be to start a measurement, allow it to be scheduled and first results collected, then after 5-20 seconds you can start polling it with the same or larger interval. The polling interval should be the longer the more probes you use in your measurement. Additionally you can estimate the data processing delay using the https://atlas.ripe.net/api/v2/system/data-delay/ API call that shows the lag in seconds and the latest received measurement timestamp. If you want it to be truly synchronous you can use the streaming API. In this case the results will be pushed to the client as soon as they are coming from the probes. WBR /vty On 6/18/19 8:08 PM, Wouter de Vries wrote: > Hi all, > > I am currently trying to do some measurements according to the following > steps: > > 1. create a one-off measurement > 2. wait for it to finish, by periodically polling the msmid and checking > the status. > 3. fetch the results > > However, the system takes a pretty long time to set the status to > finished, even when all results are already in (maybe 10 minutes?). > > What heuristics/method do you recommend to determine whether to consider > a measurement as finished? > > One option I consider is to periodically fetch all results for a given > msmid and checking if the number of results matches the number of probes > assigned to the measurement. However, I suspect that causes a much > higher load on the infrastructure. > > Best regards, > > Wouter de Vries > > > From jirka.novak at upcmail.cz Wed Jun 19 18:38:48 2019 From: jirka.novak at upcmail.cz (Novak Jirka) Date: Wed, 19 Jun 2019 18:38:48 +0200 Subject: [atlas] Probe off-line for 6 days due to bad firmware signature Message-ID: <5302b305-9506-3140-6d3c-3220c80de905@upcmail.cz> Hello, my probe 22424 is off-line due to bad firmware signature error. I try to boot it without USB stick many times, then i change the USB stick (replace the old one with new one), but it doesnt solve my problem. Could you help me? This is the information from my status page: Bad Firmware Signature What does this mean? The probe's firmware signature is wrong. How can I fix this? Power-cycle the probe and wait for a couple of hours. If probe doesn't come online you should try to reinitialise or even replace your flash drive. Please use the following procedure: 1. Unplug the probe from its power source 2. Remove the USB stick from the probe 3. Plug in the probe WITHOUT the USB stick 4. Wait for ten minutes 5. Insert the USB stick If it didn't help repeat these steps using another working USB stick that is at least 4GB in size. NOTE: This must be done on a network with working DHCP! It will NOT work if you have configured your probe to use a static IP address, because this mini-operating system does not have access to any statically configure IP addresses or DNS resolvers. If you have configured your probe to use a static IP address, the only thing you can do is move it to a network with working DHCP. When the probe is listed as "connected" again, it is safe to move the probe back to its original location. However, please note that we advise configuring your probe to use a static IP address only if you feel it is truly necessary to do so. Thx, Jiri -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3835 bytes Desc: Elektronicky podpis S/MIME URL: From philip.homburg at ripe.net Fri Jun 21 10:17:04 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 21 Jun 2019 10:17:04 +0200 Subject: [atlas] Probe off-line for 6 days due to bad firmware signature In-Reply-To: <5302b305-9506-3140-6d3c-3220c80de905@upcmail.cz> References: <5302b305-9506-3140-6d3c-3220c80de905@upcmail.cz> Message-ID: <12226b07-f8fc-2634-463a-62f30de87321@ripe.net> On 2019/06/19 18:38 , Novak Jirka wrote: > my probe 22424 is off-line due to bad firmware signature error. > I try to boot it without USB stick many times, then i change the USB > stick (replace the old one with new one), but it doesnt solve my problem. > Could you help me? Hi, A bad firmware signature error can happen if the USB stick is broken. But if it still happens after the USB stick has been replaced then it is usually a network problem. The probe seems disconnected that the moment. If you connect it again, I can see if I can find out what is going on. Philip From colinj at mx5.org.uk Sun Jun 23 09:27:15 2019 From: colinj at mx5.org.uk (Colin Johnston) Date: Sun, 23 Jun 2019 08:27:15 +0100 Subject: [atlas] Probe off-line for 6 days due to bad firmware signature In-Reply-To: <12226b07-f8fc-2634-463a-62f30de87321@ripe.net> References: <5302b305-9506-3140-6d3c-3220c80de905@upcmail.cz> <12226b07-f8fc-2634-463a-62f30de87321@ripe.net> Message-ID: My v1 uk probe back and working again, forgotten had left in work rucksack after homehub replacement Col Sent from my iPod > On 21 Jun 2019, at 09:17, Philip Homburg wrote: > >> On 2019/06/19 18:38 , Novak Jirka wrote: >> my probe 22424 is off-line due to bad firmware signature error. >> I try to boot it without USB stick many times, then i change the USB >> stick (replace the old one with new one), but it doesnt solve my problem. >> Could you help me? > > Hi, > > A bad firmware signature error can happen if the USB stick is broken. > But if it still happens after the USB stick has been replaced then it is > usually a network problem. > > The probe seems disconnected that the moment. If you connect it again, I > can see if I can find out what is going on. > > Philip > From manaponoe at gmail.com Sun Jun 23 18:58:10 2019 From: manaponoe at gmail.com (Noe Manapo) Date: Sun, 23 Jun 2019 18:58:10 +0200 Subject: [atlas] Mailing subscription Message-ID: Hi team, Please I want to join the ripe-atlas mailing list. Thank you Best regard Noe Manapo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordslater at gmail.com Sun Jun 23 19:06:02 2019 From: gordslater at gmail.com (Gord Slater) Date: Sun, 23 Jun 2019 18:06:02 +0100 Subject: [atlas] Mailing subscription In-Reply-To: References: Message-ID: You're on it now :) Woeyzo -- sent via Gmail web interface, so please excuse my gross neglect of Netiquette -------------- next part -------------- An HTML attachment was scrubbed... URL: From manaponoe at gmail.com Sun Jun 23 19:07:58 2019 From: manaponoe at gmail.com (Noe Manapo) Date: Sun, 23 Jun 2019 19:07:58 +0200 Subject: [atlas] Mailing subscription In-Reply-To: References: Message-ID: Thank you! Le dim. 23 juin 2019 ? 19:06, Gord Slater a ?crit : > > You're on it now :) > > Woeyzo > > > -- > sent via Gmail web interface, so please excuse my gross neglect of > Netiquette > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.seifert at debitel.net Sun Jun 23 19:16:45 2019 From: christian.seifert at debitel.net (Christian Seifert) Date: Sun, 23 Jun 2019 19:16:45 +0200 Subject: [atlas] Mailing list unsubscribe Message-ID: Hi, please unsubscribe me from the [atlas] mailing list. thanks From kiran.gunana at colruytgroup.com Mon Jun 24 08:39:29 2019 From: kiran.gunana at colruytgroup.com (kiran.gunana at colruytgroup.com) Date: Mon, 24 Jun 2019 08:39:29 +0200 (CEST) Subject: [atlas] delete old measurements from ripe com234.474.800 Message-ID: <-1300705611.190007.1561358369289.JavaMail.was@svpapc06> Hello , Is there a way we can delete old measurements in ripe atlas measurements tab. Thes one's which are marked should be deleted for me. Kiran Gunana Network Engineer kiran.gunana at colruytgroup.com Colruyt Group Edingensesteenweg 196 - 1500 Halle www.colruytgroup.com LinkedIn Twitter Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inline_150_1561358367075_0.png Type: image/x-png Size: 115935 bytes Desc: not available URL: From kiran.gunana at colruytgroup.com Mon Jun 24 08:50:37 2019 From: kiran.gunana at colruytgroup.com (kiran.gunana at colruytgroup.com) Date: Mon, 24 Jun 2019 08:50:37 +0200 (CEST) Subject: [atlas] any clue rtt unreachable packet loss 100% com234.476.249 Message-ID: <-943382689.2577.1561359037530.JavaMail.was@svpapc94> Hello, Can some one help me with the reason behind me always getting RTT unreachable and packet loss 100% for every probe I choose to monitor one our service from internet in belgium. Is there something I am not doing right or can guid me a better way of doing it. Even though there is 100% packet loss , my credit balance is still being consumed. Kiran Gunana Network Engineer kiran.gunana at colruytgroup.com T +32 2 363 55 45 (Ext : 55711) Colruyt Group Edingensesteenweg 196 - 1500 Halle www.colruytgroup.com LinkedIn Twitter Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inline_55_1561359035868_0.png Type: image/x-png Size: 42682 bytes Desc: not available URL: From gboonie at gmail.com Mon Jun 24 09:35:32 2019 From: gboonie at gmail.com (Dave .) Date: Mon, 24 Jun 2019 09:35:32 +0200 Subject: [atlas] any clue rtt unreachable packet loss 100% com234.476.249 In-Reply-To: <-943382689.2577.1561359037530.JavaMail.was@svpapc94> References: <-943382689.2577.1561359037530.JavaMail.was@svpapc94> Message-ID: Hi, Your destination is not responding to ICMP (ping/traceroute). This is not an Atlas issue. Dave Op ma 24 jun. 2019 om 08:50 schreef : > Hello, > > Can some one help me with the reason behind me always getting RTT > unreachable and packet loss 100% for every probe I choose to monitor one > our service from internet in belgium. > > Is there something I am not doing right or can guid me a better way of > doing it. > Even though there is 100% packet loss , my credit balance is still being > consumed. > > [image: inline_55_1561359035868_0.png] > > *Kiran Gunana * > *Network Engineer* > kiran.gunana at colruytgroup.com > T +32 2 363 55 45 (Ext : 55711) > > Colruyt Group > Edingensesteenweg 196 - 1500 Halle > www.colruytgroup.com > > *LinkedIn* > > *Twitter* > > > > > > *Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website > Ce message est soumis > aux conditions disponibles sur notre site web > This message > is subject to the terms and conditions available on our website > * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inline_55_1561359035868_0.png Type: image/png Size: 42682 bytes Desc: not available URL: From daniel.white at hahosting.com Mon Jun 24 09:37:40 2019 From: daniel.white at hahosting.com (Daniel White) Date: Mon, 24 Jun 2019 07:37:40 +0000 Subject: [atlas] any clue rtt unreachable packet loss 100% com234.476.249 In-Reply-To: <-943382689.2577.1561359037530.JavaMail.was@svpapc94> References: <-943382689.2577.1561359037530.JavaMail.was@svpapc94> Message-ID: The IP Address in the subject isn?t valid so if you?re using that, it isn?t going to work. Your Credits are being used because the Probes are still doing the job you?ve instructed them to do. It isn?t their fault that the IP Address is invalid/unreachable. From: ripe-atlas On Behalf Of kiran.gunana at colruytgroup.com Sent: 24 June 2019 07:51 To: ripe-atlas at ripe.net Subject: [atlas] any clue rtt unreachable packet loss 100% com234.476.249 Hello, Can some one help me with the reason behind me always getting RTT unreachable and packet loss 100% for every probe I choose to monitor one our service from internet in belgium. Is there something I am not doing right or can guid me a better way of doing it. Even though there is 100% packet loss , my credit balance is still being consumed. [inline_55_1561359035868_0.png] Kiran Gunana Network Engineer kiran.gunana at colruytgroup.com T +32 2 363 55 45 (Ext : 55711) Colruyt Group Edingensesteenweg 196 - 1500 Halle www.colruytgroup.com LinkedIn Twitter Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website -- This message has been scanned for viruses and dangerous content by: HA Hosting Mail Gateway and is believed to be clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 83838 bytes Desc: image001.png URL: From kiran.gunana at colruytgroup.com Mon Jun 24 16:49:43 2019 From: kiran.gunana at colruytgroup.com (kiran.gunana at colruytgroup.com) Date: Mon, 24 Jun 2019 16:49:43 +0200 (CEST) Subject: [atlas] any clue rtt unreachable packet loss 100% com234.553.190 Message-ID: <2069696867.22039.1561387783809.JavaMail.was@svpapc94> gboonie, Indeed you are right, I had the impression some thing else is breaking it, I did modify and got my results. rg, kiran ----- Original Message: com234.484.306 --------------------------------- From: Dave . (gboonie at gmail.com) To: kiran.gunana at colruytgroup.com Copy: ripe-atlas at ripe.net Subject: Re: [atlas] any clue rtt unreachable packet loss 100% com234.476.249 Date: 24 June 2019 (09:35) Hi, Your destination is not responding to ICMP (ping/traceroute). This is not an Atlas issue. Dave Op ma 24 jun. 2019 om 08:50 schreef : Hello, Can some one help me with the reason behind me always getting RTT unreachable and packet loss 100% for every probe I choose to monitor one our service from internet in belgium. Is there something I am not doing right or can guid me a better way of doing it. Even though there is 100% packet loss , my credit balance is still being consumed. Kiran Gunana Network Engineer kiran.gunana at colruytgroup.com T +32 2 363 55 45 (Ext : 55711) Colruyt Group Edingensesteenweg 196 - 1500 Halle www.colruytgroup.com LinkedIn Twitter Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inline_55_1561359035868_0.png Type: image/x-png Size: 42682 bytes Desc: not available URL: From kiran.gunana at colruytgroup.com Mon Jun 24 16:55:27 2019 From: kiran.gunana at colruytgroup.com (kiran.gunana at colruytgroup.com) Date: Mon, 24 Jun 2019 16:55:27 +0200 (CEST) Subject: [atlas] prometheus exporter atlas_exporter ripe atlas com234.553.762 Message-ID: <929381201.209769.1561388127290.JavaMail.was@svpapc06> Hello, Is any body out there using "https://github.com/czerwonk/atlas_exporter" promethues exporter for exporting metrics from ripe atlas, started using it , wanted to know experience or best practices before spending more time on it. Only exporting ping metrics for now as explained in the article, any other metrics were tried and how were the results, any such help is appreciated :) Kind Regards, Kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website -------------- next part -------------- An HTML attachment was scrubbed... URL: From jirka.novak at upcmail.cz Mon Jun 24 17:54:35 2019 From: jirka.novak at upcmail.cz (Novak Jirka) Date: Mon, 24 Jun 2019 17:54:35 +0200 Subject: [atlas] Probe off-line for 6 days due to bad firmware signature In-Reply-To: <12226b07-f8fc-2634-463a-62f30de87321@ripe.net> References: <5302b305-9506-3140-6d3c-3220c80de905@upcmail.cz> <12226b07-f8fc-2634-463a-62f30de87321@ripe.net> Message-ID: <91aea363-6905-d0db-4be4-feb37fc9e57b@upcmail.cz> Hi Philip, thank you for your replay. My probe is connected to my network infrastracture again, but not connected to RIPE ATLAS infrastracture Could you help me now? Jiri -------- P?vodn? zpr?va -------- > On 2019/06/19 18:38 , Novak Jirka wrote: >> my probe 22424 is off-line due to bad firmware signature error. >> I try to boot it without USB stick many times, then i change the USB >> stick (replace the old one with new one), but it doesnt solve my problem. >> Could you help me? > Hi, > > A bad firmware signature error can happen if the USB stick is broken. > But if it still happens after the USB stick has been replaced then it is > usually a network problem. > > The probe seems disconnected that the moment. If you connect it again, I > can see if I can find out what is going on. > > Philip > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3835 bytes Desc: Elektronicky podpis S/MIME URL: From tschaefer at t-online.de Tue Jun 25 09:58:25 2019 From: tschaefer at t-online.de (=?UTF-8?Q?Thomas_Sch=c3=a4fer?=) Date: Tue, 25 Jun 2019 09:58:25 +0200 Subject: [atlas] raspbian.net/raspbian.org ipv6 peering problems Message-ID: <20a4542c-1d70-382a-432c-fa4a6f46e562@t-online.de> Hello, I am not sure if I am right here with my question. Does someone measurements to the server of "raspbian"? Their hoster (bytemark, iomart, zayo?) seems not to be able to establish correct peerings. At least the peering to AS3320 is broken. I already contacted 3320. They say zayo doesn't fulfill the minimum security requirements. Are more peerings broken? Regards, Thomas From bortzmeyer at nic.fr Tue Jun 25 12:00:07 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 25 Jun 2019 12:00:07 +0200 Subject: [atlas] any clue rtt unreachable packet loss 100% com234.476.249 In-Reply-To: References: <-943382689.2577.1561359037530.JavaMail.was@svpapc94> Message-ID: <20190625100007.cspyqspsxkj5ynh7@nic.fr> On Mon, Jun 24, 2019 at 09:35:32AM +0200, Dave . wrote a message of 872 lines which said: > Your destination is not responding to ICMP (ping/traceroute). This > is not an Atlas issue. And, for the services who wrongly block ICMP echo, there is still hope, Atlas probes can run traceroute with UDP or TCP, which is cool. A good example: From philip.homburg at ripe.net Tue Jun 25 12:09:38 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 25 Jun 2019 12:09:38 +0200 Subject: [atlas] Probe off-line for 6 days due to bad firmware signature In-Reply-To: <91aea363-6905-d0db-4be4-feb37fc9e57b@upcmail.cz> References: <5302b305-9506-3140-6d3c-3220c80de905@upcmail.cz> <12226b07-f8fc-2634-463a-62f30de87321@ripe.net> <91aea363-6905-d0db-4be4-feb37fc9e57b@upcmail.cz> Message-ID: On 2019/06/24 17:54 , Novak Jirka wrote: > My probe is connected to my network infrastracture again, but not > connected to RIPE ATLAS infrastracture > > Could you help me now? Your probe is now fully connected. Philip From bortzmeyer at nic.fr Tue Jun 25 12:09:51 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 25 Jun 2019 12:09:51 +0200 Subject: [atlas] raspbian.net/raspbian.org ipv6 peering problems In-Reply-To: <20a4542c-1d70-382a-432c-fa4a6f46e562@t-online.de> References: <20a4542c-1d70-382a-432c-fa4a6f46e562@t-online.de> Message-ID: <20190625100951.b6kc5waqq6dbklyg@nic.fr> On Tue, Jun 25, 2019 at 09:58:25AM +0200, Thomas Sch?fer wrote a message of 17 lines which said: > Does someone measurements to the server of "raspbian"? Indeed, it's not perfect (the sad state of IPv6 connectivity): % blaeu-reach --requested 100 --by_probe 2001:41c9:1:3ce::1:10 99 probes reported Test #22099153 done at 2019-06-25T10:03:22Z Tests: 86 successful probes (86.9 %), 13 failed (13.1 %), average RTT: 71 ms Comparison with a server with good connectivity (F.root-servers.net): % blaeu-reach --requested 100 --by_probe --old_measurement 22099153 2001:500:2f::f Warning: --requested=100 ignored since a list of probes was requested 99 probes reported Test #22099157 done at 2019-06-25T10:06:11Z Tests: 99 successful probes (100.0 %), 0 failed (0.0 %), average RTT: 39 ms From jirka.novak at upcmail.cz Tue Jun 25 12:27:41 2019 From: jirka.novak at upcmail.cz (Novak Jirka) Date: Tue, 25 Jun 2019 12:27:41 +0200 Subject: [atlas] Probe off-line for 6 days due to bad firmware signature In-Reply-To: References: <5302b305-9506-3140-6d3c-3220c80de905@upcmail.cz> <12226b07-f8fc-2634-463a-62f30de87321@ripe.net> <91aea363-6905-d0db-4be4-feb37fc9e57b@upcmail.cz> Message-ID: <474fdffd-28d6-cc07-96c9-bf6b2833fc93@upcmail.cz> Philip Homburg napsal(a): > On 2019/06/24 17:54 , Novak Jirka wrote: >> My probe is connected to my network infrastracture again, but not >> connected to RIPE ATLAS infrastracture >> >> Could you help me now? > Your probe is now fully connected. > > Philip > Yes, that's true. Thanks for your help. Jiri From bjorn at mork.no Tue Jun 25 12:47:57 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 25 Jun 2019 12:47:57 +0200 Subject: [atlas] raspbian.net/raspbian.org ipv6 peering problems In-Reply-To: <20a4542c-1d70-382a-432c-fa4a6f46e562@t-online.de> ("Thomas =?utf-8?Q?Sch=C3=A4fer=22's?= message of "Tue, 25 Jun 2019 09:58:25 +0200") References: <20a4542c-1d70-382a-432c-fa4a6f46e562@t-online.de> Message-ID: <87zhm63pr6.fsf@miraculix.mork.no> Thomas Sch?fer writes: > Hello, > > I am not sure if I am right here with my question. > > Does someone measurements to the server of "raspbian"? > > Their hoster (bytemark, iomart, zayo?) seems not to be able to > establish correct peerings. At least the peering to AS3320 is broken. > I already contacted 3320. They say zayo doesn't fulfill the minimum > security requirements. The staff at Bytemark are both clueful and responsive in my experience. Did you try to contact them? In what way is the peering broken? Hmm.... I see at https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg that AS3320 seems be missing all the Bytemark IPv6 routes. Looks like they don't have any connectivity to Bytemark's transit upstream, which is AS20860 according to the RIPE db. I believe this is a fault at AS3320. It's not just Bytemark they are filtering out here. You can look up for example 2001:1b40::/32 or 2a01:b040::/32. They are also missing in the AS3320 table. Bj?rn From lists at stefan-spuehler.org Tue Jun 25 13:11:23 2019 From: lists at stefan-spuehler.org (=?UTF-8?Q?Stefan_Sp=c3=bchler?=) Date: Tue, 25 Jun 2019 13:11:23 +0200 Subject: [atlas] raspbian.net/raspbian.org ipv6 peering problems In-Reply-To: <20a4542c-1d70-382a-432c-fa4a6f46e562@t-online.de> References: <20a4542c-1d70-382a-432c-fa4a6f46e562@t-online.de> Message-ID: Hi Thomas, I've done multiple traceroutes https://atlas.ripe.net/measurements/?page=1&af=6&search=target:raspbian.org#tab-traceroute and it looks like only AS3320 is affected. PS: I've added you to the list of people who can use my credits so you can do your own measurements. Regards, Stefan From tschaefer at t-online.de Tue Jun 25 14:26:32 2019 From: tschaefer at t-online.de (Thomas =?ISO-8859-1?Q?Sch=E4fer?=) Date: Tue, 25 Jun 2019 14:26:32 +0200 Subject: [atlas] raspbian.net/raspbian.org ipv6 peering problems In-Reply-To: <87zhm63pr6.fsf@miraculix.mork.no> References: <20a4542c-1d70-382a-432c-fa4a6f46e562@t-online.de> <87zhm63pr6.fsf@miraculix.mork.no> Message-ID: <3851374.ivn22RUEWg@witz> Am Dienstag, 25. Juni 2019, 12:47:57 CEST schrieb Bj?rn Mork: > Hmm.... I see at https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg > that AS3320 seems be missing all the Bytemark IPv6 routes. Looks like > they don't have any connectivity to Bytemark's transit upstream, which > is AS20860 according to the RIPE db. I believe this is a fault at > AS3320. It's not just Bytemark they are filtering out here. I used the looking glasses at both sites. They don't see each other. I already contacted the peering guy at AS3320. He wrote me that zayo doesn't maintain a "AS-set" anymore, so DTAG cannot filter on it. I have no much clue about bgp, as-sets, peeringdb, rpki and so on. It's not my business. I am just a user/customer of the DTAG and other ISPs. Of course there are discussions about security filtering and money, even if bigger ISPs are involved. In this case it seems to me it's a security thing. For me it is just one connectivity failure. ( I am part of the costumer trial ipv6-only at DTAG) Regards, Thomas From bortzmeyer at nic.fr Tue Jun 25 14:55:42 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 25 Jun 2019 14:55:42 +0200 Subject: [atlas] When to consider a measurement finished In-Reply-To: <20190618180823.GA7783@wfstore.wbdv.nl> References: <20190618180823.GA7783@wfstore.wbdv.nl> Message-ID: <20190625125542.glazgd4bz3qnjw6r@nic.fr> On Tue, Jun 18, 2019 at 08:08:23PM +0200, Wouter de Vries wrote a message of 26 lines which said: > What heuristics/method do you recommend to determine whether to consider > a measurement as finished? Probing until N % of the requested probes replied. This is implemented in blaeu , you may check the code . From bjorn at mork.no Tue Jun 25 15:17:04 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 25 Jun 2019 15:17:04 +0200 Subject: [atlas] raspbian.net/raspbian.org ipv6 peering problems In-Reply-To: <3851374.ivn22RUEWg@witz> ("Thomas =?utf-8?Q?Sch=C3=A4fer=22'?= =?utf-8?Q?s?= message of "Tue, 25 Jun 2019 14:26:32 +0200") References: <20a4542c-1d70-382a-432c-fa4a6f46e562@t-online.de> <87zhm63pr6.fsf@miraculix.mork.no> <3851374.ivn22RUEWg@witz> Message-ID: <87mui54xf3.fsf@miraculix.mork.no> Thomas Sch?fer writes: > Am Dienstag, 25. Juni 2019, 12:47:57 CEST schrieb Bj?rn Mork: > >> Hmm.... I see at https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg >> that AS3320 seems be missing all the Bytemark IPv6 routes. Looks like >> they don't have any connectivity to Bytemark's transit upstream, which >> is AS20860 according to the RIPE db. I believe this is a fault at >> AS3320. It's not just Bytemark they are filtering out here. > > I used the looking glasses at both sites. They don't see each other. > I already contacted the peering guy at AS3320. He wrote me that zayo doesn't > maintain a "AS-set" anymore, so DTAG cannot filter on it. AS20860 (IOMART) is the transit provider for Bytemark, and they maintain the AS-IOMART as-set which includes the AS-BYTEMARK as-set among others. AS20860 again use AS174 (Cogent) and AS6461 (Zayo) for transit, and peers with a number of other ISPs mostly at LINX. For some reason not AS3320 though. But this should not matter AS3320 is obviously peering with Cogent, and should get the routes there at least. But they could obviously improve their connectivity a bit.... And there is something odd about their Cogent peering. Looking for the IPv6 prefixes DTAG has received from via AS174: https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg&query=ipv6+bgp+regexp¶=.*+174+.*&server=194.25.0.222&EXEC=Execute Not much to see there. There should have been a *lot* more routes there, especially given their lack of other peers. > I have no much clue about bgp, as-sets, peeringdb, rpki and so on. It's not my > business. I am just a user/customer of the DTAG and other ISPs. Well, it's all a part of the IPv6 fun isn't it? :-) > Of course there are discussions about security filtering and money, even if > bigger ISPs are involved. In this case it seems to me it's a security thing. Nope. You don't drop parts of the Internet because you don't like their policies. The Zayo thing is a bad excuse. They should explain why they don't take the routes from Cogent then, and also why they don't peer with IOMART at LINX. > For me it is just one connectivity failure. ( I am part of the costumer trial > ipv6-only at DTAG) I suggest pushing your contacts at DTAG. As it is, they provide only limited IPv6 connectivity to you. This is incompatible with any IPv6-only product, trial or not. Bj?rn From lprehn at mpi-inf.mpg.de Fri Jun 28 17:09:27 2019 From: lprehn at mpi-inf.mpg.de (Lars Prehn) Date: Fri, 28 Jun 2019 17:09:27 +0200 Subject: [atlas] Filter for all results of a probe within a given timeintervall Message-ID: <3a2e5c59-71e9-4451-de14-5cc3e13e00be@mpi-inf.mpg.de> Hi everyone, I'm currently trying to retrieve ping and/or traceroute results for a specific probe in a given time interval via cousteau and/or the measurement API directly. It seems like I'm not clever enough to get it done. Is there a possibility to achieve this goal without iterating over each and every measurement to check whether or not the probes and the time match? Best regards, Lars From marcel.flores at verizondigitalmedia.com Fri Jun 28 20:56:02 2019 From: marcel.flores at verizondigitalmedia.com (Marcel Flores) Date: Fri, 28 Jun 2019 12:56:02 -0600 Subject: [atlas] Streaming API Losses Message-ID: Hi all, We've been exploring the use of the Streaming API to collect result stream data for a set of user defined measurements, in particular using the interface available in Cousteau. However, we've found that the Streaming API seems to be "lossy", with only a fraction of the results reported through the usual system making their way into the stream. I've not been able to find any sort of pattern on what does and doesn't make it through. Does anyone else have experience with this? Are there known limitations with the Streaming API? If so, has anyone worked out any clever workflows to accommodate? Thanks very much! -- *Marcel Flores, PhD* | Sr. Research Scientist research.verizondigitalmedia.com | AS15133 p: +1 310.593.6880 e: marcel.flores at verizondigitalmedia.com 13031 W Jefferson Blvd. Building 900, Los Angeles, CA 90094 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at groetzner.net Sat Jun 29 16:20:02 2019 From: ripe at groetzner.net (Sascha Groetzner) Date: Sat, 29 Jun 2019 16:20:02 +0200 Subject: [atlas] Search for Probe Message-ID: Hello, I would like to take part at the ripe atlas grip. I applied already for a probe and still waiting for delivery since a long time. Does anyone have a probe which isn`t in use or would like to transfer? best regards Sascha Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum