- PR -

TCPチェックサムエラーの発生について

«前のページへ 1|2|3
投稿者投稿内容
holic
ベテラン
会議室デビュー日: 2004/08/24
投稿数: 74
投稿日時: 2006-07-16 21:20
引用:

１）障害内容
STRATUS社製マシン(独自OS)とCatalyst4507R間にて、TCPチェックサムエラーとなるフレームが頻繁に検出される。

２）想定原因
STRATUS側がオートネゴシエーション、SW側が10M全二重固定となっているため、STRATUS側のデュプレックスモードが半二重で通信が行われている。
そのため、STRATUSがフレームを送出中にSW側からフレームを受信した際、STRATUSがコリジョンを検出して送出を中止し、その結果中途半端に送出されたフレームがチェックサムエラーとしてSW側で認識される。


ネゴずれが、TCPチェックサムエラーの根本原因ではないに、一票。

とりあえず、恥ずかしいネゴずれをさっさと直して、症状が続くかどうか確認するとよいでしょう。

＃Stratus と Catalyst が泣きますぜ
Wind
ベテラン
会議室デビュー日: 2004/11/10
投稿数: 73
投稿日時: 2006-07-18 09:53
こんにちは。

改めてスレッドを読み返していたんですが、明示的にWS-C4507RがCRCエラーを検出してるわけではないわけですね？
WS-C4507Rの当該Portのsh intを張っていただけると、解決に近くなるとおもいますが……。

ご質問の件の回答。
SPAN Portでキャプチャしている限り、全てのパケットがキャプチャできる保証はどこにもありません。
特にFull Duplexでの通信をSPAN Portでキャプチャした場合、入出力パケットがひとつのPortに出力されるわけで、キャプチャ対象Portのトラフィックによってはパケット落ちが発生します（入出力合計が120Mbpsだった場合、SPAN Portが100Mbpsであれば20Mbps分落ちます）。
また、キャプチャしているPC側の性能によってもパケット落ちは発生しますので、全てのパケットがキャプチャできる保証はどこにもないわけです。
という前置きの上での回答ですが、

> (A)half側でlate collisionを検出
これは正常な状態です。半二重通信時、フレームが衝突すればcollisionを検出します。
ですので、これだけで障害とは断定できません（というか、障害ではありません）。

> (B)full側でCRC errorを検出している場合
これはさすがに障害ですが、（明示的な）CRCエラーは主に伝送路上にノイズによって引き起こされるわけで、どちらかというとDuplex Unmatchが原因というよりも他の理由の方があると考えた方がいいです（ケーブル欠損、ノイズ等）。そのあたりになりますと環境依存になりますので、我々には知るよしもない、という感じですね。

少なくとも、パケットをキャプチャして云々よりも、WS-C4507Rのsh intの結果を参照して、具体的にどのようなエラーパケットをCatalystが検知しているかを確認した方がいいかもしれません（別部署管理ならなおさらの事）。

＞ BackDoor様
PM発射しました。ご確認いただければ。
kuro
会議室デビュー日: 2006/07/13
投稿数: 7
投稿日時: 2006-07-19 19:25
お疲れ様です。
Wind様、引き続きありがとうございます。
とりあえず、その後の経過を書いておきます。

開発環境でSW側のsh intを確認しつつ、試験を行いました。
１）STRATUS=10H, SW=10F ... SW側にてCRC検出。アナライザ上は観測できず。
２）STRATUS=AUTO,SW=10F ... SW側CRC検出せず。正常に通信できた。
３）顧客開発環境とは別の試験環境(弊社社内環境)で、上記1)2)を実施したところ、1)2)とも、CRCエラーを検出できた。

以上の結果から、今のところ、以下と結論付けています。

【疑問１：本番環境と同じAUTO-全二重固定設定で事象が再現しないのは何故か？】
-> 顧客開発環境(C2950)に依存している現象と思われる。本番環境(C4507R)で同一試験を実施すれば、再現できる可能性あり。

【疑問２：Duplex Unmatchで本番同等の高負荷をかけてもCRCエラーが発生しないのは何故か？】
-> CRCエラーの発生は確認できていることから、開発環境(C2950)の仕様としてアナライザがキャプチャできていないだけ。

あと、C4507Rのsh intを確認してもらったところ、CRCエラーを大量に検出していることも確認できました。

あとはC4507R環境で再現できることを祈るだけです。
来週以降になりますが、結果が出たらまた書き込んでおきます。

Wind様

> (A)half側でlate collisionを検出
>これは正常な状態です。半二重通信時、フレームが衝突すればcollisionを検出します。
>ですので、これだけで障害とは断定できません（というか、障害ではありません）。

これは、発生頻度の問題と捉えて宜しいでしょうか。どのくらいが許容範囲なのかは算出することは困難と思いますが、少なくとも２〜３０分通信を行っただけで数十〜数百件を検出するようでは、明らかに問題があるという理解でよいですよね？(late collisionとは伝送路の空きを確認して伝送を開始した後に検出するcollisionと理解しているので、通常は(半二重同士であれば)発生しないものであると思っています)

まだご覧になられていたら、ご回答頂ければ幸いです。
わちゃ
大ベテラン
会議室デビュー日: 2005/12/05
投稿数: 162
お住まい・勤務地: 東京
投稿日時: 2006-07-19 20:25
collision ですが、それなりに負荷のかかっているネットワークで、
single collision がほとんどであれば、毎秒１個ずつでもそんなに異常とは
思わないです。
（毎秒１個でも、線をフルに使っていたら、0.1% 程度の発生率です）

半二重の１：１通信の場合の collision は、お互いに空いてると思って
通信しはじめたら（ほぼ）同時に送信を開始して信号がぶつかった場合になります。

そのため、高負荷の環境であればそれなりには起きます。
また、LAN ケーブルの線が長ければ長いほど起きやすくなります。

＃もちろん、全二重の場合の collision は、異常です。


と、ここまで書いてて気づいたのですが、SW-HUB と Stratus の間のケーブルの
長さってどんなもんなんでしょうか？

それぞれの環境によって異なるのであれば、collision の発生頻度が上がって、
全二重サイドから見たら CRC エラーが増えるのかもしれません。

--- 追記

と、思ったけど、ごめんなさい。片方が Full であれば関係ないですね。


[ メッセージ編集済み 編集者: わちゃ 編集日時 2006-07-19 20:47 ]
Wind
ベテラン
会議室デビュー日: 2004/11/10
投稿数: 73
投稿日時: 2006-07-20 13:29
うわ、失礼しました。

ご指摘の通り『late』collisionは半二重通信下であっても、通常発生するものではありません。
late collisionが発生した場合、ケーブル不良、ケーブル限界長違反（UTPであれば100mルーール）、NIC不良等が考えられます。
ですので、通常環境下（今回のようにDuplex Unmatch等の要因が考えられない環境）でlate collisionカウンタがカウントアップした場合、上記のような物理レイヤーを疑ってください。

前回の回答は通常のcollisionカウンタのカウンタアップの場合で、late collisionはその限りでない、と訂正させて頂きますm(_ _)m
わちゃ
大ベテラン
会議室デビュー日: 2005/12/05
投稿数: 162
お住まい・勤務地: 東京
投稿日時: 2006-07-20 13:58
ぐはっ、失礼しました。

late collision と、普通の collision を混同して書いてますね、、、

半二重通信同士であれば、late collision は普通は起こらないですよね。

すいません。
«前のページへ 1|2|3

スキルアップ／キャリアアップ（JOB@IT）