25 x PERPETUAL $1/Year VPS GIVEWAY !! Netfront AS4658

ccxv · October 30

coming

jcn50 · October 30

@lovelyserver : did your server became sluggish too?.. The network became terrible, the SSH session is slow to echo.

jcn50 · October 30

@netfront there is a network problem my friend, shall I open a ticket?

Inbound packet loss to my HK box, confirmed by server-side counters. Not my ISP, not ICMP rate-limiting.

1. Symptom — TCP connects from Ireland to 202.81.230.104:122, 10 tries:

ok   338 ms   <- true RTT
ok  1342 ms
ok  1347 ms
ok  1352 ms
ok  1353 ms
ok  1355 ms
ok  1355 ms
ok  3356 ms
ok  3368 ms

8 of 10 didn't complete on the first SYN. Delays quantised to whole seconds = SYN retransmission, not congestion. None failed outright.

2. Not one route — same test from my own VPN exits:

Exit          clean/10   worst
Ireland          1/10    3.37 s
France           3/10    4.36 s
Netherlands      5/10    7.37 s
Canada           6/10    3.36 s
New York         7/10    1.38 s
Japan            2/10    7.37 s

Same whole-second signature everywhere. Only common element is the destination.

Control: TCP connect to 1.1.1.1:443 -> 10 ms flat, 10/10 clean.

3. Server-side counters

eth0 RX: 283307 pkt, 4438 dropped (1.57%)
eth0 TX:  46003 pkt,    0 dropped

TcpExtTCPSynRetrans    676   <- box's own SYNs unanswered
TcpExtListenOverflows    0
TcpExtListenDrops        0
TcpExtTCPBacklogDrop     0
TcpExtSyncookiesSent     0
ss -tan state syn-recv   2
tc -s qdisc   pfifo_fast, 0 drops, 0 overlimits  (no shaping)
conntrack -C  (empty)
ip -s link    no errors/overruns

Uptime ~22 min.

4. Ruled out
- My line: 1.1.1.1 clean, every other server fine
- Server load: load1 = 0.00
- Kernel dropping SYNs: all listen/syncookie counters 0, accept queue never filled
- Guest shaping: plain pfifo_fast, 0 drops
- Outbound from box: Ireland / Amsterdam connect in ~0.3 s, 0% loss

5. What's left — inbound drops at the host/vNIC edge (RX dropped 4438, TX 0) and/or upstream transit. 676 SYN retransmits in 22 min says outbound SYNs are also going unanswered.

Test it yourself (Windows PowerShell):

1..10 | % {
  $sw=[Diagnostics.Stopwatch]::StartNew(); $c=New-Object Net.Sockets.TcpClient
  try   { $c.Connect('202.81.230.104',122); $sw.Stop(); "ok   {0,6:N0} ms" -f $sw.Elapsed.TotalMilliseconds }
  catch { $sw.Stop(); "FAIL {0,6:N0} ms" -f $sw.Elapsed.TotalMilliseconds }
  finally { $c.Close() }
}

Clean: ten lines ~335 ms. Faulty: mix of ~335 ms and ~1340/2350/3350/4350/7350 ms.

Anyone else: post your numbers.

lovelyserver · October 30

@jcn50 said:
@lovelyserver : did your server became sluggish too?.. The network became terrible, the SSH session is slow to echo.

I don't know. I'm on holiday, no laptop. This service is not saved on Terminus mobile. Just LET forum and Facebook.

jcn50 · October 30

@netfront you can see all the European nodes becoming red bec of packet losses:
https://ping.pe/202.81.230.104

netfront · October 31

@frlee said:
Is "AS4658" a line designation, or some sort of mysterious internal code? If I happen to receive it as a gift, I’ll use it to set up a personal blog.

AS4658 is just another Autonomous System Number. The internet routing people often refer individual ISPs with their AS number. We flex the number just because it is 4 digit, relatively rare on LET.

netfront · October 31

@jcn50 said:
@netfront there is a network problem my friend, shall I open a ticket?

Inbound packet loss to my HK box, confirmed by server-side counters. Not my ISP, not ICMP rate-limiting.

1. Symptom — TCP connects from Ireland to 202.81.230.104:122, 10 tries:
ok   338 ms   <- true RTT
ok  1342 ms
ok  1347 ms
ok  1352 ms
ok  1353 ms
ok  1355 ms
ok  1355 ms
ok  3356 ms
ok  3368 ms

May be your test detects packet loss ? It could be intermittent problem. You can open a ticket!

Our equivalent tests from various points right now (at this point in time though)

toronto:~# for i in $(seq 1 10); do s=${EPOCHREALTIME/./}; timeout 5 bash -c 'exec 3<>/dev/tcp/202.81.230.104/122' 2>/dev/null && r=ok || r=FAIL; e=${EPOCHREALTIME/./}; printf '%-4s %6d ms\n' "$r" $(((e-s)/1000)); done
ok 209 ms
ok 202 ms
ok 209 ms
ok 204 ms
ok 200 ms
ok 208 ms
ok 209 ms
ok 208 ms
ok 204 ms
ok 200 ms

