Differences

This shows you the differences between two versions of the page.

--- networking:mtu [2022/06/29 11:37] – aperez
+++ networking:mtu [2025/09/11 01:12] (current) – aperez
@@ Line 1: / Line 1: @@
 **Maximum transmission unit (MTU)**
-{{ :networking:mtu-image-0.png?400 |}}
+{{ :networking:mtu-image-0.png?300 |}}
-{{ :networking:mtu-image-4.png?400 |}}
+{{ :networking:mtu-image-4.png?500 |}}
 {{ :networking:mtu-image-5.png?400 |}}
-{{ :networking:mtu-image-6.png?400 |}}
+{{ :networking:mtu-image-6.png?400 |}}
+{{ :networking:mtu-image-7.png?400 |}}
+{{ :networking:mtu-image-8.png?400 |}}
+{{ :networking:mtu-image-9.png?300 |}}
-A maximum transmission unit (MTU) is the largest packet or frame size, specified in octets (eight-bit bytes) that can be sent in a packet- or frame-based network such as the internet. The internet’s transmission control protocol (TCP) uses the MTU to determine the maximum size of each packet in any transmission. MTU is usually associated with the Ethernet protocol, where a 1500-byte packet is the largest allowed in it (and hence over most of the internet).
+**A maximum transmission unit (MTU)** is the largest packet or frame size, specified in octets (eight-bit bytes) that can be sent in a packet- or frame-based network such as the internet. The internet’s transmission control protocol (TCP) uses the MTU to determine the maximum size of each packet in any transmission. MTU is usually associated with the Ethernet protocol, where a 1500-byte packet is the largest allowed in it (and hence over most of the internet).
 One of the most common problems related to MTU is that sometimes higher-level protocols may create packets larger than a particular link supports, and you’ll need to make adjustments to make it work.
@@ Line 19: / Line 23: @@
 Before we look at TCP MSS, it helps to understand the build of the  “unit” that’s being sent over the internet.
+----
+**Xubuntu - Linux**
+<code bash>
+aperez@St-Francis:~$ ping -c 4 -M do -s 1472 8.8.8.8
+PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
+bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=8.30 ms
+bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=8.06 ms
+bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=8.53 ms
+bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=8.32 ms
+--- 8.8.8.8 ping statistics ---
+packets transmitted, 4 received, 0% packet loss, time 3004ms
+rtt min/avg/max/mdev = 8.064/8.304/8.530/0.165 ms
+</code>
+----
+**Windows**
+<code dos>
+C:\Users\Administrator>ping 8.8.8.8 -f -l 1440
+Pinging 8.8.8.8 with 1440 bytes of data:
+Reply from 8.8.8.8: bytes=1440 time=8ms TTL=116
+Reply from 8.8.8.8: bytes=1440 time=8ms TTL=116
+Reply from 8.8.8.8: bytes=1440 time=8ms TTL=116
+Reply from 8.8.8.8: bytes=1440 time=8ms TTL=116
+</code>
+----
+<code dos>
+C:\Users\Administrator>ping 8.8.8.8 -f -l 1440
+Pinging 8.8.8.8 with 1440 bytes of data:
+Reply from 8.8.8.8: bytes=1440 time=8ms TTL=116
+Reply from 8.8.8.8: bytes=1440 time=8ms TTL=116
+Reply from 8.8.8.8: bytes=1440 time=8ms TTL=116
+Reply from 8.8.8.8: bytes=1440 time=8ms TTL=116
+</code>
+**Technical Explanation:**
+The parameter `-l` in Windows `ping` specifies only the ICMP payload (data).
+But the real MTU also includes protocol headers:
+  * **20 bytes** → IP header (source/destination IP, TTL, checksum, fragmentation flags).
+  * **8 bytes**  → ICMP header (type, code, checksum, sequence).
+Therefore:
+  Real MTU = Payload (-l) + 20 + 8
+  Example: `1440 + 28 = 1468` → Real MTU = **1468 bytes**
+👉 This is why you must always add **28 bytes** to the `-l` value to obtain the true MTU on the link.
+----
+{{ :networking:set-default-mtu.png?600 |}}
+{{ :networking:set-default-mtu -2.png?600 |}}
+{{ :networking:set-default-mtu -3.png?600 |}}
+{{ :networking:set-default-mtu -4.png?600 |}}
+{{ :networking:set-default-mtu -5.png?600 |}}
+**Command to test jumbo frame packets (9000 Bytes) in an Esxi 7.0**
+{{ :networking:set-default-mtu-vmware-7.png?600 |}}
 [[info.support.huawei.com/info-finder/encyclopedia/en/MTU.html|What Is Maximum Transmission Unit (MTU)?]]
@@ Line 49: / Line 133: @@
 The total size of this kind of packet will be 1524 bytes, exceeding the 1500 bytes MTU value. The “data” size in this packet is 1460, but we can and should decrease it in order to make sure the total size will be 1500 bytes or less. And this is where TCP MSS comes into the picture.
-TCP MSS, the maximum segment size, is a parameter of the options field of the TCP header that specifies the largest amount of data, specified in bytes, that a computer or communications device can receive in a single TCP segment. It does not include the TCP header or the IP header. This value will dictate the maximum size of the “data” part of the packet. In the following case for the GRE tunnel, we will set the tcp mss value to be 1436 or lower, while the default size is 1460.
+**TCP MSS, the maximum segment size**, is a parameter of the options field of the TCP header that specifies the largest amount of data, specified in bytes, that a computer or communications device can receive in a single TCP segment. It does not include the TCP header or the IP header. This value will dictate the maximum size of the “data” part of the packet. In the following case for the GRE tunnel, we will set the tcp mss value to be 1436 or lower, while the default size is 1460.
 The MSS announcement (often mistakenly called a negotiation) is sent during the three-way handshake by both sides, saying: “I can accept TCP segments up to size x”. The size (x) may be larger or smaller than the default. The MSS can be used completely independently in each direction of data flow.
@@ Line 98: / Line 182: @@
 A common mistake is to configure the “ip tcp mss-adjust 1420” command on the tunnel interface of the customer. The reason it doesn’t work is because the SYN packets that are sent from the server toward the end user are not going via the GRE tunnel interface, but via the original ISP’s interface.
+----
+----
+{{ :cisco:switch:9500:mtu_utm_switch_6400_9500.pdf |}}
+{{pdfjs 46em >:cisco:switch:9500:mtu_utm_switch_6400_9500.pdf }}
+----
+----
+----
+----