[Starlink] Re: Multiday connectivity issues in Kenya.

[Starlink] Re: Multiday connectivity issues in Kenya.

[Ben Eastvold]

Confirming this from Nakuru County, Kenya, with data. I run a residential
technology training program on Starlink (sole connectivity, ~20 students),
and we have had this exact issue for 5+ days, surviving a dish firmware
update (~July 8) and full power cycles of dish and router.

Symptoms: specific destination prefixes are blackholed or unstable while
everything else performs excellently (100+ Mbps down, ~23ms latency).
Affected destinations include Fastly and Akamai ranges, including
https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E
itself. The affected set shifts over time -- sites work for a period, then
fail.

TCP connect tests (curl, port 443), same terminal, same minute, against
https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E's
four published Fastly addresses:

151.101.0.81 -- TIMEOUT, no TCP handshake (8s)
151.101.64.81 -- TIMEOUT, no TCP handshake (8s)
151.101.128.81 -- connected 0.28s, HTTP 301
151.101.192.81 -- connected 0.30s, HTTP 301

Minutes later, all four of
https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E's
addresses (151.101.1.143, 151.101.65.143, 151.101.129.143, 151.101.193.143)
timed out with no handshake -- including addresses in the same ranges that
had just worked for
https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E.
The reachable prefix set is moving under our feet, which reads as route
instability rather than a static misroute.

Akamai similarly affected:
https://www.google.com/url?q=http://ichef.bbci.co.uk&source=gmail&ust=1784012243268000&sa=E
(23.56.162.175) fails TCP entirely, so BBC pages currently render text
without images.

