From jterbeest at ripe.net Wed Jan 3 16:37:04 2018 From: jterbeest at ripe.net (Johan ter Beest) Date: Wed, 3 Jan 2018 16:37:04 +0100 Subject: [atlas] RIPE Atlas CLI In-Reply-To: References: Message-ID: <77692bc6-59d2-1a41-1541-d287359cce42@ripe.net> Hi Milad, On 30/12/2017 12:23, Milad Afshari wrote: > Hi Dear Colleagues; > I hope you are doing well; > > I have an issue with creating a measurement using > "?--include-tag"?option,As far as I check the syntax is correct but it > doesn't work.Please let me know if you have any idea. > > cmd: > /a) - ripe-atlas measure ping --from-country ir --target 79.127.127.1 > _--include-tag system-ipv4-works_/ > / > / > /b) ripe-atlas measure ping --from-country ir --target 79.127.127.1 > _--include-tag=system-ipv4-works_/ > / > / > */ > /* > Error: > /ripe-atlas measure: error: argument --include-tag: > "system-ipv4-works" does not appear to be valid./ As your syntax is indeed correct my guess is that you're using an old version of ripe.atlas.tools. Let me know if you need help upgrading your installed version. I created the measurement for you here: https://atlas.ripe.net/measurements/10708524/ Cheers, Johan > > Regards > Milad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Wed Jan 10 11:50:13 2018 From: vnaumov at ripe.net (Viktor Naumov) Date: Wed, 10 Jan 2018 11:50:13 +0100 Subject: [atlas] Minor changes in the probe archive API Message-ID: <5d98f4eb-801c-ffbb-a4fe-3dc13d25262c@ripe.net> Dear colleagues, We made some changes to the probe archives API. The changes relate to the use of another storage back-end.?In addition to the "date" URL argument, which returns the all probes dump for the given date, the new version enables ranges of dates to be specified for all or selected probes. The example below will return dumps for probes 1, 5, 81, 82, 83 for dates in the range [2018-01-03, 2018-01-06): https://atlas.ripe.net/api/v2/probes/archive?/api/v2/probes/archive?date__gte=2018-01-03&date__lt=2018-01-06&probe=1,5,81-83 Best regards RIPE Atlas Team From vnaumov at ripe.net Wed Jan 10 11:58:06 2018 From: vnaumov at ripe.net (Viktor Naumov) Date: Wed, 10 Jan 2018 11:58:06 +0100 Subject: [atlas] Minor changes in the probe archive API In-Reply-To: <5d98f4eb-801c-ffbb-a4fe-3dc13d25262c@ripe.net> References: <5d98f4eb-801c-ffbb-a4fe-3dc13d25262c@ripe.net> Message-ID: Sorry. The URL in the example should be: https://atlas.ripe.net/api/v2/probes/archive?date__gte=2018-01-03&date__lt=2018-01-06&probe=1,5,81-83 Best regards RIPE Atlas Team On 1/10/18 11:50 AM, Viktor Naumov wrote: > Dear colleagues, > > We made some changes to the probe archives API. The changes relate to > the use of another storage back-end.?In addition to the "date" URL > argument, which returns the all probes dump for the given date, the > new version enables ranges of dates to be specified for all or > selected probes. > > The example below will return dumps for probes 1, 5, 81, 82, 83 for > dates in the range [2018-01-03, 2018-01-06): > > https://atlas.ripe.net/api/v2/probes/archive?/api/v2/probes/archive?date__gte=2018-01-03&date__lt=2018-01-06&probe=1,5,81-83 > > > Best regards > > RIPE Atlas Team > > > From klaus.mailinglists at pernau.at Thu Jan 11 00:12:03 2018 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 11 Jan 2018 00:12:03 +0100 Subject: [atlas] Connectivity Problems in China Message-ID: <0f6e2a38-572e-8644-4a83-6cf23cf4c68b@pernau.at> Hi! I have probe #248 which was working fine for long time. Now I sent it to a friend in China. He connected it to his home DSL account but the probe is still disconnected. Are you aware of any firewall problems for probes in China? Should the be able to connect on a normal residental Internet access? Where does the probes tries to connect? (Hostname, IP) so I can try to telnet the IP:port from a normal PC. Thanks Klaus From b.buerger at pengutronix.de Thu Jan 11 18:39:48 2018 From: b.buerger at pengutronix.de (Bjoern Buerger) Date: Thu, 11 Jan 2018 18:39:48 +0100 Subject: [atlas] beta status page vs. ipv6 only network Message-ID: <20180111173948.iswbtnd7h3u6pkcb@pengutronix.de> Hi, One of our probes has a warning "IPv4 Doesn't Work Properly" on the beta Status Page, along with a "IPv4 doesn't work" Tag on the main page. While this is technically correct, the cause is simple and nothing is broken. We just removed IPv4 from that specific network segment (because it's not needed anymore). Is it possible to somehow tag the probe as "single stack on purpose" in the configuration page? Thanks in advance, Bj?rn From stanish.stanishev at vivacom.bg Fri Jan 12 09:23:56 2018 From: stanish.stanishev at vivacom.bg (Stanish Stanishev) Date: Fri, 12 Jan 2018 09:23:56 +0100 Subject: [atlas] #6262 Disconnectted Message-ID: Hello, Yesterday i got a notification that one of the our Anchors - #6262 has disconnected from Atlas. According to its Current Status info - DNS Problem Suspected. I see the anchor is configured to use the following DNS Resolvers - 8.8.8.8 and 2620:74:1b::1:1. The anchor responds to pings and is reachable from the world. Also the resolvers 8.8.8.8 are 2620:74:1b::1:1 reachable from the anchor's uplink router. So apart from checking the anchor's connectivity and DNS resolvers I don't have much left to do in order to get the anchor connected again. Has anyone faced this situation before ? Thanks Stanish Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From vnaumov at ripe.net Fri Jan 12 10:27:32 2018 From: vnaumov at ripe.net (Viktor Naumov) Date: Fri, 12 Jan 2018 10:27:32 +0100 Subject: [atlas] #6262 Disconnectted In-Reply-To: References: Message-ID: <6867ae59-968c-b13e-d0a9-93bdee04ca4e@ripe.net> Hi Stanish, The "DNS Problem Suspected" tag is set when the Atlas back-end doesn't see SOS messages. Probe/anchor sends SOS messages by means of DNS when it is about to connects to the registration server. The last SOS message from your anchor was received 2017?09?12T09:47:18.115Z while it reconnected 2 times since then. That suggests the diag system that your anchor has some DNS issues. If you needs further assistance bringing your anchor online I would suggest you to create a ticket. Best regards /vty On 1/12/18 9:23 AM, Stanish Stanishev wrote: > Hello, > Yesterday i got a notification that one of the our Anchors - #6262 has disconnected from Atlas. According to its Current Status info - DNS Problem Suspected. I see the anchor is configured to use the following DNS Resolvers - 8.8.8.8 and 2620:74:1b::1:1. > > The anchor responds to pings and is reachable from the world. Also the resolvers 8.8.8.8 are 2620:74:1b::1:1 reachable from the anchor's uplink router. > > So apart from checking the anchor's connectivity and DNS resolvers I don't have much left to do in order to get the anchor connected again. > > Has anyone faced this situation before ? > > Thanks > Stanish > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stanish.Stanishev at vivacom.bg Fri Jan 12 10:46:30 2018 From: Stanish.Stanishev at vivacom.bg (Stanish Stanishev) Date: Fri, 12 Jan 2018 09:46:30 +0000 Subject: [atlas] #6262 Disconnectted In-Reply-To: <6867ae59-968c-b13e-d0a9-93bdee04ca4e@ripe.net> References: <6867ae59-968c-b13e-d0a9-93bdee04ca4e@ripe.net> Message-ID: <693dd4c736d94798a91428f85b180ce6@Exch02.ad.btk.bg> Hi Viktor, Thank you for the prompt answer. I will create a ticket. Regards Stanish From: Viktor Naumov [mailto:vnaumov at ripe.net] Sent: Friday, January 12, 2018 11:28 AM To: Stanish Stanishev ; ripe-atlas at ripe.net Subject: Re: [atlas] #6262 Disconnectted Hi Stanish, The "DNS Problem Suspected" tag is set when the Atlas back-end doesn't see SOS messages. Probe/anchor sends SOS messages by means of DNS when it is about to connects to the registration server. The last SOS message from your anchor was received 2017?09?12T09:47:18.115Z while it reconnected 2 times since then. That suggests the diag system that your anchor has some DNS issues. If you needs further assistance bringing your anchor online I would suggest you to create a ticket. Best regards /vty On 1/12/18 9:23 AM, Stanish Stanishev wrote: Hello, Yesterday i got a notification that one of the our Anchors - #6262 has disconnected from Atlas. According to its Current Status info - DNS Problem Suspected. I see the anchor is configured to use the following DNS Resolvers - 8.8.8.8 and 2620:74:1b::1:1. The anchor responds to pings and is reachable from the world. Also the resolvers 8.8.8.8 are 2620:74:1b::1:1 reachable from the anchor's uplink router. So apart from checking the anchor's connectivity and DNS resolvers I don't have much left to do in order to get the anchor connected again. Has anyone faced this situation before ? Thanks Stanish Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Fri Jan 12 11:02:02 2018 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 12 Jan 2018 11:02:02 +0100 Subject: [atlas] beta status page vs. ipv6 only network In-Reply-To: <20180111173948.iswbtnd7h3u6pkcb@pengutronix.de> References: <20180111173948.iswbtnd7h3u6pkcb@pengutronix.de> Message-ID: <6bc8ebf8-824f-e017-d12d-8b7b4eff0697@ripe.net> On 2018-01-11 18:39, Bjoern Buerger wrote: > Hi, > > One of our probes has a warning "IPv4 Doesn't Work Properly" > on the beta Status Page, along with a "IPv4 doesn't work" > Tag on the main page. > > While this is technically correct, the cause is simple and > nothing is broken. We just removed IPv4 from that specific > network segment (because it's not needed anymore). > > Is it possible to somehow tag the probe as "single stack > on purpose" in the configuration page? > > Thanks in advance, > Bj?rn Hello, This is an interesting corner case (for now :-) ) I'd think it's relatively difficult to automatically (i.e. system) tag probes as "intentionally single stack", as we don't really know if that's a misconfiguration (e.g. DHCP server is down) or intentional. We could probably system-tag your probe and others like it as no-ipv4. I'd also recommend user-tagging the probe as "IPv6-only" to make this explicit. Regards, Robert From Tim.Chown at jisc.ac.uk Mon Jan 15 13:09:14 2018 From: Tim.Chown at jisc.ac.uk (Tim Chown) Date: Mon, 15 Jan 2018 12:09:14 +0000 Subject: [atlas] Probe and firewall settings? Message-ID: Hi, At https://atlas.ripe.net/about/faq/#so-which-services-do-i-need-for-my-probe-to-work it says "The absolute minimum set is DHCP, DNS and outgoing TCP port 443 (HTTPS) in order to allow the probe to connect to the network. However, this in itself is not enough to do measurements, which is the entire focus of RIPE Atlas, so you should also allow ICMP, UDP (DNS + traceroute), TCP for traceroute and HTTP(S)." What specific ports and protocols are required for routine operation and for inbound or outbound measurements to be configured? I think the above info could be a little more detailed (having had questions asked of me). Many thanks, Tim From robert at ripe.net Mon Jan 15 13:23:27 2018 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 15 Jan 2018 13:23:27 +0100 Subject: [atlas] Probe and firewall settings? In-Reply-To: References: Message-ID: <9576a83d-497d-a9a5-374c-cb0bfd860fb6@ripe.net> On 2018-01-15 13:09, Tim Chown wrote: > Hi, > > At https://atlas.ripe.net/about/faq/#so-which-services-do-i-need-for-my-probe-to-work > > it says > > "The absolute minimum set is DHCP, DNS and outgoing TCP port 443 (HTTPS) in order to allow the probe to connect to the network. However, this in itself is not enough to do measurements, which is the entire focus of RIPE Atlas, so you should also allow ICMP, UDP (DNS + traceroute), TCP for traceroute and HTTP(S)." > > What specific ports and protocols are required for routine operation and for inbound or outbound measurements to be configured? I think the above info could be a little more detailed (having had questions asked of me). > > Many thanks, > Tim Hi, The more precise we try to be, the more wrong we'll end up being :-) but I'll try to be a bit more specific. For incoming traffic: the probes don't provide real accessible services, so incoming ICMP/ping and UDP/traceroute is probably enough (assuming the probe is otherwise not firewalled / NATed). For outgoing traffic: the more you allow, the more measurements will have a chance of succeeding. For example, if you only allow TCP/443 out, then measurements to other ports (like TCP/traceroute or TLS to non-443) will likely fail. Allowing outgoing DNS to any server is a must in order to be useful for non-local-resolver queries. And so on. We also have NTP since the writing of the above FAQ entry, and HTTP towards anchors. While the requirements (or, I should say, recommendations) don't change each day, they do evolve over time. Hope this helps! Robert From bortzmeyer at nic.fr Mon Jan 15 16:57:36 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 15 Jan 2018 16:57:36 +0100 Subject: [atlas] beta status page vs. ipv6 only network In-Reply-To: <6bc8ebf8-824f-e017-d12d-8b7b4eff0697@ripe.net> References: <20180111173948.iswbtnd7h3u6pkcb@pengutronix.de> <6bc8ebf8-824f-e017-d12d-8b7b4eff0697@ripe.net> Message-ID: <20180115155736.y2jibd2qllxa6qbt@nic.fr> On Fri, Jan 12, 2018 at 11:02:02AM +0100, Robert Kisteleki wrote a message of 31 lines which said: > I'd think it's relatively difficult to automatically (i.e. system) > tag probes as "intentionally single stack", as we don't really know > if that's a misconfiguration (e.g. DHCP server is down) or > intentional. Note there is some work at the IETF, in the sunset4 working group, to address this very problem. Document draft-ietf-sunset4-gapanalysis (the gap analysis) describe it as "3.1. Indicating that IPv4 connectivity is unavailable PROBLEM 1: When an IPv4 node boots and requests an IPv4 address (e.g., using DHCP), it typically interprets the absence of a response as a failure condition even when it is not." There is no standard solution today. Document draft-ietf-sunset4-noipv4 proposed "a new DHCPv6 option and a new Router Advertisement option to inform a dual-stack host or router that IPv4 can be turned off" but this document died, I don't know why. From Tim.Chown at jisc.ac.uk Mon Jan 15 17:12:17 2018 From: Tim.Chown at jisc.ac.uk (Tim Chown) Date: Mon, 15 Jan 2018 16:12:17 +0000 Subject: [atlas] Probe and firewall settings? In-Reply-To: <9576a83d-497d-a9a5-374c-cb0bfd860fb6@ripe.net> References: <9576a83d-497d-a9a5-374c-cb0bfd860fb6@ripe.net> Message-ID: <05A9C535-404A-4F33-8FF9-73D27146ECF5@jisc.ac.uk> Hi Robert, > On 15 Jan 2018, at 12:23, Robert Kisteleki wrote: > > On 2018-01-15 13:09, Tim Chown wrote: >> Hi, >> >> At https://atlas.ripe.net/about/faq/#so-which-services-do-i-need-for-my-probe-to-work >> >> it says >> >> "The absolute minimum set is DHCP, DNS and outgoing TCP port 443 (HTTPS) in order to allow the probe to connect to the network. However, this in itself is not enough to do measurements, which is the entire focus of RIPE Atlas, so you should also allow ICMP, UDP (DNS + traceroute), TCP for traceroute and HTTP(S)." >> >> What specific ports and protocols are required for routine operation and for inbound or outbound measurements to be configured? I think the above info could be a little more detailed (having had questions asked of me). >> >> Many thanks, >> Tim > > Hi, > > The more precise we try to be, the more wrong we'll end up being :-) but > I'll try to be a bit more specific. > > For incoming traffic: the probes don't provide real accessible services, > so incoming ICMP/ping and UDP/traceroute is probably enough (assuming > the probe is otherwise not firewalled / NATed). I think some probes we'd like to run tests to are behind a firewall, hence the interest on what's required as a minimum for at least basic connectivity tests. I'll follow up directly with a couple of specific examples rather than cite them here. > For outgoing traffic: the more you allow, the more measurements will > have a chance of succeeding. For example, if you only allow TCP/443 out, > then measurements to other ports (like TCP/traceroute or TLS to non-443) > will likely fail. Allowing outgoing DNS to any server is a must in order > to be useful for non-local-resolver queries. And so on. OK, thanks. A tweak to the FAQ along those lines would be good, I think :) > We also have NTP since the writing of the above FAQ entry, and HTTP > towards anchors. While the requirements (or, I should say, > recommendations) don't change each day, they do evolve over time. Understood, and thanks again. Tim > > Hope this helps! > Robert > From vnaumov at ripe.net Wed Jan 17 13:51:05 2018 From: vnaumov at ripe.net (Viktor Naumov) Date: Wed, 17 Jan 2018 13:51:05 +0100 Subject: [atlas] Minor changes in the credits transactions API endpoint Message-ID: <19cc3bf9-f6ce-068c-a810-552bda19921e@ripe.net> Dear colleagues, We made some changes to the credits transactions API. The changes relate to the use of another storage back-end. * Transaction IDs are no longer used to retrieve the data. * There is no detail transaction endpoint anymore, all transactions are served as paged lists. * The main transaction endpoint remains /api/v2/credits/transactions/ Deprecated endpoints are as follows: * /api/v2/credits/transactions/ * /api/v2/credits/transactions/admin/ * /api/v2/credits/transactions/measurement/ * /api/v2/credits/transactions/probe/ The transactions endpoint reference is accessible at: https://atlas.ripe.net/docs/api/v2/reference/ Best regards, Viktor Naumov RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at ripe.net Mon Jan 22 18:09:34 2018 From: sds at ripe.net (Stephen D. Strowes) Date: Mon, 22 Jan 2018 18:09:34 +0100 Subject: [atlas] HTTP server configuration fix deployed to v3 anchors Message-ID: <1a489279-a24a-1b7d-77d5-dbccb72a6e57@ripe.net> Hi, Recently we identified a web server misconfiguration on our v3 anchors, such that those anchors would not respond as expected to requests with their IP literal in the URL. Requests to their FQDN worked as expected. In other words: * http://nl-ams-as3333-3.anchors.atlas.ripe.net:80/ would respond as expected, but * http://[2001:67c:2e8:3::c100:a4]:80/ would respond with a 404 status code. The configuration was fixed and deployed by around 0900UTC on 16 January, 2018. V3 anchors now respond correctly to requests issued with their IP literal in the URL. This affected HTTP measurements to v3 anchors as follows: * Before the fix was deployed, HTTP measurements to a v3 anchor with 'Resolve on probe' set to false will have used the IP literal, and thus logged a 404 status code. * HTTP measurements as above that were running when the fix was deployed will have started returning correct results part-way through their run. If the measurement is ongoing, no other action needs to be taken. * HTTP measurements with 'Resolve on probe' set to true always operated as expected. Cheers, Stephen Strowes RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From informatica at ipysvenezuela.org Tue Jan 23 02:09:08 2018 From: informatica at ipysvenezuela.org (=?UTF-8?Q?Inform=C3=A1tica_IPYS?=) Date: Mon, 22 Jan 2018 21:09:08 -0400 Subject: [atlas] Query Message-ID: Hi, I'm Francisco Colmenares from IPYS Venezuela. I am writing to you because I have a conuslta. After having registered on the RIPE ATLAS page, connect the RIPE to the network, however when I search for the ID in the search engine that has the web page it gives me the ERROR: 101: no entries found. Is there a step I'm missing? Greetings. -- Francisco Colmenares Desarrollo web y Soporte t?cnico. IPYS Venezuela 0426-1991873 -------------- next part -------------- An HTML attachment was scrubbed... URL: From compyblog at gmail.com Wed Jan 24 21:30:23 2018 From: compyblog at gmail.com (Andre Heinrichs) Date: Wed, 24 Jan 2018 20:30:23 +0000 Subject: [atlas] Probe shown as offline although LEDs appear online Message-ID: Hi, My Probe #29384 has started being reported as offline although the LEDs show no problem. I?ve just tried switching to another USB stick without apparent success. The weird part is that the probe seems to not send any SOS requests as soon as it started running off the USB. I?m guessing that makes it offline. If I?m interpreting the connection & traffic graph correctly the probe is still able to return results. Any advice what I could do now would be appreciated. TIA, Andre Heinrichs -------------- next part -------------- An HTML attachment was scrubbed... URL: From compyblog at gmail.com Thu Jan 25 06:39:33 2018 From: compyblog at gmail.com (Andre Heinrichs) Date: Thu, 25 Jan 2018 06:39:33 +0100 Subject: [atlas] Probe shown as offline although LEDs appear online In-Reply-To: References: Message-ID: Update: The probe website has since ackowledged that the probe was online. So it appears that something outside of my network was wrong. Even more confusing: while I was still trying to get the probe and website to agree the probe was shown as having been online for 2 hours. that was wrong in the other direction. Although it seems that there still were no SOS requests after the last one before the probe booted from the newly initialized USB stick. As long as the rest works I'd count that as another weirdness. TIA, Andre Heinrichs On Wed, Jan 24, 2018 at 9:30 PM, Andre Heinrichs wrote: > Hi, > > My Probe #29384 has started being reported as offline although the LEDs show > no problem. I?ve just tried switching to another USB stick without apparent > success. The weird part is that the probe seems to not send any SOS requests > as soon as it started running off the USB. I?m guessing that makes it > offline. If I?m interpreting the connection & traffic graph correctly the > probe is still able to return results. Any advice what I could do now would > be appreciated. > > TIA, > Andre Heinrichs From mir at ripe.net Thu Jan 25 13:07:05 2018 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 25 Jan 2018 13:07:05 +0100 Subject: [atlas] New on RIPE Labs: Measurements as the Key to Transparency In-Reply-To: References: Message-ID: Dear colleagues, In this new article on RIPE Labs Alexander Azimov describes how they built a tool to visualise network latency measured with RIPE Atlas. https://labs.ripe.net/Members/alexander_azimov/measurements-as-the-key-to-transparency Kind regards, Mirjam K?hne RIPE NCC From yang.yu.list at gmail.com Sat Jan 27 20:08:11 2018 From: yang.yu.list at gmail.com (Yang Yu) Date: Sat, 27 Jan 2018 11:08:11 -0800 Subject: [atlas] Connectivity Problems in China In-Reply-To: <0f6e2a38-572e-8644-4a83-6cf23cf4c68b@pernau.at> References: <0f6e2a38-572e-8644-4a83-6cf23cf4c68b@pernau.at> Message-ID: Do you see anything under Network - SOS History? It should report the type of issue over DNS A/AAAA query to *.sos.atlas.ripe.net Likely a DHCP/DNS issue if nothing is reported under SOS hisotry. I am not aware of any DNS hijacking on atlas.ripe.net but probe rarely stays connected for more than a week (it can reconnect after a few minutes). Last time I checked the probe connects to woolsey.atlas.ripe.net tcp/22 and oneill.atlas.ripe.net tcp/443. On Wed, Jan 10, 2018 at 3:12 PM, Klaus Darilion wrote: > Hi! > > I have probe #248 which was working fine for long time. Now I sent it to > a friend in China. He connected it to his home DSL account but the probe > is still disconnected. > > Are you aware of any firewall problems for probes in China? Should the > be able to connect on a normal residental Internet access? > > Where does the probes tries to connect? (Hostname, IP) so I can try to > telnet the IP:port from a normal PC. > > Thanks > Klaus > From wolfgang.rupprecht at gmail.com Sun Jan 28 01:20:10 2018 From: wolfgang.rupprecht at gmail.com (Wolfgang S Rupprecht) Date: Sat, 27 Jan 2018 16:20:10 -0800 Subject: [atlas] tag "system: IPv6 Works" Message-ID: I just joined the RIPE-Atlas fold with probe #35105 and am still learning the ropes. My public-facing internet servers are all IPv6-only. That means that the only meaningful measurements of my systems come from IPv6 capable probes. I was surprised to see that IPv4-only probes would be scheduled to send IPv6 pings, traceroutes, nslookups etc. Even when I added "system: IPv6 Works" to the include tags and "system: IPv6 Doesn't Work" to the exclude tags I still got some IPv4-only probes assigned. Are those tags for future use and not wired up yet? Are the IPv4-only probes I'm seeing in my test runs there because their status changed recently and previously they were IPv6 capable? ? -wolfgang From camin at ripe.net Mon Jan 29 16:11:13 2018 From: camin at ripe.net (Chris Amin) Date: Mon, 29 Jan 2018 16:11:13 +0100 Subject: [atlas] tag "system: IPv6 Works" In-Reply-To: References: Message-ID: <13ff6765-be83-252c-5144-bd092ecc92d1@ripe.net> Hi Wolfgang, welcome to the community! On 28/01/2018 01:20, Wolfgang S Rupprecht wrote: > I was surprised to see that IPv4-only probes would be scheduled to > send IPv6 pings, traceroutes, nslookups etc. Even when I added > "system: IPv6 Works" to the include tags and "system: IPv6 Doesn't > Work" to the exclude tags I still got some IPv4-only probes assigned. > Are those tags for future use and not wired up yet? Are the IPv4-only > probes I'm seeing in my test runs there because their status changed > recently and previously they were IPv6 capable? These tags are currently reapplied every 4 hours, so there is indeed the possibility that a probe is no longer capable of carrying out measurements with a particular address family even though it has an "IPvX Works" tag applied. If you have a particular example or examples then please send them to me directly and I will take a look to see if there's anything strange going on. Regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rherold at afterbuy.de Wed Jan 31 13:46:03 2018 From: rherold at afterbuy.de (Ruben Herold) Date: Wed, 31 Jan 2018 13:46:03 +0100 Subject: [atlas] False positives on SSL check? Message-ID: hi, I tried to monitor on of our services running on https://login.afterbuy.de. I configured an SSL check like (Meassure ID #11090260). All probes response with: Error: timeout reading hello But the service is online and reachable. SSLabs SSL check confirmed this. So can someone explain what the error message will tell me? Thx Ruben Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum