Network trace · gf-cx-singapore vs Florida Mac → xlab.studio (APAC)

SIGNAL · NETWORK TRACE · 5 JUNE 2026

Empirical traceroute comparison between gf-cx-singapore (GCP vm-asia-gcp, asia-southeast1-b) and the Florida Mac, against xlab.studio’s SharePoint backend + adjacent APAC services. Confirms the ~13× speed delta we’ve been measuring is structural (transit hops + transatlantic egress), not contention. Sharpens the “where does the xlab.studio tenant actually live?” question that started with the NextDNS attribution analysis.

Naming. This report uses Dan’s two canonical names for the topic: gf-cx-singapore for the GCP VM (Tailscale hostname vm-asia-gcp is the same entity) and xlab.studio (APAC) for the OneDrive tenant we’re routing to.

TL;DR

Traceroutes from gf-cx-singapore

gvr20-my.sharepoint.com (xlab.studio’s SharePoint backend)

1  142.251.49.144 (Google internal)        2.2 ms
2  74.125.118.179 (Google internal)        2.0 ms
3  be20.rwa01.sg2.ntwk.msn.net             2.2 ms  ← Microsoft Singapore POP #2
4+ * (Microsoft backbone ICMP-blocked)

Three hops to Microsoft’s edge router, then opaque. ~2 ms total intra-Singapore.

nrt.dropbox.com (Dropbox Tokyo)

1  142.250.237.158 (Google internal)         1.5 ms
4  ae-13.r35.tokyjp05.jp.bb.gin.ntt.net    77.2 ms  ← NTT Tokyo backbone
5  ae-5.a01.tokyjp10.jp.bb.gin.ntt.net     71.6 ms  ← NTT Tokyo aggregation
6  unknown.telstraglobal.net               87.4 ms  ← Telstra trans-Pacific

Routes SG → NTT Tokyo POP → Telstra. tokyjp10 confirms the nrt. hostname maps to actual NTT Tokyo backbone presence.

sharepoint.com (generic anycast, different IP)

1  142.251.49.144 (Google internal)        1.8 ms
2  74.125.118.179 (Google internal)        2.1 ms
3  po20.rwa03.sg3.ntwk.msn.net             1.5 ms  ← Microsoft Singapore POP #3

Different SharePoint anycast IP → different Microsoft Singapore POP. Two POPs visible (sg2 and sg3).

docs.google.com (Google Workspace endpoint, control case)

2  209.85.250.188     0.7 ms
3  172.253.69.216     2.9 ms
4  216.239.51.46      0.6 ms  ← already inside Google's network

Same-AS routing → fastest possible path. Confirms the VM has clean, direct Google peering.

Traceroutes from Florida Mac (contrast)

Mac → gvr20-my.sharepoint.com

1  192.168.50.1                                   3.5 ms  (home router)
2  192.168.1.1                                    4.0 ms  (modem)
3  lo0-100.phlapa-vfttp-312.verizon-gni.net       5.7 ms  ← Verizon Philadelphia
7  ae21-0.ear05.ewr30.ntwk.msn.net               22.5 ms  ← Microsoft Newark NJ POP
8  ae28-0.ier02.ewr30.ntwk.msn.net               11.3 ms
9+ * (Microsoft backbone ICMP-blocked)

Verizon → Microsoft Newark NJ. The Mac never reaches Microsoft’s APAC edge directly; it hits MS at the closest US POP and then MS’s backbone carries the bytes the rest of the way. That backbone leg is invisible but it’s the dominant latency contributor for Mac-→-xlab transfers.

Mac → nrt.dropbox.com

3  lo0-100.phlapa-vfttp-312.verizon-gni.net       13.2 ms  ← Verizon Philadelphia
6  customer.alter.net                             84.5 ms  ← AS1668 transit
10 ae-0.a01.tokyjp10.jp.bb.gin.ntt.net           186.9 ms  ← NTT Tokyo (SAME as VM)
11 ae-0.dropbox.tokyjp10.jp.bb.gin.ntt.net       175.5 ms  ← Dropbox in Tokyo

Mac → NTT Tokyo via transatlantic Verizon → Alter → NTT. Same Tokyo NTT POP the VM hits, just 2.4× the latency to get there.

What this means for the gvr-ingest pipeline

  1. gf-cx-singapore’s measured ~14 MiB/s sustained vs the Mac’s ~7 MiB/s isn’t contention or random network jitter. The VM is structurally close to Microsoft’s nearest APAC edge; the Mac takes a transatlantic leg before reaching ANY Microsoft POP. This is the throughput floor, not the ceiling.

  2. APAC off-peak window targeting is correct. The actual tenant backend is invisible past Microsoft’s edge router, but the path from anywhere outside APAC is dominated by: - transatlantic / trans-Pacific latency to reach MS’s nearest POP, - MS backbone congestion between that POP and the tenant home region. The off-peak window (NYC 10-18 EDT = JST 23-07 next day) reduces contention on leg #2. The geographic premise — that contention matters because the tenant is in APAC — is reinforced by both: - DNS attribution (NextDNS: gvr20-my.sharepoint.com resolves via JP endpoints), - traceroute (VM lands in Singapore MS POP, NOT a US one, confirming MS routes the anycast to nearest-region).

  3. Microsoft has 2+ POPs in Singapore (sg2, sg3). For our purposes that’s a latency floor signal, not actionable — we can’t pick which POP serves us. But it explains why two SharePoint anycast IPs in 13.107.0.0/16 resolve via different 3rd-hop routers.

  4. Singapore → Tokyo is 71-87 ms via NTT backbone. If the xlab.studio tenant backend IS in Japan East (per the NextDNS evidence), the VM-→-tenant leg is bounded by that ~80 ms round-trip — well within the throughput cap of the rest of the pipeline.

Cross-references

Methodology

# From gf-cx-singapore — Tailscale hostname is vm-asia-gcp
ssh vm-asia-gcp "traceroute -w 2 -m 20 -q 1 <hostname>"

# From Mac
traceroute -w 2 -m 20 -q 1 <hostname>

# Targets used:
#   gvr20-my.sharepoint.com  (xlab.studio tenant SharePoint)
#   nrt.dropbox.com          (Dropbox Tokyo IATA hint)
#   sharepoint.com           (generic SharePoint anycast)
#   docs.google.com          (control — Google direct peering)
#   www.google.com           (drop test — anycast ICMP-blocked from VM)

VM tools available: /usr/bin/traceroute. mtr + tracepath not installed.

Generated 2026-06-05 16:36 ET via ad-hoc trace + comparison. Pairs with the NextDNS-based tenant attribution work. Not a recurring audit — point-in-time empirical signal for the gvr-ingest pipeline investigation.

Source: dare_gf_cx_singapore_traceroute_2026-06-05.md · Rendered 2026-06-05 16:43