Ping – setting don’t fragment bit in Linux/FreeBSD/Solaris/Cisco/Juniper
Ping.
Many times while debugging network problems of various kinds you need to send some packets of desirable size and don’t fragment bit being set. I list below how to do it for the different equipment/OSes. Let’s start with the most popular operating system among network folks – Linux:
Linux
By default ping in any Linux-based system (It also means any distribution – Slackware, Ubuntu, CentOS etc) is sent with Don’t fragment (df) bit set . You don’t need to add any command line switches for that. Here is what you get by default ping in Linux:
Defaults:
Don’t fragment bitВ (in echo request)В — set
Ip packet size – 84 bytes
Sending intervalВ — 1 second
Some examples.
-В sending station:
-В В receiving station:
[root@darkstar
]#tcpdump -s 1500 -n -vv icmp
To change sent packet size: -sВ , bytes (8 bytes of ICMP header will be added automatically).
Sending host:
[root@darkstar
]#ping 10.99.99.158 -s 1300
Receiving host:
freeBSD#tcpdump -n -v -s 1500 icmp
To change sending interval (mostly used together with large packet size) :
-iВ
Sending host:
[root@darkstar
]#ping -s 1300 -i 0.2 10.99.99.158
Receiving host:
freeBSD#tcpdump -n -v -s 1500 icmp
To force Linux to send pings with DF bit cleared (i.e. not set):
ping –M don’t
]#ping -s 1300 -M dontВ 10.99.99.158
freeBSD#tcpdump -n -v -s 1500 icmp
SideNote: FreeBSD ping has a nice add-on (see below) – sweeping size of the packets, while Linux doesn’t have such extra feature, Below is script to emulate it on Linux:
Here:
size – size of data in ICMP packet (bytes);
-I 0.5 – interval of 5 seconds (optional);
-c 3 — number of pings in each size session (NOT optional – or you will enter an endless loop which even Ctrl-C won’t be able to stop )
See it in action:
[root@darkstar
]#awk ‘ BEGINВ
Don’t fragment bit — not setВ ;В use df-bit to set
Running with defaults:
Receiving host:
[root@darkstar
]# tcpdump -n -vВ -s 1500 icmp
Set df bit and size of the packet (Note – when you set size of the ping you set IP packet size and not ICMP data size as in Nix systems).
Repeat count is set to 3 .
Tokyo#ping 191.91.21.41 size 1300 df-bit rep 3
Receiving host:
[root@darkstar
]# tcpdump -n -vВ -s 1500 icmp
Sweeping ping size.
This feature is available from extended ping menu:
Juniper routers (JunOS):
Defaults:
Ip packet size : 84 bytes
Don’t fragment bit – not set; use do-not-fragment to set
IntervalВ — 1 sec;В use interval to change
Sending pings with df bit set and size 1470 bytes
root@Juniper> ping 192.168.37.29 do-not-fragment size 1470
If packet size is too large and df is set you get this:
root@Juniper> ping 192.168.37.29 do-not-fragment size 13000
dont fragment bit PING TOOL
Actually my machine wwan0 MTU is 1500
but when i ping like
what is this difference?
My intention is to know the example.com server’s MTU size? how can I find that?
2 Answers 2
Running «ping -M do -s 1490 example.com» says that the ICMP data size is 1490 bytes and fragmentation is not allowed. For this size of ICMP data, ICMP size (i.e., header + data) is 1498 bytes. Adding IP header, frame size becomes 1518 bytes. Frame size can’t exceed MTU size of the interface. As from the error message, MTU for the interface is 1500 bytes. So, there are extra 18 bytes in the frame. Without fragmentation, this message can’t be sent. Since fragmentation is not allowed, ping fails saying message is too long.
You don’t need remote server’s MTU size. In networking, MTU sizes are needed only for the next hop (unless the destination is the next hop). Reading https://en.wikipedia.org/wiki/IP_fragmentation helps.
When you specify «-s 1490» you set size of ICMP packet to 1490 bytes. Then the IP stack of your system adds ICMP and IP headers which equals to 28 bytes. So in this case while specifying size of 1490 bytes in fact your system tries to send IP packet of size 1490 + 28 = 1518 bytes. I assume that your PC has MTU 1500 on interface and as you already prohibited your system doing fragmentation it reports to you that packet is too big to be sent through interface with lower MTU.
Regarding your attempt of checking server’s MTU size. Because of concerns above you will not be able to send IP packet bigger than 1500 bytes, so if server has higher MTU you won’t be able to find this out from this PC.
monline
Search this site:
Recent links
Recent comments
- for loop with ping
22 weeks 1 day ago - Repair Corrupted MOV File
27 weeks 3 days ago - iMacs optical drive inside really dusty due to fan location
35 weeks 23 hours ago - Found an open-source tool that worked for me — Untrunc
47 weeks 2 days ago - Re: Grau’s still working, but with some snags.
47 weeks 2 days ago - Grau’s still working, but with some snags.
48 weeks 16 hours ago - Thank You for VideoRepair1.5.zip
48 weeks 1 day ago - Re: unrouteable address or unknown user
50 weeks 2 days ago - Which came first?
1 year 8 weeks ago - En space
1 year 12 weeks ago
How to determine the proper MTU size with ICMP pings
There’s a nice intro on the topic in one of the Linksys knowledgebase articles. I copy the info here so it won’t vanish once their knowledgebase goes offline. The original article used the Windows ping command in its examples, but I’ve added linux and Mac specific examples too.
To find the proper MTU size, you’ll have to do a special ping of the destination you’re trying to go to. This could be a local machine (a router, gateway, etc.) or a distant server on the internet (eg. example.com).
In case of a Windows machine the ping command should be formatted like:
The options used are:
- -f : set «Don’t Fragment» flag in packet
- -l size : send buffer size
In case of Linux, the command line should be:
The options used are:
- -M : Select Path MTU Discovery strategy. may be either «do» (prohibit fragmentation, even local one), «want» (do PMTU discovery, fragment locally when packet size is large), or «dont» (do not set DF flag).
- -s packetsize : Specifies the number of data bytes to be sent. The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data.
In case of Mac (Leopard), the command should be:
The options used are:
- -D : set the «Don’t Fragment» bit
- -s packetsize : Specify the number of data bytes to be sent. The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data.
You should always start at 1472 and work your way down by 10 each time. Once you get a reply, go up by 2 until you get a fragmented packet. Take that value and add 28 to the value to account for the various TCP/IP headers. Eg. let’s say that 1452 was the proper packet size (where you first got an ICMP reply to your ping). The actual MTU size would be 1480, which is the optimum for the network we’re working with.
Comments
On my MAC I personally use the Min -g 1330 and Max -G 1500, plus 8 byte ICMP header to start and increment by 1 (-h 1), let ping do the work.
for a VPN I like to start at 1330 with a 1500 max.
ping -g 1330 -G 1500 -h 1 -D 10.152.0.19
PING 10.152.0.19 (10.152.0.19): (1330 . 1400) data bytes
1338 bytes from 10.152.0.19: icmp_seq=0 ttl=121 time=418.883 ms
1339 bytes from 10.152.0.19: icmp_seq=1 ttl=121 time=441.258 ms
1340 bytes from 10.152.0.19: icmp_seq=2 ttl=121 time=289.218 ms
36 bytes from 10.152.0.19: frag needed and DF set (MTU 1360)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5105 a691 0 0000 3a 01 dd47 172.24.1.16 10.152.0.19
For DSL min -g 1420 max -G 1500, My MTU is 1454
ping -g 1420 -G 1500 -h 1 -D 4.2.2.2
PING 4.2.2.2 (4.2.2.2): (1420 . 1500) data bytes
1428 bytes from 4.2.2.2: icmp_seq=0 ttl=58 time=43.811 ms
1429 bytes from 4.2.2.2: icmp_seq=1 ttl=58 time=47.041 ms
1430 bytes from 4.2.2.2: icmp_seq=2 ttl=58 time=46.520 ms
1431 bytes from 4.2.2.2: icmp_seq=3 ttl=58 time=44.635 ms
1432 bytes from 4.2.2.2: icmp_seq=4 ttl=58 time=46.400 ms
1433 bytes from 4.2.2.2: icmp_seq=5 ttl=58 time=45.652 ms
1434 bytes from 4.2.2.2: icmp_seq=6 ttl=58 time=43.712 ms
36 bytes from pool-xx-xx-xx-52.dfw.dsl-w.verizon.net (xx.xx.xx.52): frag needed and DF set (MTU 1454)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 af05 83c7 0 0000 40 01 9f64 10.200.1.87 4.2.2.2
Re: MAC
Thanks! I didn’t notice the -g and -G options on Mac.
here is an odd situation.
I tried this method to with my new NetGear GS116E switch and it always blocks pings with buffer sizes between 513 and 1472! The switch has NO problem passing traffic with even jumbo frames as proven by sharking the traffic. Pings however within those ranges are not passed.
I have not been able to find an explanation for this.
Re: here is an odd situation.
Does this mean that only pings with a packet size below 513 bytes go through? I’m asking because 1472 is most probably the upper limit (at least for most networks/ISPs). Have you tried to ping multiple hosts and the results were all the same? Do pings work with all sorts of packet sizes if you remove the switch from your network setup?
for loop with ping
for i in <1500..900..-2>; do ping -M do -c 1 $IP_OF_VPN_SERVER -s «$i» 2>&1 | grep -q ‘1 received’ && break; done; echo $i