Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am pinging between two servers. These are both connected with 100Mbps ethernet NICs to the same switch. As you can see from the results below, I can ping from one to the other giving an ICMP data payload size of 1272, but as soon as I go to 1273 or higher, it stops working.

Why is this? Including headers et all, this is well under the 1500 bytes MTU of these two links, what is going on here?

Is this a limitation of ICMP, or the OS perhaps? Both devices are Ubuntu 10.04 x86 machines.

Thank you.

root@n2:~# ping -s 1272 -f 172.22.0.159
PING 172.22.0.159 (172.22.0.159) 1272(1300) bytes of data.
.^C
--- 172.22.0.159 ping statistics ---
14361 packets transmitted, 14360 received, 0% packet loss, time 10402ms

P.S. I am well aware this is seemingly pointless, so please don't comment on that :)

UPDATE: As request, here are some command outputs;

root@n2:~$ ip link show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:e0:4c:6d:0a:49 brd ff:ff:ff:ff:ff:ff

root@n2:~$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.0.0.23       172.22.0.1      255.255.255.255 UGH       0 0          0 eth0
172.22.0.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         172.22.0.1      0.0.0.0         UG        0 0          0 eth0
0.0.0.0         172.22.0.1      0.0.0.0         UG        0 0          0 eth0

root@n2:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:e0:4c:6d:0a:49 brd ff:ff:ff:ff:ff:ff
    inet 172.22.0.121/24 brd 172.22.0.255 scope global eth0



mev@mev:~$ ip link show
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:6e:df:41:1c brd ff:ff:ff:ff:ff:ff
mev@mev:~$ ip addr show
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:6e:df:41:1c brd ff:ff:ff:ff:ff:ff
    inet 172.22.0.159/24 brd 172.22.0.255 scope global eth1
    inet6 fe80::20c:6eff:fedf:411c/64 scope link 
       valid_lft forever preferred_lft forever
mev@mev:~$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
172.22.0.0      0.0.0.0         255.255.255.0   U         0 0          0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         172.22.0.1      0.0.0.0         UG        0 0          0 eth1
share|improve this question
1  
we need to see ip link show, netstat -rn and ip addr show from both machines please –  Mike Pennington Jul 5 '12 at 16:28
    
I have added the requested output –  jwbensley Jul 5 '12 at 16:39
    
Is it a managed switch? If so, please add the configuration from the switch. FWIW, I cannot replicate the problem you're describing on my unbuntu Oneric machines –  Mike Pennington Jul 5 '12 at 16:57
    
No it's just a basic unmanaged 100Mbps NetGear switch (exactly model escapes me at the moment, but I will find out tomorrow) –  jwbensley Jul 5 '12 at 18:54
    
OK, from home over my ADSL2+ I have re-run this test to a public server which is connected via 100Mbps Ethernet NIC. I couldn't ping with a payload size any higher than 1404 bytes, which is higher than the LAN test above, even though I have a lower MTU here. So possibly a problem with that switch (I will try another) or maybe some weird default setting on the sending machine I was using. I will also try sending from the other machine. –  jwbensley Jul 5 '12 at 19:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.