All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Random TCP resets on Hosthatch LA IPv4 network (unstable ECMP?)
I've observed outgoing TCP connections being randomly reset by some websites on my Hosthatch Los Angeles IPv4 network since approximately a month ago. It happens very often on Fastly-hosted websites, which are a lot. For example, when I ran curl to get github.githubassets.com (185.199.110.154) 20 times in a row...
# for i in $(seq 1 20); do curl -4sS https://github.githubassets.com/ -o /dev/null; done
curl: (35) Send failure: Connection reset by peer
curl: (35) Send failure: Connection reset by peer
curl: (35) Send failure: Connection reset by peer
curl: (35) Send failure: Connection reset by peer
curl: (35) Send failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
curl: (35) Send failure: Connection reset by peer
curl: (35) Send failure: Connection reset by peer
curl: (35) Send failure: Connection reset by peer
curl: (35) Send failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
curl: (35) Send failure: Connection reset by peer
It turned out 13 out of 20 requests were reset by peer, a failure rate of 65%. But repeatly sending requests to https://github.com (140.82.116.3), which is not on Fastly, returns zero errors.
Dumping the TCP packets showed a successful three-way handshake, followed by RST from server and retransmission of SYN+ACK, also from server. Note that the two aforementioned packets had different TTL values, as if they were two servers from separate networks.
# tcpdump -i eth0 -vpn net 185.199/16
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
00:00:11.510604 IP (tos 0x0, ttl 64, id 11694, offset 0, flags [DF], proto TCP (6), length 60)
45.67.xxx.yyy.46888 > 185.199.110.154.443: Flags [S], cksum 0x30f8 (incorrect -> 0x6f57), seq 4124939881, win 31504, options [mss 1432,sackOK,TS val 4152029250 ecr 0,nop,wscale 9], length 0
00:00:11.511103 IP (tos 0x48, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 60)
185.199.110.154.443 > 45.67.xxx.yyy.46888: Flags [S.], cksum 0x1e4f (correct), seq 354031431, ack 4124939882, win 65535, options [mss 1460,sackOK,TS val 1139170212 ecr 4152029250,nop,wscale 9], length 0
00:00:11.511117 IP (tos 0x0, ttl 64, id 11695, offset 0, flags [DF], proto TCP (6), length 52)
45.67.xxx.yyy.46888 > 185.199.110.154.443: Flags [.], cksum 0x30f0 (incorrect -> 0x4cde), ack 1, win 62, options [nop,nop,TS val 4152029251 ecr 1139170212], length 0
00:00:11.512297 IP (tos 0x0, ttl 64, id 11696, offset 0, flags [DF], proto TCP (6), length 569)
45.67.xxx.yyy.46888 > 185.199.110.154.443: Flags [P.], cksum 0x32f5 (incorrect -> 0x5ad2), seq 1:518, ack 1, win 62, options [nop,nop,TS val 4152029252 ecr 1139170212], length 517
00:00:11.513096 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto TCP (6), length 40)
185.199.110.154.443 > 45.67.xxx.yyy.46888: Flags [R], cksum 0x99d1 (correct), seq 354031432, win 0, length 0
00:00:12.539278 IP (tos 0x48, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 60)
185.199.110.154.443 > 45.67.xxx.yyy.46888: Flags [S.], cksum 0x1a49 (correct), seq 354031431, ack 4124939882, win 65535, options [mss 1460,sackOK,TS val 1139171241 ecr 4152029251,nop,wscale 9], length 0
00:00:12.539304 IP (tos 0x48, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
45.67.xxx.yyy.46888 > 185.199.110.154.443: Flags [R], cksum 0x39eb (correct), seq 4124939882, win 0, length 0
Digging around, there is a post on Fastly forum about a similar problem, indicating unstable ECMP. The OP of that post was fortunate enough to have their ISP resolve the problem quickly.
I wonder if there are other Hosthatch LA users affected by this or is it just me?
Comments
cool, wanna get the reason of this, waiting for update
I did test and the same result. Did you open a ticket?
My test results are the same as yours. Also on Hosthatch LA.
Thank you all for testing. Having confirmed that it's not faulty configuration at my end, I have just opened a ticket with Hosthatch. I'll update the post if and when they reply.
Thanks for reporting this, this happens on certain routes and we're working on a resolution with the affected upstream in LA.
Thanks! I have to commend Hosthatch support for improved responsiveness. Here's the timeline:
Now, 48 hours have passed, but the issue has not been resolved yet. I guess we have to wait a bit longer...
Update: It looks like the issue has been resolved now.
cool
Same. Finally resolved.