timeout when ping target with 85 bytes

Question

Sir,

A hosting produce - C2338 CPU with Intel I120 network adpater installed Windows 2019. When I ping it from Internet with default 32 bytes, it is okay. But time out when using 85 or more bytes. How to find out why package was dropped?

Pinging 51.158.148.26 with 32 bytes of data:  
Reply from 51.158.148.26: bytes=32 time=283ms TTL=114  
Reply from 51.158.148.26: bytes=32 time=284ms TTL=114  

But with 85 or more bytes of data was 'Time out'

Pinging 51.158.148.26 with 85 bytes of data:  
Request timed out.  
Request timed out.  
Request timed out.  
Request timed out.  
  
Ping statistics for 51.158.148.26:  
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)  

If I run mtupath.exe 51.158.148.26, it shows

MTU path scan to 51.158.148.26, ttl=64, limit=48  
# 26 best MSS 84 (estimated MTU 112) [pPPPP****p*p**ppP**P**P***]  
  
  
        #1 MSS IN RANGE     1 <==    83 ==>    84  
        #2 SCAN TIMEOUT    85 <==  1379 ==>  1464  
        #3 MSS EXCEEDED  1465 <== 14919 ==> 16384  
  
[WARNING] Minimum IPv4 Internet MTU of 576 was not reached  
[WARNING] Possible PMTU blackhole in route to peer  

Why this server's MTU has limited to 112 bytes?

I installed latest NIC driver from Intel or Windows update, it did not help. I have disabled Windows Firewall, but nothing was chagned. I tried to run 'netsh wfp show netevents', but there is no related block events by wfp too. If changed server from Windows 2019 to Linux, everyting is okay.

If package did not drop on network layer, it is possible happen on physical layer or data link layer? How to check or debug if package drop on them? Refer: https://learn.microsoft.com/en-us/windows-hardware/drivers/network/windows-network-architecture-and-the-osi-model

Answer 1

Hello @liujia

1. Please try to ping with different public ip address from this 2019 server.
2. Please try to ping with 51.158.148.26 ip from different machine having different subnet to check if there is any request time out.
3. Please check if you any VLAN configurations or NAT rules in placed at gateway or firewall level.
4. Try swap internal ip of Windows 2019 with Linux system to see if there are any firewall rules for static ip.

----------------

--If the reply is helpful, please Upvote and Accept as answer--

Answer 2

Hi @liujia

Have you try to repeat the test from a machine on the same network, rather than across the internet?

Some firewalls and routes support a feature to limit the maximum size of a ICMP packet that they will forward, this is to limit the potential for DDoS attacks. The details of the tests you have run above are all based on ICMP. Have you completed any tests that use TCP or UDP?

Are you seeing a problem with the service you are planning to run on the server?

Gary.

Answer 3

Hi @liujia

With the packet captures we have completed so far, we are capturing the packets seen by the network stack and not what has been transmitted on the wire. Really we need to see what is being sent by the server on the wire but without another machine, or help from your hosting company I'm not sure we will be able to get any more information.

I've seen weird networking issues before that are caused by the offload features in the driver, I think the next thing to try is to disable all the optimization features in the network card driver properties and see if this fixes the issue.

Based on the Intel i210 network card and this page ethernet-products.html I would recommend that you disable the following settings:

Jumbo frames (jumbo packets)
Large send offload
Adaptive inter-frame spacing
Flow control
Interrupt moderation rate - Off
Receive Side Scaling
IPv4 checksum offload
TCP checksum offload
Offload transmit IP checksum
UDP checksum offload

I would check that the transmit and receive buffer settings I wuld try increasing them, but also set them to 0 and see if this makes any difference.

I know your hosting company has told you that the server is a Dell, but I can't find any information
on Dell server\machines that having Intel Atom C3250 processor, but that might be because the processor was released back in 2013. The other thing that doesn't make sense is that the MAC address of your machine is associated to ADI Engineering and not Intel. ADI Engineering specialise in embedded single board computers, which might explain why your hosting company has said that it doesn't support Windows as the board might not be tested or certified for Windows. May be ask them.

Give the network options a try and see if that fixes the problem, if not, then my suggestion would to send a network capture of the issue to the hosting company and try to get them to do a packet capture from the router or another machine on the network segment to see what is being transmitted by the server when you have an ICMP over 85 bytes.

Gary.