Seems they fixed it.
I did check their route server to see what was going on, here's the
before and after:
Broken:
RP/0/RSP0/CPU0:route-server.newyork.ny.ibone#show bgp 202.12.27.33
Mon Aug 26 19:51:23.615 utc
BGP routing table entry for 202.12.27.33/32
Versions:
Process bRIB/RIB Sen
Yes, definitely Comcast-wide. And I should have realized that was almost
certainly true earlier. I did look at the Comcast looking glass listed at
PeeringDB and even saw the problem, but didn't put 2-and-2 together at the
time. All I saw was that the path for the IPv4 prefix for m-root,
202.12.27.0
Same here in East Central Illinois. v4 fails; v6 works.
Trace stops in Chicago.
On 8/26/24 03:54, Thomas Wodarek wrote:
I'm getting similar results on residential Comcast up here in Michigan,
US (Comcast's Heartland region). Checking from a Google Cloud vm in
Iowa, US, I was able to reach m.
I'm getting similar results on residential Comcast up here in Michigan, US
(Comcast's Heartland region). Checking from a Google Cloud vm in Iowa, US,
I was able to reach m.root-servers.net via both v4 and v6, but it looks
like it's routing to the Sao Paulo cluster in both cases (looking at
https:/
I would be opening a ticket with comcast. This appears to be off charter as it
is a individual home user issue.
> On 26 Aug 2024, at 10:15, Crist Clark wrote:
>
> Debated whether to bring this up on the OARC DNS Ops list or NANOG. Seem more
> of a network-y thing.
>
> I happened to notice th
Debated whether to bring this up on the OARC DNS Ops list or NANOG. Seem
more of a network-y thing.
I happened to notice that I cannot query or ping m.root-servers.net's IPv4
address from my home Comcast connection (SF Bay Area). IPv6 works. All of
the other root servers are reachable via both IPv
6 matches
Mail list logo
