Satellite based "last mile" and Atlas probes
Hello all, I am running what I believe to be the only probe on a Starlink satellite connection right now: https://atlas.ripe.net/probes/1001821/ Is anyone aware of a list of probe ID numbers which are definitively known to be on some form of satellite-based access technology? I am thinking of, for instance, sites on consumer grade geostationary VSATs, more serious VSATs, or in island nations which are not known to have any submarine cables. The reason why I am searching for such a list is that I intend to consume some of my accumulated credits to run periodic one-off measurements of latency, traceroutes and other things to quantify improvements in satellite based latency and other performance metrics over time. And to quantify what it looks like when an ISP previously dependent on geostationary (min 495ms latency) gains access to either terrestrial/submarine fiber, or a lower latency low earth orbit based service. The best information I can find right now is to manually pick probes which never show below geostationary latency to a first hop in any traceroute, and are located on the probes map in certain island locations. It's a bit more time consuming to manually search for probes in continental locations which are on a VSAT (for instance if anyone knows of a probe on a VSAT terminal in a remote part of Wyoming, USA, let me know...).
Am Donnerstag, 22. April 2021, 17:18:59 CEST schrieb Eric Kuhnke:
Hello all,
I am running what I believe to be the only probe on a Starlink satellite connection right now:
Is there a certain reason, why you are without IPv6?
On 22 Apr 2021, at 20:29, Thomas Schäfer <tschaefer@t-online.de> wrote:
Am Donnerstag, 22. April 2021, 17:18:59 CEST schrieb Eric Kuhnke:
Hello all,
I am running what I believe to be the only probe on a Starlink satellite connection right now:
Is there a certain reason, why you are without IPv6?
Yeah, that’s disappointing, as impressive as having a node on Starlink is. Is that a local choice, or does Starlink not carry IPv6? Tim
ipv6 has been enabled in some test areas of the Starlink network - but not all. At present it looks like a 4-to-4 cgnat. This particular test setup is using a mikrotik HAP AC router with the latest firmware, and is set up as a DHCPv6 client, if and when the network actually offers v6 to it, I'll do the rest of the work to make it available to the LAN clients. On Fri, Apr 23, 2021 at 2:18 AM Tim Chown via ripe-atlas < ripe-atlas@ripe.net> wrote:
On 22 Apr 2021, at 20:29, Thomas Schäfer <tschaefer@t-online.de> wrote:
Am Donnerstag, 22. April 2021, 17:18:59 CEST schrieb Eric Kuhnke:
Hello all,
I am running what I believe to be the only probe on a Starlink satellite connection right now:
Is there a certain reason, why you are without IPv6?
Yeah, that’s disappointing, as impressive as having a node on Starlink is.
Is that a local choice, or does Starlink not carry IPv6?
Tim
Am Freitag, 23. April 2021, 11:18:17 CEST schrieb Tim Chown:
Is that a local choice, or does Starlink not carry IPv6?
A very interesting setup was yesterday documented by awlnx via twitter. https://twitter.com/awlnx/status/1385263694649700353 She got it working. Some things I can remember: inbound is open, she presented an IPv6-only webserver, at least yesterday it was functional: https://atlas.ripe.net/measurements/29792632/#general there are some strange things: mtu is only 1280 icmp echo requests/answers are faked Regards, Thomas
On 23 Apr 2021, at 16:03, Thomas Schäfer <tschaefer@t-online.de> wrote:
Am Freitag, 23. April 2021, 11:18:17 CEST schrieb Tim Chown:
Is that a local choice, or does Starlink not carry IPv6?
A very interesting setup was yesterday documented by awlnx via twitter.
https://twitter.com/awlnx/status/1385263694649700353
She got it working. Some things I can remember:
inbound is open, she presented an IPv6-only webserver, at least yesterday it was functional: https://atlas.ripe.net/measurements/29792632/#general
there are some strange things: mtu is only 1280 icmp echo requests/answers are faked
Thanks Thomas, Eric and a couple of off list comments on IPv6. It seems you can get IPv6 working, and get a prefix via DHCPv6-PD, and support's coming more formally in May or thereabouts. Good news :) Tim
My config for IPv6-PD: root@testbox:/var/atlas-probe/etc# cat /etc/wide-dhcpv6/dhcp6c.conf profile default { information-only; request domain-name-servers; request domain-name; script "/etc/wide-dhcpv6/dhcp6c-script"; }; interface eth0 { send ia-pd 0; send ia-na 0; }; id-assoc na 0 { }; id-assoc pd 0 { prefix-interface wlan0 { sla-len 8; sla-id 1; }; prefix-interface eth0.222 { sla-len 8; sla-id 2; }; }; It works flawless but prefixes tend to change every 48 hours at least. Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap. Happy measuring!
On 26. Apr 2021, at 10:18, Tim Chown via ripe-atlas <ripe-atlas@ripe.net> wrote:
On 23 Apr 2021, at 16:03, Thomas Schäfer <tschaefer@t-online.de> wrote:
Am Freitag, 23. April 2021, 11:18:17 CEST schrieb Tim Chown:
Is that a local choice, or does Starlink not carry IPv6?
A very interesting setup was yesterday documented by awlnx via twitter.
https://twitter.com/awlnx/status/1385263694649700353
She got it working. Some things I can remember:
inbound is open, she presented an IPv6-only webserver, at least yesterday it was functional: https://atlas.ripe.net/measurements/29792632/#general
there are some strange things: mtu is only 1280 icmp echo requests/answers are faked
Thanks Thomas, Eric and a couple of off list comments on IPv6. It seems you can get IPv6 working, and get a prefix via DHCPv6-PD, and support's coming more formally in May or thereabouts. Good news :)
Tim
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: <snip>
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap.
This (the web page) is awesome. I want one (even though I have no use for Starlink here) -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane
Thank you :). And here ist the probe: https://atlas.ripe.net/probes/1002289/ It also has v6.
On 26. Apr 2021, at 14:13, Sanjeev Gupta <ghane0@gmail.com> wrote:
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: <snip> Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap.
This (the web page) is awesome. I want one (even though I have no use for Starlink here)
-- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane
Than URL doesn't resolve for me :-)-O el On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...]
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap.
[...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
V6 only ;)
On 26. Apr 2021, at 16:43, Dr Eberhard W Lisse <el@lisse.na> wrote:
Than URL doesn't resolve for me :-)-O
el
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...]
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap. [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
Hi, On Mon, Apr 26, 2021 at 04:45:11PM +0200, Annika Wickert wrote:
V6 only ;)
This is the spirit! :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Shame :-)-O el On 26/04/2021 16:45, Annika Wickert wrote:
V6 only ;)
On 26. Apr 2021, at 16:43, Dr Eberhard W Lisse <el@lisse.na> wrote:
Than URL doesn't resolve for me :-)-O
el
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...]
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap.
[...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
-- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
It’s not only viewing stats of my Dish but it’s hosted via starlink ;)
On 26. Apr 2021, at 16:55, Dr Eberhard W Lisse <el@lisse.NA> wrote:
Shame :-)-O
el
On 26/04/2021 16:45, Annika Wickert wrote:
V6 only ;)
On 26. Apr 2021, at 16:43, Dr Eberhard W Lisse <el@lisse.na> wrote:
Than URL doesn't resolve for me :-)-O
el
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...]
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap. [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
-- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
So, give it an IPv4 address as well :-)-O el On 26/04/2021 17:00, Annika Wickert wrote:
It’s not only viewing stats of my Dish but it’s hosted via starlink ;)
On 26. Apr 2021, at 16:55, Dr Eberhard W Lisse <el@lisse.NA> wrote:
Shame :-)-O
el
On 26/04/2021 16:45, Annika Wickert wrote:
V6 only ;)
On 26. Apr 2021, at 16:43, Dr Eberhard W Lisse <el@lisse.na> wrote:
Than URL doesn't resolve for me :-)-O
el
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...]
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap.
[...] [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
Starlink uses CGNAT so not an option ;).
On 26. Apr 2021, at 17:08, Dr Eberhard W Lisse <el@lisse.NA> wrote:
So, give it an IPv4 address as well :-)-O
el
On 26/04/2021 17:00, Annika Wickert wrote:
It’s not only viewing stats of my Dish but it’s hosted via starlink ;)
On 26. Apr 2021, at 16:55, Dr Eberhard W Lisse <el@lisse.NA> wrote:
Shame :-)-O
el
On 26/04/2021 16:45, Annika Wickert wrote:
V6 only ;)
On 26. Apr 2021, at 16:43, Dr Eberhard W Lisse <el@lisse.na> wrote:
Than URL doesn't resolve for me :-)-O
el
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...]
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap. [...] [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA <mailto:el@lisse.NA> / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
Ewww!
On 26 Apr 2021, at 16:09, Annika Wickert <annikaw@penguinfriends.org> wrote:
Starlink uses CGNAT so not an option ;).
On 26. Apr 2021, at 17:08, Dr Eberhard W Lisse <el@lisse.NA> wrote:
So, give it an IPv4 address as well :-)-O
el
On 26/04/2021 17:00, Annika Wickert wrote:
It’s not only viewing stats of my Dish but it’s hosted via starlink ;)
On 26. Apr 2021, at 16:55, Dr Eberhard W Lisse <el@lisse.NA> wrote:
Shame :-)-O
el
On 26/04/2021 16:45, Annika Wickert wrote:
V6 only ;)
On 26. Apr 2021, at 16:43, Dr Eberhard W Lisse <el@lisse.na> wrote:
Than URL doesn't resolve for me :-)-O
el
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...] > Also you can access my starlink via https://starlink.awlnx.space a > RIPE Probe will show up asap. [...] [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
One funny thing about the cgnat is for a while they were moving things around. I'm linked through an earth station in WA state but for a couple of days was meeting the internet in Chicago. Then it moved back to Seattle. On Mon, Apr 26, 2021, 8:10 AM Annika Wickert <annikaw@penguinfriends.org> wrote:
Starlink uses CGNAT so not an option ;).
On 26. Apr 2021, at 17:08, Dr Eberhard W Lisse <el@lisse.NA> wrote:
So, give it an IPv4 address as well :-)-O
el
On 26/04/2021 17:00, Annika Wickert wrote:
It’s not only viewing stats of my Dish but it’s hosted via starlink ;)
On 26. Apr 2021, at 16:55, Dr Eberhard W Lisse <el@lisse.NA> wrote:
Shame :-)-O
el
On 26/04/2021 16:45, Annika Wickert wrote:
V6 only ;)
On 26. Apr 2021, at 16:43, Dr Eberhard W Lisse <el@lisse.na> wrote:
Than URL doesn't resolve for me :-)-O
el
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...]
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap.
[...]
[...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
ULA :) But cool!
On 26 Apr 2021, at 15:45, Annika Wickert <annikaw@penguinfriends.org> wrote:
V6 only ;)
On 26. Apr 2021, at 16:43, Dr Eberhard W Lisse <el@lisse.na> wrote:
Than URL doesn't resolve for me :-)-O
el
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...]
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap. [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
ULA because of docker ...
On 26. Apr 2021, at 17:00, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
ULA :)
But cool!
On 26 Apr 2021, at 15:45, Annika Wickert <annikaw@penguinfriends.org> wrote:
V6 only ;)
On 26. Apr 2021, at 16:43, Dr Eberhard W Lisse <el@lisse.na> wrote:
Than URL doesn't resolve for me :-)-O
el
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...]
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap. [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
😢 Am Montag, 26. April 2021, 17:01:18 CEST schrieb Annika Wickert:
ULA because of docker ...
On 26. Apr 2021, at 17:00, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
ULA :)
But cool!
On 26 Apr 2021, at 15:45, Annika Wickert <annikaw@penguinfriends.org> wrote:
V6 only ;)
On 26. Apr 2021, at 16:43, Dr Eberhard W Lisse <el@lisse.na> wrote:
Than URL doesn't resolve for me :-)-O
el
On Mon, Apr 26, 2021 at 5:48 PM Annika Wickert <annikaw@penguinfriends.org> wrote: [...]
Also you can access my starlink via https://starlink.awlnx.space a RIPE Probe will show up asap.
[...]
At the moment the test site is using an old mikrotik HAP AC router I had sitting around, connected to the starlink PoE injector and antenna. I've tried as a dhcpv6 client with no good results, but will dig into the mikrotik documentation as a dhcp client further. On Mon, Apr 26, 2021, 1:19 AM Tim Chown via ripe-atlas <ripe-atlas@ripe.net> wrote:
On 23 Apr 2021, at 16:03, Thomas Schäfer <tschaefer@t-online.de> wrote:
Am Freitag, 23. April 2021, 11:18:17 CEST schrieb Tim Chown:
Is that a local choice, or does Starlink not carry IPv6?
A very interesting setup was yesterday documented by awlnx via twitter.
https://twitter.com/awlnx/status/1385263694649700353
She got it working. Some things I can remember:
inbound is open, she presented an IPv6-only webserver, at least yesterday it was functional: https://atlas.ripe.net/measurements/29792632/#general
there are some strange things: mtu is only 1280 icmp echo requests/answers are faked
Thanks Thomas, Eric and a couple of off list comments on IPv6. It seems you can get IPv6 working, and get a prefix via DHCPv6-PD, and support's coming more formally in May or thereabouts. Good news :)
Tim
Am Freitag, 23. April 2021, 11:18:17 CEST schrieb Tim Chown:
Is that a local choice, or does Starlink not carry IPv6?
A very interesting setup was yesterday documented by awlnx via twitter. https://twitter.com/awlnx/status/1385263694649700353 She got it working. Some things I can remember: inbound is open, she presented an IPv6-only webserver, at least yesterday it was functional: https://atlas.ripe.net/measurements/29792632/#general there are some strange things: mtu is only 1280 icmp echo request answers are faked Regards, Thomas
MTU being only 1280 can't be right, my connection looks like a normal 1500 MTU... The v4 IP shown in the measurement which is only 10ms from something, I do not think the ICMP echo is faked, that's the terrestrial gateway side of the cgnat. Which in the examples of my own starlink terminal and several others, is some item of Google equipment located near a major city's IX point. The "public" side of the cgnat for my terminal is less than a millisecond from core stuff in Seattle. Starlink terminals which exit to the Internet through a gateway in Chicago, have global-routing-table facing sides of their cgnat only 1 to 2ms away from several ISPs' looking glasses at 350 E. Cermak and other IX points in Chicago. But the end to end latency from a terminal is more like an absolute minimum of 16ms, more often an average of 23ms. On Fri, Apr 23, 2021 at 8:09 AM Thomas Schäfer <tschaefer@t-online.de> wrote:
Am Freitag, 23. April 2021, 11:18:17 CEST schrieb Tim Chown:
Is that a local choice, or does Starlink not carry IPv6?
A very interesting setup was yesterday documented by awlnx via twitter.
https://twitter.com/awlnx/status/1385263694649700353
She got it working. Some things I can remember:
inbound is open, she presented an IPv6-only webserver, at least yesterday it was functional: https://atlas.ripe.net/measurements/29792632/#general
there are some strange things: mtu is only 1280 icmp echo request answers are faked
Regards, Thomas
Wow, quite complex description worth a good diagram :D Regards, Grzegorz From: Eric Kuhnke <eric.kuhnke@gmail.com> Date: Friday 2021-04-23 at 17:23 To: Thomas Schäfer <tschaefer@t-online.de> Cc: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: Re: [atlas] Satellite based "last mile" and Atlas probes MTU being only 1280 can't be right, my connection looks like a normal 1500 MTU... The v4 IP shown in the measurement which is only 10ms from something, I do not think the ICMP echo is faked, that's the terrestrial gateway side of the cgnat. Which in the examples of my own starlink terminal and several others, is some item of Google equipment located near a major city's IX point. The "public" side of the cgnat for my terminal is less than a millisecond from core stuff in Seattle. Starlink terminals which exit to the Internet through a gateway in Chicago, have global-routing-table facing sides of their cgnat only 1 to 2ms away from several ISPs' looking glasses at 350 E. Cermak and other IX points in Chicago. But the end to end latency from a terminal is more like an absolute minimum of 16ms, more often an average of 23ms. On Fri, Apr 23, 2021 at 8:09 AM Thomas Schäfer <tschaefer@t-online.de<mailto:tschaefer@t-online.de>> wrote: Am Freitag, 23. April 2021, 11:18:17 CEST schrieb Tim Chown:
Is that a local choice, or does Starlink not carry IPv6?
A very interesting setup was yesterday documented by awlnx via twitter. https://twitter.com/awlnx/status/1385263694649700353<https://urldefense.com/v3/__https:/twitter.com/awlnx/status/1385263694649700353__;!!GjvTz_vk!DqcXz7Mmqa10BK1BpyLbKeGkcBUW4yw_iOuva3BsA94XLy7QMCqQAh-2aTtAmiQ$> She got it working. Some things I can remember: inbound is open, she presented an IPv6-only webserver, at least yesterday it was functional: https://atlas.ripe.net/measurements/29792632/#general<https://urldefense.com/v3/__https:/atlas.ripe.net/measurements/29792632/*general__;Iw!!GjvTz_vk!DqcXz7Mmqa10BK1BpyLbKeGkcBUW4yw_iOuva3BsA94XLy7QMCqQAh-26b4vRr8$> there are some strange things: mtu is only 1280 icmp echo request answers are faked Regards, Thomas
Hi Eric! I'm not aware about such list but I would use API to get list of all probes and look for tags with "satellite" or "sat" in name. Checking first hop can be tricky because this first hop can be local router with RTT <1ms and second hop can indicate that we are on satellite connectivity. For that API for sure API must be used. Here is the full list of build in measurements: https://beta-docs.atlas.ripe.net/built-in/reference.html#traceroute-5-000-6-... + build in ping tests for 1st and 2nd hop are respectively measurement #1 and #2. Regards, Grzegorz From: Eric Kuhnke <eric.kuhnke@gmail.com> Date: Thursday 2021-04-22 at 17:19 To: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: [atlas] Satellite based "last mile" and Atlas probes Hello all, I am running what I believe to be the only probe on a Starlink satellite connection right now: https://atlas.ripe.net/probes/1001821/<https://urldefense.com/v3/__https:/atlas.ripe.net/probes/1001821/__;!!GjvTz_vk!DI_IF58ljPZGyBfvrBuCqzI_b8BjXFQYsN5iY-b4H4cWPot9HcTFhbGD3LIld6o$> Is anyone aware of a list of probe ID numbers which are definitively known to be on some form of satellite-based access technology? I am thinking of, for instance, sites on consumer grade geostationary VSATs, more serious VSATs, or in island nations which are not known to have any submarine cables. The reason why I am searching for such a list is that I intend to consume some of my accumulated credits to run periodic one-off measurements of latency, traceroutes and other things to quantify improvements in satellite based latency and other performance metrics over time. And to quantify what it looks like when an ISP previously dependent on geostationary (min 495ms latency) gains access to either terrestrial/submarine fiber, or a lower latency low earth orbit based service. The best information I can find right now is to manually pick probes which never show below geostationary latency to a first hop in any traceroute, and are located on the probes map in certain island locations. It's a bit more time consuming to manually search for probes in continental locations which are on a VSAT (for instance if anyone knows of a probe on a VSAT terminal in a remote part of Wyoming, USA, let me know...).
This can be good for a start: https://atlas.ripe.net//api/v2/probes/?tags=Satellite<https://atlas.ripe.net/api/v2/probes/?tags=Satellite> https://atlas.ripe.net//api/v2/probes/?tags=VSAT<https://atlas.ripe.net/api/v2/probes/?tags=VSAT> Funny thing is that 'VSAT' is not visible in https://atlas.ripe.net/api/v2/probes/tags/ Regards, Grzegorz From: "Ponikierski, Grzegorz" <gponikie@akamai.com> Date: Thursday 2021-04-22 at 21:52 To: Eric Kuhnke <eric.kuhnke@gmail.com>, "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: Re: [atlas] Satellite based "last mile" and Atlas probes Hi Eric! I'm not aware about such list but I would use API to get list of all probes and look for tags with "satellite" or "sat" in name. Checking first hop can be tricky because this first hop can be local router with RTT <1ms and second hop can indicate that we are on satellite connectivity. For that API for sure API must be used. Here is the full list of build in measurements: https://beta-docs.atlas.ripe.net/built-in/reference.html#traceroute-5-000-6-... + build in ping tests for 1st and 2nd hop are respectively measurement #1 and #2. Regards, Grzegorz From: Eric Kuhnke <eric.kuhnke@gmail.com> Date: Thursday 2021-04-22 at 17:19 To: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: [atlas] Satellite based "last mile" and Atlas probes Hello all, I am running what I believe to be the only probe on a Starlink satellite connection right now: https://atlas.ripe.net/probes/1001821/<https://urldefense.com/v3/__https:/atlas.ripe.net/probes/1001821/__;!!GjvTz_vk!DI_IF58ljPZGyBfvrBuCqzI_b8BjXFQYsN5iY-b4H4cWPot9HcTFhbGD3LIld6o$> Is anyone aware of a list of probe ID numbers which are definitively known to be on some form of satellite-based access technology? I am thinking of, for instance, sites on consumer grade geostationary VSATs, more serious VSATs, or in island nations which are not known to have any submarine cables. The reason why I am searching for such a list is that I intend to consume some of my accumulated credits to run periodic one-off measurements of latency, traceroutes and other things to quantify improvements in satellite based latency and other performance metrics over time. And to quantify what it looks like when an ISP previously dependent on geostationary (min 495ms latency) gains access to either terrestrial/submarine fiber, or a lower latency low earth orbit based service. The best information I can find right now is to manually pick probes which never show below geostationary latency to a first hop in any traceroute, and are located on the probes map in certain island locations. It's a bit more time consuming to manually search for probes in continental locations which are on a VSAT (for instance if anyone knows of a probe on a VSAT terminal in a remote part of Wyoming, USA, let me know...).
Hello, I'm really happy to see real community help here! :-) A few extra words from my perspective:
Is anyone aware of a list of probe ID numbers which are definitively known to be on some form of satellite-based access technology? I am thinking of, for instance, sites on consumer grade geostationary VSATs, more serious VSATs, or in island nations which are not known to have any submarine cables.
We encourage hosts to tag their probes with whatever they find useful to share. I consider the connection type as one such useful attribute. Not everyone does this but indeed as Grzegorz says:
https://atlas.ripe.net//api/v2/probes/?tags=Satellite https://atlas.ripe.net//api/v2/probes/?tags=VSAT
This is what hosts already did. The list is likely not complete, and may contain false positives.
Funny thing is that 'VSAT' is not visible in https://atlas.ripe.net/api/v2/probes/tags/
I can explain this: all user-assigned tags start their lives on one probe. Some tags are not likely to be ever used by multiple hosts (eg. "email_[address]_for_questions"), others become popular and are used on multiple probes. We periodically "approve" the ones that look like they are common, so they publicly pop up in various places, eg. the one you point to above. I just approved the VSAT tag.
This gives you the list of probes that have a last-mile median RTT (endpoint_type=LM&median__gte=495) higher than 495ms: https://ihr.iijlab.net/ihr/api/network_delay/?timebin=2021-04-21T00%3A15&endpoint_type=LM&median__gte=495
I suspect Stephen will soon offer a self-service alternative using BigQuery any minute now :-) Cheers, Robert
On 23/04/2021 09:11, Robert Kisteleki wrote:
This gives you the list of probes that have a last-mile median RTT (endpoint_type=LM&median__gte=495) higher than 495ms: https://ihr.iijlab.net/ihr/api/network_delay/?timebin=2021-04-21T00%3A15&endpoint_type=LM&median__gte=495
I suspect Stephen will soon offer a self-service alternative using BigQuery any minute now :-)
Sure, why not. Maybe something like this: https://gist.github.com/sdstrowes/cb67ca755c50bbb2f23ce384750f2048 - take all yesterday's traceroutes - pick out only hops <= 2 that weren't errors or timeouts - calculate quantiles for those per probe/af/hop, and also count how many traceroutes ran - retain only those probe/af/hop rows with a median RTT >= 495 and `n` traceroutes > 100 Cheers, S.
On 22/04/2021 20:52, Ponikierski, Grzegorz via ripe-atlas wrote:
Checking first hop can be tricky because this first hop can be local router with RTT <1ms and second hop can indicate that we are on satellite connectivity. For that API for sure API must be used. Here is the full list of build in measurements: https://beta-docs.atlas.ripe.net/built-in/reference.html#traceroute-5-000-6-... <https://beta-docs.atlas.ripe.net/built-in/reference.html#traceroute-5-000-6-999> + build in ping tests for 1^st and 2^nd hop are respectively measurement #1 and #2.
Can you please elaborate on this? I have a separate need (relating to an ICANN RSSAC WG) to be able to detect high latency last mile hops but I could not identify the specific "built-in ping tests for 1st and 2nd hop" that you described. Were you perhaps suggesting that it was actually just the first couple of rows of data from the built-in *traceroute* tests that hold this data? thanks, Ray
Hi Ray, On 23/04/2021 17:44, Ray Bellis wrote:
Can you please elaborate on this?
I have a separate need (relating to an ICANN RSSAC WG) to be able to detect high latency last mile hops but I could not identify the specific "built-in ping tests for 1st and 2nd hop" that you described.
You can find these measurements either in the Built-ins tab of the probe (Ping First Hop / Ping Second Hop). https://atlas.ripe.net/probes/1001821/#tab-builtins Or over the API by accessing measurements with ids 1 (first hop, see below) and 2 (second hop). https://atlas.ripe.net/api/v2/measurements/1/results/?probe_ids=1001821&start=1619136000&stop=1619222399 Best, Malte
On 23/04/2021 10:12, Malte Appel wrote:
You can find these measurements either in the Built-ins tab of the probe (Ping First Hop / Ping Second Hop).
https://atlas.ripe.net/probes/1001821/#tab-builtins
Or over the API by accessing measurements with ids 1 (first hop, see below) and 2 (second hop).
Ah, perfect, thanks. There was a disconnect between the link previously sent, and the references to #1 and #2, mostly because those measurements don't appear to be listed on that RIPE page! Here are some probes that I spotted on my own Atlas visualiser as having slow access to the DNS root system (~300ms+) followed up by queries to measurements to #1 or #2 to look for very slow last "mile" connectivity: 11268 (DSL, very variable 100 - 900ms) 12803 (4G, /me waves at Eberhard!) 16494 (LTE, variable 30 - 250ms) 20306 (Satellite, 1st and 2nd sub 3ms, root servers 700ms+) 26228 (data not accessible) 27843 (data not accessible) 33110 (untagged, 2nd hop 270 - 420ms) 50592 ("Swisscom SAT Probe", 1st and 2nd hop sub 4ms, root 600ms+) 51871 (FTTH, 1st and 2nd hops sub 2ms, large root latency jump today) 52560 ("FastestVPN", consistent 285ms second hop) 1000244 (untagged, 2nd hop 600ms, occasional drops to 60ms) 1000795 (untagged, very variable, 35 - 1000ms!) For background, the RSSAC Local Perspective WG is looking at measurements of the root system, perhaps using Atlas, but we'd like to be able to establish a baseline figure that we can subtract to account for probes that are on the end of a slow internet access technology. We don't want the figures skewed by these outliers. I'll probably need to do some explicit traceroutes on those where the high latency was not introduced by the 1st or 2nd hop to find out where the latency does happen. I also spotted an odd probe geolocated in the north SF Bay area but with 170ms second hop latency and only hitting root anycast instances located in Europe. It smells like a long distance BGP tunnel to me, but I know the individual that runs that network so I'll check with him. Ray
I recommend some empirical care when interpreting the 1st and 2nd hop built-in measurements. These measurements heavily depend on the particular implementation of the ‘local loop’ IP layer. So please take them as just one data point. The good news is that RIPE Atlas allows researchers to do on-demand measurements from probes to better understand their local connection. Daniel
Ray, this is Africa :-)-O You can look at 1000327 if you wish as well, same location different provider. I am moving house however in May, and will get upgraded access (Fiber) from both providers. So we can see what happens as of June. 54617 is unattended in my house on the coast, but that will improve after August. And, I did pay the 99$ Deposit for Starlink (for 2022) :-)-O greetings, el On 23/04/2021 12:31, Ray Bellis wrote:
On 23/04/2021 10:12, Malte Appel wrote: [...] Here are some probes that I spotted on my own Atlas visualiser as having slow access to the DNS root system (~300ms+) followed up by queries to measurements to #1 or #2 to look for very slow last "mile" connectivity:
12803 (4G, /me waves at Eberhard!) [...]
-- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
Malte Appel already partially responded to you questions. I will try to provide more details. Each probe has build-in measurements for 1st and 2nd hop. For your probe it is: * nice view https://atlas.ripe.net/probes/1001821/#tab-builtins * 1st hop https://atlas.ripe.net/api/v2/measurements/1/results/?probe_ids=1001821&start=1619136000&stop=1619222399&format=json * 2nd hop https://atlas.ripe.net/api/v2/measurements/2/results/?probe_ids=1001821&start=1619136000&stop=1619222399&format=json If you take your probe as an example you will notice that your first hop is your local router (Starlink dish?) and it has RTT <1ms. It's your 2nd hop which can indicate what RTT is generated by Starlink satellite connection (RTT Median Average ~30ms). I'm curious where exactly is located this 2nd hop :) Regards, Grzegorz From: Ray Bellis <ray@isc.org> Date: Friday 2021-04-23 at 10:44 To: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: Re: [atlas] Satellite based "last mile" and Atlas probes On 22/04/2021 20:52, Ponikierski, Grzegorz via ripe-atlas wrote: Checking first hop can be tricky because this first hop can be local router with RTT <1ms and second hop can indicate that we are on satellite connectivity. For that API for sure API must be used. Here is the full list of build in measurements: https://urldefense.com/v3/__https://beta-docs.atlas.ripe.net/built-in/reference.html*traceroute-5-000-6-999__;Iw!!GjvTz_vk!CGnJSJwFwnAeSTFJcu_wN5qF5pxMnHYnUY2rcHz_afOJoH0Tp49DDDQm0TvPlSQ$<https://urldefense.com/v3/__https:/beta-docs.atlas.ripe.net/built-in/reference.html*traceroute-5-000-6-999__;Iw!!GjvTz_vk!CGnJSJwFwnAeSTFJcu_wN5qF5pxMnHYnUY2rcHz_afOJoH0Tp49DDDQm0TvPlSQ$> <https://urldefense.com/v3/__https://beta-docs.atlas.ripe.net/built-in/reference.html*traceroute-5-000-6-999__;Iw!!GjvTz_vk!CGnJSJwFwnAeSTFJcu_wN5qF5pxMnHYnUY2rcHz_afOJoH0Tp49DDDQm0TvPlSQ$<https://urldefense.com/v3/__https:/beta-docs.atlas.ripe.net/built-in/reference.html*traceroute-5-000-6-999__;Iw!!GjvTz_vk!CGnJSJwFwnAeSTFJcu_wN5qF5pxMnHYnUY2rcHz_afOJoH0Tp49DDDQm0TvPlSQ$> > + build in ping tests for 1^st and 2^nd hop are respectively measurement #1 and #2. Can you please elaborate on this? I have a separate need (relating to an ICANN RSSAC WG) to be able to detect high latency last mile hops but I could not identify the specific "built-in ping tests for 1st and 2nd hop" that you described. Were you perhaps suggesting that it was actually just the first couple of rows of data from the built-in *traceroute* tests that hold this data? thanks, Ray
As best I can determine the 2nd and 3rd hops are topologically very close to the major IX points in Seattle. Based on the geographic location of my probe and starlink terminal, its traffic goes up to space and back down again to 1 of 3 possible starlink earth stations in Washington state. These earth stations are known to be located at either the Starlink offices in Redmond, WA, there is one site colocated with a Level3/Centurylink/Lumen DWDM site slightly east of Seattle, and another which is at a commercial teleport in the north-central part of the state. RTT ICMP ping times to things in Seattle are a combination of two round trips through space, plus modem framing/encoding/FEC, and terrestrial latency from one of those earth stations to the downtown Seattle destination and back. For instance to the anycase instances of a nameserver that I know to be physically located at one of Seattle's main carrier hotels. On Fri, Apr 23, 2021 at 3:22 AM Ponikierski, Grzegorz via ripe-atlas < ripe-atlas@ripe.net> wrote:
Malte Appel already partially responded to you questions. I will try to provide more details.
Each probe has build-in measurements for 1st and 2nd hop. For your probe it is:
- nice view https://atlas.ripe.net/probes/1001821/#tab-builtins - 1st hop https://atlas.ripe.net/api/v2/measurements/1/results/?probe_ids=1001821&start=1619136000&stop=1619222399&format=json - 2nd hop https://atlas.ripe.net/api/v2/measurements/2/results/?probe_ids=1001821&start=1619136000&stop=1619222399&format=json
If you take your probe as an example you will notice that your first hop is your local router (Starlink dish?) and it has RTT <1ms. It's your 2nd hop which can indicate what RTT is generated by Starlink satellite connection (RTT Median Average ~30ms). I'm curious where exactly is located this 2nd hop :)
Regards,
Grzegorz
*From: *Ray Bellis <ray@isc.org> *Date: *Friday 2021-04-23 at 10:44 *To: *"ripe-atlas@ripe.net" <ripe-atlas@ripe.net> *Subject: *Re: [atlas] Satellite based "last mile" and Atlas probes
On 22/04/2021 20:52, Ponikierski, Grzegorz via ripe-atlas wrote:
Checking
first hop can be tricky because this first hop can be local router with
RTT <1ms and second hop can indicate that we are on satellite
connectivity. For that API for sure API must be used. Here is the full
list of build in measurements:
https://urldefense.com/v3/__https://beta-docs.atlas.ripe.net/built-in/refere... <https://urldefense.com/v3/__https:/beta-docs.atlas.ripe.net/built-in/reference.html*traceroute-5-000-6-999__;Iw!!GjvTz_vk!CGnJSJwFwnAeSTFJcu_wN5qF5pxMnHYnUY2rcHz_afOJoH0Tp49DDDQm0TvPlSQ$>
< https://urldefense.com/v3/__https://beta-docs.atlas.ripe.net/built-in/refere... <https://urldefense.com/v3/__https:/beta-docs.atlas.ripe.net/built-in/reference.html*traceroute-5-000-6-999__;Iw!!GjvTz_vk!CGnJSJwFwnAeSTFJcu_wN5qF5pxMnHYnUY2rcHz_afOJoH0Tp49DDDQm0TvPlSQ$>
+ build in ping tests for 1^st and 2^nd hop are respectively measurement
#1 and #2.
Can you please elaborate on this?
I have a separate need (relating to an ICANN RSSAC WG) to be able to
detect high latency last mile hops but I could not identify the specific
"built-in ping tests for 1st and 2nd hop" that you described.
Were you perhaps suggesting that it was actually just the first couple
of rows of data from the built-in *traceroute* tests that hold this data?
thanks,
Ray
Hi Eric, This gives you the list of probes that have a last-mile median RTT (endpoint_type=LM&median__gte=495) higher than 495ms: https://ihr.iijlab.net/ihr/api/network_delay/?timebin=2021-04-21T00%3A15&endpoint_type=LM&median__gte=495 Looks like probes 55562 and 1000244 are both in US and over satellite. I don't see the probes tagged with 'Satellite' but some of these probes are <200ms to the K-root... https://atlas.ripe.net/api/v2/measurements/1001/results/?probe_ids=14943&start=1619136000&stop=1619222399&format=json Romain On 4/23/21 12:18 AM, Eric Kuhnke wrote:
Hello all,
I am running what I believe to be the only probe on a Starlink satellite connection right now:
https://atlas.ripe.net/probes/1001821/ <https://atlas.ripe.net/probes/1001821/>
Is anyone aware of a list of probe ID numbers which are definitively known to be on some form of satellite-based access technology? I am thinking of, for instance, sites on consumer grade geostationary VSATs, more serious VSATs, or in island nations which are not known to have any submarine cables.
The reason why I am searching for such a list is that I intend to consume some of my accumulated credits to run periodic one-off measurements of latency, traceroutes and other things to quantify improvements in satellite based latency and other performance metrics over time. And to quantify what it looks like when an ISP previously dependent on geostationary (min 495ms latency) gains access to either terrestrial/submarine fiber, or a lower latency low earth orbit based service.
The best information I can find right now is to manually pick probes which never show below geostationary latency to a first hop in any traceroute, and are located on the probes map in certain island locations. It's a bit more time consuming to manually search for probes in continental locations which are on a VSAT (for instance if anyone knows of a probe on a VSAT terminal in a remote part of Wyoming, USA, let me know...).
participants (14)
-
Annika Wickert -
Daniel Karrenberg -
Dr Eberhard W Lisse -
Eric Kuhnke -
Gert Doering -
Malte Appel -
Ponikierski, Grzegorz -
Ray Bellis -
Robert Kisteleki -
Romain Fontugne -
Sanjeev Gupta -
Stephen Strowes -
Thomas Schäfer -
Tim Chown