- - PR -
TCPチェックサムエラーの発生について
1|2|3
次のページへ»
投稿者 | 投稿内容 |
---|---|
|
投稿日時: 2006-07-13 02:39
はじめまして。実務で発生している障害について、皆様のお知恵を拝借させて頂きたく投稿致します。
1)障害内容 STRATUS社製マシン(独自OS)とCatalyst4507R間にて、TCPチェックサムエラーとなるフレームが頻繁に検出される。 2)想定原因 STRATUS側がオートネゴシエーション、SW側が10M全二重固定となっているため、STRATUS側のデュプレックスモードが半二重で通信が行われている。 そのため、STRATUSがフレームを送出中にSW側からフレームを受信した際、STRATUSがコリジョンを検出して送出を中止し、その結果中途半端に送出されたフレームがチェックサムエラーとしてSW側で認識される。 上記原因を実証するため、再現試験を試みていますがなかなか再現ができません。 STRATUS側を明示的に半二重固定、SW側を全二重固定で通信を行うとSTRATUS側でコリジョンの発生を認識している(netstatで確認)ようですが、SW上でトレースをかけても本番障害と同じようなチェックサムエラーフレームが確認できません。 ちなみに、負荷度は、秒間1,000フレーム前後、開発環境のSWはCatalyst2950となります。 このようなケースを意図的に再現するために考えられる方法をご存知の方がいらっしゃいましたら、どなたかご教授頂きたく、お願い致します。 [ メッセージ編集済み 編集者: kuro 編集日時 2006-07-13 02:43 ] |
|
投稿日時: 2006-07-13 08:06
おはようございます。
用途があっているかちょっと自信がないのですがアナライザーかスマートビット辺りの測定器でできそうな来もしますが、実機間の問題ならだめかもしれないです。 はずしていたらごめんなさいm(_ _)m |
|
投稿日時: 2006-07-13 20:24
イーサネットレベルで衝突して壊れたフレームは、FCSが不正なので、
受信されずにそのまま捨てられます(ふつうは)。ので、上位のTCPチェックサム エラーになることは考えられないのですが、いかがでしょうか? |
|
投稿日時: 2006-07-13 22:10
Uchikoshi さんの意見に一票。
Catalyst4507R の機能とか、どんな処理をしているか分かりませんが、普通の SW-HUB ではなくて、NAT のようなパケットを書き換える処理を行っているのでしょうか? また、通信の相手は、Catalyst なのでしょうか?(SNMP とか?) Catalyst が、問題の中に出てくる理由をいまひとつ分かりませんでした。 個人的な印象では、送信側の機器、ドライバ、プログラムに問題があるような気がしますが。 頻繁におこるなら、hidekipo さんの言うように現地でアナライザを使うのもいい気がします。 |
|
投稿日時: 2006-07-13 22:17
hidekipoさん、Uchikoshiさん、ご回答ありがとうございます。
調査方法についてですが、SWにLANアナライザを接続し、STRATUS-SW間のポートのトレースを取得して現象を把握しています。この際、アナライザはSWで破棄されるフレームも含め、全てのフレームを記録しています。 アナライザで取得したトレースをEtherealで照会すると、問題のフレームには確かにFCSを含んでいません(後半が欠けているため)。Ethereal上では、そのようなフレームはTCP Checksum Incorrectと表示されているようです(データが欠けているため、Etherealが計算したTCPチェックサムと実際のチェックサム値が異なる)。 上記の理由でTCPチェックサムエラーと言ってしまったのですが、正確にはCRCエラーとかFCS不正と言うほうが正しいかもしれません。 私はネットワーク専門ではないのであまり詳しくないのですが、個人的に調べたところでは全二重・半二重相違による通信障害というのは典型的な障害のように見受けられ、意図的にこのような設定をしてテストをすれば簡単に欠損フレーム発生を再現できると考えていたのですが、実際にはSTRATUS側でコリジョンを検出しているにもかかわらずどうしても事象の再現ができずにいます。 引き続き、ご意見、ご指摘などありましたら何卒宜しくお願い致します。 |
|
投稿日時: 2006-07-13 22:28
わちゃさん、書き込みありがとうございます。
物理的に直接通信をする相手がCatalystになります。実際には、その先にある機器とTCP通信をしています。 >個人的な印象では、送信側の機器、ドライバ、プログラムに問題があるような気がしますが。 ご指摘のように、デュプレックスモードの相違以外で疑っている点としては、物理的な機器(NIC)やケーブルなどを考えています。但し、システムエラーログなどを見る限り正常に動作しているように見受けられるため、可能性は低いと考えています。 試験環境でもう少しトライした後、障害が発生した環境で(同一機器、ドライバなどで)試験を行おうと考えています。 |
|
投稿日時: 2006-07-13 22:51
フレーム欠損であれば、確かに Catalyst と STRATUS の問題かもしれませんね。
ただ、全二重、半二重だと考えられているのであれば、再現試験をするよりも、どちらも全二重か、オートネゴにして、問題が解決するかを調べてもいい気がします。 一応、確認事項 1.今回の件は、STRATUS が Catalyst に向かって送ったパケットで起きている障害ですよね。 2.本番環境、試験環境どちらも STRATUS はコリジョンを検出しているのですよね? で、全然、外してそうですが考えられそうなのを、、、 1.MTU の設定が違うとか? 2.Catalyst2950 と Catalyst4507 でダメパケットに対する処理が違うとか、、 どっちも、可能性は薄そうですが ^^; |
|
投稿日時: 2006-07-13 23:33
>ただ、全二重、半二重だと考えられているのであれば、再現試験をするよりも、どちらも全二重か、オートネゴにして、問題が解決するかを調べてもいい気がします。
そこなんですが・・・両方全二重、または両方オートネゴにすると当然のようにうまくいくのですが、STRATUS=AUTO、SW=全二重でもなんら問題なく通信できているように見えており、頭が痛いのです(双方全二重と動作的に違いが見受けられない)。 >1.今回の件は、STRATUS が Catalyst に向かって送ったパケットで起きている障害ですよね。 そのとおりです。CRCエラーは全て、STRATUS→SW方向でした。 >2.本番環境、試験環境どちらも STRATUS はコリジョンを検出しているのですよね? ちょっとややこしいかもしれませんが、 1)本番環境では、netstatコマンドを叩く機会が無かったため、コマンドでのコリジョン発生は確認していません。トレース上でCRCエラーパケットの頻発を確認しているのみです。 ちなみに、障害についてさらに詳しく言うと、トラフィックの少ない時間帯ではまったく問題が表面化せず、多くなるとCRCエラーを契機としてアプリケーションで通信障害を認識する、という事象です。 2)開発環境では、@STRATUS=半二重、SW=全二重と明示的に設定した場合はコマンドでのコリジョン発生を確認できています。但し、ASTRATUS=AUTO、SW=全二重の設定上では、コリジョン発生は確認できていません(CRCエラーは何れも確認できていません)。 そもそもですが、STRATUS=AUTO、SW=10M全二重固定とした場合、(STRATUSメーカサイドの回答として)STRATUSは10M半二重で通信を行う仕様である、というのが前提となっています(STRATUS上、採用されているデュプレックスモードが何かを確認するコマンドがないとのこと)。 前述@で発生して、Aで発生しないということは、Aでも全二重で通信されているのではないかと疑っていますが、その前段階として、@設定でなんとか欠損フレームの再現をしようとしている状態です。 >1.MTU の設定が違うとか? STRATUSとSW間で、ということでしょうか?因みに、STRATUSのMTUは1500固定となっています。 >2.Catalyst2950 と Catalyst4507 でダメパケットに対する処理が違うとか、、 実は、これもちょっと疑っているのですが・・・実際、ありうる話でしょうか?(素人なもので・・・^^;)メーカーとかに聞いてみる価値があれば、確認してみようと思います。 ところで、ひとつ質問があります。 オートネゴの場合、速度とデュプレックスモードはNIC同士がLINK UPしたタイミングでFLPという信号をやりとりすることで行う、と理解していますが、この信号をアナライザその他でトレースをとることはできないでしょうか?実際に全半二重どちらで通信しているのかを確認したいと思っているのですが・・・ 皆様のご協力感謝致します。m(_ _)m |
1|2|3
次のページへ»