[Starlink] Re: Multiday connectivity issues in Kenya.

[Ben Eastvold <ben@gladtech.org>]

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
>