From christian at kuhtz.com Thu May 2 04:38:13 2019 From: christian at kuhtz.com (Christian Kuhtz) Date: Wed, 1 May 2019 19:38:13 -0700 Subject: [atlas] Communication with probes' owners In-Reply-To: <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> Message-ID: Please no automatic nag emails. On Sun, Apr 21, 2019, 3:14 PM Carsten Schiefner wrote: > Am 21.04.2019 um 19:59 schrieb Dave . : > If this gets implemented, please add a checkbox where one can indicate > whether one is a user or also can get things fixed in the AS where your > probe is connected. > Makes sense to me: +1. > > Would then a reminder every 1/2/3 month[s] make sense that this is (still) > the case aka. this flag to be set? > > As the probe?s circumstances may change... > > Op vr 19 apr. 2019 om 12:37 schreef Paolo Pozzan >: > >> It seems a good idea. I don't think this will be abused and in case it >> would be easy to point out the spammers. >> Would this be useful also for other kind of messages? >> >> Paolo >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gponikie at akamai.com Tue May 7 17:36:49 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Tue, 7 May 2019 15:36:49 +0000 Subject: [atlas] Incorrect location of probe #6422 Message-ID: <2D126B11-9901-4644-9EFF-2001AA47673E@akamai.com> Hi all! According to Atlas probe #6422 is located in Los Angeles but from measurements it's clear that probe is in Miami. Can somebody relay this information to probe owner to fix location? Regards, Grzegorz -------------- next part -------------- An HTML attachment was scrubbed... URL: From gponikie at akamai.com Tue May 7 17:39:58 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Tue, 7 May 2019 15:39:58 +0000 Subject: [atlas] [WARNING! RECEIVED FROM EXTERNAL SENDER] Incorrect location of probe #6422 Message-ID: <3AB5B8BB-7A79-4605-A93E-E3738B971CA0@akamai.com> BTW it's an anchor. I guess that location of anchors should be double-checked as they play important role. Regards, Grzegorz From: "Ponikierski, Grzegorz" Date: Tuesday 2019-05-07 at 17:37 To: "ripe-atlas at ripe.net" Subject: [WARNING! RECEIVED FROM EXTERNAL SENDER] [atlas] Incorrect location of probe #6422 Hi all! According to Atlas probe #6422 is located in Los Angeles but from measurements it's clear that probe is in Miami. Can somebody relay this information to probe owner to fix location? Regards, Grzegorz -------------- next part -------------- An HTML attachment was scrubbed... URL: From carsten at schiefner.de Thu May 9 11:09:19 2019 From: carsten at schiefner.de (Carsten Schiefner) Date: Thu, 9 May 2019 11:09:19 +0200 Subject: [atlas] Trimming the 'Subject:'... In-Reply-To: <3AB5B8BB-7A79-4605-A93E-E3738B971CA0@akamai.com> References: <3AB5B8BB-7A79-4605-A93E-E3738B971CA0@akamai.com> Message-ID: <66bd5438-6a8b-eb78-8559-d9ee05e7b530@schiefner.de> Dar all - could I please kindly ask everybody who is subscribed to this as well as to any other mailing list and whose employer sports an email system that heavily alter an email subject by adding "WARNINGS" about "EXTERNAL SENDERS" and the likes to revert the subject back to what it was before sending a reply? I find it particularly odd if such additions more than double the subject length. In any case it makes it harder to read. Thanks and best, -C. -------- Forwarded Message -------- Subject: Re: [atlas] [WARNING! RECEIVED FROM EXTERNAL SENDER] Incorrect location of probe #6422 Date: Tue, 7 May 2019 15:39:58 +0000 From: Ponikierski, Grzegorz To: ripe-atlas at ripe.net BTW it's an anchor. I guess that location of anchors should be double-checked as they play important role. ? Regards, Grzegorz ? *From: *"Ponikierski, Grzegorz" *Date: *Tuesday 2019-05-07 at 17:37 *To: *"ripe-atlas at ripe.net" *Subject: *[WARNING! RECEIVED FROM EXTERNAL SENDER] [atlas] Incorrect location of probe #6422 ? Hi all! ? According to Atlas probe #6422 is located in Los Angeles but from measurements it's clear that probe is in Miami. Can somebody relay this information to probe owner to fix location? ? Regards, Grzegorz From daknob.mac at gmail.com Sat May 18 21:55:35 2019 From: daknob.mac at gmail.com (Antonios Chariton) Date: Sat, 18 May 2019 22:55:35 +0300 Subject: [atlas] New probe tags proposal Message-ID: <567A4416-0795-4946-9636-16F62B1EB653@gmail.com> Hello everyone, I believe it would be of interest to have system-assigned tags to probes based on whether their network is performing RPKI validation or not. This can be two new tags, ?rpki-validating? and ?no-rpki-validation?, or similar. The tags should be assigned per probe, using RIPE?s RIS Routing Beacons [1], by running system ping checks every hour / day. What do you think? Would this be something that you would find useful? Thanks, Antonis 1: https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/current-ris-routing-beacons -------------- next part -------------- An HTML attachment was scrubbed... URL: From amreesh.phokeer at gmail.com Sat May 18 23:34:05 2019 From: amreesh.phokeer at gmail.com (Amreesh Phokeer) Date: Sun, 19 May 2019 01:34:05 +0400 Subject: [atlas] New probe tags proposal In-Reply-To: <567A4416-0795-4946-9636-16F62B1EB653@gmail.com> References: <567A4416-0795-4946-9636-16F62B1EB653@gmail.com> Message-ID: That's a cool idea and easily implementable. On Sat, May 18, 2019, 23:56 Antonios Chariton wrote: > Hello everyone, > I believe it would be of interest to have system-assigned tags to probes > based on whether their network is performing RPKI validation or not. This > can be two new tags, ?rpki-validating? and ?no-rpki-validation?, or > similar. The tags should be assigned per probe, using RIPE?s RIS Routing > Beacons [1], by running system ping checks every hour / day. > > What do you think? Would this be something that you would find useful? > > Thanks, > Antonis > > 1: > https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/current-ris-routing-beacons > -------------- next part -------------- An HTML attachment was scrubbed... URL: From furry13 at gmail.com Mon May 20 19:08:14 2019 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 21 May 2019 03:08:14 +1000 Subject: [atlas] Feature Request to consider: DNS response IP header Message-ID: Hello, I have a number of use cases when it would be very useful to have access to the IP header of the measurement response packets. In my scenario I'd like to see TTL/Hop Limit of packets received in DNS measurements. So I'm curious if anyone else think it would be a useful feature and if there is some demand for such a feature - maybe the Atlas team could consider implementing it? Thanks! -- SY, Jen Linkova aka Furry From petr.spacek at nic.cz Wed May 22 13:32:38 2019 From: petr.spacek at nic.cz (=?UTF-8?B?UGV0ciDFoHBhxI1law==?=) Date: Wed, 22 May 2019 11:32:38 +0000 Subject: [atlas] Feature Request to consider: DNS response IP header In-Reply-To: References: Message-ID: Hello, On 20. 05. 19 17:08, Jen Linkova wrote: > Hello, > > I have a number of use cases when it would be very useful to have > access to the IP header of the measurement response packets. In my > scenario I'd like to see TTL/Hop Limit of packets received in DNS > measurements. > > So I'm curious if anyone else think it would be a useful feature and > if there is some demand for such a feature - maybe the Atlas team > could consider implementing it? Yes, I think it is occasionally useful. -- Petr ?pa?ek @ CZ.NIC From Hans.Mayer at iiasa.ac.at Wed May 22 14:40:49 2019 From: Hans.Mayer at iiasa.ac.at (Mayer Hans) Date: Wed, 22 May 2019 12:40:49 +0000 Subject: [atlas] RFC1918 probes Message-ID: <8ae4f6ab8d7f4a688540bd23a4294aae@RHONE.iiasa.ac.at> Dear All, Looking at the result of a traceroute measurement I see very often that first hop has a RFC1918 address. These days a found a result where the first 3 hops are showing something like 192.168.x.y Of course this could falsify the result especially for response time. Is there a way to select only Atlas probes which are located in non RFC1918 networks ? If not it would be nice to have such a possibility. Kind regards Hans -- Ing. Dipl.-Ing. Hans Mayer Systems Administrator Information and Communication Technologies (ICT) International Institute for Applied Systems Analysis (IIASA) Schlossplatz 1 A-2361 Laxenburg, Austria Phone: +43 2236 807 Ext 215 Mobile: +43 676 83 807 215 Web: http://www.iiasa.at E-Mail: mayer at iiasa.ac.at Atlas probe: 35603 Note: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. From jared at puck.nether.net Wed May 22 15:31:24 2019 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 22 May 2019 09:31:24 -0400 Subject: [atlas] RFC1918 probes In-Reply-To: <8ae4f6ab8d7f4a688540bd23a4294aae@RHONE.iiasa.ac.at> References: <8ae4f6ab8d7f4a688540bd23a4294aae@RHONE.iiasa.ac.at> Message-ID: <62DBCC73-BA12-473A-B719-DF18206AE5C2@puck.nether.net> > On May 22, 2019, at 8:40 AM, Mayer Hans wrote: > > > > Dear All, > > Looking at the result of a traceroute measurement I see very often that first hop has a RFC1918 address. > These days a found a result where the first 3 hops are showing something like 192.168.x.y > Of course this could falsify the result especially for response time. > Is there a way to select only Atlas probes which are located in non RFC1918 networks ? > If not it would be nice to have such a possibility. I think you?re speaking of just using the anchors? - Jared From robert at ripe.net Wed May 22 15:37:32 2019 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 22 May 2019 15:37:32 +0200 Subject: [atlas] RFC1918 probes In-Reply-To: <8ae4f6ab8d7f4a688540bd23a4294aae@RHONE.iiasa.ac.at> References: <8ae4f6ab8d7f4a688540bd23a4294aae@RHONE.iiasa.ac.at> Message-ID: <5720f989-ab7e-4343-93dc-723f95b6718e@ripe.net> On 2019-05-22 14:40, Mayer Hans wrote: > > > Dear All, > > Looking at the result of a traceroute measurement I see very often that first hop has a RFC1918 address. > These days a found a result where the first 3 hops are showing something like 192.168.x.y > Of course this could falsify the result especially for response time. > Is there a way to select only Atlas probes which are located in non RFC1918 networks ? > If not it would be nice to have such a possibility. > > Kind regards > Hans Hi, When you set up your measurement, you can exclude probes that are tagged with IPv4 RFC1918 (system-ipv4-rfc1918). Regards, Robert From Hans.Mayer at iiasa.ac.at Wed May 22 15:40:28 2019 From: Hans.Mayer at iiasa.ac.at (Mayer Hans) Date: Wed, 22 May 2019 13:40:28 +0000 Subject: [atlas] RFC1918 probes In-Reply-To: <62DBCC73-BA12-473A-B719-DF18206AE5C2@puck.nether.net> References: <8ae4f6ab8d7f4a688540bd23a4294aae@RHONE.iiasa.ac.at> <62DBCC73-BA12-473A-B719-DF18206AE5C2@puck.nether.net> Message-ID: <14b0a45f45cf425496f9197d7bc66856@RHONE.iiasa.ac.at> Dear Jared, > ... I think you?re speaking of just using the anchors? Actually not. We are owner of Atlas probe: 35603 When I setup a new measurement I am asked to enter a number of probes. So I assume only probes are used for my measurement. Isn't it ? // Hans -----Original Message----- From: Jared Mauch Sent: Wednesday, May 22, 2019 3:31 PM To: Mayer Hans Cc: ripe-atlas at ripe.net Subject: Re: [atlas] RFC1918 probes > On May 22, 2019, at 8:40 AM, Mayer Hans wrote: > > > > Dear All, > > Looking at the result of a traceroute measurement I see very often that first hop has a RFC1918 address. > These days a found a result where the first 3 hops are showing > something like 192.168.x.y Of course this could falsify the result especially for response time. > Is there a way to select only Atlas probes which are located in non RFC1918 networks ? > If not it would be nice to have such a possibility. I think you?re speaking of just using the anchors? - Jared From Hans.Mayer at iiasa.ac.at Wed May 22 15:46:35 2019 From: Hans.Mayer at iiasa.ac.at (Mayer Hans) Date: Wed, 22 May 2019 13:46:35 +0000 Subject: [atlas] RFC1918 probes In-Reply-To: <5720f989-ab7e-4343-93dc-723f95b6718e@ripe.net> References: <8ae4f6ab8d7f4a688540bd23a4294aae@RHONE.iiasa.ac.at> <5720f989-ab7e-4343-93dc-723f95b6718e@ripe.net> Message-ID: <4d284dcbbb2a42829b1a4b9056d5b068@RHONE.iiasa.ac.at> Dear Robert, Many thanks for coming back so quickly. Just to verify that I understood correctly: When I open "Create your selection" then I should enter the word " system-ipv4-rfc1918" in field "exclude tags". Is that what you are saying ? Kind regards Hans -- -----Original Message----- From: Robert Kisteleki Sent: Wednesday, May 22, 2019 3:38 PM To: Mayer Hans ; ripe-atlas at ripe.net Subject: Re: [atlas] RFC1918 probes On 2019-05-22 14:40, Mayer Hans wrote: > > > Dear All, > > Looking at the result of a traceroute measurement I see very often that first hop has a RFC1918 address. > These days a found a result where the first 3 hops are showing > something like 192.168.x.y Of course this could falsify the result especially for response time. > Is there a way to select only Atlas probes which are located in non RFC1918 networks ? > If not it would be nice to have such a possibility. > > Kind regards > Hans Hi, When you set up your measurement, you can exclude probes that are tagged with IPv4 RFC1918 (system-ipv4-rfc1918). Regards, Robert From robert at ripe.net Wed May 22 16:06:45 2019 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 22 May 2019 16:06:45 +0200 Subject: [atlas] RFC1918 probes In-Reply-To: <4d284dcbbb2a42829b1a4b9056d5b068@RHONE.iiasa.ac.at> References: <8ae4f6ab8d7f4a688540bd23a4294aae@RHONE.iiasa.ac.at> <5720f989-ab7e-4343-93dc-723f95b6718e@ripe.net> <4d284dcbbb2a42829b1a4b9056d5b068@RHONE.iiasa.ac.at> Message-ID: On 2019-05-22 15:46, Mayer Hans wrote: > > Dear Robert, > > Many thanks for coming back so quickly. > Just to verify that I understood correctly: > When I open "Create your selection" then I should enter the word " system-ipv4-rfc1918" in field "exclude tags". > Is that what you are saying ? > > Kind regards > Hans It depends on whether you're using the UI or the API. The UI indeed has that dialog where you can include or exclude tagged probes. Suggestions should also work so typing "1918" also should get you there. Don't forget to remove the default "any 10 probes" default. Regards, Robert From gponikie at akamai.com Thu May 30 15:22:48 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Thu, 30 May 2019 13:22:48 +0000 Subject: [atlas] Feature Request to consider: DNS response IP header In-Reply-To: References: Message-ID: <4492177B-F513-440B-98B4-EB3D252BD0B9@akamai.com> Can be useful to estimate proximity between probe and DNS and to detect nasty middle boxes. To limit overhead on Atlas side, IP header can be provided as raw data to decode on end-user side. Regards, Grzegorz From: Jen Linkova Date: Monday 2019-05-20 at 19:08 To: "ripe-atlas at ripe.net" Subject: [atlas] Feature Request to consider: DNS response IP header Hello, I have a number of use cases when it would be very useful to have access to the IP header of the measurement response packets. In my scenario I'd like to see TTL/Hop Limit of packets received in DNS measurements. So I'm curious if anyone else think it would be a useful feature and if there is some demand for such a feature - maybe the Atlas team could consider implementing it? Thanks! -- SY, Jen Linkova aka Furry -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Fri May 31 16:51:09 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 31 May 2019 16:51:09 +0200 Subject: [atlas] Feature Request to consider: DNS response IP header In-Reply-To: <4492177B-F513-440B-98B4-EB3D252BD0B9@akamai.com> References: <4492177B-F513-440B-98B4-EB3D252BD0B9@akamai.com> Message-ID: <4f48bcbd-839d-9883-76d3-23a86d9e8b8b@ripe.net> On 2019/05/30 15:22 , Ponikierski, Grzegorz wrote: > Can be useful to estimate proximity between probe and DNS and to detect > nasty middle boxes. To limit overhead on Atlas side, IP header can be > provided as raw data to decode on end-user side. As far as I know there is no option provided by the Linux kernel to receive the original IP header with recvmsg. Fields that are returned by recvmsg, such as TTL, can be added without to much trouble. I'll make a note to add that that at some point. Philip