Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Does True Hawaii → Asia IP Transit Even Exist?

LatnidLatnid Member

Hey everyone,

I’m stuck out here in Honolulu chasing mythical low-latency unicorns 🦄🌊. I'm trying to find a real-life provider offering direct IP transit from Hawaii straight to Asia-Pacific without dragging packets across California first.

Two cables (SEA-US and AAG) look good on paper, but every provider I’ve talked to (HE, Cogent, OneQode, etc.) insists on a scenic detour through LA, turning my ideal 80ms trip into a sluggish 140ms+ journey.

Honolulu test box for your traceroute amusement:

test.hnl01.orion.cloud

Does anyone here actually have (or know someone who has) a legit direct APAC IP route from Hawaii? Bonus points if it includes:

  • Honolulu hand-off (DRFortress/AlohaNAP, ideally)
  • True APAC-first exit (Tokyo, SG, HK and etc.)
  • Ability to announce my own /24 (or provider IPs are fine)

Tips, experiences, or unicorn sightings appreciated—thanks in advance! 🍻

Thanked by 2MannDude borkedascii

Comments

  • LatnidLatnid Member

    That is the one that can connect but not directly; it will hit California first. All the people living in Hawaii are currently using it.

  • LatnidLatnid Member

    The answer remains unknown but should be capable.

  • rm_rm_ IPv6 Advocate, Veteran
    edited July 2025

    Give @Neoon your subnet IP on Hawaii, he might sort you out with some quality bending, if there's any to begin with.

    Oh I see you posted the test IP, but it seems to majorly use HE.net, and going via LAX might be just how they roll. You might need to try out other ISPs or DCs on your side first. I doubt you have too many to choose from, so it might not be as hard to try them all :)

    Thanked by 2gbzret4d tentor
  • NeoonNeoon Community Contributor, Veteran

    Interesting conquest.

    This map suggests, there are a few.
    https://www.submarinecablemap.com/

    Thanked by 2gbzret4d ws6895
  • NeoonNeoon Community Contributor, Veteran

    You can get Vultr, Hawai, works from US but not from Asia.
    Probably you need another box in-between

  • LatnidLatnid Member
    edited July 2025

    @Neoon I don’t mind setting up a box in-between, but the farthest I can reach is Guam via HE. Vultr and most other providers in Hawaii also route traffic to Asia via the US West Coast first, not directly.

    We have three submarine cables, but I haven’t found any provider that actually offers a direct Asia route.

    Interestingly, HE is now peering with OneQode at Guam, but OneQode doesn’t seem to allow their traffic to go through HE — so the direct path isn’t available in practice.
    Not sure owning both colocation services(Guam & Hawaii) can solve this problem or not. But that cost will be huge.

    This is a tricky situation without a real solution so far—quite rare to see.

  • borkedasciiborkedascii Member
    edited July 2025

    @Latnid said:
    @Neoon I don’t mind setting up a box in-between, but the farthest I can reach is Guam via HE. Vultr and most other providers in Hawaii also route traffic to Asia via the US West Coast first, not directly.

    We have three submarine cables, but I haven’t found any provider that actually offers a direct Asia route.

    Interestingly, HE is now peering with OneQode at Guam, but OneQode doesn’t seem to allow their traffic to go through HE — so the direct path isn’t available in practice.
    Not sure owning both colocation services(Guam & Hawaii) can solve this problem or not. But that cost will be huge.

    This is a tricky situation without a real solution so far—quite rare to see.

    If you can connect to Guam then GSL can serve you directly to Tokyo (28ms) and Sydney (70ms)

    Edit: HE does not connect with GSL either at Guam. It looks like a roadblock unless you find some way to connect to Guam remotely. Have you tried speaking to OneQode or GSL to see how they can help you connect from Hawaii?

  • LeviLevi Member

    Just dive in and splice directly into the damn cable.

  • NeoonNeoon Community Contributor, Veteran

    @Latnid said:
    @Neoon I don’t mind setting up a box in-between, but the farthest I can reach is Guam via HE. Vultr and most other providers in Hawaii also route traffic to Asia via the US West Coast first, not directly.

    We have three submarine cables, but I haven’t found any provider that actually offers a direct Asia route.

    Interestingly, HE is now peering with OneQode at Guam, but OneQode doesn’t seem to allow their traffic to go through HE — so the direct path isn’t available in practice.
    Not sure owning both colocation services(Guam & Hawaii) can solve this problem or not. But that cost will be huge.

    This is a tricky situation without a real solution so far—quite rare to see.

    Indeed, Gunam looks interesting.

    Results
    Latency  Source   City     Provider        
    -------  -------  -------  -------         
    29.12ms  mudfish  Tokyo    G-Core Labs 2   
    29.12ms  vultr    Tokyo    Vultr           
    29.36ms  mudfish  Tokyo    OneProvider 10  
    29.37ms  mudfish  Tokyo    LightNode       
    29.38ms  mudfish  Tokyo    Linode3 IDC     
    29.41ms  mudfish  Tokyo    Equinix         
    29.41ms  mudfish  Tokyo    Linode7 IDC     
    29.46ms  mudfish  Tokyo    Linode5 IDC     
    29.47ms  pingpe   Tokyo    Vultr           
    29.54ms  mudfish  Tokyo    Linode6 IDC     
    29.58ms  pingpe   Tokyo    DODO            
    29.71ms  mudfish  Tokyo    Greenweb        
    29.79ms  mudfish  Tokyo    Linode8 IDC     
    29.86ms  mudfish  Tokyo    Linode2 IDC     
    29.86ms  mudfish  Tokyo    Linode4 IDC     
    30.09ms  mudfish  Tokyo    ConoHa 1        
    30.37ms  mudfish  Osaka    Maggie          
    32.04ms  mudfish  Tokyo    Aliyun 2        
    36.30ms  mudfish  Osaka    SakuraNet 1     
    37.19ms  mudfish  Osaka    Linode 1        
    45.37ms  mudfish  Hokkaido SakuraNet 1     
    58.75ms  mudfish  Tokyo    HostRoyale      
    60.47ms  mudfish  Osaka    Amazon EC2 1    
    60.98ms  mudfish  Tokyo    Amazon Lightsail
    61.58ms  mudfish  Tokyo    Amazon EC2 2    
    99.20ms  dnstools Japan    n/a             
    99.25ms  mudfish  Tokyo    HostHatch 2     
    100.82ms mudfish  Tokyo    Azure 01        
    107.95ms mudfish  Osaka    Azure 01        
    133.54ms mudfish  Tokyo    Google 2        
    138.43ms mudfish  Osaka    Google 1        
    139.24ms mudfish  Osaka    TinMok 10       
    145.77ms mudfish  Osaka    Vultr 1         
    148.78ms vultr    Osaka    Vultr 
    
  • NeoonNeoon Community Contributor, Veteran
    edited July 2025

    LA to Toyko in 140ms.
    Direct ls lower with 118ms, to backhauled, meh.

    Results
    Latency  Source   City              Provider       
    -------  -------  -------           -------        
    109.00ms dnstools Los Angeles       n/a            
    109.17ms vultr    Los Angeles       Vultr          
    109.73ms pingpe   Los Angeles       Vultr          
    110.18ms pingpe   Los Angeles       NetActuate     
    118.46ms mudfish  Denver, CO        Mean Servers 2 
    120.11ms vultr    Silicon Valley    Vultr          
    139.55ms vultr    Dallas            Vultr          
    139.98ms mudfish  Dallas, TX        Vultr 2        
    140.33ms pingpe   Dallas            NetActuate     
    141.98ms mudfish  Dallas, TX        Linode         
    143.72ms vultr    Seattle           Vultr          
    146.79ms pingpe   Fort Worth        AT&T       
    152.40ms mudfish  Dallas, TX        Nodisto        
    153.08ms mudfish  Dallas, TX        HostUS 2       
    153.12ms mudfish  Denver, CO        Nodisto        
    154.05ms mudfish  Chicago           Nodisto        
    154.13ms mudfish  Lombard, IL       Atlantic Metro 
    157.50ms mudfish  Atlanta           RamNode        
    157.72ms mudfish  Chicago           Linode         
    157.87ms vultr    Atlanta           Vultr          
    158.34ms pingpe   Los Angeles       Hurricane      
    160.24ms pingpe   Fremont           Linode         
    161.38ms mudfish  Chicago           G-Core Labs    
    162.16ms mudfish  Chicago           Vultr 4        
    162.22ms vultr    Chicago           Vultr          
    164.10ms pingpe   Chicago           NetActuate     
    167.12ms pingpe   Fremont           Hurricane      
    168.82ms pingpe   Fremont           IT7 FMT2       
    168.92ms pingpe   Santa Clara       Hurricane      
    170.05ms pingpe   Seattle           Google         
    171.34ms mudfish  Florida           Secure Dragon  
    172.11ms vultr    New Jersey        Vultr          
    172.35ms mudfish  New York          G-Core Labs    
    173.66ms mudfish  Miami             G-Core Labs    
    173.80ms mudfish  Miami             Vultr 1        
    173.85ms vultr    Miami             Vultr          
    174.00ms dnstools Miami             n/a            
    175.19ms mudfish  New Jersey        Linode         
    177.30ms pingpe   Buffalo           ColoCrossing   
    178.52ms mudfish  Ashburn           SYN 2          
    179.21ms mudfish  Denver, CO        Secure Dragon 2
    180.39ms mudfish  Wyoming           Azure          
    182.78ms mudfish  Dallas, TX        Azure          
    182.83ms pingpe   Ashburn           NetActuate     
    194.35ms mudfish  Iowa              Azure          
    195.47ms pingpe   New York          Hurricane      
    206.50ms pingpe   Los Angeles       DMIT           
    207.21ms mudfish  Illinois          Azure          
    214.49ms pingpe   Denver            Cogent         
    215.11ms pingpe   Kansas City       Rozint         
    216.33ms mudfish  Northern Virginia Google         
    219.74ms mudfish  Houston, TX       Oplink 2       
    221.00ms dnstools New York          n/a            
    221.29ms mudfish  Ashburn           G-Core Labs    
    222.96ms pingpe   Denver            NetActuate     
    223.99ms mudfish  New York          Digital Ocean 3
    228.31ms vultr    Honolulu          Vultr          
    232.04ms pingpe   Chicago           Infraly        
    232.48ms mudfish  Ashburn           Hetzner        
    235.65ms mudfish  Chicago           VIG28          
    247.78ms pingpe   San Francisco     Digital Ocean
    
  • LatnidLatnid Member

    @Neoon

    I have tried reaching out to all the OneQode contacts, but so far only received automated replies. I also talked to HE (Hurricane Electric); they said the issue is on OneQode’s side.

    Even though HE and OneQode are both present and peering at the same IX in Guam, the latency between them is still over 100 ms. It looks like they only have basic peering, not IP transit, so traffic isn’t handed over directly at Guam.

    I haven’t contacted GSL yet, not sure how they can help.

    Honestly, this seems like a rare situation where even with both networks present and peered, there’s no true direct route because there’s no transit agreement in place.

  • NeoonNeoon Community Contributor, Veteran

    @Latnid said:
    @Neoon

    I have tried reaching out to all the OneQode contacts, but so far only received automated replies. I also talked to HE (Hurricane Electric); they said the issue is on OneQode’s side.

    Even though HE and OneQode are both present and peering at the same IX in Guam, the latency between them is still over 100 ms. It looks like they only have basic peering, not IP transit, so traffic isn’t handed over directly at Guam.

    I haven’t contacted GSL yet, not sure how they can help.

    Honestly, this seems like a rare situation where even with both networks present and peered, there’s no true direct route because there’s no transit agreement in place.

    That is most of the time the cause, that they don't have transit and just peering.

Sign In or Register to comment.