Traceroutes: local hops (terminal -> 100.64.0.1 -> SpaceX 206.224.x) are
consistently healthy at 20-30ms. Traffic then enters Liquid Telecom and
takes inconsistent paths to the same destination set -- some traces via
Johannesburg (lza-p2-tdn, lza-p3-jhb hops), one via Marseille
(lfr-p1/p2-mrs), with latency spiking 80-265ms and heavy loss beyond hop 7.
A trace toward the Akamai destination exits via a different upstream (
https://www.google.com/url?q=http://twelve99.net/Arelion&source=gmail&ust=1784012243268000&sa=E)
and dies similarly, so this spans multiple transit paths out of the Kenya
gateway, not a single peer.

Full timestamped traceroute and curl output available if useful, and I can
run tests on demand from this terminal. Ticket filed with Starlink support
(maintained via workaround, since their portal is unreachable from the
affected connection).

Ben Eastvold
GLAD Technology, Nakuru County, Kenya

[Starlink] Re: Multiday connectivity issues in Kenya.

[Inemesit Affia]

Thanks for your insight Ben.

I believe a VPN may help your users (has its own issues).

One of the issues with diagnosing these issues generally is a lack of an eye from the inside. Running an RIPE Atlas and/or Globalping probe would help.

Of course SpaceX staff would have better tools.

Ciao

Jul 13, 2026 8:30:30 AM Ben Eastvold via Starlink <starlink@lists.bufferbloat.net>:

> Confirming this from Nakuru County, Kenya, with data. I run a residential
> technology training program on Starlink (sole connectivity, ~20 students),
> and we have had this exact issue for 5+ days, surviving a dish firmware
> update (~July 8) and full power cycles of dish and router.
> 
> Symptoms: specific destination prefixes are blackholed or unstable while
> everything else performs excellently (100+ Mbps down, ~23ms latency).
> Affected destinations include Fastly and Akamai ranges, including
> https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E
> itself. The affected set shifts over time -- sites work for a period, then
> fail.
> 
> TCP connect tests (curl, port 443), same terminal, same minute, against
> https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E's
> four published Fastly addresses:
> 
> 151.101.0.81 -- TIMEOUT, no TCP handshake (8s)
> 151.101.64.81 -- TIMEOUT, no TCP handshake (8s)
> 151.101.128.81 -- connected 0.28s, HTTP 301
> 151.101.192.81 -- connected 0.30s, HTTP 301
> 
> Minutes later, all four of
> https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E's
> addresses (151.101.1.143, 151.101.65.143, 151.101.129.143, 151.101.193.143)
> timed out with no handshake -- including addresses in the same ranges that
> had just worked for
> https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E.
> The reachable prefix set is moving under our feet, which reads as route
> instability rather than a static misroute.
> 
> Akamai similarly affected:
> https://www.google.com/url?q=http://ichef.bbci.co.uk&source=gmail&ust=1784012243268000&sa=E
> (23.56.162.175) fails TCP entirely, so BBC pages currently render text
> without images.
> 
> Traceroutes: local hops (terminal -> 100.64.0.1 -> SpaceX 206.224.x) are
> consistently healthy at 20-30ms. Traffic then enters Liquid Telecom and
> takes inconsistent paths to the same destination set -- some traces via
> Johannesburg (lza-p2-tdn, lza-p3-jhb hops), one via Marseille
> (lfr-p1/p2-mrs), with latency spiking 80-265ms and heavy loss beyond hop 7.
> A trace toward the Akamai destination exits via a different upstream (
> https://www.google.com/url?q=http://twelve99.net/Arelion&source=gmail&ust=1784012243268000&sa=E)
> and dies similarly, so this spans multiple transit paths out of the Kenya
> gateway, not a single peer.
> 
> Full timestamped traceroute and curl output available if useful, and I can
> run tests on demand from this terminal. Ticket filed with Starlink support
> (maintained via workaround, since their portal is unreachable from the
> affected connection).
> 
> Ben Eastvold
> GLAD Technology, Nakuru County, Kenya
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: Multiday connectivity issues in Kenya.

[Jianping Pan]

yes, a common mismatch between sat-based access networks and ground-centric cdn, as reported in https://www.arxiv.org/pdf/2510.13710 as well

Hi Ben: can you figure out your pop (likely nairobi) and service points of problematic websites through their dns providers (i.e., the actual location of servers fulfilling your dns, http and https requests) using the techniques reported in the above paper, or host a vm for me to figure it out for you? we did observe oscillating behaviors for kenya users before with service points jumping around in mombasa and johannesburg. hope it helps. cheers.  -j
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

________________________________________
From: Inemesit Affia via Starlink <starlink@lists.bufferbloat.net>
Sent: Monday, July 13, 2026 12:52 AM
To: Ben Eastvold; Dave Taht via Starlink
Subject: [Starlink] Re: Multiday connectivity issues in Kenya.

Thanks for your insight Ben.

I believe a VPN may help your users (has its own issues).

One of the issues with diagnosing these issues generally is a lack of an eye from the inside. Running an RIPE Atlas and/or Globalping probe would help.

Of course SpaceX staff would have better tools.

Ciao

Jul 13, 2026 8:30:30 AM Ben Eastvold via Starlink <starlink@lists.bufferbloat.net>:

> Confirming this from Nakuru County, Kenya, with data. I run a residential
> technology training program on Starlink (sole connectivity, ~20 students),
> and we have had this exact issue for 5+ days, surviving a dish firmware
> update (~July 8) and full power cycles of dish and router.
>
> Symptoms: specific destination prefixes are blackholed or unstable while
> everything else performs excellently (100+ Mbps down, ~23ms latency).
> Affected destinations include Fastly and Akamai ranges, including
> https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E
> itself. The affected set shifts over time -- sites work for a period, then
> fail.
>
> TCP connect tests (curl, port 443), same terminal, same minute, against
> https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E's
> four published Fastly addresses:
>
> 151.101.0.81 -- TIMEOUT, no TCP handshake (8s)
> 151.101.64.81 -- TIMEOUT, no TCP handshake (8s)
> 151.101.128.81 -- connected 0.28s, HTTP 301
> 151.101.192.81 -- connected 0.30s, HTTP 301
>
> Minutes later, all four of
> https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E's
> addresses (151.101.1.143, 151.101.65.143, 151.101.129.143, 151.101.193.143)
> timed out with no handshake -- including addresses in the same ranges that
> had just worked for
> https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E.
> The reachable prefix set is moving under our feet, which reads as route
> instability rather than a static misroute.
>
> Akamai similarly affected:
> https://www.google.com/url?q=http://ichef.bbci.co.uk&source=gmail&ust=1784012243268000&sa=E
> (23.56.162.175) fails TCP entirely, so BBC pages currently render text
> without images.
>
> Traceroutes: local hops (terminal -> 100.64.0.1 -> SpaceX 206.224.x) are
> consistently healthy at 20-30ms. Traffic then enters Liquid Telecom and
> takes inconsistent paths to the same destination set -- some traces via
> Johannesburg (lza-p2-tdn, lza-p3-jhb hops), one via Marseille
> (lfr-p1/p2-mrs), with latency spiking 80-265ms and heavy loss beyond hop 7.
> A trace toward the Akamai destination exits via a different upstream (
> https://www.google.com/url?q=http://twelve99.net/Arelion&source=gmail&ust=1784012243268000&sa=E)
> and dies similarly, so this spans multiple transit paths out of the Kenya
> gateway, not a single peer.
>
> Full timestamped traceroute and curl output available if useful, and I can
> run tests on demand from this terminal. Ticket filed with Starlink support
> (maintained via workaround, since their portal is unreachable from the
> affected connection).
>
> Ben Eastvold
> GLAD Technology, Nakuru County, Kenya
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
_______________________________________________
Starlink mailing list -- starlink@lists.bufferbloat.net
To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: Multiday connectivity issues in Kenya.

[Ben Eastvold]

Hi, Jianping,

I'm in a rural off-grid part of Kenya so we don't have any always-on tech
to run a VM on. My personal MacBook is the most consistent thing, but
that's off-and-on throughout the day as I use it for teaching. Also, full
disclosure, I teach tech but my expertise isn't in networking - so I'm
actively working with Claude here. Lol. If anything doesn't seem right, let
me know and I can recheck.

I ran your suggested measurements from the terminal (VPN off, verified
vantage: public IP 129.222.147.68, hostname
customer.nrbiken1.isp.starlink.com, AS14593). Findings:

PoP confirmed: Nairobi (nrbiken1, per Starlink's own PTR).

Transit problem segment: all paths, working and failing alike, exit via
102.134.22.170 then 154.66.247.x, where latency jumps from ~25ms to
90-290ms with heavy loss. A working google.com trace completes through it
at ~100ms (23ms baseline last week); Fastly/Akamai traces die beyond it,
variously toward Johannesburg (lza/jhb hops) and Marseille (lfr-mrs).

Fastly: service point unidentifiable from here, because every Fastly edge
is TCP-unreachable (no handshake to any of bbc.com's four addresses or
starlink.com's four; can't even fetch x-served-by). Yesterday two of bbc.com's
four connected; today zero of eight.

Akamai: actively re-steering me and it isn't helping. ichef.bbci.co.uk
resolved to 23.56.162.175 yesterday, 23.44.208.162 today; both edges
TCP-timeout. Whatever edge Akamai assigns lands behind the same broken
transit.

Google service point: yesterday's google.com trace terminated at
mba01s09-in-f14.1e100.net, so Google steers me to Mombasa, and it works
(degraded).

DNS steering, possibly the interesting part: my resolver is 8.8.8.8, and
whoami.akamai.net + edns.ip-api.com show my queries answered by Google
resolvers in South Africa (173.194.171.216). Google does forward ECS with
my true subnet (129.222.147.0/24, Nairobi). So CDNs honoring ECS see Kenya;
CDNs keying on resolver location see South Africa. That mixed signal seems
consistent with the Johannesburg-bound routing and the oscillation you
described.

Happy to run anything else if it's helpful.

*Ben Eastvold*
Founder / Executive Director
GLAD Technology
https://www.gladtech.org




On Mon, Jul 13, 2026 at 6:16 PM Jianping Pan <pan@uvic.ca> wrote:

> yes, a common mismatch between sat-based access networks and
> ground-centric cdn, as reported in https://www.arxiv.org/pdf/2510.13710
> as well
>
> Hi Ben: can you figure out your pop (likely nairobi) and service points of
> problematic websites through their dns providers (i.e., the actual location
> of servers fulfilling your dns, http and https requests) using the
> techniques reported in the above paper, or host a vm for me to figure it
> out for you? we did observe oscillating behaviors for kenya users before
> with service points jumping around in mombasa and johannesburg. hope it
> helps. cheers.  -j
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,
> Web.UVic.CA/~pan
>
> ________________________________________
> From: Inemesit Affia via Starlink <starlink@lists.bufferbloat.net>
> Sent: Monday, July 13, 2026 12:52 AM
> To: Ben Eastvold; Dave Taht via Starlink
> Subject: [Starlink] Re: Multiday connectivity issues in Kenya.
>
> Thanks for your insight Ben.
>
> I believe a VPN may help your users (has its own issues).
>
> One of the issues with diagnosing these issues generally is a lack of an
> eye from the inside. Running an RIPE Atlas and/or Globalping probe would
> help.
>
> Of course SpaceX staff would have better tools.
>
> Ciao
>
> Jul 13, 2026 8:30:30 AM Ben Eastvold via Starlink <
> starlink@lists.bufferbloat.net>:
>
> > Confirming this from Nakuru County, Kenya, with data. I run a residential
> > technology training program on Starlink (sole connectivity, ~20
> students),
> > and we have had this exact issue for 5+ days, surviving a dish firmware
> > update (~July 8) and full power cycles of dish and router.
> >
> > Symptoms: specific destination prefixes are blackholed or unstable while
> > everything else performs excellently (100+ Mbps down, ~23ms latency).
> > Affected destinations include Fastly and Akamai ranges, including
> >
> https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E
> > itself. The affected set shifts over time -- sites work for a period,
> then
> > fail.
> >
> > TCP connect tests (curl, port 443), same terminal, same minute, against
> >
> https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E's
> > four published Fastly addresses:
> >
> > 151.101.0.81 -- TIMEOUT, no TCP handshake (8s)
> > 151.101.64.81 -- TIMEOUT, no TCP handshake (8s)
> > 151.101.128.81 -- connected 0.28s, HTTP 301
> > 151.101.192.81 -- connected 0.30s, HTTP 301
> >
> > Minutes later, all four of
> >
> https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E's
> > addresses (151.101.1.143, 151.101.65.143, 151.101.129.143,
> 151.101.193.143)
> > timed out with no handshake -- including addresses in the same ranges
> that
> > had just worked for
> >
> https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E
> .
> > The reachable prefix set is moving under our feet, which reads as route
> > instability rather than a static misroute.
> >
> > Akamai similarly affected:
> >
> https://www.google.com/url?q=http://ichef.bbci.co.uk&source=gmail&ust=1784012243268000&sa=E
> > (23.56.162.175) fails TCP entirely, so BBC pages currently render text
> > without images.
> >
> > Traceroutes: local hops (terminal -> 100.64.0.1 -> SpaceX 206.224.x) are
> > consistently healthy at 20-30ms. Traffic then enters Liquid Telecom and
> > takes inconsistent paths to the same destination set -- some traces via
> > Johannesburg (lza-p2-tdn, lza-p3-jhb hops), one via Marseille
> > (lfr-p1/p2-mrs), with latency spiking 80-265ms and heavy loss beyond hop
> 7.
> > A trace toward the Akamai destination exits via a different upstream (
> >
> https://www.google.com/url?q=http://twelve99.net/Arelion&source=gmail&ust=1784012243268000&sa=E
> )
> > and dies similarly, so this spans multiple transit paths out of the Kenya
> > gateway, not a single peer.
> >
> > Full timestamped traceroute and curl output available if useful, and I
> can
> > run tests on demand from this terminal. Ticket filed with Starlink
> support
> > (maintained via workaround, since their portal is unreachable from the
> > affected connection).
> >
> > Ben Eastvold
> > GLAD Technology, Nakuru County, Kenya
> > _______________________________________________
> > Starlink mailing list -- starlink@lists.bufferbloat.net
> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>

[Starlink] Re: Multiday connectivity issues in Kenya.

[Jianping Pan]

Hi Ben: networking is to connect everyone everywhere, regardless pros or not. i will get back to individually due to some networking details. cheers.  -j
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

________________________________________
From: Ben Eastvold <ben@gladtech.org>
Sent: Tuesday, July 14, 2026 4:52 AM
To: Jianping Pan
Cc: Dave Taht via Starlink; Inemesit Affia
Subject: Re: [Starlink] Re: Multiday connectivity issues in Kenya.

Hi, Jianping,

I'm in a rural off-grid part of Kenya so we don't have any always-on tech to run a VM on. My personal MacBook is the most consistent thing, but that's off-and-on throughout the day as I use it for teaching. Also, full disclosure, I teach tech but my expertise isn't in networking - so I'm actively working with Claude here. Lol. If anything doesn't seem right, let me know and I can recheck.

I ran your suggested measurements from the terminal (VPN off, verified vantage: public IP 129.222.147.68, hostname customer.nrbiken1.isp.starlink.com<http://customer.nrbiken1.isp.starlink.com/>, AS14593). Findings:

PoP confirmed: Nairobi (nrbiken1, per Starlink's own PTR).

Transit problem segment: all paths, working and failing alike, exit via 102.134.22.170 then 154.66.247.x, where latency jumps from ~25ms to 90-290ms with heavy loss. A working google.com<http://google.com/> trace completes through it at ~100ms (23ms baseline last week); Fastly/Akamai traces die beyond it, variously toward Johannesburg (lza/jhb hops) and Marseille (lfr-mrs).

Fastly: service point unidentifiable from here, because every Fastly edge is TCP-unreachable (no handshake to any of bbc.com<http://bbc.com/>'s four addresses or starlink.com<http://starlink.com/>'s four; can't even fetch x-served-by). Yesterday two of bbc.com<http://bbc.com/>'s four connected; today zero of eight.

Akamai: actively re-steering me and it isn't helping. ichef.bbci.co.uk<http://ichef.bbci.co.uk/> resolved to 23.56.162.175 yesterday, 23.44.208.162 today; both edges TCP-timeout. Whatever edge Akamai assigns lands behind the same broken transit.

Google service point: yesterday's google.com<http://google.com/> trace terminated at mba01s09-in-f14.1e100.net<http://mba01s09-in-f14.1e100.net/>, so Google steers me to Mombasa, and it works (degraded).

DNS steering, possibly the interesting part: my resolver is 8.8.8.8, and whoami.akamai.net<http://whoami.akamai.net/> + edns.ip-api.com<http://edns.ip-api.com/> show my queries answered by Google resolvers in South Africa (173.194.171.216). Google does forward ECS with my true subnet (129.222.147.0/24<http://129.222.147.0/24>, Nairobi). So CDNs honoring ECS see Kenya; CDNs keying on resolver location see South Africa. That mixed signal seems consistent with the Johannesburg-bound routing and the oscillation you described.

Happy to run anything else if it's helpful.

Ben Eastvold
Founder / Executive Director
GLAD Technology
https://www.gladtech.org/<https://www.gladtech.org/>

[https://ci3.googleusercontent.com/mail-sig/AIorK4wtBOa1PYJ-up8Kz6dbC6r5hSGkgzrE0_3QFLbsp0ugSrmTWiVJw94HgIrQQmvbndoIXbC9DHA]


On Mon, Jul 13, 2026 at 6:16 PM Jianping Pan <pan@uvic.ca<mailto:pan@uvic.ca>> wrote:
yes, a common mismatch between sat-based access networks and ground-centric cdn, as reported in https://www.arxiv.org/pdf/2510.13710<https://www.arxiv.org/pdf/2510.13710> as well

Hi Ben: can you figure out your pop (likely nairobi) and service points of problematic websites through their dns providers (i.e., the actual location of servers fulfilling your dns, http and https requests) using the techniques reported in the above paper, or host a vm for me to figure it out for you? we did observe oscillating behaviors for kenya users before with service points jumping around in mombasa and johannesburg. hope it helps. cheers.  -j
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan<http://web.uvic.ca/~pan>

________________________________________
From: Inemesit Affia via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>>
Sent: Monday, July 13, 2026 12:52 AM
To: Ben Eastvold; Dave Taht via Starlink
Subject: [Starlink] Re: Multiday connectivity issues in Kenya.

Thanks for your insight Ben.

I believe a VPN may help your users (has its own issues).

One of the issues with diagnosing these issues generally is a lack of an eye from the inside. Running an RIPE Atlas and/or Globalping probe would help.

Of course SpaceX staff would have better tools.

Ciao

Jul 13, 2026 8:30:30 AM Ben Eastvold via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>>:

> Confirming this from Nakuru County, Kenya, with data. I run a residential
> technology training program on Starlink (sole connectivity, ~20 students),
> and we have had this exact issue for 5+ days, surviving a dish firmware
> update (~July 8) and full power cycles of dish and router.
>
> Symptoms: specific destination prefixes are blackholed or unstable while
> everything else performs excellently (100+ Mbps down, ~23ms latency).
> Affected destinations include Fastly and Akamai ranges, including
> https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E<https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E>
> itself. The affected set shifts over time -- sites work for a period, then
> fail.
>
> TCP connect tests (curl, port 443), same terminal, same minute, against
> https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E's<https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E's>
> four published Fastly addresses:
>
> 151.101.0.81 -- TIMEOUT, no TCP handshake (8s)
> 151.101.64.81 -- TIMEOUT, no TCP handshake (8s)
> 151.101.128.81 -- connected 0.28s, HTTP 301
> 151.101.192.81 -- connected 0.30s, HTTP 301
>
> Minutes later, all four of
> https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E's<https://www.google.com/url?q=http://starlink.com&source=gmail&ust=1784012243268000&sa=E's>
> addresses (151.101.1.143, 151.101.65.143, 151.101.129.143, 151.101.193.143)
> timed out with no handshake -- including addresses in the same ranges that
> had just worked for
> https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E<https://www.google.com/url?q=http://bbc.com&source=gmail&ust=1784012243268000&sa=E>.
> The reachable prefix set is moving under our feet, which reads as route
> instability rather than a static misroute.
>
> Akamai similarly affected:
> https://www.google.com/url?q=http://ichef.bbci.co.uk&source=gmail&ust=1784012243268000&sa=E<https://www.google.com/url?q=http://ichef.bbci.co.uk&source=gmail&ust=1784012243268000&sa=E>
> (23.56.162.175) fails TCP entirely, so BBC pages currently render text
> without images.
>
> Traceroutes: local hops (terminal -> 100.64.0.1 -> SpaceX 206.224.x) are
> consistently healthy at 20-30ms. Traffic then enters Liquid Telecom and
> takes inconsistent paths to the same destination set -- some traces via
> Johannesburg (lza-p2-tdn, lza-p3-jhb hops), one via Marseille
> (lfr-p1/p2-mrs), with latency spiking 80-265ms and heavy loss beyond hop 7.
> A trace toward the Akamai destination exits via a different upstream (
> https://www.google.com/url?q=http://twelve99.net/Arelion&source=gmail&ust=1784012243268000&sa=E<https://www.google.com/url?q=http://twelve99.net/Arelion&source=gmail&ust=1784012243268000&sa=E>)
> and dies similarly, so this spans multiple transit paths out of the Kenya
> gateway, not a single peer.
>
> Full timestamped traceroute and curl output available if useful, and I can
> run tests on demand from this terminal. Ticket filed with Starlink support
> (maintained via workaround, since their portal is unreachable from the
> affected connection).
>
> Ben Eastvold
> GLAD Technology, Nakuru County, Kenya
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net<mailto:starlink-leave@lists.bufferbloat.net>
_______________________________________________
Starlink mailing list -- starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>
To unsubscribe send an email to starlink-leave@lists.bufferbloat.net<mailto:starlink-leave@lists.bufferbloat.net>