iperf、scamper、およびパスのMTU検出パケットキャプチャがパスのMTUに同意しないのはなぜですか？

Shorewallで生成されたiptablesルールを実行するDebianルーターによって分離された2つのDebianホスト間でパスMTU検出を実行してみましょう。2つのホストはそれぞれ1つのイーサネットリンクを使用し、ルーターは2つの集約されたイーサネットリンク上でタグ付き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を発表するのですか？

その時点で、スカンパートレースセッション中に何が起こるかを詳しく調べる必要があります。

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が6108である最後の2つを除いて、24のudp.lengthを持っています。

6108、6116、6128 ...非常に多くのMTUから選択できます。

routing ipv4

— ジャンマルク・リオティエ
ソース

何か回答がありましたか？もしそうなら、質問が永遠にポップアップし続けないように答えを受け入れ、答えを探します。または、独自の回答を提供して受け入れることもできます。

— Ron Maupin

回答:

とても興味深い。

MSS（最大セグメントサイズ）= MTU-IPヘッダー= 6076。

6076 + 40 = 6116。

DebianがIPヘッダーのIPオプションフィールドを使用しているのでしょうか？それは余分な12バイトかもしれません...

— ピータータベニエ
ソース

TCPハンドシェイクが6128バイトのMTUを確立し、その後iperfが一度に6116バイトを超える送信に失敗したことを検出することは可能ですか？これは、「公式の」MTUとは無関係の経験的なMTUの一種です。

— Jean-Marc Liotier 2013年

IPオプションが何であれ、長さ（IPオプション+パディング）= 32ビットであることを保証するパディングはありませんか？

— Jean-Marc Liotier 2013年

12バイト…「IPオプション」の代わりに「TCPオプション」を意味していませんでしたか？

— Jean-Marc Liotier 2013年

私はiperfセッションのTCPオプションをサンプリングしました：明らかに常に12バイト（タイムスタンプのみ）

— Jean-Marc Liotier

github.com/jasonrm/iperf/blob/…のコメントには「//読み取りサイズを追跡-> MTUサイズの表示」とあり、github.com / jasonrm / iperf / blob /…には「レポートMSS（またはその推測）を考慮したMSSおよびMTU」-iperfが実際のパスMTUディスカバリーをサポートすることになっていることを考えると奇妙です。

— Jean-Marc Liotier 2013年

tsharkがイーサネットフレームサイズを報告しています：6142-14（イーサネットヘッダー）= 6128 IPバイト。

scamperは、MTU検出のために大きなパケットでプローブする前に、小さなパケットでtracerouteを実行します（そのため、小さなパケットに続いて大きなパケットが表示されます）。これは、破棄される/応答しないすべてのパケットと大きなパケットだけを区別するのに役立ちます。

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

— マシュー・ラッキー
ソース