▲ | Bender a day ago | |||||||||||||||||||||||||
Packet loss over ICMP can be artificial based on the backplane load of routers, ACL's and artificial rate limits. They will de-prioritize responding to ICMP and fail to respond if CPU load is high but that does not mean the packets are not being forwarded 100%. Linux and BSD also have knobs for this behavior as well. HN is BSD. Are you seeing TCP retransmits to port 443?
Do that at the same time as watching
It would be most useful to do this from your location and also from VM's on a few different providers in different locations to find which thing is not like the other. The 'nc' I am using is part of the nmap distribution. To force IPv6 replace the name with the IPv6 address. | ||||||||||||||||||||||||||
▲ | eqvinox a day ago | parent [-] | |||||||||||||||||||||||||
> Packet loss over ICMP can be artificial based on the backplane load of routers. This doesn't generally apply to the end host; note the last hop in the trace I posted is the web server itself. Also, the second last hop having very similar loss% makes it likely that neither of the two systems is hitting rate limits (as they would be different). > Are you seeing TCP retransmits to port 443? If the webpage loaded normally, I wouldn't have investigated to begin with ;). Right now, the loss on TCP SYNs is about 70%. (mtr -T -P 443) Second to last hop still has roughly the same loss. Something's h0rked at americanis.net. | ||||||||||||||||||||||||||
|