From klaus.mailinglists at pernau.at Wed Jul 2 10:19:14 2014 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 02 Jul 2014 10:19:14 +0200 Subject: [atlas] tracing from anchor nodes Message-ID: <53B3C082.7050809@pernau.at> Hi! According to DNSMON [1] r.ns.at IPv4 is not reachable from us-bos-as11488. Are there any tools available to analyse the problem from the anchor? E.g. performing a traceroute from the respective anchor node? Thanks Klaus [1] https://atlas.ripe.net/dnsmon/group/at.?dnsmon.session.color_range_pls=0-66-66-99-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=194.0.25.10&dnsmon.zone=at.&dnsmon.startTime=1404246000&dnsmon.endTime=1404288000&dnsmon.ipVersion=both From gilles.massen at restena.lu Wed Jul 2 10:24:43 2014 From: gilles.massen at restena.lu (Gilles Massen) Date: Wed, 02 Jul 2014 10:24:43 +0200 Subject: [atlas] tracing from anchor nodes In-Reply-To: <53B3C082.7050809@pernau.at> References: <53B3C082.7050809@pernau.at> Message-ID: <53B3C1CB.3020703@restena.lu> Hi, On 07/02/2014 10:19 AM, Klaus Darilion wrote: > According to DNSMON [1] r.ns.at IPv4 is not reachable from > us-bos-as11488. Are there any tools available to analyse the problem > from the anchor? E.g. performing a traceroute from the respective anchor > node? Define an UDM, and set the anchor as source. Seems obvious, so maybe I've misunderstood the problem? Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From astrikos at ripe.net Wed Jul 2 10:29:13 2014 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 02 Jul 2014 10:29:13 +0200 Subject: [atlas] tracing from anchor nodes In-Reply-To: <53B3C082.7050809@pernau.at> References: <53B3C082.7050809@pernau.at> Message-ID: <53B3C2D9.3030909@ripe.net> Hi Klaus, DSNMON itself is doing also traceroutes. So, for each anchor you can see its traceroute towards each target. You have to click on a specific tile and you will get a pop up window with the closest time-wise traceroute(s). Regards, Andreas On 7/2/14, 10:19 AM, Klaus Darilion wrote: > Hi! > > According to DNSMON [1] r.ns.at IPv4 is not reachable from > us-bos-as11488. Are there any tools available to analyse the problem > from the anchor? E.g. performing a traceroute from the respective anchor > node? > > Thanks > Klaus > > > [1] > https://atlas.ripe.net/dnsmon/group/at.?dnsmon.session.color_range_pls=0-66-66-99-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=194.0.25.10&dnsmon.zone=at.&dnsmon.startTime=1404246000&dnsmon.endTime=1404288000&dnsmon.ipVersion=both > From klaus.mailinglists at pernau.at Wed Jul 2 13:52:12 2014 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 02 Jul 2014 13:52:12 +0200 Subject: [atlas] tracing from anchor nodes In-Reply-To: <53B3C1CB.3020703@restena.lu> References: <53B3C082.7050809@pernau.at> <53B3C1CB.3020703@restena.lu> Message-ID: <53B3F26C.4010901@pernau.at> On 02.07.2014 10:24, Gilles Massen wrote: > Hi, > > On 07/02/2014 10:19 AM, Klaus Darilion wrote: > >> According to DNSMON [1] r.ns.at IPv4 is not reachable from >> us-bos-as11488. Are there any tools available to analyse the problem >> from the anchor? E.g. performing a traceroute from the respective anchor >> node? > > Define an UDM, and set the anchor as source. Seems obvious, so maybe > I've misunderstood the problem? Ups, I have not known that anchors have a probe id and can be used like any other probe. Thanks Klaus PS: Meanwhile I found out the problem is a routing problem on the reverse path .... From hvjunk at gmail.com Thu Jul 3 21:43:22 2014 From: hvjunk at gmail.com (Hendrik Visage) Date: Thu, 3 Jul 2014 21:43:22 +0200 Subject: [atlas] Fwd: Deleting/editing a UDM: Not Owner In-Reply-To: References: Message-ID: Good day, I'm trying to delete/stop/edit an UDM, but I get this error: Not Owner when I click on the settings tab. Screen grab: https://www.dropbox.com/s/p0u2oiboct3ut23/Screenshot%202014-07-03%2021.21.17.png Any advice ideas how to do that? Thanks HEndrik From hvjunk at gmail.com Thu Jul 3 21:43:49 2014 From: hvjunk at gmail.com (Hendrik Visage) Date: Thu, 3 Jul 2014 21:43:49 +0200 Subject: [atlas] Fwd: monitoring RFC1918 IPs In-Reply-To: References: Message-ID: Hi there, I'd like to monitor a couple of internal routes from one of my probes, but I get this error: Ping: Field 'target' : Measurement target "10.23.0.1" is invalid. Is that a limit somewhere? possible to relax that for probes owned/operated by me? Thanks HEndrik From Ondrej.Caletka at cesnet.cz Fri Jul 4 12:23:35 2014 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?B?T25kxZllaiBDYWxldGth?=) Date: Fri, 04 Jul 2014 12:23:35 +0200 Subject: [atlas] Probe connectivity status update interval Message-ID: <53B680A7.3010308@cesnet.cz> Hello list, yesterday, we've deployed IPv6 in the network probe #16666 is located. The probe obtained its address via SLAAC and is world-pingable, however the Atlas system still haven't recognized the probe has IPv6 connectivity. When scheduling IPv6 UDMs for this probe, they are stuck in state "Scheduling" - see UDM #1694838 or #1694575. I guess that the system avoids scheduling IPv6 measurements to probes without IPv6 connectivity. How often is the connectivity status updated? Should we replug the probe to update its status? Cheers, Ond?ej Caletka -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5563 bytes Desc: Elektronicky podpis S/MIME URL: From s.eravuchira at jacobs-university.de Fri Jul 4 16:24:18 2014 From: s.eravuchira at jacobs-university.de (Eravuchira, Steffie Jacob) Date: Fri, 4 Jul 2014 14:24:18 +0000 Subject: [atlas] How to find the correct ASN of a probe? Message-ID: <081E9415D79F9A469A4B6C79815FC09205C28701@SXCHMB01.jacobs.jacobs-university.de> Hello, The RIPE Atlas probe API [1] says that the probe with ID 14468 belongs to the ASN 6871. As per the RIPE stat API [2], the holder for ASN 6871 is PlusNet PLC,GB. I run a traceroute measurement from the same probe (Probe ID 14468) and the IP address of the second hop ICMP response is "86.4.10.1". But the RIPE stat API [2] shows that "86.4.10.1" belongs to the prefix announced by ASN 5089, NTL Virgin Media Limited,GB. Could someone tell me how I can find the correct AS which the probe belongs to? [1] https://atlas.ripe.net/api/v1/probe/?id=14468 [2] https://stat.ripe.net/ Kind Regards, Steffie From philip.homburg at ripe.net Mon Jul 7 10:33:59 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 07 Jul 2014 10:33:59 +0200 Subject: [atlas] How to find the correct ASN of a probe? In-Reply-To: <081E9415D79F9A469A4B6C79815FC09205C28701@SXCHMB01.jacobs.jacobs-university.de> References: <081E9415D79F9A469A4B6C79815FC09205C28701@SXCHMB01.jacobs.jacobs-university.de> Message-ID: <53BA5B77.2040801@ripe.net> Hi Steffie, On 2014/07/04 16:24 , Eravuchira, Steffie Jacob wrote: > Hello, > > The RIPE Atlas probe API [1] says that the probe with ID 14468 belongs to the > ASN 6871. As per the RIPE stat API [2], the holder for ASN 6871 is PlusNet PLC,GB. > > I run a traceroute measurement from the same probe (Probe ID 14468) and the > IP address of the second hop ICMP response is "86.4.10.1". But the RIPE stat > API [2] shows that "86.4.10.1" belongs to the prefix announced by ASN 5089, > NTL Virgin Media Limited,GB. > > Could someone tell me how I can find the correct AS which the probe belongs to? When the probe connects to the Atlas infrastructure, the IPv4 source address comes from a /16 announced by AS 6871. I have no idea why the router in the traceroute is in a different AS. So I'd say that based on its IP address, the probe belongs to AS 6871. Philip From daniel.karrenberg at ripe.net Mon Jul 7 11:18:36 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 07 Jul 2014 11:18:36 +0200 Subject: [atlas] Fwd: monitoring RFC1918 IPs In-Reply-To: References: Message-ID: <53BA65EC.8090108@ripe.net> On 3.07.14 21:43 , Hendrik Visage wrote: > Hi there, > > I'd like to monitor a couple of internal routes from one of my > probes, but I get this error: > Ping: Field 'target' : Measurement target "10.23.0.1" is invalid. > > Is that a limit somewhere? possible to relax that for probes > owned/operated by me? Hi Hendrik, [Sorry for the latish response. The office was closed for our summer outing on Friday.] We do not allow this because the usefulness and semantics of such measurements is local and we assumed that this can be done with local resources outside of RIPE Atlas. Also we intended to prevent others 'snooping around' in local infrastructure. If allowing this for the probe host themselves is something more people want, we can certainly add it to the road-map. If this is a one-off, we can probably accommodate you with a "one-time special". Daniel From colinj at mx5.org.uk Mon Jul 7 11:24:52 2014 From: colinj at mx5.org.uk (Colin Johnston) Date: Mon, 7 Jul 2014 10:24:52 +0100 Subject: [atlas] Fwd: monitoring RFC1918 IPs In-Reply-To: <53BA65EC.8090108@ripe.net> References: <53BA65EC.8090108@ripe.net> Message-ID: <28655563-F72D-425F-953B-6C406FB213CE@mx5.org.uk> It would for useful for internal network monitoring for backup lans if such networks could be monitored via probes. also satellite networks nat internally in same fashion using internal network address space. Colin On 7 Jul 2014, at 10:18, Daniel Karrenberg wrote: > On 3.07.14 21:43 , Hendrik Visage wrote: >> Hi there, >> >> I'd like to monitor a couple of internal routes from one of my >> probes, but I get this error: >> Ping: Field 'target' : Measurement target "10.23.0.1" is invalid. >> >> Is that a limit somewhere? possible to relax that for probes >> owned/operated by me? > > > Hi Hendrik, > > [Sorry for the latish response. The office was closed for our summer > outing on Friday.] > > We do not allow this because the usefulness and semantics of such > measurements is local and we assumed that this can be done with local > resources outside of RIPE Atlas. Also we intended to prevent others > 'snooping around' in local infrastructure. > > If allowing this for the probe host themselves is something more people > want, we can certainly add it to the road-map. > > If this is a one-off, we can probably accommodate you with a "one-time > special". > > Daniel > > > > From vnaumov at ripe.net Mon Jul 7 12:27:11 2014 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 07 Jul 2014 12:27:11 +0200 Subject: [atlas] Fwd: Deleting/editing a UDM: Not Owner In-Reply-To: References: Message-ID: <53BA75FF.10909@ripe.net> Hi Hendrik, It looks like you clicked the "Settings" button while being logged off. Most probably you left the page and then the system logged you off. Could you try it again? WBR /vty On 7/3/14, 9:43 PM, Hendrik Visage wrote: > Good day, > > I'm trying to delete/stop/edit an UDM, but I get this error: Not > Owner when I click on the settings tab. > > Screen grab: > https://www.dropbox.com/s/p0u2oiboct3ut23/Screenshot%202014-07-03%2021.21.17.png > > Any advice ideas how to do that? > > Thanks > HEndrik > From hvjunk at gmail.com Mon Jul 7 13:27:29 2014 From: hvjunk at gmail.com (Hendrik Visage) Date: Mon, 7 Jul 2014 13:27:29 +0200 Subject: [atlas] Fwd: monitoring RFC1918 IPs In-Reply-To: <28655563-F72D-425F-953B-6C406FB213CE@mx5.org.uk> References: <53BA65EC.8090108@ripe.net> <28655563-F72D-425F-953B-6C406FB213CE@mx5.org.uk> Message-ID: On Mon, Jul 7, 2014 at 11:24 AM, Colin Johnston wrote: > It would for useful for internal network monitoring for backup lans if such networks could be monitored via probes. also satellite networks nat internally in same fashion using internal network address space. Same for 3G networks here in ZA that issues RFC1918 IPs, so to check the "speed"/response of your local link with the probe, necessitates a ping to a RFC1918 IP. My use case was for checking a VPN link, but yes, that is a local case, and the only real need I could come up for using my credits :) > On 7 Jul 2014, at 10:18, Daniel Karrenberg wrote: > >> On 3.07.14 21:43 , Hendrik Visage wrote: >>> Hi there, >>> >>> I'd like to monitor a couple of internal routes from one of my >>> probes, but I get this error: >>> Ping: Field 'target' : Measurement target "10.23.0.1" is invalid. >>> >>> Is that a limit somewhere? possible to relax that for probes >>> owned/operated by me? >> >> >> Hi Hendrik, >> >> [Sorry for the latish response. The office was closed for our summer >> outing on Friday.] >> >> We do not allow this because the usefulness and semantics of such >> measurements is local and we assumed that this can be done with local >> resources outside of RIPE Atlas. Also we intended to prevent others >> 'snooping around' in local infrastructure. >> >> If allowing this for the probe host themselves is something more people >> want, we can certainly add it to the road-map. >> >> If this is a one-off, we can probably accommodate you with a "one-time >> special". >> >> Daniel >> >> >> >> > From hvjunk at gmail.com Mon Jul 7 13:32:52 2014 From: hvjunk at gmail.com (Hendrik Visage) Date: Mon, 7 Jul 2014 13:32:52 +0200 Subject: [atlas] Fwd: Deleting/editing a UDM: Not Owner In-Reply-To: <53BA75FF.10909@ripe.net> References: <53BA75FF.10909@ripe.net> Message-ID: On Mon, Jul 7, 2014 at 12:27 PM, Viktor Naumov wrote: > Hi Hendrik, > > It looks like you clicked the "Settings" button while being logged off. Most > probably you left the page and then the system logged you off. > Could you try it again? Same problem. Logged in to atlas.ripe.net Clicked on my measurement clicked on the settings cog-wheel, it says loading data, then: "Failure: Not owner" Tried it with Safari (MacOSX 10.9.2) to discount my FireFox privacy plugins/add-on as being guilty, and the same result > > WBR > > /vty > > > On 7/3/14, 9:43 PM, Hendrik Visage wrote: >> >> Good day, >> >> I'm trying to delete/stop/edit an UDM, but I get this error: Not >> Owner when I click on the settings tab. >> >> Screen grab: >> >> https://www.dropbox.com/s/p0u2oiboct3ut23/Screenshot%202014-07-03%2021.21.17.png >> >> Any advice ideas how to do that? >> >> Thanks >> HEndrik >> > From jared at puck.nether.net Mon Jul 7 15:58:53 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 7 Jul 2014 09:58:53 -0400 Subject: [atlas] Fwd: monitoring RFC1918 IPs In-Reply-To: References: <53BA65EC.8090108@ripe.net> <28655563-F72D-425F-953B-6C406FB213CE@mx5.org.uk> Message-ID: On Jul 7, 2014, at 7:27 AM, Hendrik Visage wrote: > On Mon, Jul 7, 2014 at 11:24 AM, Colin Johnston wrote: >> It would for useful for internal network monitoring for backup lans if such networks could be monitored via probes. also satellite networks nat internally in same fashion using internal network address space. > > Same for 3G networks here in ZA that issues RFC1918 IPs, so to check > the "speed"/response of your local link with the probe, necessitates a > ping to a RFC1918 IP. > > My use case was for checking a VPN link, but yes, that is a local > case, and the only real need I could come up for using my credits :) Seems like they should be numbered with IPv6 addresses instead? :) Then this could work ... or can you work around this by using a DNS name that points to 1918 IP? - Jared From alexsaroyan at gmail.com Tue Jul 8 11:23:59 2014 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Tue, 08 Jul 2014 13:23:59 +0400 Subject: [atlas] Fwd: Deleting/editing a UDM: Not Owner In-Reply-To: <53BA75FF.10909@ripe.net> References: <53BA75FF.10909@ripe.net> Message-ID: <53BBB8AF.30007@gmail.com> Hi, I have faced similar problem. Delete button is inactive and going to settings sometimes says "not owner". Basically I can't delete or edit UDM which is running for a while. I have opened a ticket (1132194) to Ripe Atlas team. Regards. /Alex Saroyan On 07/07/2014 02:27 PM, Viktor Naumov wrote: > Hi Hendrik, > > It looks like you clicked the "Settings" button while being logged > off. Most probably you left the page and then the system logged you off. > Could you try it again? > > WBR > > /vty > > On 7/3/14, 9:43 PM, Hendrik Visage wrote: >> Good day, >> >> I'm trying to delete/stop/edit an UDM, but I get this error: Not >> Owner when I click on the settings tab. >> >> Screen grab: >> https://www.dropbox.com/s/p0u2oiboct3ut23/Screenshot%202014-07-03%2021.21.17.png >> >> Any advice ideas how to do that? >> >> Thanks >> HEndrik >> > > From vnaumov at ripe.net Tue Jul 8 12:58:23 2014 From: vnaumov at ripe.net (Viktor Naumov) Date: Tue, 08 Jul 2014 12:58:23 +0200 Subject: [atlas] Fwd: Deleting/editing a UDM: Not Owner In-Reply-To: <53BBB8AF.30007@gmail.com> References: <53BA75FF.10909@ripe.net> <53BBB8AF.30007@gmail.com> Message-ID: <53BBCECF.4010902@ripe.net> Hi Alex, I'm working on it. WBR /vty On 7/8/14, 11:23 AM, Alex Saroyan wrote: > Hi, > > I have faced similar problem. Delete button is inactive and going to > settings sometimes says "not owner". Basically I can't delete or edit > UDM which is running for a while. > I have opened a ticket (1132194) to Ripe Atlas team. > > Regards. > /Alex Saroyan > > On 07/07/2014 02:27 PM, Viktor Naumov wrote: >> Hi Hendrik, >> >> It looks like you clicked the "Settings" button while being logged >> off. Most probably you left the page and then the system logged you off. >> Could you try it again? >> >> WBR >> >> /vty >> >> On 7/3/14, 9:43 PM, Hendrik Visage wrote: >>> Good day, >>> >>> I'm trying to delete/stop/edit an UDM, but I get this error: Not >>> Owner when I click on the settings tab. >>> >>> Screen grab: >>> https://www.dropbox.com/s/p0u2oiboct3ut23/Screenshot%202014-07-03%2021.21.17.png >>> >>> >>> Any advice ideas how to do that? >>> >>> Thanks >>> HEndrik >>> >> >> > > From vnaumov at ripe.net Tue Jul 8 14:39:07 2014 From: vnaumov at ripe.net (Viktor Naumov) Date: Tue, 08 Jul 2014 14:39:07 +0200 Subject: [atlas] Fwd: Deleting/editing a UDM: Not Owner In-Reply-To: <53BBCECF.4010902@ripe.net> References: <53BA75FF.10909@ripe.net> <53BBB8AF.30007@gmail.com> <53BBCECF.4010902@ripe.net> Message-ID: <53BBE66B.8090909@ripe.net> it should be fixed now. Sorry for inconvenience. WBR /vty On 7/8/14, 12:58 PM, Viktor Naumov wrote: > Hi Alex, > > I'm working on it. > > WBR > > /vty > > On 7/8/14, 11:23 AM, Alex Saroyan wrote: >> Hi, >> >> I have faced similar problem. Delete button is inactive and going to >> settings sometimes says "not owner". Basically I can't delete or edit >> UDM which is running for a while. >> I have opened a ticket (1132194) to Ripe Atlas team. >> >> Regards. >> /Alex Saroyan >> >> On 07/07/2014 02:27 PM, Viktor Naumov wrote: >>> Hi Hendrik, >>> >>> It looks like you clicked the "Settings" button while being logged >>> off. Most probably you left the page and then the system logged you >>> off. >>> Could you try it again? >>> >>> WBR >>> >>> /vty >>> >>> On 7/3/14, 9:43 PM, Hendrik Visage wrote: >>>> Good day, >>>> >>>> I'm trying to delete/stop/edit an UDM, but I get this error: Not >>>> Owner when I click on the settings tab. >>>> >>>> Screen grab: >>>> https://www.dropbox.com/s/p0u2oiboct3ut23/Screenshot%202014-07-03%2021.21.17.png >>>> >>>> >>>> Any advice ideas how to do that? >>>> >>>> Thanks >>>> HEndrik >>>> >>> >>> >> >> > > From alexsaroyan at gmail.com Tue Jul 8 15:01:59 2014 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Tue, 08 Jul 2014 17:01:59 +0400 Subject: [atlas] Fwd: Deleting/editing a UDM: Not Owner In-Reply-To: <53BBE66B.8090909@ripe.net> References: <53BA75FF.10909@ripe.net> <53BBB8AF.30007@gmail.com> <53BBCECF.4010902@ripe.net> <53BBE66B.8090909@ripe.net> Message-ID: <53BBEBC7.3000703@gmail.com> Hi, I confirm, in my case it is solved. Regards. /Alex Saroyan On 07/08/2014 04:39 PM, Viktor Naumov wrote: > it should be fixed now. Sorry for inconvenience. > > WBR > > /vty > > > On 7/8/14, 12:58 PM, Viktor Naumov wrote: >> Hi Alex, >> >> I'm working on it. >> >> WBR >> >> /vty >> >> On 7/8/14, 11:23 AM, Alex Saroyan wrote: >>> Hi, >>> >>> I have faced similar problem. Delete button is inactive and going to >>> settings sometimes says "not owner". Basically I can't delete or >>> edit UDM which is running for a while. >>> I have opened a ticket (1132194) to Ripe Atlas team. >>> >>> Regards. >>> /Alex Saroyan >>> >>> On 07/07/2014 02:27 PM, Viktor Naumov wrote: >>>> Hi Hendrik, >>>> >>>> It looks like you clicked the "Settings" button while being logged >>>> off. Most probably you left the page and then the system logged you >>>> off. >>>> Could you try it again? >>>> >>>> WBR >>>> >>>> /vty >>>> >>>> On 7/3/14, 9:43 PM, Hendrik Visage wrote: >>>>> Good day, >>>>> >>>>> I'm trying to delete/stop/edit an UDM, but I get this error: Not >>>>> Owner when I click on the settings tab. >>>>> >>>>> Screen grab: >>>>> https://www.dropbox.com/s/p0u2oiboct3ut23/Screenshot%202014-07-03%2021.21.17.png >>>>> >>>>> >>>>> Any advice ideas how to do that? >>>>> >>>>> Thanks >>>>> HEndrik >>>>> >>>> >>>> >>> >>> >> >> > From hvjunk at gmail.com Tue Jul 8 15:21:13 2014 From: hvjunk at gmail.com (Hendrik Visage) Date: Tue, 8 Jul 2014 15:21:13 +0200 Subject: [atlas] Fwd: Deleting/editing a UDM: Not Owner In-Reply-To: <53BBEBC7.3000703@gmail.com> References: <53BA75FF.10909@ripe.net> <53BBB8AF.30007@gmail.com> <53BBCECF.4010902@ripe.net> <53BBE66B.8090909@ripe.net> <53BBEBC7.3000703@gmail.com> Message-ID: Thanx Victor, fixed for me too :) On Tue, Jul 8, 2014 at 3:01 PM, Alex Saroyan wrote: > Hi, > > I confirm, in my case it is solved. > > Regards. > /Alex Saroyan > > > On 07/08/2014 04:39 PM, Viktor Naumov wrote: >> >> it should be fixed now. Sorry for inconvenience. >> >> WBR >> >> /vty >> >> >> On 7/8/14, 12:58 PM, Viktor Naumov wrote: >>> >>> Hi Alex, >>> >>> I'm working on it. >>> >>> WBR >>> >>> /vty >>> >>> On 7/8/14, 11:23 AM, Alex Saroyan wrote: >>>> >>>> Hi, >>>> >>>> I have faced similar problem. Delete button is inactive and going to >>>> settings sometimes says "not owner". Basically I can't delete or edit UDM >>>> which is running for a while. >>>> I have opened a ticket (1132194) to Ripe Atlas team. >>>> >>>> Regards. >>>> /Alex Saroyan >>>> >>>> On 07/07/2014 02:27 PM, Viktor Naumov wrote: >>>>> >>>>> Hi Hendrik, >>>>> >>>>> It looks like you clicked the "Settings" button while being logged off. >>>>> Most probably you left the page and then the system logged you off. >>>>> Could you try it again? >>>>> >>>>> WBR >>>>> >>>>> /vty >>>>> >>>>> On 7/3/14, 9:43 PM, Hendrik Visage wrote: >>>>>> >>>>>> Good day, >>>>>> >>>>>> I'm trying to delete/stop/edit an UDM, but I get this error: Not >>>>>> Owner when I click on the settings tab. >>>>>> >>>>>> Screen grab: >>>>>> >>>>>> https://www.dropbox.com/s/p0u2oiboct3ut23/Screenshot%202014-07-03%2021.21.17.png >>>>>> >>>>>> Any advice ideas how to do that? >>>>>> >>>>>> Thanks >>>>>> HEndrik >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > From jared at puck.nether.net Tue Jul 8 20:19:03 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 8 Jul 2014 14:19:03 -0400 Subject: [atlas] Credit Usage math Message-ID: I am in the lucky position of earning more credits than I currently care to spend so have engaged in a bit of a 'share the wealth' campaign. (Yes, you can ask me for credits, but I am hoping something can be done to improve this as well, read on). I just sent 1 million credits to someone and now my credit "burn" rate is calculated as a large negative number. (I recently sent someone else 10x that and it caused odd math as well). It seems a few things happen: 1) E-Mail alerts go out based on credit consumption (including transfers) in past N hours. 2) Credit "earn rate" calculation includes transfers vs UDM samples. Currently I have income of almost 1M/day but shows -4k/hour due to UDM + transfer. This means when I sent 10m credits to someone, the system thought I was using 10m credits/day and emailed me a few times because it thought I would run out of credits when my UDMs gave me a few more weeks of time with my balance. I also have a large number of "small" UDMs which post quite often, so have 397 pages of the recent credit history. Are there plans to improve this display? - Jared From lhestina at ripe.net Fri Jul 11 12:00:20 2014 From: lhestina at ripe.net (Lia Hestina) Date: Fri, 11 Jul 2014 12:00:20 +0200 Subject: [atlas] CEZNET, z.s.p.o has joined RIPE Atlas anchors Message-ID: <77631B1F-E0B7-48A4-A55A-ED727B949BDE@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called cz-prg-as2852 and it is hosted by CEZNET, z.s.p.o. in Prague, Czech Republic. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2622 bytes Desc: not available URL: From Ondrej.Caletka at cesnet.cz Sat Jul 12 09:26:50 2014 From: Ondrej.Caletka at cesnet.cz (=?windows-1250?Q?Ond=F8ej_Caletka?=) Date: Sat, 12 Jul 2014 09:26:50 +0200 Subject: [atlas] CEZNET, z.s.p.o has joined RIPE Atlas anchors In-Reply-To: <77631B1F-E0B7-48A4-A55A-ED727B949BDE@ripe.net> References: <77631B1F-E0B7-48A4-A55A-ED727B949BDE@ripe.net> Message-ID: <53C0E33A.60603@cesnet.cz> Dne 11.7.2014 12:00, Lia Hestina napsal(a): > The new anchor is called cz-prg-as2852 and it is hosted by CEZNET, > z.s.p.o. in Prague, Czech Republic. Hello Lia and others, thanks for the announcment and also for perfect cooperation during setting the anchor up. Just a small clarification, our association (actually NREN) is called CESNET, not CEZNET 8) Best Regards, Ond?ej Caletka, CESNET -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3248 bytes Desc: Elektronicky podpis S/MIME URL: From mail at johnbond.org Sat Jul 12 15:28:08 2014 From: mail at johnbond.org (john) Date: Sat, 12 Jul 2014 15:28:08 +0200 Subject: [atlas] Atlas nagios tools Message-ID: <53C137E8.4070501@johnbond.org> Hello all, i would like to introduce a tool[1] i have been developing on and off for a bit of time. its uses the atlas latest call[2] and sagan[3] to preform nagios checks based on measurement results. it supports checking a wide range of ssl, dns and http parameters which i have tried to document on github[1]. it also supports checking ping however i think it is better to use the atlas status checks[4][5] for this. The git hub repo contains some sample nagios configs which can be seen in action at https://icinga.johnbond.org/ (ripeatlas/ripeatlas). at $dayjob we dont use nagios/icinga so this is not well tested and one should expect some bugs. if you dare inspect the source you can definitely expect spelling mistakes and hacks. Thanks to I?igo Ortiz de Urbina and Wolfgang Nagele for patches. Also thanks to Daniel Quinn and Philip Homburg for working with me integrating some changes to sagan. feedback, criticism and patches most welcome John *as http is a restricted measurement this has received little testing [1]https://github.com/b4ldr/atlas [2]https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-latest-results-api-and-parsing-library [3]https://github.com/RIPE-NCC/ripe.atlas.sagan [4]https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atlas-status-checks [5]https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib/blob/master/scripts_for_nagios_icinga_alerts From lhestina at ripe.net Mon Jul 14 17:01:23 2014 From: lhestina at ripe.net (Lia Hestina) Date: Mon, 14 Jul 2014 17:01:23 +0200 Subject: [atlas] Solido Networks ApS has joined RIPE Atlas anchors Message-ID: <2FC3AE25-4F7A-4B24-9161-3F24D7428ADC@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called dk-blp-as59469 and it is hosted by Solido Networks ApS in Ballerup, Denmark. Our congratulations to Solido Networks ApS! This is the first anchor in Denmark. In our announcement about last week's new anchor, there was a typo in the company name and we would like to apologise for this. The anchor, cz-prg-as2852, is hosted by CESNET, z. s. p. o. in Prague, Czech Republic. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2622 bytes Desc: not available URL: From rob.turner.derby at gmail.com Tue Jul 15 12:59:49 2014 From: rob.turner.derby at gmail.com (Rob Turner) Date: Tue, 15 Jul 2014 11:59:49 +0100 Subject: [atlas] Local resolver for one off DNS measurement Message-ID: Hi is it possible to perform a one off DNS A record test that uses each probes local resolver? I think this would be handy to test DNS propagation. Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at johnbond.org Tue Jul 15 13:42:24 2014 From: mail at johnbond.org (john) Date: Tue, 15 Jul 2014 13:42:24 +0200 Subject: [atlas] Local resolver for one off DNS measurement In-Reply-To: References: Message-ID: <53C513A0.7040303@johnbond.org> Hi Rob On 15/07/14 12:59, Rob Turner wrote: > Hi is it possible to perform a one off DNS A record test that uses each > probes local resolver? I think this would be handy to test DNS propagation. If you create the measurement via the "New Measurement" button and not the "One-Off Measurement", you have all options available including "Use probes resolver". In the last form you can select the tick box to make the measurement a one-off. From dquinn at ripe.net Tue Jul 15 16:23:27 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 15 Jul 2014 16:23:27 +0200 Subject: [atlas] Credit Usage math In-Reply-To: References: Message-ID: <53C5395F.1@ripe.net> On Tue 08 Jul 2014 20:19:03 CEST, Jared Mauch wrote: > I just sent 1 million credits to someone and now my credit "burn" rate is calculated as a large negative number. (I recently sent someone else 10x that and it caused odd math as well). Unfortunately, this is a known bug in our burn rate calculation code. We've got someone tasked to look into it in the next couple weeks though, so hopefully this will go away soon. For now, you can safely ignore the warnings knowing that they won't be a problem in the future. > I also have a large number of "small" UDMs which post quite often, so have 397 pages of the recent credit history. Are there plans to improve this display? There's currently a face-lift project under way and the credits page will likely be affected, so we'll definitely be considering UX options for that page. Feel free to message me off-list if you have suggestions as to how that data might be navigated, and we'll add it to the mix. From lhestina at ripe.net Tue Jul 15 16:27:03 2014 From: lhestina at ripe.net (Lia Hestina) Date: Tue, 15 Jul 2014 16:27:03 +0200 Subject: [atlas] Three new Anchors have joined the RIPE Atlas network Message-ID: <2087237F-E47E-417F-88E5-E9A789F23EED@ripe.net> Dear RIPE Atlas users, We proudly announce three new RIPE Atlas anchors have joined the network and are now available as target for probe hosts conducting their own user-defined measurements. The new anchors are called: be-anr-as2611 is hosted by MOSAIC - University of Antwerp - iMinds uk-lon-as60157 is hosted by Antheus Telecom LTD us-wct-as7922 is hosted by Comcast Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2622 bytes Desc: not available URL: From jared at puck.nether.net Thu Jul 17 02:33:20 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 16 Jul 2014 20:33:20 -0400 Subject: [atlas] adding probes to UDM Message-ID: <84C77E3A-9DA5-4659-AD08-FE345DED5FEB@puck.nether.net> I have a few ongoing UDMs and there?s a few things that have occurred over the duration: 1) I requested 5 probes and only 3 were available (at the time). Is there a way to request the system consider more? 2) I requested 5 probes and 5 were available, but some have fallen out (and are now crossed out). I want to request 1 or 2 more to get back to the 5 threshold so I feel I have more accurate data. Are either of these possible, or do I need to stop these and create a new UDM with a larger number of probes to keep a more stable population over time? (They have been running for ~2 months so far). - jared From thomasholterbach at gmail.com Thu Jul 17 04:29:13 2014 From: thomasholterbach at gmail.com (Thomas Holterbach) Date: Thu, 17 Jul 2014 11:29:13 +0900 Subject: [atlas] Questions about paris traceroute Message-ID: Hi all, I would like to start some Paris-traceroute measurements from RIPE Atlas probes, with a specific frequency and a control over the paris id. In particular, I am wondering if it is possible to start a traceroute measurement with all the 16 paris id at the same time. Because so far, I only find out how to start periodically a traceroute with a different paris id. I am also a little bit confused about the interval between two measurements. In the doc, it is written that the default value (900s) is the minimum, but when I create a UDM, the minimum interval seems to be 60s. I also tried 10 secondes with Restful API and the measurement started, but the real interval seems to be far upper than 10s. Can you give me more informations about this interval ? Thank you for your help, Thomas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Jul 17 04:48:51 2014 From: randy at psg.com (Randy Bush) Date: Thu, 17 Jul 2014 11:48:51 +0900 Subject: [atlas] Questions about paris traceroute In-Reply-To: References: Message-ID: look at the upside, > In particular, I am wondering if it is possible to start a traceroute > measurement with all the 16 paris id at the same time. Because so far, > I only find out how to start periodically a traceroute with a > different paris id. if your measurement per id is nicely separated in time, it is a real opportunity to publish in http://www.jir.com/ randy From vnaumov at ripe.net Thu Jul 17 08:59:06 2014 From: vnaumov at ripe.net (Viktor Naumov) Date: Thu, 17 Jul 2014 08:59:06 +0200 Subject: [atlas] adding probes to UDM In-Reply-To: <84C77E3A-9DA5-4659-AD08-FE345DED5FEB@puck.nether.net> References: <84C77E3A-9DA5-4659-AD08-FE345DED5FEB@puck.nether.net> Message-ID: <53C7743A.4090405@ripe.net> Hi Jared, You can use our REST API for changing participants. See docs here: https://atlas.ripe.net/docs/rest/#participation-request WBR /vty On 7/17/14, 2:33 AM, Jared Mauch wrote: > I have a few ongoing UDMs and there?s a few things that have occurred over the duration: > > 1) I requested 5 probes and only 3 were available (at the time). Is there a way to request the system consider more? > > 2) I requested 5 probes and 5 were available, but some have fallen out (and are now crossed out). I want to request 1 or 2 more to get back to the 5 threshold so I feel I have more accurate data. > > Are either of these possible, or do I need to stop these and create a new UDM with a larger number of probes to keep a more stable population over time? (They have been running for ~2 months so far). > > - jared > > > From robert at ripe.net Thu Jul 17 11:02:06 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 17 Jul 2014 11:02:06 +0200 Subject: [atlas] Questions about paris traceroute In-Reply-To: References: Message-ID: <53C7910E.9060502@ripe.net> Hi, It used to be true that the default measurement frequency was also the minimum. We've changed that to allow more frequent measurements, but apparently not all the documentation reflects that. We'll update the documentation. While technically it would be possible to add some feature to the system to do multiple paris variations at (or close to) the same time, this would add a lot of complications to the code base and to result parsing (which is already not simple). Instead, it is already possible to schedule multiple measurements to run at roughly the same time, which provides an approximation to what you describe here. Regards, Robert On 2014.07.17. 4:29, Thomas Holterbach wrote: > Hi all, > > I would like to start some Paris-traceroute measurements from RIPE Atlas probes, > with a specific frequency and a control over the paris id. > > In particular, I am wondering if it is possible to start a traceroute > measurement with all the 16 paris id at the same time. Because so far, I only > find out how to start periodically a traceroute with a different paris id. > > I am also a little bit confused about the interval between two measurements. > In the doc, it is written that the default value (900s) is the minimum, > but when I create a UDM, the minimum interval seems to be 60s. > I also tried 10 secondes with Restful API and the measurement > started, but the real interval seems to be far upper than 10s. > Can you give me more informations about this interval ? > > Thank you for your help, > > Thomas. From randy at psg.com Thu Jul 17 11:28:16 2014 From: randy at psg.com (Randy Bush) Date: Thu, 17 Jul 2014 18:28:16 +0900 Subject: [atlas] Questions about paris traceroute In-Reply-To: <53C7910E.9060502@ripe.net> References: <53C7910E.9060502@ripe.net> Message-ID: > While technically it would be possible to add some feature to the > system to do multiple paris variations at (or close to) the same time, > this would add a lot of complications to the code base and to result > parsing (which is already not simple). Instead, it is already possible > to schedule multiple measurements to run at roughly the same time, > which provides an approximation to what you describe here. how close an approximation? chasing ecmp and lag is bad enough without other changes. folk need reproducible results. randy From philip.homburg at ripe.net Thu Jul 17 11:37:32 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 17 Jul 2014 11:37:32 +0200 Subject: [atlas] Questions about paris traceroute In-Reply-To: References: <53C7910E.9060502@ripe.net> Message-ID: <53C7995C.2090306@ripe.net> On 2014/07/17 11:28 , Randy Bush wrote: >> While technically it would be possible to add some feature to the >> system to do multiple paris variations at (or close to) the same time, >> this would add a lot of complications to the code base and to result >> parsing (which is already not simple). Instead, it is already possible >> to schedule multiple measurements to run at roughly the same time, >> which provides an approximation to what you describe here. > > how close an approximation? chasing ecmp and lag is bad enough without > other changes. folk need reproducible results. As far as I know, the actual hashing algorithms used by load balancers are in general not known. So the only thing paris-traceroute can do is to try to provide consistent results for each variation and try to create enough difference between variations that it likely that all paths are tried. In this context, it doesn't really matter if you try different variations in one measurement or run different measurements. In both cases some bits will be different. But it not possible to predict in advance what is going to happen. Worth pointing out in this context (and it is also documented somewhere) is that if a probe reboots, the bits it uses for paris-traceroute are likely to be different. So consistent results with a single measurement are only achieved for as long as a probe doesn't reboot. Philip From randy at psg.com Thu Jul 17 11:49:02 2014 From: randy at psg.com (Randy Bush) Date: Thu, 17 Jul 2014 18:49:02 +0900 Subject: [atlas] Questions about paris traceroute In-Reply-To: <53C7995C.2090306@ripe.net> References: <53C7910E.9060502@ripe.net> <53C7995C.2090306@ripe.net> Message-ID: >> how close an approximation? chasing ecmp and lag is bad enough without >> other changes. folk need reproducible results. > > As far as I know, the actual hashing algorithms used by load balancers > are in general not known. > > So the only thing paris-traceroute can do is to try to provide > consistent results for each variation and try to create enough > difference between variations that it likely that all paths are tried. > > In this context, it doesn't really matter if you try different > variations in one measurement or run different measurements. In both > cases some bits will be different. But it not possible to predict in > advance what is going to happen. > > Worth pointing out in this context (and it is also documented somewhere) > is that if a probe reboots, the bits it uses for paris-traceroute are > likely to be different. So consistent results with a single measurement > are only achieved for as long as a probe doesn't reboot. a multi-id measurement needs to be closely clusetered in time or changes in routing or other network events can create ugly and unreproducible (in the someone else tries the same experiment) results. don't know about others, but i don't really care about load balancers. it's ecmp and lag on big pipes. randy From Woeber at CC.UniVie.ac.at Thu Jul 17 14:48:40 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 17 Jul 2014 14:48:40 +0200 Subject: [atlas] some thoughts and question regrding probe "stability" Message-ID: <53C7C628.3020500@CC.UniVie.ac.at> Hi Folks, triggered by the discussion related to DNSMON, and an issue (power, resolved) with one of my V1 probes, I'd like to get some input or start a disussion or an investigation. To start with, I am not very clear what the term "stability" w/should mean in this context, as the probes are supposed to buffer measurment data locally, at least for a while (true?). So, here goes... Obviously, looking at some Atlas Stat pages, there are probes with a 100% uptime. Now, looking a the 3 under my supervision (2x V1, 1 Anchor), ref "Connected" and "Disconnected", there's no chance to get near that value, as all of them tend to topple over on a regular basis, mostly for a *short* period of time in the range of 0m(!) to some 30+m. With respct to the bahaviour of the Anchor, which is mounted in the same rack as the backbone router it connects to, in a Data Center, we tried to correlate the (reported) disconnection events with the router and interface logs for the probe. No luck there, also, no maint works or the like, so I presume the Anchor didn't reboot or that there were "real" network problems. Let's compare the most recent dis/connection logs for my 3 pets: ID 6009 2014-07-14 03:58:03 3d 8h 16m Still Connected 2014-05-27 03:03:54 48d 0h 46m 2014-07-14 03:50:47 0h 7m 2014-05-20 15:19:02 6d 11h 37m 2014-05-27 02:57:00 0h 6m 2014-05-14 21:16:56 5d 17h 59m 2014-05-20 15:16:22 0h 2m 2014-04-08 16:03:21 36d 5h 1m 2014-05-14 21:05:17 0h 11m ID 0466 2014-07-13 23:31:05 3d 12h 45m Still Connected 2014-07-09 23:05:40 3d 23h 54m 2014-07-13 22:59:49 0h 31m 2014-06-16 10:53:21 23d 11h 55m 2014-07-09 22:49:04 0h 16m 2014-05-25 09:03:06 22d 1h 38m 2014-06-16 10:42:00 0h 11m 2014-05-24 20:34:50 11h 54m 2014-05-25 08:29:12 0h 33m ID 0414 2014-07-07 23:41:23 9d 12h 35m Still Connected 2014-07-02 03:58:45 5d 19h 31m 2014-07-07 23:29:54 0h 11m 2014-06-13 09:37:50 18d 18h 7m 2014-07-02 03:45:08 0h 13m 2014-06-08 13:22:14 4d 20h 7m 2014-06-13 09:29:38 0h 8m 2014-05-21 08:29:23 18d 4h 45m 2014-06-08 13:15:11 0h 7m Again, I fail to see some obvious correlation, what am I missing? Does anyone else see a similar pattern? How to start debugging, if there's anythig that needs debugging? Thanks for your ideas and help! Wilfried From aftabs at cyber.net.pk Thu Jul 17 15:03:50 2014 From: aftabs at cyber.net.pk (Aftab A. Siddiqui) Date: Thu, 17 Jul 2014 18:03:50 +0500 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <53C7C628.3020500@CC.UniVie.ac.at> References: <53C7C628.3020500@CC.UniVie.ac.at> Message-ID: <04a901cfa1bf$9c54c3a0$d4fe4ae0$@net.pk> Hi Wilfred, Atleast your probes were online for many number of days. Here is the availability report of my V1 probe 0303. 99.71% Availability. +---------------------+---------------------+------------+--------------+ | Connected (UTC) | Disconnected (UTC) | Connected | Disconnected | |---------------------+---------------------+------------+--------------+ | 2014-05-29 23:46:12 | 2014-06-02 06:30:06 | 1d 06:30 | 0d 00:00 | | 2014-06-02 06:40:35 | 2014-06-03 06:52:14 | 1d 00:11 | 0d 00:10 | | 2014-06-03 06:59:53 | 2014-06-04 22:11:56 | 1d 15:12 | 0d 00:07 | | 2014-06-04 22:22:43 | 2014-06-16 15:48:25 | 11d 17:25 | 0d 00:10 | | 2014-06-16 15:59:17 | 2014-06-17 22:11:24 | 1d 06:12 | 0d 00:10 | | 2014-06-17 22:22:53 | 2014-06-21 21:13:51 | 3d 22:50 | 0d 00:11 | | 2014-06-21 21:41:35 | 2014-06-23 15:44:56 | 1d 18:03 | 0d 00:27 | | 2014-06-23 15:54:55 | 2014-06-29 04:19:02 | 5d 12:24 | 0d 00:09 | | 2014-06-29 04:53:22 | Still up | 1d 19:06 | 0d 00:34 | +---------------------+---------------------+------------+--------------+ It is directly connected to our core router. I was never able to correlate any of the disconnection times with any network incident. Best Wishes, Aftab A. Siddiqui -----Original Message----- From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Wilfried Woeber Sent: Thursday, July 17, 2014 5:49 PM To: ripe-atlas at ripe.net Subject: [atlas] some thoughts and question regrding probe "stability" Hi Folks, triggered by the discussion related to DNSMON, and an issue (power, resolved) with one of my V1 probes, I'd like to get some input or start a disussion or an investigation. To start with, I am not very clear what the term "stability" w/should mean in this context, as the probes are supposed to buffer measurment data locally, at least for a while (true?). So, here goes... Obviously, looking at some Atlas Stat pages, there are probes with a 100% uptime. Now, looking a the 3 under my supervision (2x V1, 1 Anchor), ref "Connected" and "Disconnected", there's no chance to get near that value, as all of them tend to topple over on a regular basis, mostly for a *short* period of time in the range of 0m(!) to some 30+m. With respct to the bahaviour of the Anchor, which is mounted in the same rack as the backbone router it connects to, in a Data Center, we tried to correlate the (reported) disconnection events with the router and interface logs for the probe. No luck there, also, no maint works or the like, so I presume the Anchor didn't reboot or that there were "real" network problems. Let's compare the most recent dis/connection logs for my 3 pets: ID 6009 2014-07-14 03:58:03 3d 8h 16m Still Connected 2014-05-27 03:03:54 48d 0h 46m 2014-07-14 03:50:47 0h 7m 2014-05-20 15:19:02 6d 11h 37m 2014-05-27 02:57:00 0h 6m 2014-05-14 21:16:56 5d 17h 59m 2014-05-20 15:16:22 0h 2m 2014-04-08 16:03:21 36d 5h 1m 2014-05-14 21:05:17 0h 11m ID 0466 2014-07-13 23:31:05 3d 12h 45m Still Connected 2014-07-09 23:05:40 3d 23h 54m 2014-07-13 22:59:49 0h 31m 2014-06-16 10:53:21 23d 11h 55m 2014-07-09 22:49:04 0h 16m 2014-05-25 09:03:06 22d 1h 38m 2014-06-16 10:42:00 0h 11m 2014-05-24 20:34:50 11h 54m 2014-05-25 08:29:12 0h 33m ID 0414 2014-07-07 23:41:23 9d 12h 35m Still Connected 2014-07-02 03:58:45 5d 19h 31m 2014-07-07 23:29:54 0h 11m 2014-06-13 09:37:50 18d 18h 7m 2014-07-02 03:45:08 0h 13m 2014-06-08 13:22:14 4d 20h 7m 2014-06-13 09:29:38 0h 8m 2014-05-21 08:29:23 18d 4h 45m 2014-06-08 13:15:11 0h 7m Again, I fail to see some obvious correlation, what am I missing? Does anyone else see a similar pattern? How to start debugging, if there's anythig that needs debugging? Thanks for your ideas and help! Wilfried From jeroen at dckd.nl Thu Jul 17 16:04:01 2014 From: jeroen at dckd.nl (Jeroen van der Ham) Date: Thu, 17 Jul 2014 16:04:01 +0200 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <53C7C628.3020500@CC.UniVie.ac.at> References: <53C7C628.3020500@CC.UniVie.ac.at> Message-ID: <29F7106E-BD8C-4A85-A321-97EACC6F3944@dckd.nl> Hi, On 17 Jul 2014, at 14:48, Wilfried Woeber wrote: > Let's compare the most recent dis/connection logs for my 3 pets: > > ID 6009 > 2014-07-14 03:58:03 3d 8h 16m Still Connected > 2014-05-27 03:03:54 48d 0h 46m 2014-07-14 03:50:47 0h 7m > 2014-05-20 15:19:02 6d 11h 37m 2014-05-27 02:57:00 0h 6m > 2014-05-14 21:16:56 5d 17h 59m 2014-05-20 15:16:22 0h 2m > 2014-04-08 16:03:21 36d 5h 1m 2014-05-14 21:05:17 0h 11m > > ID 0466 > 2014-07-13 23:31:05 3d 12h 45m Still Connected > 2014-07-09 23:05:40 3d 23h 54m 2014-07-13 22:59:49 0h 31m > 2014-06-16 10:53:21 23d 11h 55m 2014-07-09 22:49:04 0h 16m > 2014-05-25 09:03:06 22d 1h 38m 2014-06-16 10:42:00 0h 11m > 2014-05-24 20:34:50 11h 54m 2014-05-25 08:29:12 0h 33m > > ID 0414 > 2014-07-07 23:41:23 9d 12h 35m Still Connected > 2014-07-02 03:58:45 5d 19h 31m 2014-07-07 23:29:54 0h 11m > 2014-06-13 09:37:50 18d 18h 7m 2014-07-02 03:45:08 0h 13m > 2014-06-08 13:22:14 4d 20h 7m 2014-06-13 09:29:38 0h 8m > 2014-05-21 08:29:23 18d 4h 45m 2014-06-08 13:15:11 0h 7m I see something similar, where I have two probes connected at home, to the same switch, to the same DSL connection. These probes are from different generations though. ID 3144 2014-07-16 10:22:03 1d 3h 38m Still Connected 2014-07-16 08:48:36 1h 10m 2014-07-16 09:58:51 0h 23m 2014-07-15 22:15:36 10h 13m 2014-07-16 08:29:29 0h 19m 2014-07-15 03:48:13 16h 49m 2014-07-15 20:37:48 1h 37m 2014-07-11 23:16:11 3d 3h 49m 2014-07-15 03:05:51 0h 42m 2014-07-06 19:00:04 5d 4h 1m 2014-07-11 23:01:08 0h 15m ID 11849 2014-07-16 10:13:47 1d 3h 49m Still Connected 2014-07-16 08:41:47 1h 17m 2014-07-16 09:58:56 0h 14m 2014-07-16 08:31:26 0h 1m 2014-07-16 08:33:10 0h 8m 2014-07-15 22:08:37 10h 20m 2014-07-16 08:29:27 0h 1m 2014-07-15 03:52:50 16h 45m 2014-07-15 20:38:05 1h 30m Jeroen. From ross at a-ics.com Thu Jul 17 16:12:42 2014 From: ross at a-ics.com (Ross Weseloh) Date: Thu, 17 Jul 2014 09:12:42 -0500 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <04a901cfa1bf$9c54c3a0$d4fe4ae0$@net.pk> References: <53C7C628.3020500@CC.UniVie.ac.at> <04a901cfa1bf$9c54c3a0$d4fe4ae0$@net.pk> Message-ID: For what it's worth, I've seen similar trouble over the last couple days. I've only had my probe hooked up since the 2nd of July, and compared to some of you it's a pretty basic local network. Unfortunately the 2 times it's gone down have been two hours before our store opens for the day so I haven't been here to see what's up. Of course it's very possible that something on our end is just going down and I don't know about it, so I'll keep an eye on it. *Ross Weseloh* On Thu, Jul 17, 2014 at 8:03 AM, Aftab A. Siddiqui wrote: > Hi Wilfred, > Atleast your probes were online for many number of days. Here is the > availability report of my V1 probe 0303. 99.71% Availability. > > +---------------------+---------------------+------------+--------------+ > | Connected (UTC) | Disconnected (UTC) | Connected | Disconnected | > |---------------------+---------------------+------------+--------------+ > | 2014-05-29 23:46:12 | 2014-06-02 06:30:06 | 1d 06:30 | 0d 00:00 | > | 2014-06-02 06:40:35 | 2014-06-03 06:52:14 | 1d 00:11 | 0d 00:10 | > | 2014-06-03 06:59:53 | 2014-06-04 22:11:56 | 1d 15:12 | 0d 00:07 | > | 2014-06-04 22:22:43 | 2014-06-16 15:48:25 | 11d 17:25 | 0d 00:10 | > | 2014-06-16 15:59:17 | 2014-06-17 22:11:24 | 1d 06:12 | 0d 00:10 | > | 2014-06-17 22:22:53 | 2014-06-21 21:13:51 | 3d 22:50 | 0d 00:11 | > | 2014-06-21 21:41:35 | 2014-06-23 15:44:56 | 1d 18:03 | 0d 00:27 | > | 2014-06-23 15:54:55 | 2014-06-29 04:19:02 | 5d 12:24 | 0d 00:09 | > | 2014-06-29 04:53:22 | Still up | 1d 19:06 | 0d 00:34 | > +---------------------+---------------------+------------+--------------+ > > It is directly connected to our core router. I was never able to correlate > any of the disconnection times with any network incident. > > Best Wishes, > > Aftab A. Siddiqui > > > -----Original Message----- > From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] On > Behalf Of Wilfried Woeber > Sent: Thursday, July 17, 2014 5:49 PM > To: ripe-atlas at ripe.net > Subject: [atlas] some thoughts and question regrding probe "stability" > > > Hi Folks, > > triggered by the discussion related to DNSMON, and an issue (power, > resolved) with one of my V1 probes, I'd like to get some input or start a > disussion or an investigation. > > To start with, I am not very clear what the term "stability" w/should mean > in this context, as the probes are supposed to buffer measurment data > locally, at least for a while (true?). > > So, here goes... > > Obviously, looking at some Atlas Stat pages, there are probes with a 100% > uptime. > > Now, looking a the 3 under my supervision (2x V1, 1 Anchor), ref > "Connected" > and "Disconnected", there's no chance to get near that value, as all of > them > tend to topple over on a regular basis, mostly for a *short* period of time > in the range of 0m(!) to some 30+m. > > With respct to the bahaviour of the Anchor, which is mounted in the same > rack as the backbone router it connects to, in a Data Center, we tried to > correlate the (reported) disconnection events with the router and interface > logs for the probe. No luck there, also, no maint works or the like, so I > presume the Anchor didn't reboot or that there were "real" network > problems. > > Let's compare the most recent dis/connection logs for my 3 pets: > > ID 6009 > 2014-07-14 03:58:03 3d 8h 16m Still Connected > 2014-05-27 03:03:54 48d 0h 46m 2014-07-14 03:50:47 0h 7m > 2014-05-20 15:19:02 6d 11h 37m 2014-05-27 02:57:00 0h 6m > 2014-05-14 21:16:56 5d 17h 59m 2014-05-20 15:16:22 0h 2m > 2014-04-08 16:03:21 36d 5h 1m 2014-05-14 21:05:17 0h 11m > > ID 0466 > 2014-07-13 23:31:05 3d 12h 45m Still Connected > 2014-07-09 23:05:40 3d 23h 54m 2014-07-13 22:59:49 0h 31m > 2014-06-16 10:53:21 23d 11h 55m 2014-07-09 22:49:04 0h 16m > 2014-05-25 09:03:06 22d 1h 38m 2014-06-16 10:42:00 0h 11m > 2014-05-24 20:34:50 11h 54m 2014-05-25 08:29:12 0h 33m > > ID 0414 > 2014-07-07 23:41:23 9d 12h 35m Still Connected > 2014-07-02 03:58:45 5d 19h 31m 2014-07-07 23:29:54 0h 11m > 2014-06-13 09:37:50 18d 18h 7m 2014-07-02 03:45:08 0h 13m > 2014-06-08 13:22:14 4d 20h 7m 2014-06-13 09:29:38 0h 8m > 2014-05-21 08:29:23 18d 4h 45m 2014-06-08 13:15:11 0h 7m > > Again, I fail to see some obvious correlation, what am I missing? > > Does anyone else see a similar pattern? > > How to start debugging, if there's anythig that needs debugging? > > Thanks for your ideas and help! > Wilfried > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Thu Jul 17 18:03:15 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 17 Jul 2014 18:03:15 +0200 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <53C7C628.3020500@CC.UniVie.ac.at> References: <53C7C628.3020500@CC.UniVie.ac.at> Message-ID: <53C7F3C3.7030603@ripe.net> Hi Wilfried, > Let's compare the most recent dis/connection logs for my 3 pets: Here is what I found in our logs: > ID 6009 > 2014-07-14 03:58:03 3d 8h 16m Still Connected Upgrade to firmware 4650 > 2014-05-27 03:03:54 48d 0h 46m 2014-07-14 03:50:47 0h 7m Hard to say, some network glitch > 2014-05-20 15:19:02 6d 11h 37m 2014-05-27 02:57:00 0h 6m Anchor was rebooted > 2014-05-14 21:16:56 5d 17h 59m 2014-05-20 15:16:22 0h 2m Network glitch https://atlas.ripe.net/atlas/udm.html?1026358.increase_type=rel&1026358.current_shift=150&1026358.current_clip=250&1026358.group_by=cc&1026358.show_me_filter=max,pls&msm_id=1026358&1026358.start_timestamp=1400098401&1026358.end_timestamp=1400102942&1026358.selected_probes=6001,6002,6003,6019,6022,6031,6040,6052#tab-seismograph1026358 > 2014-04-08 16:03:21 36d 5h 1m 2014-05-14 21:05:17 0h 11m Anchor was rebooted > ID 0466 > 2014-07-13 23:31:05 3d 12h 45m Still Connected Some network glitch, unclear what > 2014-07-09 23:05:40 3d 23h 54m 2014-07-13 22:59:49 0h 31m Probe upgraded firmware, reason for disconnect got lost > 2014-06-16 10:53:21 23d 11h 55m 2014-07-09 22:49:04 0h 16m Network problem > 2014-05-25 09:03:06 22d 1h 38m 2014-06-16 10:42:00 0h 11m Some network problem. > 2014-05-24 20:34:50 11h 54m 2014-05-25 08:29:12 0h 33m Unclear > ID 0414 > 2014-07-07 23:41:23 9d 12h 35m Still Connected Some network problem > 2014-07-02 03:58:45 5d 19h 31m 2014-07-07 23:29:54 0h 11m Power cycled? > 2014-06-13 09:37:50 18d 18h 7m 2014-07-02 03:45:08 0h 13m Some network problem. High RTTs > 2014-06-08 13:22:14 4d 20h 7m 2014-06-13 09:29:38 0h 8m Power cycled? > 2014-05-21 08:29:23 18d 4h 45m 2014-06-08 13:15:11 0h 7m Same. > Again, I fail to see some obvious correlation, what am I missing? > > Does anyone else see a similar pattern? > > How to start debugging, if there's anythig that needs debugging? A couple of points: 1) The connection between a probe (or anchor) and its controller doesn't have to be perfectly stable. It has to be good enough that probes will report results in timely fashion and can get commands. But nothing beyond that. 2) For single probe to see a network failure (with measurements using the default parameters) the failure has to last for at least 10 minutes. That way a couple of measurements will have a chance to report on the failure. In contrast, the connection between a probe and the controller is already terminated if the network is down for one minute. 3) When a target is measured by many probes then it is likely that at least some probes will pick up an event. But one probe on its own, it is hard to say anything about that. 4) Version 1 probes tend to reboot after losing the connection to the controller due to memory fragmentation issues. That is unfortunate, but we can't really do anything about it. Version 3 probes and anchors just report their results a little later. Philip From bryan at digitalocean.com Thu Jul 17 18:44:15 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Thu, 17 Jul 2014 12:44:15 -0400 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <53C7F3C3.7030603@ripe.net> References: <53C7C628.3020500@CC.UniVie.ac.at> <53C7F3C3.7030603@ripe.net> Message-ID: Just a thought, Are you connected to a "green" switch that might be dropping the power when idle and the probe can't handle that situation and disconnecting from the network and the process starts over? Bryan Socha Network Engineer DigitalOcean On Thu, Jul 17, 2014 at 12:03 PM, Philip Homburg wrote: > Hi Wilfried, > > > Let's compare the most recent dis/connection logs for my 3 pets: > > Here is what I found in our logs: > > > ID 6009 > > 2014-07-14 03:58:03 3d 8h 16m Still Connected > > Upgrade to firmware 4650 > > > 2014-05-27 03:03:54 48d 0h 46m 2014-07-14 03:50:47 0h 7m > > Hard to say, some network glitch > > > 2014-05-20 15:19:02 6d 11h 37m 2014-05-27 02:57:00 0h 6m > > Anchor was rebooted > > > 2014-05-14 21:16:56 5d 17h 59m 2014-05-20 15:16:22 0h 2m > > Network glitch > > > https://atlas.ripe.net/atlas/udm.html?1026358.increase_type=rel&1026358.current_shift=150&1026358.current_clip=250&1026358.group_by=cc&1026358.show_me_filter=max,pls&msm_id=1026358&1026358.start_timestamp=1400098401&1026358.end_timestamp=1400102942&1026358.selected_probes=6001,6002,6003,6019,6022,6031,6040,6052#tab-seismograph1026358 > > > 2014-04-08 16:03:21 36d 5h 1m 2014-05-14 21:05:17 0h 11m > > Anchor was rebooted > > > ID 0466 > > 2014-07-13 23:31:05 3d 12h 45m Still Connected > > Some network glitch, unclear what > > > 2014-07-09 23:05:40 3d 23h 54m 2014-07-13 22:59:49 0h 31m > > Probe upgraded firmware, reason for disconnect got lost > > > 2014-06-16 10:53:21 23d 11h 55m 2014-07-09 22:49:04 0h 16m > > Network problem > > > 2014-05-25 09:03:06 22d 1h 38m 2014-06-16 10:42:00 0h 11m > > Some network problem. > > > 2014-05-24 20:34:50 11h 54m 2014-05-25 08:29:12 0h 33m > > Unclear > > > ID 0414 > > 2014-07-07 23:41:23 9d 12h 35m Still Connected > > Some network problem > > > 2014-07-02 03:58:45 5d 19h 31m 2014-07-07 23:29:54 0h 11m > > Power cycled? > > > 2014-06-13 09:37:50 18d 18h 7m 2014-07-02 03:45:08 0h 13m > > Some network problem. High RTTs > > > 2014-06-08 13:22:14 4d 20h 7m 2014-06-13 09:29:38 0h 8m > > Power cycled? > > > 2014-05-21 08:29:23 18d 4h 45m 2014-06-08 13:15:11 0h 7m > > Same. > > > Again, I fail to see some obvious correlation, what am I missing? > > > > Does anyone else see a similar pattern? > > > > How to start debugging, if there's anythig that needs debugging? > > A couple of points: > 1) The connection between a probe (or anchor) and its controller doesn't > have to be perfectly stable. It has to be good enough that probes will > report results in timely fashion and can get commands. But nothing > beyond that. > 2) For single probe to see a network failure (with measurements using > the default parameters) the failure has to last for at least 10 minutes. > That way a couple of measurements will have a chance to report on the > failure. In contrast, the connection between a probe and the controller > is already terminated if the network is down for one minute. > 3) When a target is measured by many probes then it is likely that at > least some probes will pick up an event. But one probe on its own, it is > hard to say anything about that. > 4) Version 1 probes tend to reboot after losing the connection to the > controller due to memory fragmentation issues. That is unfortunate, but > we can't really do anything about it. Version 3 probes and anchors just > report their results a little later. > > Philip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.lists at mgm51.com Thu Jul 17 19:01:10 2014 From: the.lists at mgm51.com (Mike.) Date: Thu, 17 Jul 2014 13:01:10 -0400 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <53C7F3C3.7030603@ripe.net> References: <53C7C628.3020500@CC.UniVie.ac.at> <53C7F3C3.7030603@ripe.net> Message-ID: <201407171301100526.00F370EF@smtp.24cl.home> On 7/17/2014 at 6:03 PM Philip Homburg wrote: |Hi Wilfried, | [major snip] | | In contrast, the connection between a probe and the | controller is already terminated if the network is | down for one minute. ============= Pulling that one sentence out of a long-ish reply. If I read that correctly... If a probe loses contact with its controller for 60 seconds, then the controller considers the probe offline and starts a disconnected timer. Is that a correct interpretation? From philip.homburg at ripe.net Fri Jul 18 00:27:05 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 18 Jul 2014 00:27:05 +0200 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <201407171301100526.00F370EF@smtp.24cl.home> References: <53C7C628.3020500@CC.UniVie.ac.at> <53C7F3C3.7030603@ripe.net> <201407171301100526.00F370EF@smtp.24cl.home> Message-ID: <53C84DB9.1060602@ripe.net> On 2014/07/17 19:01 , Mike. wrote: > On 7/17/2014 at 6:03 PM Philip Homburg wrote: > > |Hi Wilfried, > | [major snip] > | > | In contrast, the connection between a probe and the > | controller is already terminated if the network is > | down for one minute. > ============= > > > > Pulling that one sentence out of a long-ish reply. > > If I read that correctly... > > If a probe loses contact with its controller for > 60 seconds, then the controller considers the probe > offline and starts a disconnected timer. More like, the controller 'pings' the probe every 20 seconds and after 3 missed responses the connection is terminated. And for the Atlas system as a whole, that works. But the goal of the Atlas system is not to have a probe connected as long as possible. Philip From cristel at iij.ad.jp Fri Jul 18 03:07:58 2014 From: cristel at iij.ad.jp (Pelsser Cristel) Date: Fri, 18 Jul 2014 10:07:58 +0900 Subject: [atlas] Questions about paris traceroute In-Reply-To: References: <53C7910E.9060502@ripe.net> <53C7995C.2090306@ripe.net> Message-ID: On Jul 17, 2014, at 6:49 PM, Randy Bush wrote: >>> how close an approximation? chasing ecmp and lag is bad enough without >>> other changes. folk need reproducible results. >> >> As far as I know, the actual hashing algorithms used by load balancers >> are in general not known. >> >> So the only thing paris-traceroute can do is to try to provide >> consistent results for each variation and try to create enough >> difference between variations that it likely that all paths are tried. >> >> In this context, it doesn't really matter if you try different >> variations in one measurement or run different measurements. In both >> cases some bits will be different. But it not possible to predict in >> advance what is going to happen. >> >> Worth pointing out in this context (and it is also documented somewhere) >> is that if a probe reboots, the bits it uses for paris-traceroute are >> likely to be different. So consistent results with a single measurement >> are only achieved for as long as a probe doesn't reboot. > > a multi-id measurement needs to be closely clusetered in time or changes > in routing or other network events can create ugly and unreproducible > (in the someone else tries the same experiment) results. > > don't know about others, but i don't really care about load balancers. > it's ecmp and lag on big pipes. With ecmp and lag, I hope that a routeur's hash stays consistent as long as the number of interfaces stays constant. The fact that a probe reboot may lead to a change in flow id is an issue. Cristel From Woeber at CC.UniVie.ac.at Fri Jul 18 12:12:58 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Fri, 18 Jul 2014 12:12:58 +0200 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <53C84DB9.1060602@ripe.net> References: <53C7C628.3020500@CC.UniVie.ac.at> <53C7F3C3.7030603@ripe.net> <201407171301100526.00F370EF@smtp.24cl.home> <53C84DB9.1060602@ripe.net> Message-ID: <53C8F32A.5030207@CC.UniVie.ac.at> Hu Philip + Team, Philip Homburg wrote: first of all thanks for investigating! [...] > More like, the controller 'pings' the probe every 20 seconds and after 3 > missed responses the connection is terminated. > > And for the Atlas system as a whole, that works. But the goal of the > Atlas system is not to have a probe connected as long as possible. That's fully understood. I'm still having a couple of questions :-) 1) if I do understand correctly, the decision to label a probe "disconnected" is made by the associateed collector, based on pings? (btw. - "real" pings on ICMP or internal over the channel?) 2) if that's the case, is there an easy way to find out to which collector a probe is "assigned"? (is this static or dynamic?) 3) if a probe, in particular an anchor, gets updated with a new firmware, is it possible that the ethernet IF does *not* go down? (Note, the 6009 is an old, big, beta box! Is there a difference with the new soekris probes?) > Philip Just to be very clear, I just want to understand how to interpret things, 'cause I already had an issue with one of my v1 probes, and in the end it turned out that the USB power feed was just boarderline, problem gone after replacement. And as an ISP and backbone operator, seeing stuff as "down" or "disconnected", without a good explanation, starts to itch after a while :-) All the best, have a nice weekend, Wilfried. From philip.homburg at ripe.net Fri Jul 18 14:23:43 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 18 Jul 2014 14:23:43 +0200 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <53C8F32A.5030207@CC.UniVie.ac.at> References: <53C7C628.3020500@CC.UniVie.ac.at> <53C7F3C3.7030603@ripe.net> <201407171301100526.00F370EF@smtp.24cl.home> <53C84DB9.1060602@ripe.net> <53C8F32A.5030207@CC.UniVie.ac.at> Message-ID: <53C911CF.9040604@ripe.net> On 2014/07/18 12:12 , Wilfried Woeber wrote: > Hu Philip + Team, > > Philip Homburg wrote: > > first of all thanks for investigating! No problem. I was also curious myself why 'normal' probes would disconnect. Most time is spend looking at the exceptions. > [...] >> More like, the controller 'pings' the probe every 20 seconds and after 3 >> missed responses the connection is terminated. >> >> And for the Atlas system as a whole, that works. But the goal of the >> Atlas system is not to have a probe connected as long as possible. > > That's fully understood. > > I'm still having a couple of questions :-) > > 1) if I do understand correctly, the decision to label a probe "disconnected" > is made by the associateed collector, based on pings? (btw. - "real" pings > on ICMP or internal over the channel?) Connected/disconnected is based on whether a probe has a ssh connection to a controller. There is a keepalive mechanism within the ssh protocol to see if there other end is still there. That ssh mechanism is used abort the connection. Nothing to do with real (ICMP) pings. > 2) if that's the case, is there an easy way to find out to which collector a > probe is "assigned"? (is this static or dynamic?) I don't know why, but that information is not shown to normal users. Of course, if you can capture traffic, you can easily find out :-) The assignment is dynamic. > 3) if a probe, in particular an anchor, gets updated with a new firmware, is > it possible that the ethernet IF does *not* go down? (Note, the 6009 is an > old, big, beta box! Is there a difference with the new soekris probes?) On regular probes a firmware upgrade always involves a reboot. On anchors the Atlas 'firmware' is an rpm. There is no reason to reboot the box or bring its interface down to upgrade the Atlas rpm. > Just to be very clear, I just want to understand how to interpret things, > 'cause I already had an issue with one of my v1 probes, and in the end it > turned out that the USB power feed was just boarderline, problem gone after > replacement. Yes it is good to keep an eye on those things. We can only look at probes statistically or in response to tickets, mail, etc. > And as an ISP and backbone operator, seeing stuff as "down" or "disconnected", > without a good explanation, starts to itch after a while :-) I think the best page to look at is the 'Result from Built-in Measurements'. If those graphs look fine, then there is no real reason to worry. Unless the probe keeps connecting and disconnecting multiple time a day or something like that. From cpetrie at ripe.net Fri Jul 18 18:11:12 2014 From: cpetrie at ripe.net (Colin Petrie) Date: Fri, 18 Jul 2014 18:11:12 +0200 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <53C911CF.9040604@ripe.net> References: <53C7C628.3020500@CC.UniVie.ac.at> <53C7F3C3.7030603@ripe.net> <201407171301100526.00F370EF@smtp.24cl.home> <53C84DB9.1060602@ripe.net> <53C8F32A.5030207@CC.UniVie.ac.at> <53C911CF.9040604@ripe.net> Message-ID: <53C94720.20808@ripe.net> On 18/07/14 14:23, Philip Homburg wrote: >> 3) if a probe, in particular an anchor, gets updated with a new firmware, is >> it possible that the ethernet IF does *not* go down? (Note, the 6009 is an >> old, big, beta box! Is there a difference with the new soekris probes?) > > On regular probes a firmware upgrade always involves a reboot. On > anchors the Atlas 'firmware' is an rpm. There is no reason to reboot the > box or bring its interface down to upgrade the Atlas rpm. To add to this point: When we roll out a new probe firmware to the Anchors, the software restarts (and will disconnect and reconnect to the controller) but nothing happens to the system OS - it will not result in a reboot, or a network interface flap. However, seperately from the probe firmware, we also patch and maintain the Anchor system OS. This happens during a weekly scheduled maintenance window: Tuesdays between 14:00 and 15:00 UTC (at least we try, sometimes the window overruns a little!) This may result in system services (such as the DNS and HTTP servers on the Anchors) restarting, and if there is a kernel update available, we will also reboot the Anchor during this window. This will result in the network interface going down and up during the reboot. This applies to both the V1 Dell Anchors and the V2 Soekris Anchors. Hope this helps, Cheers, Colin -- Colin Petrie Systems Engineer RIPE NCC From the.lists at mgm51.com Sat Jul 19 18:46:46 2014 From: the.lists at mgm51.com (Mike.) Date: Sat, 19 Jul 2014 12:46:46 -0400 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <53C94720.20808@ripe.net> References: <53C7C628.3020500@CC.UniVie.ac.at> <53C7F3C3.7030603@ripe.net> <201407171301100526.00F370EF@smtp.24cl.home> <53C84DB9.1060602@ripe.net> <53C8F32A.5030207@CC.UniVie.ac.at> <53C911CF.9040604@ripe.net> <53C94720.20808@ripe.net> Message-ID: <201407191246460805.00E139F8@smtp.24cl.home> On 7/18/2014 at 6:11 PM Colin Petrie wrote: |On 18/07/14 14:23, Philip Homburg wrote: |>> 3) if a probe, in particular an anchor, gets updated with a new |firmware, is | [ snip ] | |Hope this helps, | |Cheers, |Colin | |-- |Colin Petrie |Systems Engineer |RIPE NCC ============= Many thanks to you and Philip for providing the technical overview messages. I like to understand what I see on the status page for the probe I host, and the overviews have been most helpful towards that end. Thanks again. From brak at gameservers.com Mon Jul 21 23:29:30 2014 From: brak at gameservers.com (Brian Rak) Date: Mon, 21 Jul 2014 17:29:30 -0400 Subject: [atlas] Actual public measurements Message-ID: <53CD863A.9080302@gameservers.com> Is there any way to link someone to a public measurement, without requiring that they go and sign up for a RIPE account? It's an annoying extra step when I'm just trying to show someone the results of a measurement. I'm aware I could grab that raw data via the API, but then I'd have to re-implement the UI... which I don't have time for. From jared at puck.nether.net Tue Jul 22 00:28:02 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 21 Jul 2014 18:28:02 -0400 Subject: [atlas] Actual public measurements In-Reply-To: <53CD863A.9080302@gameservers.com> References: <53CD863A.9080302@gameservers.com> Message-ID: <7AB55612-263C-4695-BE37-DA1A9052078D@puck.nether.net> There are some ways to do this but I generally have asked for folks to create an account. I believe this is a work in progress to improve this from the RIPE Atlas team. Jared Mauch > On Jul 21, 2014, at 5:29 PM, Brian Rak wrote: > > Is there any way to link someone to a public measurement, without requiring that they go and sign up for a RIPE account? > > It's an annoying extra step when I'm just trying to show someone the results of a measurement. > > I'm aware I could grab that raw data via the API, but then I'd have to re-implement the UI... which I don't have time for. From dquinn at ripe.net Tue Jul 22 10:03:54 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 22 Jul 2014 10:03:54 +0200 Subject: [atlas] Actual public measurements In-Reply-To: <53CD863A.9080302@gameservers.com> References: <53CD863A.9080302@gameservers.com> Message-ID: <53CE1AEA.9070001@ripe.net> On 21/07/14 23:29, Brian Rak wrote: > Is there any way to link someone to a public measurement, without requiring that they go and sign up for a RIPE account? Indeed there is... just not yet. We're currently working on a redesign that, like the new probe pages, will make public measurements actually *public* so you can give people a link like https://atlas.ripe.net/measurements/1234567 -- but it's not finished yet. This new layout will be coupled with a completely redesigned creation process, which is what's eating the lion's share of the development time. Look for the new layout in the coming months. Until then, people will have to log in to see all measurements :-( From robert at ripe.net Tue Jul 22 15:53:13 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 22 Jul 2014 09:53:13 -0400 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <201407191246460805.00E139F8@smtp.24cl.home> References: <53C7C628.3020500@CC.UniVie.ac.at> <53C7F3C3.7030603@ripe.net> <201407171301100526.00F370EF@smtp.24cl.home> <53C84DB9.1060602@ripe.net> <53C8F32A.5030207@CC.UniVie.ac.at> <53C911CF.9040604@ripe.net> <53C94720.20808@ripe.net> <201407191246460805.00E139F8@smtp.24cl.home> Message-ID: <53CE6CC9.70903@ripe.net> Hello, To provide a bit of background information about $subject: In order to receive reports from the probes, and to deliver (measurement) commands to it, we maintain a bidirectional channel from the probe to the infrastructure. At the moment this is using SSH. We consider the probe to be "connected" as long as this channel is open, and "disconnected" when it's not. Note that this is only an indicator for the probe's stability, not a precise quality metric. Said connections can break for a number of reasons -- administrative actions, probe power loss, power cycle, path problems between probe and infrastructure (including the NAT box, if applicable), and infrastructure availability. For example, every now and then we disconnect the probes to make them upgrade, or have to reboot the server the probe is connected to. All these event show up as disconnects. The disconnection time mostly depends on the reason of the disconnect -- for example a probe reboot can be done in seconds, firmware upgrade takes something like 5-15 minutes, a controller reboot can cause up to 2 hours of non-connectedness. Finally: as Philip mentioned, we don't optimise for high connection times. The probes execute the pre-scheduled measurements even if they are not connected to the infrastructure. Regards, Robert From Woeber at CC.UniVie.ac.at Tue Jul 22 19:53:16 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 22 Jul 2014 19:53:16 +0200 Subject: [atlas] some thoughts and question regrding probe "stability" In-Reply-To: <53CE6CC9.70903@ripe.net> References: <53C7C628.3020500@CC.UniVie.ac.at> <53C7F3C3.7030603@ripe.net> <201407171301100526.00F370EF@smtp.24cl.home> <53C84DB9.1060602@ripe.net> <53C8F32A.5030207@CC.UniVie.ac.at> <53C911CF.9040604@ripe.net> <53C94720.20808@ripe.net> <201407191246460805.00E139F8@smtp.24cl.home> <53CE6CC9.70903@ripe.net> Message-ID: <53CEA50C.4080302@CC.UniVie.ac.at> Robert Kisteleki wrote: > Hello, > > To provide a bit of background information about $subject: Thanks to all who added to the picture, really appreciated! I'm feeling considerably more comfortable now to see somw "disconnects"[1] for a few minutes, always now and then :-) Still I'd like to see - eventually - some sort of alerts "from the system", if the frequency of the disconnects grows outside of of some sanity envelope. To be chatted about during the next RIPE meeting, maybe. Have a nice summer period, everyone, Wilfried [1] given that background, I wonder what the usefulness of the top-up-time page is, when this is not under the control of the probe host ;-) From daniel.karrenberg at ripe.net Thu Jul 24 11:34:33 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 24 Jul 2014 11:34:33 +0200 Subject: [atlas] Support RIPE Atlas with RIPE NCC Board Message-ID: <53D0D329.1010801@ripe.net> The RIPE NCC Executive Board is discussing RIPE Atlas as documented in the latest meeting minutes that have been published recently. https://www.ripe.net/lir-services/ncc/executive-board/minutes/2014/minutes-94-executive-board-meeting The relevant part is: --------- 3.3.1 ATLAS EB286 01/04/2014 AP The Board asked Axel to produce a break down of the costs for ATLAS over a period of 3 years and an outlook beyond 2014 to see the development on OPEX and CAPEX in the coming years. Furthermore the Board asked to see a comparison between the current figures and a case where TTM and DNSMON services were continued in their current form in 2014 and beyond. Status 19/06/2014: DONE There was discussion about the value of ATLAS to the various stakeholders and the associated maintenance cost. After discussion the Board asked for clear documentation of the results of the activities so that they could review and ultimately justify the cost of the project overall. The Board discussed the ongoing cost of the ATLAS project. The Board agreed that the value of the project needed to be packaged correctly. ATLAS now has many other projects wrapped into it and the activity needed proper and concise documentation as well as a solid marketing plan moving forward. ACTION EB295: The Board asked Axel to produce a value proposition for the ATLAS service in preparation for the September meeting. --------- It looks to me that the board needs to be re-assured that RIPE Atlas is valuable enough for the membership to justify the cost. Between the lines I read basic support but a desire to hear a consistent story and success stories of benefit to the membership. Of course the RIPE NCC staff will produce an answer to the board and I will do my best to help with that. But ultimately the board is responsible to the membership. So it would be very very helpful if we could get some users of RIPE Atlas to speak up both directly to the board and to help us prepare our answer to the board. Daniel From randy at psg.com Thu Jul 24 15:39:55 2014 From: randy at psg.com (Randy Bush) Date: Thu, 24 Jul 2014 09:39:55 -0400 Subject: [atlas] Support RIPE Atlas with RIPE NCC Board In-Reply-To: <53D0D329.1010801@ripe.net> References: <53D0D329.1010801@ripe.net> Message-ID: dfk, as researchers, we have found atlas probes useful if the experiment is calibrated and the probes are used very carefully. thanks to the atlas folk at the ncc. but note the symptomatic recent discussion between the atlas team and thomas holterbach. research experiments, like much of life, have time constraints. propagation of bug fixes and changes to the measurement model seriously impact the usability. randy From pvlaar at afilias.info Thu Jul 24 15:26:18 2014 From: pvlaar at afilias.info (Paul Vlaar) Date: Thu, 24 Jul 2014 15:26:18 +0200 Subject: [atlas] probe selection criteria on "WW" measurements Message-ID: <53D1097A.3050202@afilias.info> Hi, I have two questions regarding probe selection for UDMs. When I specify for example that I want to run an ongoing measurement on 250 probes in the "WW" region, will these probes remain the same throughout the lifecycle of the measurement (unlimited) or will these be somehow randomized every time the measurement is run? Secondly, I am wondering about even spread of probe location in doing such a measurement. For instance I am as much interested in results from regions that have only a few probes, as I am interested in results from those regions that are better served. When I look at the results so far of a test measurement, it appears that I'm receiving results from 35 probes in US, but only 3 from FI and none from NO. The latter surprises me a bit since there are 100 probes reported in NO, so why aren't there any results from those coming back? While I understand that countries with more probes will likely yield more results, I am wondering if there is any method to get a better "country-balanced" result for measurements ran in "WW". Thanks, ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar at afilias.info phone: +1-416-673-4078 mobile: +31-6-506-306-35 mobile USA: +1-602-410-4148 From jared at puck.nether.net Thu Jul 24 16:09:45 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 24 Jul 2014 10:09:45 -0400 Subject: [atlas] probe selection criteria on "WW" measurements In-Reply-To: <53D1097A.3050202@afilias.info> References: <53D1097A.3050202@afilias.info> Message-ID: <81C71AD6-7586-4A06-B3B8-48D776DC549C@puck.nether.net> On Jul 24, 2014, at 9:26 AM, Paul Vlaar wrote: > When I specify for example that I want to run an ongoing measurement on > 250 probes in the "WW" region, will these probes remain the same > throughout the lifecycle of the measurement (unlimited) or will these be > somehow randomized every time the measurement is run? Probe selection will remain static for the duration of the UDM (unless you add/remove probes). - Jared From astrikos at ripe.net Thu Jul 24 16:24:02 2014 From: astrikos at ripe.net (Andreas Strikos) Date: Thu, 24 Jul 2014 16:24:02 +0200 Subject: [atlas] probe selection criteria on "WW" measurements In-Reply-To: <53D1097A.3050202@afilias.info> References: <53D1097A.3050202@afilias.info> Message-ID: <53D11702.8010209@ripe.net> Hi Paul, On 7/24/14, 3:26 PM, Paul Vlaar wrote: > Hi, I have two questions regarding probe selection for UDMs. > > When I specify for example that I want to run an ongoing measurement on > 250 probes in the "WW" region, will these probes remain the same > throughout the lifecycle of the measurement (unlimited) or will these be > somehow randomized every time the measurement is run? > > Secondly, I am wondering about even spread of probe location in doing > such a measurement. For instance I am as much interested in results from > regions that have only a few probes, as I am interested in results from > those regions that are better served. When I look at the results so far > of a test measurement, it appears that I'm receiving results from 35 > probes in US, but only 3 from FI and none from NO. The latter surprises > me a bit since there are 100 probes reported in NO, so why aren't there > any results from those coming back? The main reason for this is that when you specify only WW the only criterion to pick a probe is how busy it is in terms of how many measurements probes is assigned. We don't try to make any balance (country/region/ASN/prefix) except how busy is it and which controller they are connected. > > While I understand that countries with more probes will likely yield > more results, I am wondering if there is any method to get a better > "country-balanced" result for measurements ran in "WW". I am afraid not at the moment. But, maybe there is something to consider for the future since I think other people have request it and we have internally discuss about it. > > Thanks, > > ~paul > Regards, Andreas From pvlaar at afilias.info Thu Jul 24 17:17:43 2014 From: pvlaar at afilias.info (Paul Vlaar) Date: Thu, 24 Jul 2014 17:17:43 +0200 Subject: [atlas] probe selection criteria on "WW" measurements In-Reply-To: <81C71AD6-7586-4A06-B3B8-48D776DC549C@puck.nether.net> References: <53D1097A.3050202@afilias.info> <81C71AD6-7586-4A06-B3B8-48D776DC549C@puck.nether.net> Message-ID: <53D12397.1030205@afilias.info> On 24/7/14, 4:09 PM, Jared Mauch wrote: > Probe selection will remain static for the duration of the UDM (unless you add/remove probes). I don't see a way to add/remove probes to an existing UDM, or to make any significant changes other than the description field. So I suppose one way around this is to create a new UDM for every iteration of my measurement, in order to randomize probe selection. Doesn't sound very appealing to me. ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar at afilias.info phone: +1-416-673-4078 mobile: +31-6-506-306-35 mobile USA: +1-602-410-4148 From robert at ripe.net Thu Jul 24 17:23:56 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 24 Jul 2014 11:23:56 -0400 Subject: [atlas] probe selection criteria on "WW" measurements In-Reply-To: <53D12397.1030205@afilias.info> References: <53D1097A.3050202@afilias.info> <81C71AD6-7586-4A06-B3B8-48D776DC549C@puck.nether.net> <53D12397.1030205@afilias.info> Message-ID: <53D1250C.9090306@ripe.net> On 2014.07.24. 11:17, Paul Vlaar wrote: > On 24/7/14, 4:09 PM, Jared Mauch wrote: >> Probe selection will remain static for the duration of the UDM (unless you add/remove probes). > > I don't see a way to add/remove probes to an existing UDM, or to make > any significant changes other than the description field. See https://atlas.ripe.net/docs/rest/#participation-request > So I suppose one way around this is to create a new UDM for every > iteration of my measurement, in order to randomize probe selection. > Doesn't sound very appealing to me. Neither does it to us ;-) Cheers, Robert > ~paul > > From BECHA at ripe.net Thu Jul 24 17:51:19 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 24 Jul 2014 17:51:19 +0200 Subject: [atlas] New on RIPE Labs: Midsummer Update for RIPE Atlas In-Reply-To: <53D12AFD.7020205@ripe.net> References: <53D12AFD.7020205@ripe.net> Message-ID: <53D12B77.9080104@ripe.net> Dear colleagues, in these hot and slow summer days, we give you an overview of the current status of RIPE Atlas, new features since the last update during RIPE68, and an insight into past and future community activities: https://labs.ripe.net/Members/fatemah_mafi/ripe-atlas-midsummer-update-2014 Regards, Vesna -- Measurements Community Building team From v.bajpai at jacobs-university.de Thu Jul 24 18:14:36 2014 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Thu, 24 Jul 2014 16:14:36 +0000 Subject: [atlas] New on RIPE Labs: Midsummer Update for RIPE Atlas In-Reply-To: <53D12B77.9080104@ripe.net> References: <53D12AFD.7020205@ripe.net> <53D12B77.9080104@ripe.net> Message-ID: On 24 Jul 2014, at 17:51, Vesna Manojlovic wrote: > Dear colleagues, > > in these hot and slow summer days, we give you an overview of the > current status of RIPE Atlas, new features since the last update during > RIPE68, and an insight into past and future community activities: > > https://labs.ripe.net/Members/fatemah_mafi/ripe-atlas-midsummer-update-2014 The network coverage map visualisation looks very nice :-) Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gert at space.net Fri Jul 25 10:24:59 2014 From: gert at space.net (Gert Doering) Date: Fri, 25 Jul 2014 10:24:59 +0200 Subject: [atlas] Support RIPE Atlas with RIPE NCC Board In-Reply-To: <53D0D329.1010801@ripe.net> References: <53D0D329.1010801@ripe.net> Message-ID: <20140725082459.GC51793@Space.Net> Hi, On Thu, Jul 24, 2014 at 11:34:33AM +0200, Daniel Karrenberg wrote: > It looks to me that the board needs to be re-assured that RIPE Atlas is > valuable enough for the membership to justify the cost. Between the > lines I read basic support but a desire to hear a consistent story and > success stories of benefit to the membership. As an Anchor host, I find Atlas useful to help us ensure that the interconnections between our network and "The Internet" are working properly, and are monitored properly. "Local" measurements are just not as good as having a swarm of probes (and Anchors) widely distributed across the 'net. This is why we're sponsoring our Anchor, and are happy to pay our share of the Atlas costs. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From daniel.karrenberg at ripe.net Fri Jul 25 12:22:26 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 25 Jul 2014 12:22:26 +0200 Subject: [atlas] probe selection criteria on "WW" measurements In-Reply-To: <53D12397.1030205@afilias.info> References: <53D1097A.3050202@afilias.info> <81C71AD6-7586-4A06-B3B8-48D776DC549C@puck.nether.net> <53D12397.1030205@afilias.info> Message-ID: <53D22FE2.9070804@ripe.net> On 24.07.14 17:17 , Paul Vlaar wrote: > On 24/7/14, 4:09 PM, Jared Mauch wrote: >> Probe selection will remain static for the duration of the UDM (unless you add/remove probes). > > I don't see a way to add/remove probes to an existing UDM, or to make > any significant changes other than the description field. This is possible using the API. This is not all that difficult as I could do it an my coding skills have eroded seriously. I would consider investing a little. It is easy to retrieve a list of all probes and make any selection one would like based on geographic location, AS, public address ..... https://atlas.ripe.net/docs/rest/#probe Then you can create a measurement requesting exactly those probes. https://atlas.ripe.net/docs/rest/#measurement > > So I suppose one way around this is to create a new UDM for every > iteration of my measurement, in order to randomize probe selection. > Doesn't sound very appealing to me. I recommend investing in using the API. Alternative is to wait for UI improvements. The only way to make sure these get done eventually is to get them onto the roadmap: http://roadmap.ripe.net/ripe-atlas/ Groetjes Daniel From colinj at mx5.org.uk Tue Jul 29 13:34:55 2014 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 29 Jul 2014 12:34:55 +0100 Subject: [atlas] Fwd: Probe 2317 (home fibre) is disconnected References: <20140729113005.32636.40047@janus.atlas.ripe.net> Message-ID: strange, connectivity seems fine to me at least within BT network range and HSO network range ? Should I reset the probe or this is a bigger monitoring probe failure ? Colin Begin forwarded message: > From: RIPE Atlas > Subject: Probe 2317 (home fibre) is disconnected > Date: 29 July 2014 12:30:05 BST > To: colin johnston > Delivered-To: colinj at mx5.org.uk > Received: by 10.70.41.145 with SMTP id f17csp332256pdl; Tue, 29 Jul 2014 04:30:32 -0700 (PDT) > Received: from koko.ripe.net (koko.ripe.net. [2001:67c:2e8:11::c100:1348]) by mx.google.com with ESMTPS id f10si19194016wic.74.2014.07.29.04.30.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jul 2014 04:30:20 -0700 (PDT) > Received: from janus.atlas.ripe.net ([193.0.19.13]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XC5bZ-0004TU-Nf for colinj at mx5.org.uk; Tue, 29 Jul 2014 13:30:08 +0200 > Received: from localhost.localdomain ([127.0.0.1] helo=janus.atlas.ripe.net) by janus.atlas.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XC5bZ-00004y-IA for colinj at mx5.org.uk; Tue, 29 Jul 2014 11:30:05 +0000 > X-Received: by 10.180.75.230 with SMTP id f6mr41435469wiw.5.1406633431897; Tue, 29 Jul 2014 04:30:31 -0700 (PDT) > Return-Path: > Received-Spf: none (google.com: atlas at ripe.net does not designate permitted sender hosts) client-ip=2001:67c:2e8:11::c100:1348; > Authentication-Results: mx.google.com; spf=neutral (google.com: atlas at ripe.net does not designate permitted sender hosts) smtp.mail=atlas at ripe.net > Content-Type: text/plain; charset="utf-8" > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > Message-Id: <20140729113005.32636.40047 at janus.atlas.ripe.net> > X-Ripe-Spam-Level: / > X-Ripe-Spam-Report: Spam Total Points: 0.4 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 4.0 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net) > X-Ripe-Signature: 407c82a9d3629e01ca957e4b84b7f67191521e4a20cb459dafae86d3fab252b9 > > Dear colin, > > Your probe 2317 has been disconnected since 2014-07-29 10:38:01 UTC. > > This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to be notified if your probe becomes disconnected for more than 30 minutes. > > If you want to change this, or disable this notification altogether, please go to https://atlas.ripe.net/probes/2317/, and click the "edit" button under "Notifications". > > Kind regards, > > RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexsaroyan at gmail.com Tue Jul 29 15:00:58 2014 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Tue, 29 Jul 2014 17:00:58 +0400 Subject: [atlas] Fwd: Probe 2317 (home fibre) is disconnected In-Reply-To: References: <20140729113005.32636.40047@janus.atlas.ripe.net> Message-ID: <53D79B0A.4060301@gmail.com> Hi, Try to reboot the probe at least by troubleshooting means. Regards. /Alex Saroyan On 07/29/2014 03:34 PM, Colin Johnston wrote: > strange, connectivity seems fine to me at least within BT network > range and HSO network range ? > > Should I reset the probe or this is a bigger monitoring probe failure ? > > Colin > > > Begin forwarded message: > >> *From: *RIPE Atlas > >> *Subject: **Probe 2317 (home fibre) is disconnected* >> *Date: *29 July 2014 12:30:05 BST >> *To: *colin johnston > >> *Delivered-To: *colinj at mx5.org.uk >> *Received: *by 10.70.41.145 with SMTP id f17csp332256pdl; Tue, 29 Jul >> 2014 04:30:32 -0700 (PDT) >> *Received: *from koko.ripe.net (koko.ripe.net >> . [2001:67c:2e8:11::c100:1348]) by >> mx.google.com with ESMTPS id >> f10si19194016wic.74.2014.07.29.04.30.19 for > > (version=TLSv1.2 >> cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jul 2014 >> 04:30:20 -0700 (PDT) >> *Received: *from janus.atlas.ripe.net >> ([193.0.19.13]) by koko.ripe.net with esmtps >> (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from >> >) id 1XC5bZ-0004TU-Nf for >> colinj at mx5.org.uk ; Tue, 29 Jul 2014 >> 13:30:08 +0200 >> *Received: *from localhost.localdomain ([127.0.0.1] >> helo=janus.atlas.ripe.net ) by >> janus.atlas.ripe.net with esmtp (Exim >> 4.72) (envelope-from >) id >> 1XC5bZ-00004y-IA for colinj at mx5.org.uk ; >> Tue, 29 Jul 2014 11:30:05 +0000 >> *X-Received: *by 10.180.75.230 with SMTP id >> f6mr41435469wiw.5.1406633431897; Tue, 29 Jul 2014 04:30:31 -0700 (PDT) >> *Return-Path: *> >> *Received-Spf: *none (google.com : atlas at ripe.net >> does not designate permitted sender hosts) >> client-ip=2001:67c:2e8:11::c100:1348; >> *Authentication-Results: *mx.google.com ; >> spf=neutral (google.com : atlas at ripe.net >> does not designate permitted sender hosts) >> smtp.mail=atlas at ripe.net >> *Content-Type: *text/plain; charset="utf-8" >> *Mime-Version: *1.0 >> *Content-Transfer-Encoding: *7bit >> *Message-Id: *<20140729113005.32636.40047 at janus.atlas.ripe.net >> > >> *X-Ripe-Spam-Level: */ >> *X-Ripe-Spam-Report: *Spam Total Points: 0.4 points pts rule name >> description ---- ---------------------- >> ------------------------------------ -1.0 ALL_TRUSTED Passed through >> trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender >> domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam >> probability is 0 to 1% [score: 0.0000] 4.0 DCC_CHECK Detected as bulk >> mail by DCC (dcc-servers.net ) >> *X-Ripe-Signature: >> *407c82a9d3629e01ca957e4b84b7f67191521e4a20cb459dafae86d3fab252b9 >> >> Dear colin, >> >> Your probe 2317 has been disconnected since 2014-07-29 10:38:01 UTC. >> >> This is an automatically generated email from RIPE Atlas. It was sent >> to you because you asked to be notified if your probe becomes >> disconnected for more than 30 minutes. >> >> If you want to change this, or disable this notification altogether, >> please go to https://atlas.ripe.net/probes/2317/, and click the >> "edit" button under "Notifications". >> >> Kind regards, >> >> RIPE Atlas Team > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Tue Jul 29 15:07:44 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 29 Jul 2014 15:07:44 +0200 Subject: [atlas] Fwd: Probe 2317 (home fibre) is disconnected In-Reply-To: References: <20140729113005.32636.40047@janus.atlas.ripe.net> Message-ID: <53D79CA0.6010108@ripe.net> On 2014.07.29. 13:34, Colin Johnston wrote: > strange, connectivity seems fine to me at least within BT network range and > HSO network range ? > > Should I reset the probe or this is a bigger monitoring probe failure ? > > Colin Hello, This morning our IT team executed a planned maintenance in one of our colos, which had a more adverse effect than anticipated. Your probe (as well as ~98% of others) is now connected again. Sorry for the inconvenience, Robert From alexsaroyan at gmail.com Tue Jul 29 15:15:42 2014 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Tue, 29 Jul 2014 17:15:42 +0400 Subject: [atlas] Fwd: Probe 2317 (home fibre) is disconnected In-Reply-To: <53D79CA0.6010108@ripe.net> References: <20140729113005.32636.40047@janus.atlas.ripe.net> <53D79CA0.6010108@ripe.net> Message-ID: <53D79E7E.2030100@gmail.com> BTW - I am hosting 6 probes - all 6 have uptime of more then 1 day. Regards. /Alex Saroyan On 07/29/2014 05:07 PM, Robert Kisteleki wrote: > On 2014.07.29. 13:34, Colin Johnston wrote: >> strange, connectivity seems fine to me at least within BT network range and >> HSO network range ? >> >> Should I reset the probe or this is a bigger monitoring probe failure ? >> >> Colin > Hello, > > This morning our IT team executed a planned maintenance in one of our colos, > which had a more adverse effect than anticipated. Your probe (as well as > ~98% of others) is now connected again. > > Sorry for the inconvenience, > Robert > > From colinj at mx5.org.uk Tue Jul 29 17:58:54 2014 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 29 Jul 2014 16:58:54 +0100 Subject: [atlas] Fwd: Probe 2317 (home fibre) is disconnected In-Reply-To: <53D79CA0.6010108@ripe.net> References: <20140729113005.32636.40047@janus.atlas.ripe.net> <53D79CA0.6010108@ripe.net> Message-ID: Thanks Robert, that might well have explained it :) Colin On 29 Jul 2014, at 14:07, Robert Kisteleki wrote: > On 2014.07.29. 13:34, Colin Johnston wrote: >> strange, connectivity seems fine to me at least within BT network range and >> HSO network range ? >> >> Should I reset the probe or this is a bigger monitoring probe failure ? >> >> Colin > > Hello, > > This morning our IT team executed a planned maintenance in one of our colos, > which had a more adverse effect than anticipated. Your probe (as well as > ~98% of others) is now connected again. > > Sorry for the inconvenience, > Robert > From colinj at mx5.org.uk Tue Jul 29 18:07:52 2014 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 29 Jul 2014 17:07:52 +0100 Subject: [atlas] Probe 2317 (home fibre) is disconnected In-Reply-To: References: <20140729113005.32636.40047@janus.atlas.ripe.net> <53D79CA0.6010108@ripe.net> Message-ID: A enhancement might be to send second email when connectivity is working ok again ? Colin On 29 Jul 2014, at 16:58, Colin Johnston wrote: > Thanks Robert, > that might well have explained it :) > > Colin > > On 29 Jul 2014, at 14:07, Robert Kisteleki wrote: > >> On 2014.07.29. 13:34, Colin Johnston wrote: >>> strange, connectivity seems fine to me at least within BT network range and >>> HSO network range ? >>> >>> Should I reset the probe or this is a bigger monitoring probe failure ? >>> >>> Colin >> >> Hello, >> >> This morning our IT team executed a planned maintenance in one of our colos, >> which had a more adverse effect than anticipated. Your probe (as well as >> ~98% of others) is now connected again. >> >> Sorry for the inconvenience, >> Robert >> > From danny at danysek.cz Tue Jul 29 19:29:17 2014 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 29 Jul 2014 19:29:17 +0200 Subject: [atlas] [ripe.net #1133019] Re: Your RIPE Atlas Probe is not connected to our network In-Reply-To: References: <20140718034027.4116.36417@janus.atlas.ripe.net> <53C8B106.4090607@danysek.cz> Message-ID: <53D7D9ED.7030206@danysek.cz> There's no firewall / ACL, anything on the way, just pure L3 device. Probe worked properly, then disconnected without any logical reason with that notification received. Probe is pingable on both IPv4 and IPv6 from outside, proper (so there's no L3 issue on the way). Probe itself resets all incoming TCP connections from my IP address located in another ASN (probably due to firewall at the probe). On traffic mirrored from the probe I see ocasional NTP queries to some servers, so "something" on probe runs. Nothing else. You do not provide any access to probe for hosts to check anything directly, so I expect you can manage fully (as this is something running any kind of Linux?). As probe has public IPv4/IPv6 address, you should not have problem reach it. Unfortunatelly, probe is located on remote datacenter with limited physical access. Also this is not a solution of problem - with reboot you probably loose anything to diagnose causes of this problem. What checks did you performed at your side before sending such email? You don't have any kind of "emenergency" probe management, like SSH shell access directly to the device? What do you see in *your* logs about affected probe before it was disconnected? With regards, Daniel On 22.7.2014 11:17, Alastair Strachan wrote: > Hello Daniel, > > Thanks for your email. > > It would appear there is something on your network blocking the probe from connecting outside your network. Could I ask you to double check to ensure there is no security/firewall rule that has been updated or needs updating to allow the probe a clean connection outside your network. > > I would also recommend trying a complete power recycle on the probe. > > Thank you for taking the time to host a RIPE Atlas probe. > > If you have any further questions, please let me know > > Kind Regards, > > Alastair Strachan > > 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 18.7.2014 05:40, RIPE Atlas wrote: >>> Dear RIPE Atlas probe host, >>> >>> Thank you for participating in RIPE Atlas! >>> >>> We have noticed that your probe is not connected to our infrastructure and has been >> disconnected since 2014-07-11 03:15 UTC. Could you please check >> whether everything is set up correctly on your side? If it is, and >> your probe is still reported as disconnected when you log in at >> https://atlas.ripe.net, please reply to this email so that we can >> follow up. >>> >>> You can review the instructions for setting up your probe at >> https://atlas.ripe.net/getting-started >>> >>> If you have any questions, please contact us at atlas at ripe.net >>> >>> Best regards, >>> >>> RIPE Atlas Team >>> >>> ********** >>> You are receiving this message because you applied for or were given >> a RIPE Atlas probe. We will only send messages when your probe >> becomes disconnected for an extended period of time. >>> >> > > From rene at bartschnet.de Tue Jul 29 14:56:36 2014 From: rene at bartschnet.de (Rene Bartsch) Date: Tue, 29 Jul 2014 14:56:36 +0200 Subject: [atlas] Fwd: Probe 2317 (home fibre) is disconnected In-Reply-To: References: <20140729113005.32636.40047@janus.atlas.ripe.net> Message-ID: <258d59c5d1ca18a571eddcd939a438b0@triangulum.uberspace.de> I have this over and over, too. The probes seem to be unstable and need at least half an hour to re-register after the IP address has changed. Meanwhile I just ignore it ... Am 2014-07-29 13:34, schrieb Colin Johnston: > strange, connectivity seems fine to me at least within BT network > range and HSO network range ? > > Should I reset the probe or this is a bigger monitoring probe failure > ? > > Colin > > Begin forwarded message: > >> FROM: RIPE Atlas >> >> SUBJECT: PROBE 2317 (HOME FIBRE) IS DISCONNECTED >> >> DATE: 29 July 2014 12:30:05 BST >> >> TO: colin johnston >> >> DELIVERED-TO: colinj at mx5.org.uk >> >> RECEIVED: by 10.70.41.145 with SMTP id f17csp332256pdl; Tue, 29 Jul >> 2014 04:30:32 -0700 (PDT) >> >> RECEIVED: from koko.ripe.net [1] (koko.ripe.net [1]. >> [2001:67c:2e8:11::c100:1348]) by mx.google.com [2] with ESMTPS id >> f10si19194016wic.74.2014.07.29.04.30.19 for >> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); >> Tue, 29 Jul 2014 04:30:20 -0700 (PDT) >> >> RECEIVED: from janus.atlas.ripe.net [3] ([193.0.19.13]) by >> koko.ripe.net [1] with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim >> 4.72) (envelope-from ) id 1XC5bZ-0004TU-Nf for >> colinj at mx5.org.uk; Tue, 29 Jul 2014 13:30:08 +0200 >> >> RECEIVED: from localhost.localdomain ([127.0.0.1] >> helo=janus.atlas.ripe.net [3]) by janus.atlas.ripe.net [3] with >> esmtp (Exim 4.72) (envelope-from ) id >> 1XC5bZ-00004y-IA for colinj at mx5.org.uk; Tue, 29 Jul 2014 11:30:05 >> +0000 >> >> X-RECEIVED: by 10.180.75.230 with SMTP id >> f6mr41435469wiw.5.1406633431897; Tue, 29 Jul 2014 04:30:31 -0700 >> (PDT) >> >> RETURN-PATH: >> >> RECEIVED-SPF: none (google.com [4]: atlas at ripe.net does not >> designate permitted sender hosts) >> client-ip=2001:67c:2e8:11::c100:1348; >> >> AUTHENTICATION-RESULTS: mx.google.com [2]; spf=neutral (google.com >> [4]: atlas at ripe.net does not designate permitted sender hosts) >> smtp.mail=atlas at ripe.net >> >> CONTENT-TYPE: text/plain; charset="utf-8" >> >> MIME-VERSION: 1.0 >> >> CONTENT-TRANSFER-ENCODING: 7bit >> >> MESSAGE-ID: <20140729113005.32636.40047 at janus.atlas.ripe.net> >> >> X-RIPE-SPAM-LEVEL: / >> >> X-RIPE-SPAM-REPORT: Spam Total Points: 0.4 points pts rule name >> description ---- ---------------------- >> ------------------------------------ -1.0 ALL_TRUSTED Passed through >> trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender >> domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam >> probability is 0 to 1% [score: 0.0000] 4.0 DCC_CHECK Detected as >> bulk mail by DCC (dcc-servers.net [5]) >> >> X-RIPE-SIGNATURE: >> 407c82a9d3629e01ca957e4b84b7f67191521e4a20cb459dafae86d3fab252b9 >> >> Dear colin, >> >> Your probe 2317 has been disconnected since 2014-07-29 10:38:01 UTC. >> >> This is an automatically generated email from RIPE Atlas. It was >> sent to you because you asked to be notified if your probe becomes >> disconnected for more than 30 minutes. >> >> If you want to change this, or disable this notification altogether, >> please go to https://atlas.ripe.net/probes/2317/ [6], and click the >> "edit" button under "Notifications". >> >> Kind regards, >> >> RIPE Atlas Team > > > > Links: > ------ > [1] http://koko.ripe.net > [2] http://mx.google.com > [3] http://janus.atlas.ripe.net > [4] http://google.com > [5] http://dcc-servers.net > [6] https://atlas.ripe.net/probes/2317/ -- Best regards, Rene Bartsch, B. Sc. Informatics From roderick.fanou at gmail.com Thu Jul 31 11:14:59 2014 From: roderick.fanou at gmail.com (FANOU Roderick) Date: Thu, 31 Jul 2014 11:14:59 +0200 Subject: [atlas] Paris-traceroute variations Message-ID: Hi all, Just a quick question. What is the real difference between a TCP paris-traceroutes and an UDP paris-traceroute ? How do the probes perform each of them? Thanks, Best regards, Roderick On 26.06.2014 13:13, Philip Homburg wrote: > Hi Juan, > > On 2014/06/19 16:59 , Juan Antonio Cordero Fuertes wrote: >> Not sure this is the right place to ask this... sorry if it is not. >> >> I'm trying to configure Paris-traceroute measurements, and it is not >> clear for me what is the meaning of the /paris/ parameter. In >> https://atlas.ripe.net/docs/udm/ it is said that it corresponds, for >> values from 1 to 16, to "the number of variations to be used for a Paris >> traceroute ". What is this? Does it >> correspond to the number of initial probes to be used by >> paris-traceroute? I am unable to figure it out from the RIPE Atlas >> docs... any indication would be appreciated. > > Paris-traceroute tries to make sure that all packets of a traceroute > take the same route through a load balancer. This in contrast to > traditional traceroute where packets from different hops typically take > different routes when load balancers are involved. > > However, in the case of paris-traceroute it is still interesting to find > out if there are multiple routes or not. For this reason, the traceroute > measurement creates different variations that may take a different route. > > Each interval, it will try one variation. So if you select 16 variations > then it will take 16 intervals before you get back to the first one. > > Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Thu Jul 31 11:35:50 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 31 Jul 2014 11:35:50 +0200 Subject: [atlas] Paris-traceroute variations In-Reply-To: References: Message-ID: <53DA0DF6.5000504@ripe.net> On 2014/07/31 11:14 , FANOU Roderick wrote: > Hi all, > Just a quick question. > What is the real difference between a TCP paris-traceroutes and an UDP > paris-traceroute ? > How do the probes perform each of them? The Atlas traceroute can perform traceroute over ICMP, TCP, and UDP. The difference here is which protocol is used to send the probing packets. Beyond that, the 'paris' option tries to create packets in such a way that the computed flow id is stable during a run of traceroute. This can be done in different ways for ICMP, TCP, and UDP. Philip