您可以使用 tracepath（Linux IPutils 包的一部分）或 mturoute（仅限 Windows）等工具在实时网络中测试路径 MTU 发现。这是上图实验室的 tracepath 输出示例，使用 ip mtu 命令将 F0/1 的 MTU 减少到 1400 字节：

Host$ tracepath -n 192.168.1.2
 1:  192.168.0.2       0.097ms pmtu 1500
 1:  192.168.0.1       0.535ms 
 1:  192.168.0.1       0.355ms 
 2:  192.168.0.1       0.430ms pmtu 1400
 2:  192.168.1.2       0.763ms reached
    Resume: pmtu 1400 hops 2 back 254 

检查支持的 MTU 大小的最简单方法是ping- 前提是您的路由节点支持回显请求/回复。

例如，在 Windows 中，您可以使用ping -f -l 1472 <destination IP>一直检查 1500 字节 MTU 到 . 如果您收到碎片错误或根本没有回复，则目标路径不支持测试的 MTU。

Ping 使用 ICMP 回显请求，ICMP 数据包和封装的 IPv4 数据包导致 28 字节的开销。-l 1472将 1472 字节的测试数据添加到数据包头中，总大小为 1500 字节。该-f选项设置“Don't Fragment”位以避免碎片化（这将隐藏无法整体传输请求的数据包）。显然，要测试其他 MTU 大小，您需要从所需的 MTU 中减去 28 并将其与-l.

一旦确定了给定路径的 MTU 值（请参阅 Maverick 的回答），可能值得寻找ip tcp adjust-mss沿源和目的地之间的路径发生的 TCP MSS 钳制（又名Cisco 说）的痕迹。

为什么？如果测试碰巧是基于 TCP 的，结果可能会因 MSS 钳位而出现偏差。

在普通以太网的典型场景中，发起方（主要称为“客户端”，但 TCP 没有客户端或服务器的概念）在其初始 TCP SYN 段中，将宣布自己的 NIC的 TCP 最大段大小（MSS）- MTU_minus_(TCP+IPv4-Headers)，或 1500 - 40 = 1460（如果使用 TCP 时间戳，则为 1428）。

响应者（“服务器”）也会做同样的事情，从它自己的 NIC 导出最大 TCP 有效负载大小，并在它的 SYN/ACK 段中发送该值。

沿路径互连具有不同 MTU 特性的不同链路/媒体的路由器可以并且将会操纵该值，从而可以避免分段。如果在路径的某些部分（如 PPPoE、GRE 或 IPSec 隧道）上发生进一步封装，这将变得非常重要。

为了观察TCP MSS钳位的效果，你需要能够捕捉到初始SYN和SYN / ACK数据包都initiatior和响应的TCP会话。

如果在同一 SYN 段中，到达响应者时，该值低于离开接收者时的值，则至少有一个路由器（或 L3 交换机或防火墙或 VPN 集中器或...）正在执行 TCP MSS 夹紧。

请务必比较两个方向的值（与同一 tcp 会话的 SYN/ACK 数据包）。PathMTU 本身是单向的，在另一个方向上独立发生，而且给定设备上的 MSS 钳位配置位可以是单向的（只有入口，只有出口，两者）——这取决于供应商。

UDP 没有 MSS 的概念；应用程序知道每个数据包要发送多少字节，或者它依赖于 PMTU 发现和较低 MTU 的提示，并相应地进行调整。但是 IPv4 上的 PMTU 并不是特别出名的可靠。

根据经验，如果我被（应用程序人员，即）问到“我们的网络上有 1400 字节的 MTU 吗？”，我会反问：“1400 是你需要的吗？如果我确认，你会吗？对在无时间戳的 TCP 上每个数据包发送最多 1360 字节的有效载荷和在 UDP 上发送 1372 字节感到满意吗？” 最后，我希望他们根据每个数据包的n 字节有效载荷提出他们的要求，而不是MTU或数据包大小或他们认为的任何单位。