よかろうもん!

アプリからインフラまで幅広くこなすいまどきのクラウドエンジニアが記す技術ブログ

MTU(Maximum Transfer Unit)を確認するには?

以前のエントリ『MTUを変更するには』で、MTUの変更方法を紹介しました。
変更をしたものの、本当にその設定が反映されているかどうかを確認する方法を今回は紹介します。

サーバのMTUを大きくしても、途中の経路のMTUがサーバで設定した値よりも小さかったら、途中でフラグメント(パケット?の分割)が発生してしまい、転送効率が落ちてしまう事態に陥ることだってあります。
このような事態にならないようにするためにも、MTUの設定を変更する前の事前確認、設定変更後の通信相手までの経路の最小MTUを確認しておくことは大切です。

確認の際はpingコマンドを利用します。

$ ping -c [送信回数] -s [データグラムサイズ] -M do [宛先ホストIP]

ちなみにpingコマンドの -M オプションには、do、dont、wantが指定可能なようです。

ーM hint
Select Path MTU Discovery strategy.
hint may be either
do (pro-hibit fragmentation, even local one),
want (do PMTU discovery, fragment locally when packet size is large), or
dont (do not set DF flag).

簡単な解説をかいておきます。

  • do : フラグメントを一切禁止
  • want : ローカルの場合のみフラグメントし、それ以外は禁止
  • dont : フラグメント禁止フラグ(DF)をセットしない

通信相手までの経路において、最小MTUよりも大きなパケットが送信された場合、DFフラグがセットされていればパケットが途中で破棄されてしまいますが、DFフラグがセットされていなければ、最小MTUのネットワーク機器にデータを送信するネットワーク機器がパケットをフラグメントして、最小MTUの範囲に収まるようにしてからデータを転送します。

それでは、通信経路の全ネットワーク機器およびサーバのMTUを9000に設定し、経路の最小MTUを検出してみます。

サイズが9000以上のパケットを送信した場合

$ ping -c 1 -s 14972 -M do 192.168.1.33
PING 192.168.1.33 (192.168.1.33) 14972(15000) bytes of data.
From 192.168.1.35 icmp_seq=0 Frag needed and DF set (mtu = 9000)

--- 192.168.1.33 ping statistics ---
0 packets transmitted, 0 received, +1 errors

DFフラグがセットされているため、エラーになっています。
また、このエラーからMTUは9000であることわかります。
今回パケットが破棄されたネットワーク機器が通信相手までの経路の中で最小のMTUかどうかは、パケットサイズを9000にして、再度pingコマンドを発行する必要があります。

$ ping -c 1 -s 8972 -M do 192.168.1.33

PING 192.168.1.33 (192.168.1.33) 8972(9000) bytes of data.
8980 bytes from 192.168.1.33: icmp_seq=0 ttl=255 time=0.890 ms

--- 192.168.1.33 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.890/0.890/0.890/0.000 ms, pipe 2

エラーもなく、通信相手までサイズが9000のパケットを送信できたので、通信相手までの経路において、最小MTUが9000であることが確認できました。