Skip to content

Dallas location suddenly routing through Tokyo, anyone else seeing this?

VPS Hosting by kat_fold 27 replies 3.2K views
4 #11

kat_fold said:
Louis, the logical location is apparently now the Pacific Rim.

Confirmed from Cleveland. My Contabo St. Louis box is taking the scenic route. traceroute shows level3 seattle, then ntt tokyo, then level3 back to chicago, then st. louis. Someone is advertising a very wrong prefix.

I tested against my Vultr Chicago instance: normal 15ms path. So this is not universal, just specific upstream combinations.

#12

ana_mad said:
Forced path through HostHatch mirror

HostHatch Tokyo or HostHatch Chicago? If Tokyo, you are just leaning into the problem. If Chicago, curious how you are forcing the path -- anycast dns or explicit proxy?

My Vultr Seattle instance routes normally to Dallas. The jp hop only appears on certain origin networks.

#13

adadude said:
HostHatch Tokyo or HostHatch Chicago?

HostHatch Chicago. I have a storage VPS there that I use for offsite backups. Set up a wireguard tunnel (I used https://www.wireguard.com) and routed critical traffic through it. Latency to Chicago is 95ms from Madrid, not great, but better than 180ms to St. Louis via Tokyo.

The tunnel endpoints are both in Europe so the path stays on this side.

swimming upstream since 2019 🐟
#14

kat_fold said:
HDD plans are in the same datacenter though, so routing would be identical.

Confirmed again. My RackNerd Dallas VPS shows normal domestic routing from Los Angeles. 35ms direct. The reverse path from North America to Dallas is where the anomaly lives.

I also tested Vultr Osaka to Dallas: 110ms, normal trans-pacific path. No loop.

conbini > datacenter snacks
3 #15

I see nothing unusual from Lyon to Contabo St. Louis. 45ms, path via Düsseldorf then London then New York then Chicago then St. Louis. No Tokyo.

This suggests the problem is specific to trans-Atlantic routes that normally land on the US west coast. My traffic enters via the east coast.

prix fixe infrastructure: €5/mo
#16

lookuppierre said:
45ms, path via Düsseldorf then London then New York then Chicago then St.

Same here from Bratislava. East coast entry, no jp hops. My smokeping to Contabo St. Louis is flat at 38ms.

The Seattle origin paths are the ones getting hijacked to Tokyo. Someone on the west coast is accepting a bad route announcement.

boot anything, anywhere, anytime
#17

PetraSuper said:
Someone on the west coast is accepting a bad route announcement.

This is the threat. A bad route announcement accepted by multiple Tier-1s is either a configuration error or a deliberate path manipulation. The difference is indistinguishable from the endpoint.

ana_mad said:
Set up a wireguard tunnel

Good instinct. Encrypting the payload mitigates interception risk even if the path is compromised. But verify your wireguard endpoints independently — I used https://www.wireguard.com for that.

#18

salavi said:
Deliberate path manipulation

Or someone fat-fingered a prefix list and the RPKI ROA was not strict enough. Not everything is a threat, some things are just incompetence. Rust would not help here, but a strongly typed BGP configuration language might.

I have seen this before. NTT had a similar leak in 2019. Lasted six hours.

#19

I just want to know if my server in Mexico City is affected. I do not know how to traceroute. Is there a website that does this?

#20

Nadia59 said:
Is there a website that does this?

Use mtr.sh or ping.pe from your browser. But this thread is not a help desk. Read the first post, the issue is from North American origins to Dallas/St. Louis. Mexico City is unlikely to show the same path unless your provider peers through Seattle.

Please keep signal to noise reasonable.

~be kind or be gone~

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft