パケットドロップの発生について

こんにちは。

現在、専用線にて他社とEDIを行っています。
こちらからデータを全銀TCP/IPにて送信しています。

まれに通信障害が発生し、先方からはパケットがドロップしている
と回答がありました。
提示された通信トレースをみると、確かにTCPでフラグメントされた
最後の数バイトが欠けていました。

こうした障害はどのような場合に起こるのでしょうか？
通信途中に壊れてしまったり、形を変えてしまったりして、正しく
ないパケットになってしまうことがあることは認識しておりますが、
定期的に発生するわけではなく、月に2、3度です。

まず、何を疑い、どのような改善を施せばよいのでしょうか？
原因を追究できる良い手段はありますか？

情報有りましたら、よろしくお願いします。

No.4 回答者： junkUser 回答日時： 2009/12/01 05:10

> 先方も私もOSがMTUに合わせて複数のパケットに分けることを

> フラグメントと誤って解釈して、話が進んでいたようです。

フラグメントパケットがドロップされた通信障害だと思いこんでいましたが、これだと調べる範囲が変わってきますね。
根本に立ち返りますが・・・通信障害はどのように発見されたでしょうか？

タイムアウト・・・TCPに問題
データ異常・・・ソフトウェアに問題
　　　　アプリケーション、ネットワークドライバなどOSより上の領域で不具合

TCP のレイヤーで異常があれば、再送リクエストが送られます。
再送リクエストでもパケットを受け取ることができなければ、タイムアウトします。
アプリケーション側から見れば、TCP 異常は通信タイムアウトとして処理されます。
逆に、再送リクエストが無いのであれば、TCP に異常は無いと解釈できます。


> ウインドウサイズの影響で、パケット1から4までが途中で異常となら
> ず送信されていると考えられるでしょうか？

その通りです。

この回答への補足

どうもありがとうございます。

エラーの発生は、通信時、アプリケーションが通信エラーコード
を返したことで判明しました。
（相手から強制的に切断された）
このエラーがTCPタイムアウトだったかどうかは、残念ながら不明
です。
そして、先方から前述の回答がありました。

先方からは「パケット1から4までの長さと、アプリケーションの制御
ヘッダ部分に格納されている、全体のレコード長と差異があるため
にエラーとなった」とのことでした。

どこでパケットが欠けてしまったかは、原点に戻り、TCPなのかアプリ
なのか、それぞれのトレースを双方で確認したいと思っています。

補足日時：2009/12/01 12:12

No.3 回答者： junkUser 回答日時： 2009/11/30 10:03

●回答の前提条件

　フラグメントの後ろのパケットが先に届いてドロップするのは、通信障害の原因として考えられる１つではありますが、今回の件もこれが原因と確定したわけではありません。
　原因調査は別途行う必要があります。

●本題
> 現在、アプリ側で設定しているテキスト長がイーサネット標準MTU
> の1500を上回っています。（実際は5000以上）

えーと・・・テキスト長が 5000 で、MTUを上回っていた場合、OS自身が複数のパケットに分けるので問題ありませんよ。（これはフラグメントではありません。）
OSの送信したMTU 1500 のパケットが通信経路を通過する過程で分割されるのがフラグメントです。

>>「フラグメント化した後ろのパケットのほうが先に届いている」
> この件について、下記のサイトでは、到着順が前後しても相手先の
> コンピュータで再構成される（「IPパケットの再構成」）ようなこと
> が書かれていますが、どうなのでしょうか？

たとえば、フラグメント パケットを許容しないルーターが経路中にあったり、数年前の Firewall-1 のようにパケットを再構成させずに打ち落とす間抜けなファイアウォールであれば、フラグメント パケットの後部が打ち落とされます。したがって「必ず再構成される保障は無い」と思っていたほうがいいです。

送信元が Windows Server 2003 ならば MTU の変更は簡単ですね。
具体的な値については環境によるとしか言えませんが、たとえばですが、Googleでは通信障害を起こさないようにするため、MTU 値を 1400 に設定しています。なので、Microsoft にはつながらないのに Google だけは表示されるといった現象がまま発生します。

この回答への補足

どうもありがとうございます。

先方から提示されたトレースでは、
当方から約4500バイトのデータを送信し、
パケット1 約1400バイト受信
パケット2 約1400バイト受信
パケット3 約1400バイト受信
パケット4 約300バイト受信
このうちパケット1とパケット2が数バイト欠けているというものでした。

先方も私もOSがMTUに合わせて複数のパケットに分けることを
フラグメントと誤って解釈して、話が進んでいたようです。