singapore:~# for i in $(seq 1 10); do s=${EPOCHREALTIME/./}; timeout 5 bash -c 'exec 3<>/dev/tcp/202.81.230.104/122' 2>/dev/null && r=ok || r=FAIL; e=${EPOCHREALTIME/./}; printf '%-4s %6d ms\n' "$r" $(((e-s)/1000)); done
ok 39 ms
ok 39 ms
ok 39 ms
ok 39 ms
ok 40 ms
ok 38 ms
ok 37 ms
ok 39 ms
ok 39 ms
ok 41 ms

silicon-valley-2:~# for i in $(seq 1 10); do s=${EPOCHREALTIME/./}; timeout 5 bash -c 'exec 3<>/dev/tcp/202.81.230.104/122' 2>/dev/null && r=ok || r=FAIL; e=${EPOCHREALTIME/./}; printf '%-4s %6d ms\n' "$r" $(((e-s)/1000)); done
ok 159 ms
ok 164 ms
ok 164 ms
ok 168 ms
ok 160 ms
ok 167 ms
ok 163 ms
ok 162 ms
ok 167 ms
ok 164 ms

frankfurt:~# for i in $(seq 1 10); do s=${EPOCHREALTIME/./}; timeout 5 bash -c 'exec 3<>/dev/tcp/202.81.230.104/122' 2>/dev/null && r=ok || r=FAIL; e=${EPOCHREALTIME/./}; printf '%-4s %6d ms\n' "$r" $(((e-s)/1000)); done
ok 250 ms
ok 246 ms
ok 247 ms
ok 247 ms
ok 259 ms
ok 258 ms
ok 235 ms
ok 244 ms
ok 264 ms
ok 262 ms

hk:/boot# for i in $(seq 1 10); do s=${EPOCHREALTIME/./}; timeout 5 bash -c 'exec 3<>/dev/tcp/202.81.230.104/122' 2>/dev/null && r=ok || r=FAIL; e=${EPOCHREALTIME/./}; printf '%-4s %6d ms\n' "$r" $(((e-s)/1000)); done
ok 9 ms
ok 8 ms
ok 7 ms
ok 7 ms
ok 7 ms
ok 7 ms
ok 7 ms
ok 8 ms
ok 7 ms
ok 7 ms

netfront · October 31

@jcn50 said:
@lovelyserver : did your server became sluggish too?.. The network became terrible, the SSH session is slow to echo.

You may be right, could have been congestion to Europe a few days back. Looking into it!

What is the result right now ? Thank you!

jcn50 · October 31

@netfront I only have errors to your network my friend, I have opened a ticket now (#216787).

Same Irish line, same minute. Other Hong Kong destinations are clean, yours is not.

Non-netfront Hong Kong destination sample (using Windows PowerShell): all OK!

1..10 | % {
  $sw=[Diagnostics.Stopwatch]::StartNew(); $c=New-Object Net.Sockets.TcpClient
  try   { $c.Connect('efiling.ipd.gov.hk',443); $sw.Stop(); "ok   {0,6:N0} ms" -f $sw.Elapsed.TotalMilliseconds }
  catch { $sw.Stop(); "FAIL {0,6:N0} ms" -f $sw.Elapsed.TotalMilliseconds }
  finally { $c.Close() }
  Start-Sleep -Seconds 2
}
ok    245 ms
ok    217 ms
ok    217 ms
ok    215 ms
ok    215 ms
ok    216 ms
ok    218 ms
ok    234 ms
ok    217 ms
ok    217 ms

Your netfront Hong Kong AS4658 network (using Windows PowerShell): NOT OK!

1..10 | % {
  $sw=[Diagnostics.Stopwatch]::StartNew(); $c=New-Object Net.Sockets.TcpClient
  try   { $c.Connect('hosting.netfront.net',443); $sw.Stop(); "ok   {0,6:N0} ms" -f $sw.Elapsed.TotalMilliseconds }
  catch { $sw.Stop(); "FAIL {0,6:N0} ms" -f $sw.Elapsed.TotalMilliseconds }
  finally { $c.Close() }
  Start-Sleep -Seconds 2
}
ok    357 ms
ok    336 ms
ok    378 ms
ok  1,340 ms -- puke
ok    330 ms
ok    334 ms
ok    341 ms
ok  1,338 ms -- puke
ok  2,547 ms -- puke
ok    337 ms

Clean looks like ten flat lines. Faulty looks like whole-second jumps (1.3s, 2.5s, 3.5s).

jcn50 · October 31

@netfront said: AS4658 is just another Autonomous System Number. The internet routing people often refer individual ISPs with their AS number. We flex the number just because it is 4 digit, relatively rare on LET.

Follow-up: I looked at the public routing data for AS4658, and it could explain the path behaviour

Everything below is public data — RIPEstat/RIPE RIS, APNIC RDAP, PeeringDB. No test instructions, just what the routes show.

=== 1. AS4658 IS NOT A NEW ASN ===

Registered with APNIC on 2008-09-04, name M2012LIMITED-AS, holder 2012 Limited (ORG-LA9-AP), country HK.
So the number itself is old. But the address space could have been moved onto it recently, which would line up with a "fine at first, broken later" timeline.
They announce 33 prefixes in the current window, a lot of them inside 202.81.224.0/19 — including 202.81.230.0/23 and the more-specifics 202.81.230.0/24 and 202.81.231.0/24.

=== 2. ROUTE VISIBILITY IS SPLIT ===

This is the interesting part. Both prefixes are originated by AS4658, but they are not seen equally:

202.81.230.0/23 — seen by 323 / 323 RIS peers. Universal.
202.81.230.0/24 — seen by 38 / 323 peers (~12%).

So the covering /23 is everywhere, while the more-specific /24 is visible to roughly one peer in eight. Both are valid, both are announced, but they are not propagating the same way.

=== 3. THE PREFIX IS CHURNING ===

BGP updates on 202.81.230.0/24 in October: 214 total — 177 announcements, 37 withdrawals.

Withdrawals fell on Oct 1, 3, 6, 7, 18, 20, 21, 23, 24, 25, 26, 28 and 30. On 30 October there was a withdrawal at 10:31:05 UTC, re-announced at 10:32:24 UTC — 79 seconds later.

That is a route appearing and disappearing repeatedly, on a prefix that is already thinly visible.

=== 4. IT IS NOT A FILTERING MISTAKE ===

RPKI: Valid for origin AS4658 (ROA on 202.81.224.0/19, max length /24).
IRR route objects exist in APNIC, NTTCOM and RADB.
They peer at HKIX (two Peering LAN entries, route-server peer).
Observed neighbours include AS6939 (Hurricane Electric), AS4635, AS9304, AS24077, AS45250 and others.

So this could not be a "they forgot the route object" or "RPKI is invalid" situation. The paperwork is in order.

=== 5. WHAT THIS COULD MEAN ===

It could be a routing/announcement problem on their side — around that /24 and how it is selected — rather than anything wrong with the VM.

Longest-prefix-match divergence. The /24 is thinly visible while the /23 is everywhere, so different networks could end up choosing different routes to the same host. Networks that see the /24 use it; networks that don't fall back to the /23, which may arrive over a different peer with a different AS path. That could be how one region gets a worse path than everyone else to the same server.
The churn could match the intermittency. Withdrawals and re-announcements mean the path could literally be changing underneath you. A withdrawn-and-restored route is a classic source of the whole-second SYN-retransmit pattern — first SYN goes into a hole, retransmit lands after reconvergence.
Both directions being affected could fit a route that flaps or is sub-optimal in both directions, rather than a one-way policer.

=== 6. WHY OTHER SERVERS DO NOT SHOW IT ===

Other VPSes tend to sit on different ASNs with stable, well-propagated routes — one consistent, universally-visible path, nothing to diverge on and nothing to flap. If this HK network is currently reorganising its announcements, its path could be the only one that changes depending on where you connect from. Same client, same software, different route, different result.

TL;DR:

AS4658's 202.81.230.0/24 could be thinly visible (~12% of RIS peers vs ~100% for the /23) and is churning, with 37 withdrawals in October alone. This could explain region-dependent loss to the same host without anything being wrong with the server itself. Worth a look from their side.

walker_muse · November 1

Thanks for the giveaway! If I get lucky, I'd use this HK VPS as a small Asia-side monitoring node for my own little fleet of servers (uptime checks and latency probes from Hong Kong), plus a lightweight personal service or two. The HKIX location is exactly what makes it interesting. Fingers crossed for a reserve slot!

roast · November 1

i would like to know more about AS4658

conpuissance · 5:26AM

I plan to use this permanent $1/year VPS plan.
How to register？

igctt · 5:30AM

where to buy?

Howdy, Stranger!

Categories

In this Discussion

25 x PERPETUAL $1/Year VPS GIVEWAY !! Netfront AS4658

Comments

@netfront I only have errors to your network my friend, I have opened a ticket now (#216787).

=== 1. AS4658 IS NOT A NEW ASN ===

=== 2. ROUTE VISIBILITY IS SPLIT ===

=== 3. THE PREFIX IS CHURNING ===

=== 4. IT IS NOT A FILTERING MISTAKE ===

=== 5. WHAT THIS COULD MEAN ===

=== 6. WHY OTHER SERVERS DO NOT SHOW IT ===

TL;DR:

Howdy, Stranger!

Quick Links

Categories

In this Discussion

25 x PERPETUAL $1/Year VPS GIVEWAY !! Netfront AS4658

Comments

@netfront I only have errors to your network my friend, I have opened a ticket now (#216787).

=== 1. AS4658 IS NOT A NEW ASN ===

=== 2. ROUTE VISIBILITY IS SPLIT ===

=== 3. THE PREFIX IS CHURNING ===

=== 4. IT IS NOT A FILTERING MISTAKE ===

=== 5. WHAT THIS COULD MEAN ===

=== 6. WHY OTHER SERVERS DO NOT SHOW IT ===

TL;DR: