Japan tunnel server with high latency in recent days

[98118]

Hi HE.net team,

I am running a Oracle VPS intance in Japan datacenter, which has been connected to HE tunnel server for a long time.
But in recent days, I find that the latency between them is increasing a lot, from <10ms to >200ms.
I execute a mtr from VPS to tunnerl server, seeing that the route path is Japan -> US -> Japan.
What causes the issue? Thank you

Code Select Expand

$ mtr 74.82.46.6 -r
Start: 2026-05-30T10:26:02+0800
HOST: intance2                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 140.91.206.106             0.0%    10    0.3   0.3   0.3   0.4   0.0
  2.|-- 180.87.180.138             0.0%    10    1.2   1.1   1.0   1.3   0.1
  3.|-- ix-be-35.ecore1.tv2-tokyo 30.0%    10    1.6   1.6   1.6   1.7   0.0
  4.|-- 209.58.55.73              90.0%    10  101.3 101.3 101.3 101.3   0.0
  5.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  6.|-- 64.86.26.38               50.0%    10  102.2 102.2 101.9 102.4   0.2
  7.|-- 64.86.26.37               80.0%    10  101.6 101.6 101.6 101.6   0.0
  8.|-- if-bundle-2-2.qcore2.sqn- 80.0%    10  101.1 101.3 101.1 101.4   0.2
  9.|-- port-channel22.core3.sjc2  0.0%    10  101.2 101.2 100.9 102.2   0.4
 10.|-- be47.core1.sjc2.he.net     0.0%    10  101.5 103.5 101.5 104.9   1.1
 11.|-- be1.core3.lax1.he.net     10.0%    10  115.5 114.5 112.9 115.5   0.8
 12.|-- be48.core1.lax2.he.net     0.0%    10  114.2 114.1 113.0 115.5   0.8
 13.|-- 100ge0-77.core3.tyo1.he.n 80.0%    10  211.5 211.4 211.2 211.5   0.2
 14.|-- port-channel9.core2.tyo1.  0.0%    10  211.6 211.8 211.4 213.0   0.5
 15.|-- tserv1.tyo1.he.net         0.0%    10  210.7 211.3 210.7 215.8   1.6

[snarked]

Routing.  Someone probably in Japan thinks the best route to HE in Japan is via the U.S. instead of a peering in country.  There may have been a Japan peering with HE which is currently not working.

Using the BGP interface here, HE peers at 2 cities in Japan:  Osaka and Tokyo.  Your trace route hop 3 has a hostname indicating Tokyo routing, but hop 4's latency implies a trans-Pacific crossing.  Although the hostname is truncated, it probably refers to Tata Communications at Equinix Tokyo.  HE and Tata are both present there, but maybe they're not talking to each other.  Tata is presenting only an IPv4 interface at Equinix Tokyo at present, so maybe that has some effect on the peering situation.