そうですね、原因調査はいずれ時間を絞ってやらなければならないと
思います。

最後の質問となりますが、
先方にはパケット1から4まで届いています。
ですが、パケット1で全てのデータが届かなかったということならば
そこでTCPのエラーとなり、通信が異常終了する気がします。
正確にはパケットトレースを見ない限り分からないと思いますが、
ウインドウサイズの影響で、パケット1から4までが途中で異常となら
ず送信されていると考えられるでしょうか？

よろしくお願いいたします。

補足日時：2009/11/30 23:49

No.2 回答者： junkUser 回答日時： 2009/11/28 04:36

> フラグメントが発生することで、通信エラーが起こりやすくなることはあるのでしょうか？

よくあります。
No.1 で例示した、「フラグメント化した後ろのパケットのほうが先に届いている」がそれです。
フラグメント化した後ろのパケットの方が先に届いてもOSは処理できないので無視しますし、ファイアウォールでも遮断してしまいます。

余談ですが、フラグメントの仕様は1990年代から問題視されており、IPv6からはフラグメントを廃止し、初めから最適なパケットサイズで送信するよう仕様が変更されました。したがって、IPv6ではこのような通信障害が起きません。

> フラグメントが発生しないように適切なパケットサイズとするよう、アプリで制御した方が良いような内容のものを見つけました。

MTU 調整、やMTU 変更で検索してみてください。
MTUを調整することでフラグメント化しないパケットサイズにすることができます。
OSが何か分からないので回答はできませんが、どんなOSでも設定方法があるはずです。

この回答への補足

どうもありがとうございます。

受け側はWindows 2003 Serverです。
現在、アプリ側で設定しているテキスト長がイーサネット標準MTU
の1500を上回っています。（実際は5000以上）
ですのでTCPフラグメントが確実に発生している状況です。
このあたりも見直す必要がありそうです。

今まで同一LAN上のPCとのEDIがメインでした。
TCPフラグメントは基本的にルータが行うということのようですので、
テキスト長を大きくしても問題にならなかったのかもしれません。

>「フラグメント化した後ろのパケットのほうが先に届いている」
この件について、下記のサイトでは、到着順が前後しても相手先の
コンピュータで再構成される（「IPパケットの再構成」）ようなこと
が書かれていますが、どうなのでしょうか？
もし、補足等あればお願いします。
http://www.atmarkit.co.jp/fwin2k/network/baswinl …

よろしくお願いいたします。

補足日時：2009/11/29 23:56

No.1 回答者： junkUser 回答日時： 2009/11/27 19:18

地道に問題の通信経路を絞り込んでいくしかないでしょう。

最低2地点を同時にモニターして、どこまでは通った・通っていないを抑えていきます。
月に2,3度しか無いので時間がかかりそうです。

後は、本当に「月に2,3度しか無いのか？」という点です。
問題が顕在化したのが2,3度ということではないでしょうか？
TCP/IPは通信に異常があれば数回再送リクエストをおくるため
多少遅くなっても正常に通信できる仕様になっています。
つまり、数回の再送リクエストを超えて失敗していると考えることができるため、パケットのドロップはもっと頻繁にあるのではないかと思われます。

＞こうした障害はどのような場合に起こるのでしょうか？
羅列すると
・フラグメント化した後ろのパケットのほうが先に届いている
　ネットワークの負荷が上がると回復するという事象が起きます。
・コンピュータ自身のドライバーに問題がある
・経路中のケーブル、HUBに問題がある
　ケーブルに問題があったら、フラグメントに関係なく発生しそうですが・・・
・ルーターのファームウェアに問題がある
　たとえば、Yamaha RT 1000 の一時期のファームで、通信が輻輳するとキューに溜め込みすぎてドロップしてしまう不具合がありました。
　ファームウェアのアップデートで解決しました。

とりあえず、フラグメントパケットが発生しないように、送信元のコンピュータでMTUを調整してみてはいかがでしょうか。

この回答への補足

どうもありがとうございます。

双方でトレースを仕掛ける必要があるということで、合意はしている
のですが、時間帯などが絞りきれず、なかなか実現できていません。

ところで、フラグメントが発生することで、通信エラーが起こりやす
くなることはあるのでしょうか？

ネットで情報を集めていると、フラグメントが発生しないように
適切なパケットサイズとするよう、アプリで制御した方が良いような
内容のものを見つけました。

もし、情報がありましたらよろしくお願いいたします。

補足日時：2009/11/27 23:10