Differences

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

--- networking:mtu [2025/09/11 00:32] – aperez
+++ networking:mtu [2025/10/04 15:48] (current) – aperez
@@ Line 41: / Line 41: @@
 </code>
+----
+<note tip>
+**MTU & PMTU Validation (side note)**
+Quick reference on how to confirm the effective MTU and Path MTU (PMTU) end-to-end. Use these tests when enabling jumbo frames or troubleshooting connectivity.
+----
+**1) ICMP Check with ping**
+Command:
+<code bash>
+ping -M do -s 1472 8.8.8.8
+</code>
+Expected output (OK, MTU 1500):
+<code>
+PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
+bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=8.0 ms
+bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=7.9 ms
+--- 8.8.8.8 ping statistics ---
+packets transmitted, 2 received, 0% packet loss
+</code>
+👉 If **1472 passes**, effective MTU ≈ **1500**.
+👉 If it fails (e.g., *Frag needed*), the link is forcing MTU <1500.
+----
+**2) Path MTU Discovery with tracepath**
+Command:
+<code bash>
+tracepath -n 8.8.8.8
+</code>
+**Case A — Standard network (PMTU 1500):**
+<code>
+: 192.168.1.1          0.45ms
+: 192.168.1.1          0.39ms pmtu 1500
+: 10.10.10.1           3.21ms
+: 8.8.8.8              7.84ms reached
+     Resume: pmtu 1500 hops 3 back 3
+</code>
+**Case B — Jumbo end-to-end (PMTU ~9000):**
+<code>
+: 10.0.0.1             0.22ms
+: 10.0.0.1             0.21ms pmtu 9000
+: 172.20.0.1           0.95ms
+: 8.8.8.8              6.74ms reached
+     Resume: pmtu 9000 hops 3 back 3
+</code>
+👉 If you see **`pmtu 1500`**, the path is limited to standard frames.
+👉 If you see **`pmtu 9000`** (or similar), jumbo frames are preserved across the path.
+👉 If it drops (e.g., 9000 → 1500 mid-path), a hop does not support jumbo.
+----
+**Validation summary**
+^ Test                  ^ Expected outcome                           ^
+| `ping -M do -s 1472`  | Successful reply ⇒ effective MTU ≈ 1500    |
+| `tracepath -n`        | Reports PMTU 1500 (standard) or 9000 (jumbo)|
+</note>
 ----
@@ Line 88: / Line 156: @@
+----
+> **Note: PMTU and PMTUD (Path MTU / Path MTU Discovery)**
+The *Path Maximum Transmission Unit (PMTU)* is the **largest IP packet size that can travel end-to-end without fragmentation**.
+It is determined by the **smallest MTU along the entire path**.
+Example:
+  * Link 1: MTU = 9000
+  * Link 2: MTU = 1500
+  * Link 3: MTU = 1400
+  → **PMTU = 1400 bytes**
+---
+**Path MTU Discovery (PMTUD):**
+A dynamic mechanism to discover the PMTU using the **DF (Don’t Fragment)** bit.
+Steps:
+  - Source sends a large packet with DF=1.
+  - If a router cannot forward due to its MTU, it discards the packet and replies with ICMP *Fragmentation Needed* (Type 3, Code 4).
+  - The source reduces the size until it learns the **real PMTU**.
+---
+**Verification on Linux**::
+  ping -M do -s 1472 8.8.8.8
+    → If it replies: path supports 1500 (1472+28 headers).
+    → If it fails: PMTU is smaller.
+  tracepath -n 8.8.8.8
+    → Displays estimated PMTU along the route.
+---
+**Common pitfalls**
+  * Blocking ICMP → breaks PMTUD (TCP sessions may hang).
+  * Tunnel/VPN overhead → reduces MTU (e.g., IPSec 1500 → ~1400).
+  * Misconfigured Jumbo Frames → one 1500 hop breaks 9000 end-to-end.
+---
+**In summary:**
+  * **PMTU** = max packet size without fragmentation.
+  * **PMTUD** = process to dynamically discover it using ICMP + DF.
@@ Line 182: / Line 296: @@
 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 }}
+----
+----
+{{ :aruba_networks:switch:6400:mtu_pmtu.pdf |}}
+{{pdfjs 46em >:aruba_networks:switch:6400:mtu_pmtu.pdf}}
+----
+----