MTUの設計

最近MTUの設計方法をド忘れしていたので、備忘録を残しておきます。

MTUとは1フレームで送信できるデータの最大値を示す伝送単位であり、一般的に使われるイーサネットであればイーサネットフレームの最大値である1518byteからEthernetヘッダ ( 14byte ) と FCS ( 4byte ) は除くため、IPとして通信できるサイズは1500byteとなります。

基本的にはこのMTUサイズが大きければ大きいほど、一度に送信できるデータ量が増えるため、（間の経路でフラグメントを考慮しなければ）通信の効率化が見込めます。そのため、間の経路でPPPoEやカプセル化などのヘッダ追加がないのであれば、実際に機器に設定するMTUも1500にしておけば問題ありません。実際にはローカル環境でない限り1500にすることはあまり無いと思います。その理由はMTUの最適値が間の経路を含めた最小値になるためです。MTUより大きなサイズのパケットがくるとフラグメント化して送信する必要があり、フラグメントの処理はハードウェア処理ではなくソフトウェア処理になってしまい、断片化したパケットを元に戻すのにも処理が必要で負荷が高くなるためです。

例えばGreヘッダは24byteの構成要素があるため、MTUの計算は-24しなければならず1476byteとなります。つまり実際に一度に送れるデータ量が1456byteです。

また、MTUサイズはフラグメントを避けるために小さくすれば良いか？と問われると答えはそうではありません、フラグメントを禁止したパケットがドロップしてしまうためです。このドロップを防ぐためにはいくつかの方法が存在します。

「mtu path discovery」という機能を使えばパケットサイズが超過していた場合に、フラグメントせずに済むサイズで再送するように要求を行うことが出来ます。ただし、mtu path discovery機能はICMPを使用するため、ルータのACLやFWでICMPが全て無効になっていると使うことが出来ません。また、通信を行う相手側（サーバ等）も対応している必要があるため、この機能だけで救えない場合も存在します。

「crypto ipsec df-bit」コマンドを使用すれば強制的にdf-bitを上書きすることも可能です。しかし、各パケットがプロセス レベルで再アセンブルされるため、高いデータ レートでパフォーマンスに大きな影響が生じます。プロセススイッチングによる通信速度低下が起こるうえに、再アセンブル キューが満杯になるとフラグメントが強制的に廃棄されることがあります。また、SSLなどの通信がフラグメント禁止にしているのはハッシュ値が変わることを防ぐためでもあります。これを強制的にフラグメントすることで想定外の挙動になる可能性があります。