Ping test mtu linux

Значение MTU в Linux

MTU — maximum transmission unit — максимальный размер пакета или фрейма в байтах, который может быть отправлен единовременно без фрагментации. Узнать значение и поменять MTU в Linux можно используя утилиту ip. Чтобы изменения сохранялись после перезагрузки требуется продублировать новое значение в сетевых настройках.

Как узнать значение и поменять 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

На скриншоте показан процесс смены mtu:

Новое значение выделено, это 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

Как проверить MTU для внешнего сервера

Для сервера, к которому нет доступа по 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

Источник

Ping MTU – Find a Path’s MTU using PING Command

In some cases, higher-layer protocols may create large-size packets that not all network paths can support, such as the case of the jumbo frames.

These large packets (or frames) exceed the conventional Ethernet 1500 bytes of MTU (Maximum Transmission Unit).

So, the routers along the path with a default Ethernet MTU in their interfaces will fragment any of these large size packets that threaten to hurt their performance.

An improperly configured MTU can lead to failed transfers and intermittent connectivity.

But what is more daunting is that troubleshooting these kinds of problems can be really challenging.

Fortunately, we can do advanced troubleshooting and find the path MTU with the precious simple networking tool — The Ping Command.

How Does Path MTU Discovery Work?

The default Ethernet II MTU size is 1500 bytes, which is the largest size allowed in most of the Internet.

Although this value is known to be suitable for most environments, it is sometimes adjusted to a higher or lower value.

Adjusting MTU values can help match and improve the capacity of the network.

Larger MTU values can lead to lower network overhead, while a smaller MTU can help decrease the network delay.

How do routers discover MTU in a path?

Modern routers and endpoints use a process known as Path MTU Discovery (PMTUD) to find the path MTU, which is smaller than its interface MTU.

The goal of this process is to find the MTU size of a path while avoiding IP fragmentation.

The PMTUD works by setting the “Don’t Fragment (DF)” flag bit ON, within the IP packet header.

Routers along the path will receive these incoming packets and compare them with their MTU.

If the router interface’s MTU is smaller than the packet’s, and the packet contains the “Don’t Fragment” flag bit on, then the router will be forced to drop the packet and send back an ICMP Fragmentation Needed error message.

Knowing that the path MTU is too large, the source can adjust its packet’s MTU accordingly.

The process is repeated until the MTU has the right size to go through the entire path without fragmentation.

Simulating the Path MTU Discovery Process

You can simulate the Path MTU Discovery process using the ICMP Ping command with additional flags.

Perform a Ping to the target destination address. It can be the local gateway, a server, or a remote IP address.

To do this, we will be using the following additional Ping Flags:

Start by adjusting the TCP send buffer (size) with the “-l” flag. In the following Windows OS screenshot, you can see that we are sending an ICMP packet of 2000 bytes in size to the public IP 1.1.1.1

The Ethernet packet with a size of 2000 bytes is generally larger than most MTU in typical networks.

The packet is successfully going through the path and reaching its destination because it is being fragmented by the routers along the path.

Now, let’s see what happens when we set the “Don’t Fragment” flag, with the following command:

ping (destination IP) (-f) (-l (packet size))

When a packet is too large for a path MTU, a router would usually fragment it into pieces for a safer delivery.

But, as you can see from the screenshot above, now the destination returns a “Packet needs to be fragmented but DF set”.

Since we are choosing not to fragment packets, all the routers along the path will see no choice than to drop the packet.

For other Operating Systems:

ping (-M do) (-s (packet size)) (destination)

ping (-D) (-s (packet size)) (destination)

How to Find the Path’s MTU with Ping?

Now, to find the path MTU with a Ping command, you would need to repeat the process shown before and adjust the packet size every time.

You will ultimately find the path MTU by trial and error.

In the previous ping test, we used the 2000 bytes as the packet size.

You would probably want to start with a number around 1800-2000 bytes and move down every couple of 100 bytes until you get a successful ping reply.

As you can see in the following screenshot, we started with 1800, tested with 1500, until 1400 finally gave a successful reply.

That means the path MTU between our source and destination is somewhere between 1400 and 1500 bytes.

The next step would be to move the size up between 10-50 bytes until you get another successful reply.

We tested with 1450 bytes and got a reply, which means our value is above that.

Repeating this process led us to find the value, which is 1452 bytes.

The routers along the path were still fragmenting 1453 bytes (but not 1452). They considered 1453 to be too large to traverse the path.

But 1452 was the first proper packet size that returned a successful ICMP reply. My MTU value 1452 is common in Ethernet II.

We have to take into account the size of the TCP/IP header, which can range between 20-60 bytes. The header size varies according to the transmission media.

According to a chart from Wikipedia.

My Point-to-Point Protocol over Ethernet (PPPoE) header takes up 8 bytes in size, while the IPv6 header accounts for 40 bytes in size. So, the size of my TCP/IP header is 48 bytes (40+8).

Let’s take the packet size that gave us the ping reply (1452 bytes) and add it to the header size (48 bytes).

That leads us to the real MTU size, which is 1500 bytes, the common Ethernet MTU.

1452 is the data payload size or Maximum Segment Size (MSS), that results from the 1500 MTU.

Ping MTU FAQs

What is the default MTU size for ping?

The default MTU size for ping is typically 1500 bytes, but it can vary depending on the network and operating system.

How can I change the MTU size for ping?

To change the MTU size for ping, you can use the -l option followed by the desired packet size in bytes. For example: ping -l

Why would I want to change the MTU size for ping?

You may want to change the MTU size for ping to test the maximum size of packets that can be transmitted over a network or to test the performance of a network with different MTU sizes.

What is the relationship between MTU and packet loss in ping?

The relationship between MTU and packet loss in ping is that a larger MTU size can result in more packets being lost if the network has a lower MTU size limit. This is because larger packets may be fragmented and some fragments may be lost in transit.

How can I determine the optimal MTU size for a network?

To determine the optimal MTU size for a network, you can use a tool such as «ping -f -l » to incrementally increase the packet size and check for packet loss. The optimal MTU size is the largest size with no packet loss.

Источник

How to test if 9000 MTU/Jumbo Frames are working

Fairly straight forward this time, you’ve configured your MTU/jumbo frames to be 9000 on your client and destination devices (say a laptop/desktop/server/san/nas) and on ALL your switching devices in between — you’ve done that right? 😉

Testing#

So the next step is, we want to test if our new 9000 byte MTU is actually working and we can reap the benefits of a larger packet size (whether it’s on iSCSI, LAN, whatever) being of course a higher latency but also higher throughput. This depends on the OS you are running.

MacOS#

On Mac OSX (that I run) it’s:

ping -D -s 8184 [destinationIP] 

Note: Some commenters have noted that in newer versions of macOS (unknown from what version — but effective in 11.x and 12.x at least) that the max frame size for the ping should be as follows:

ping -D -s 8164 [destinationIP] 

Linux#

ping -M do -s 8972 [destinationIP] 

Windows#

ping -f -l 9000 [destinationIP] 

Additional Context#

The reason for the 8972 on *nix devices is that the ICMP/ping implementation doesn’t encapsulate the 28 byte ICMP (8) + IP (20) (ping + standard internet protocol packet) header — thus we must take the 9000 and subtract 28 = 8972 .

On Mac’s even though they are *nix kernels, the ping implementation only supports packets 8192 in size so we must remove the ICMP ( 8 byte ) header as the ping implementation has already included the 20 byte IP header, 8192 — 8 = 8184 .

(Apple macs DO support packets up to 9000 bytes, just the ICMP implementation they sport doesn’t…)

EDIT 31/10/13: According to BernieC in a comment here OSX does support 9000+ byte packets if you run the following command to increase its maximum datagram size:

sudo sysctl -w net.inet.raw.maxdgram=16384 

It is also important to understand where I got my values from this is an IP packet’s layout, you can see the IP info is 20 bytes:

Troubleshooting#

If you’ve forgotten to enable jumbo frames/9k MTU on your client device you’re sending the ping from you’ll see:

PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): 8184 data bytes ping: sendto: Message too long 

If you have enabled jumbo frames on your client but not the destination (or a switch in between) you’ll see:

PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): 8184 data bytes Request timeout for icmp_seq 0 

If you’ve done everything right and you’re set up ready to go you’ll get this:

PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): 8184 data bytes 8192 bytes from xxx.xxx.xxx.xxx: icmp_seq=0 ttl=128 time=0.714 ms 

Now rejoice in your lovely jumbo-framey goodness and a good 20-30% in sustained data throughput.

Why not follow @mylesagray on Twitter ↗ for more like this!

Источник