Path MTU Discovery

「インターネットにつながらない」とか、「遅い」という状況はよくあります。ただ「完全につながらない」とか「いつも遅い」とかではなく、「特定のサーバーのみ通信ができない」とか、データが大きいと通信できない、というような不可解な現象が起きる場合もあります。もしかするとそれは、「Path MTU Discoveryブラックホール」現象かもしれません。
（参照サイト：http://plusd.itmedia.co.jp/broadband/0302/19/lp22.html　）

まず、Path MTU Discoveryのしくみはこちらが詳しいでしょう。http://www.itbook.info/study/p3.html　たとえばクライアント⇔サーバ間の通信路中にMTUの小さい経路があった場合にMTUを調整するための機能です。具体的には、たとえばサーバが大きいサイズ（1500Bytesなど）のパケットをDF（Don't Fragment）フラグ付きで流します。そうすると、上位の機器（ルータなど）から、「MTUをこの値にしないと送れないよ」という旨を示すICMPエラーが返ってくるので、サーバはMTUをその値に調整してパケットを送りなおします。

ただ、途中の経路のファイアウォールなどでICMPを止めてしまう、ということもけっこうあります。その場合、正しい通信ができず、通信がタイムアウトしてしまいます。（端末がICMPエラーを待たずに小さいMTUで送るような場合には通信可能ですが、その場合通信は遅くなるはずです）

回避策ですが、たとえばWindowsサーバではhttp://support.microsoft.com/kb/314825/ja　など紹介されているようにいくつかの回避法があります。

たとえばレジストリで”EnablePMTUBHDetec”tを有効にすると、一定時間ICMPに応答がなければTCP はセグメントを複数回再送しても ACK が返されない場合に、Don't Fragment ビットをセットせずにセグメントを送信します。セグメントに対する ACK が返された場合は、MSS の値を小さくし、接続でその後送信されるパケットに Don't Fragment ビットをセットします。ブラック ホール検出を有効にすると、特定のセグメントに対して実行される再送の最大回数が増加します。http://support.microsoft.com/kb/314053/ja　も参考になりますね。

他の方法は「ルータやファイアウォールでICMPのDFが通過できるようにする」「サーバ側でMTUを調整する」といった方法です。

この状況、以前はPPPoE環境とかでよく起きていたみたいです。確かに、PPPoEの場合には通常のイーサネット通信と比較してPPPoEヘッダの分だけIPパケットの分が小さくなる、というのもありますが、Bフレッツとかだともうちょっと小さいようです。ただまぁ、いまどきのブロードバンドルータであればそのあたりは自動調整してくれるのであまり問題はなさそうですが。（参照サイト：http://homepage2.nifty.com/oso/faq/mtu-faq.html）

そういえば、PPPoE環境ではルータ側でMTU(MSS)を書きかえるのでそもそもPath MTU　Discoveryさえ発生しないことが多いと思いますが、ぢろーらもがだいぶ前に検証を行なった際、VPN環境で使っているときにPath MTU Discoveryが発生し、途中の機器がPath MTU Discoveryを止めていたため通信ができなくなったことはありました。

たとえばYAMAHAルータだと、http://www.rtpro.yamaha.co.jp/RT/docs/flash/vpn-20040412.swf　のの52ページにもあるように、VPNの場合のMTU初期値は1280です。他にもこれに近い設定のルータはあるかと思います。そのときは確か、ルータ側でパケットキャプチャを見たところ、サーバは1500のパケットを送信していて、ルータでICMPエラーを返していることも確認できました。

で、ICMPエラーを止めているネットワーク機器でPath MTU Discovery関連の設定箇所を確認するまで時間がかかってしまったので、その際はサーバ側のMTUを調整して回避しました。

ちなみに、昔はWindowsでもMTUの自動調整機能はなかったようですね。http://www.geocities.jp/sugachan1973/doc/funto27.html

あと、別の方法としては「DFフラグに関係なくルータで強制的にフラグメントする」という方法もありますが、それだとパフォーマンスが落ちてしまいます。もっとも、それをやらないためのPath MTU Discoveryですしね。

まあ、最近はあまり問題になったケースは聞かないです。問題になること自体減ってきたのかなぁ？
　
ちなみに、IPv6の場合についてもいくつかのサイトを調べてみました。

（参照サイト

　http://www.atmarkit.co.jp/fnetwork/rensai/ipv6-03/ipv6-01.html

　http://itpro.nikkeibp.co.jp/article/COLUMN/20071009/284087/

　http://www.n-study.com/kyo/archives/2005/07/ipip.html　など）

IPv6の場合には基本的にはフラグメント自体しないようです。少なくとも、途中のルータにはフラグメントはさせません。この場合、パケット長（MTU)の調整は通常はPath MTU Discoveryを使うようですね。むしろIPv4よりも積極的にやるのか・・・。

Path MTU Discoveryをサポートしてない場合で、MTU制限を超えるパケットを送信する必要がどうしてもある場合には、端末側でIPv6の拡張ヘッダを使います。

いずれにせよ、IPv6が主流になるのであれば、途中経路のルータやファイアウォールなども、基本的にはPath MTU Discoveryを通す流れになるんでしょうね。

---

この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

---