Linux ping with mtu

Узнать значение и поменять MTU в Linux

Узнать значение MTU для всех интерфейсов можно выполнив в консоли команду ip link

1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:
mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 54:52:00:91:96:85 brd ff:ff:ff:ff:ff:ff

Чаще всего встречается 1500 — это значение по умолчанию для Ethernet интерфейсов.

Поменять MTU на сервере с Debian можно так:

ip link set dev eth0 mtu 1400

При этом начинает использоваться значение 1400, после перезагрузки эти изменения не сохранятся.

Чтобы сделать их постоянными нужно отредактировать файл /etc/network/interfaces

Для CentOS это скрипты /etc/sysconfig/network-scripts/*, для других систем иначе — для Debian также возможны варианты, но чаще всего это /etc/network/interfaces

К нужному интерфейсу достаточно дописать mtu 1400 отдельной строкой

IFACE при этом заменить именем интерфейса, таким как eth0

Если настройки сети выдаются DHCP, то секция примет такой вид:

iface eth0 inet dhcp
pre-up /sbin/ifconfig $IFACE mtu 1454

Для сервера, к которому нет доступа по SSH MTU можно узнать экспериментальным путем. Значение может потребоваться при поиске сетевых неполадок.

Это делается за счет опции -M do утилиты ping.

ICMP пакеты при этом будут отправляться с заданным MTU, из ответа будет видно реальное значение.

PING ya.ru (87.250.250.242) 1572(1600) bytes of data.
ping: local error: Message too long, mtu=1500

— ya.ru ping statistics —
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

28 байт вычитается, поскольку они отданы под хэдеры IP и ICMP.

При установке 1500 байт PING проходит успешно.

PING ya.ru (87.250.250.242) 1472(1500) bytes of data.
1480 bytes from ya.ru (87.250.250.242): icmp_seq=1 ttl=57 time=32.0 ms

— ya.ru ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 32.040/32.040/32.040/0.000 ms

Читайте про iface inet — директиву, которую можно увидеть в /etc/network/interfaces

Источник

How to find the correct MTU and MRU of your link

Overview

In the previous post, I talked about Network IP Fragmentation, what it is and why it’s needed (You are advised to read it before continuing). I also covered the so called PMTUD Black hole effect.

Fixing a PMTUD Black hole is a multistep process, and it starts with finding the correct MTU/MRU of your link.

Now as I’ve discussed, every path can have its own unique MTU/MRU value, but we are usually interested in the max value that is dictated by your ISP.

When you send a packet, it always routes through your ISP. Because of different protocols in place and their overheads (mostly layer 2 ones), it is common for your ISP to force MTU/MRU of less than 1500 bytes on your link.

If a packet exceeds these values, your ISP is required to send the appropriate ICMP messages either back to you (for the MTU), or to the server sending the data (for the MRU). These messages give the corresponding hosts a chance to adapt themselves to the link.

If your ISP decides to not send the required ICMP messages (or they get lost in transaction for some reason), all sorts of issues could arise. And for solving that, the first step is to manually determine your links MTU/MRU values.

ICMP packets

The best way for finding your link’s MTU/MRU is by sending ICMP packets (or more precisely, Pings) to the other host.

To be able to interpret the results, we first need to have an understanding of an ICMP packet’s structure.

Each PDU in layer 3, consists of different parts. Lets take a look at a typical IPv4 ICMP packet:

As you can see, we have 20 bytes of IPv4 header at the top, followed by 8 bytes of ICMP header, and finally the data or the payload .

Procedure

If we send some packets to a remote host with the DF flag set, and if those packets exceed the maximum packet size of our link, not only they should never reach the remote host, we should also receive an ICMP message from a router along the way (likely our own ISP), informing us.

The easiest way to do so, is by using ICMP Ping. The ping command, is available in pretty much every platform you can think of.

To summarize: We set the DF flag on our ICMP packet and send a big enough ICMP Ping payload, after exceeding the maximum packet size of our link, we will observe the results.

Constructing the ping command

We first try to send a 1500 bytes ping packet to a remote server. Shortly I will explain why.

Linux

For this, we’re going to use iputils package which is most likely already installed in your distro 1 .

Open the terminal and issue this command:

ping -c 4 -s 1472 -M do 8.8.4.4

The arguments are pretty simple:

Argument	Description
-c 4	Number of pings
-s 1472	Size of the payload. Remember that each ICMP payload has 28 bytes of overhead ( 1472 + 28 = 1500 )
-M do	Path MTU Discovery strategy. The do option, makes it to set the Don’t Fragment flag (not confusing at all)
8.8.4.4	The remote host we’re sending the packets to (In this case, one of google’s public DNS servers)

Windows

Open cmd.exe and issue this command:

ping -l 1472 -f 8.8.4.4

Again, arguments are very simple:

Argument	Description
-l 1472	Size of the payload (just like above)
-f	Set the Don’t Fragment flag
8.8.4.4	Sorry google! Your DNS servers are just too awesome

Identifying the correct MTU

Now if you do get a ping reply with the above commands, it means that at least for the path between you and google’s DNS servers, your MTU is 1500 2 and you should not have any MTU (and likely MRU) problems.

If you suspect you are having MTU issues on your link, the first step is to reproduce it. So try again those commands with another IP address (or ideally the IP address you have issue with) until you do not get a pong from the other end.

On a healthy link with MTU of less than 1500 bytes, you should see a response like this:

On Linux:

On Windows:

As you can see, we got a response from a hop on the link that it can not pass our packet. We also get the hop’s IP address and as a bonus, Linux ping also shows the MTU.

Most likely than not, the said hop is either the next immediate router on your path (i.e, your home router) or your ISP.

You can then adjust the payload size (in this case 1492-28= 1464 ) again and retry. You do that until you get a response from the other end.

That however, is how it should work and if it did work like this, you wouldn’t be needing to find the MTU manually.

If you do get a plain ping-timeout reply every time, then you might indeed have a PMTUD black hole on your path. Finding the MTU at this point is as easy as adjusting ping’s payload.

To summarize: You reduce the ping’s payload until you start getting replies. You could start by reducing its size in half (which you most likely would get a reply) and then fine-tune it from there 3 .

Identifying the correct MRU

You usually shouldn’t be needing to adjust this. It’s not your problem but the next-hop’s ones 4 .

There is a certain twist in finding your MRU:

Setting the DF flag on your ping packet, does not automatically mean the reply would also have the DF flag set (In fact my testing shows it doesn’t). And even if you could force that, you still would have trouble finding out whether in fact PMTUD works for your link’s MRU or not. That is unless you control the other end as well.

To summarize: Your best bet for finding the correct MRU of your link, is to ping your host from a remote location (making it the MTU of that remote location). If you don’t have access to a remote host, search the web for online ping services and use those instead.

Caveats and pitfalls

You should be aware that there are some situations in which you might not get the expected results. Some of them are as follows:

Your ISP might silently remove the DF flags: This is really a bad practice but some ISPs opt for this as a way of solving MTU issues altogether. On such connections, once a packet reaches the ISP, the DF flag is removed.

Some remote hosts might send truncated replies: To protect their network, some remote hosts instead of replying the ping with the same payload, they truncate it. Making the reply somewhat invalid. While the client can usually correctly handle this for a single ping packet, the situation could get complicated once they get fragmented. Best to use a host known to not do that (like google DNS servers).

A firewall might be blocking your ping request/response: If that’s the case and you are sure it’s not being done on your end, you are pretty much out of luck using ping. One way would be constructing a TCP packet to send to a remote host (this is somewhat more complex). Another way is to just run Wireshark and observe the normal traffic for couple of minutes to make an educated guess about your links MTU/MRU.

You might be behind a transparent proxy: That means you think you have a direct connection but you really don’t. Most of your traffic goes through what’s called a Transparent Proxy. Even if you do get a ping response from a remote host, that’s not necessarily reflect your real MTU/MRU to the transparent proxy.

Your link MTU might change over time: This is rather unusual for home networks but I’ve seen this on mobile networks. In such cases the all time low MTU of your link is your only reliable MTU.

A firewall might block fragmented ping requests/responses: Yes, no kidding, I’ve seen this too. Whether it was accidental and the result of connection tracking issue, or on purpose to possibly discourage the use of ping payloads to transfer real data (e.g., to bypass firewalls), it effectively blocks pings as soon as they get fragmented. So basically you may not have any MTU issue at all and yet, ping results would suggest otherwise. This one is really unfair to troubleshoot!

The NIC on your host, migh be set to use a MTU value other than 1500: Specially in windows, this may cause lots of weird results. Whether its set via adapter’s setting or the netsh command, that can influence your result.

Some low-level network drivers might affect the result: Again, specially in windows, this can easily happen with security softwares such as Kaspersky’s NDIS filter.

Note that some ping implementations like BusyBox, are not suitable for this since they lacked the required parameters. ↩︎

Or possibly even more, but uncommon. It could also mean your ISP is being really naughty, more on that later. ↩︎

If you never get a reply and you are sure your internet connection is working, then a firewall in the path might be blocking it. I will briefly introduce another approach at the end of the article. ↩︎

Refer to the PMTUD discussion for more info. ↩︎

Источник

monline

Search this site:

Recent links

Recent comments

• Szia!Nem vagyok biztos
  36 weeks 2 days ago
• nem jön ki a matek
  36 weeks 4 days ago
• Thanks for this, with one modification
  38 weeks 3 days ago
• Hi
  39 weeks 3 days ago
• Re: App
  46 weeks 20 hours ago
• Re: App
  46 weeks 1 day ago
• App
  46 weeks 2 days ago
• Re: Köszi !
  46 weeks 3 days ago
• Köszi !
  46 weeks 5 days ago
• Re: OSM alapú alternatíva
  46 weeks 5 days 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

Just my two cents!

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

You can try this.

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

Источник