让我们在由运行Shorewall生成的iptables规则的Debian路由器隔开的两个Debian主机之间进行一些路径MTU发现。两个主机中的每一个都使用单个以太网链路，而路由器在两个聚合的以太网链路上使用带标记的VLAN。

使用scamper：

root@kitandara:/home/jm# scamper -I "trace -M 10.64.0.2"
traceroute from 10.1.0.5 to 10.64.0.2
 1  10.1.0.1  0.180 ms [mtu: 6128]
 2  10.64.0.2  0.243 ms [mtu: 6128]


好：6128字节是预期的结果（便宜的Realtek以太网适配器无法处理大小合适的巨型帧）。

现在，让iperf执行吞吐量测试并通过方式告诉我们有关MTU的信息。 ：

root@kitandara:/home/jm# iperf -c 10.64.0.2 -N -m
------------------------------------------------------------
Client connecting to 10.64.0.2, TCP port 5001
TCP window size: 66.2 KByte (default)
------------------------------------------------------------
[  3] local 10.1.0.5 port 59828 connected with 10.64.0.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1011 MBytes   848 Mbits/sec
[  3] MSS size 6076 bytes (MTU 6116 bytes, unknown interface)


6116个字节？为什么？

现在，对于完全不同的内容，让我们看看该会话的流量实际包含的内容：

root@kitandara:/home/jm# tshark -i eth0 -R "(ip.dst == 10.64.0.2) || (ip.src == 10.64.0.2)" | head
Capturing on eth0
  1.308557     10.1.0.5 -> 10.64.0.2    TCP 74 60310 > 5001 [SYN] Seq=0 Win=5340 Len=0 MSS=534 SACK_PERM=1 TSval=101928961 TSecr=0 WS=16
  1.308801    10.64.0.2 -> 10.1.0.5     TCP 74 5001 > 60310 [SYN, ACK] Seq=0 Ack=1 Win=18328 Len=0 MSS=6088 SACK_PERM=1 TSval=3764064056 TSecr=101928961 WS=64


6088字节MSS，这意味着6128 MTU ...好。但是，为什么iperf为什么宣布6116字节的MTU？

那时，全面性要求我们仔细研究一下Scrap跟踪会话期间发生的情况：

root@kitandara:/home/jm# tshark -i eth0 -R "(ip.dst == 10.64.0.2) || (ip.src == 10.64.0.2)"
Capturing on eth0
  0.000000     10.1.0.5 -> 10.64.0.2    UDP 58 Source port: 43870  Destination port: 33435
  0.000175     10.1.0.1 -> 10.1.0.5     ICMP 86 Time-to-live exceeded (Time to live exceeded in transit)
  0.050358     10.1.0.5 -> 10.64.0.2    UDP 58 Source port: 43870  Destination port: 33436
  0.050592    10.64.0.2 -> 10.1.0.5     ICMP 86 Destination unreachable (Port unreachable)
  0.099790     10.1.0.5 -> 10.64.0.2    UDP 6142 Source port: 43870  Destination port: 33437
  0.100912    10.64.0.2 -> 10.1.0.5     ICMP 590 Destination unreachable (Port unreachable)


所有这些数据包的udp.length均为24，最后两个数据包的udp.length为6108 ...但是然后如何通过散点图告诉我们路径MTU为6128？

6108、6116、6128 ...有这么多MTU可供选择！

评论

有什么答案对您有帮助吗？如果是这样，您应该接受答案，这样问题就不会永远弹出来寻找答案。或者，您可以发布并接受自己的答案。

#1 楼

非常有趣。

MSS（最大段大小）= MTU-IP标头=6076。

6076 + 40 =6116。

Debian使用IP标头中的IP选项字段？那可能是额外的12个字节...

评论

TCP握手是否有可能建立6128字节的MTU，然后iperf一次发现自己未能传输超过6116字节-这将是一种与“官方”无关的经验MTU？

–让·马克·利奥捷（Jean-Marc Liotier）
13年5月16日在10:25
无论使用哪种IP选项，都没有一种填充可以确保长度（IP选项+填充）= 32位吗？

–让·马克·利奥捷（Jean-Marc Liotier）
13年5月16日在10:29
12个字节…不是用“ TCP选项”代替“ IP选项”吗？

–让·马克·利奥捷（Jean-Marc Liotier）
13年5月16日在10:37
我对iperf会话的TCP选项进行了采样：显然总是12个字节（仅时间戳）

–让·马克·利奥捷（Jean-Marc Liotier）
13年5月16日在10:42
在github.com/jasonrm/iperf/blob/中，有一条评论说：“ //跟踪读取的大小->给出MTU大小的指示”；在github.com/jasonrm/iperf/blob/中，有一条评论说：“报告MSS和MTU，给定MSS（或其猜测）”-考虑到iperf应该支持实际的路径MTU发现，这很奇怪。

–让·马克·利奥捷（Jean-Marc Liotier）
13年5月17日在12:02

#2 楼

tshark正在报告以太网帧大小：6142-14（以太网标头）= 6128 IP字节。

scamper在对大数据包进行探测以进行MTU发现之前会先对小数据包进行跟踪路由（这就是为什么看到较小的数据包的原因）数据包之后是一大包）。这有助于区分所有被丢弃/无响应的数据包和仅是大数据包。

https://www.usenix.org/conference/imc-05/inferring-and-debugging-path- mtu-discovery-failures