QA@IT
この質問・回答は、@ITの旧掲示板からインポートされたものです。

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

はじめまして。実務で発生している障害について、皆様のお知恵を拝借させて頂きたく投稿致します。

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 ]

質問者:kuro

回答

おはようございます。
用途があっているかちょっと自信がないのですがアナライザーかスマートビット辺りの測定器でできそうな来もしますが、実機間の問題ならだめかもしれないです。

はずしていたらごめんなさいm(_ _)m

投稿者:hidekipo

編集 履歴 (0)

イーサネットレベルで衝突して壊れたフレームは、FCSが不正なので、
受信されずにそのまま捨てられます(ふつうは)。ので、上位のTCPチェックサム
エラーになることは考えられないのですが、いかがでしょうか?

投稿者:Uchikoshi

編集 履歴 (0)

Uchikoshi さんの意見に一票。

Catalyst4507R の機能とか、どんな処理をしているか分かりませんが、普通の SW-HUB ではなくて、NAT のようなパケットを書き換える処理を行っているのでしょうか?

また、通信の相手は、Catalyst なのでしょうか?(SNMP とか?)

Catalyst が、問題の中に出てくる理由をいまひとつ分かりませんでした。

個人的な印象では、送信側の機器、ドライバ、プログラムに問題があるような気がしますが。

頻繁におこるなら、hidekipo さんの言うように現地でアナライザを使うのもいい気がします。

投稿者:わちゃ

編集 履歴 (0)

hidekipoさん、Uchikoshiさん、ご回答ありがとうございます。

調査方法についてですが、SWにLANアナライザを接続し、STRATUS-SW間のポートのトレースを取得して現象を把握しています。この際、アナライザはSWで破棄されるフレームも含め、全てのフレームを記録しています。

アナライザで取得したトレースをEtherealで照会すると、問題のフレームには確かにFCSを含んでいません(後半が欠けているため)。Ethereal上では、そのようなフレームはTCP Checksum Incorrectと表示されているようです(データが欠けているため、Etherealが計算したTCPチェックサムと実際のチェックサム値が異なる)。

上記の理由でTCPチェックサムエラーと言ってしまったのですが、正確にはCRCエラーとかFCS不正と言うほうが正しいかもしれません。

私はネットワーク専門ではないのであまり詳しくないのですが、個人的に調べたところでは全二重・半二重相違による通信障害というのは典型的な障害のように見受けられ、意図的にこのような設定をしてテストをすれば簡単に欠損フレーム発生を再現できると考えていたのですが、実際にはSTRATUS側でコリジョンを検出しているにもかかわらずどうしても事象の再現ができずにいます。

引き続き、ご意見、ご指摘などありましたら何卒宜しくお願い致します。

投稿者:kuro

編集 履歴 (0)

わちゃさん、書き込みありがとうございます。

物理的に直接通信をする相手がCatalystになります。実際には、その先にある機器とTCP通信をしています。

>個人的な印象では、送信側の機器、ドライバ、プログラムに問題があるような気がしますが。

ご指摘のように、デュプレックスモードの相違以外で疑っている点としては、物理的な機器(NIC)やケーブルなどを考えています。但し、システムエラーログなどを見る限り正常に動作しているように見受けられるため、可能性は低いと考えています。
試験環境でもう少しトライした後、障害が発生した環境で(同一機器、ドライバなどで)試験を行おうと考えています。

投稿者:kuro

編集 履歴 (0)

フレーム欠損であれば、確かに Catalyst と STRATUS の問題かもしれませんね。

ただ、全二重、半二重だと考えられているのであれば、再現試験をするよりも、どちらも全二重か、オートネゴにして、問題が解決するかを調べてもいい気がします。

一応、確認事項

1.今回の件は、STRATUS が Catalyst に向かって送ったパケットで起きている障害ですよね。

2.本番環境、試験環境どちらも STRATUS はコリジョンを検出しているのですよね?

で、全然、外してそうですが考えられそうなのを、、、

1.MTU の設定が違うとか?
2.Catalyst2950 と Catalyst4507 でダメパケットに対する処理が違うとか、、

どっちも、可能性は薄そうですが ^^;

投稿者:わちゃ

編集 履歴 (0)

>ただ、全二重、半二重だと考えられているのであれば、再現試験をするよりも、どちらも全二重か、オートネゴにして、問題が解決するかを調べてもいい気がします。

そこなんですが・・・両方全二重、または両方オートネゴにすると当然のようにうまくいくのですが、STRATUS=AUTO、SW=全二重でもなんら問題なく通信できているように見えており、頭が痛いのです(双方全二重と動作的に違いが見受けられない)。

>1.今回の件は、STRATUS が Catalyst に向かって送ったパケットで起きている障害ですよね。

そのとおりです。CRCエラーは全て、STRATUS→SW方向でした。

>2.本番環境、試験環境どちらも STRATUS はコリジョンを検出しているのですよね?

ちょっとややこしいかもしれませんが、

1)本番環境では、netstatコマンドを叩く機会が無かったため、コマンドでのコリジョン発生は確認していません。トレース上でCRCエラーパケットの頻発を確認しているのみです。
ちなみに、障害についてさらに詳しく言うと、トラフィックの少ない時間帯ではまったく問題が表面化せず、多くなるとCRCエラーを契機としてアプリケーションで通信障害を認識する、という事象です。

2)開発環境では、①STRATUS=半二重、SW=全二重と明示的に設定した場合はコマンドでのコリジョン発生を確認できています。但し、②STRATUS=AUTO、SW=全二重の設定上では、コリジョン発生は確認できていません(CRCエラーは何れも確認できていません)。

そもそもですが、STRATUS=AUTO、SW=10M全二重固定とした場合、(STRATUSメーカサイドの回答として)STRATUSは10M半二重で通信を行う仕様である、というのが前提となっています(STRATUS上、採用されているデュプレックスモードが何かを確認するコマンドがないとのこと)。
前述①で発生して、②で発生しないということは、②でも全二重で通信されているのではないかと疑っていますが、その前段階として、①設定でなんとか欠損フレームの再現をしようとしている状態です。

>1.MTU の設定が違うとか?

STRATUSとSW間で、ということでしょうか?因みに、STRATUSのMTUは1500固定となっています。

>2.Catalyst2950 と Catalyst4507 でダメパケットに対する処理が違うとか、、

実は、これもちょっと疑っているのですが・・・実際、ありうる話でしょうか?(素人なもので・・・^^;)メーカーとかに聞いてみる価値があれば、確認してみようと思います。

ところで、ひとつ質問があります。

オートネゴの場合、速度とデュプレックスモードはNIC同士がLINK UPしたタイミングでFLPという信号をやりとりすることで行う、と理解していますが、この信号をアナライザその他でトレースをとることはできないでしょうか?実際に全半二重どちらで通信しているのかを確認したいと思っているのですが・・・

皆様のご協力感謝致します。m(_ _)m

投稿者:kuro

編集 履歴 (0)

オートネゴでうまくいくものを、わざわざ片方だけ固定に設定する要件が何かあるのでしょうか?
それで、解決じゃだめ?

また、STRATUS は半二重で通信を行う仕様であれば、SW-HUB を全二重固定にしているのがそもそも間違いでは?

なんか、特殊な要件または、再現試験を行なわなくてはいけない理由があるのでしょうか?

Catalyst2950 と Catalyst4507 での仕様ですが、これはなんともって感じです。

私は、Catalyst 4507 なんて、高価なものは触ったこともないので、、、

ただ、スイッチング方式が、ストアアンドフォーワードか、カットスルーかは調べてみてもいいかもしれません。
最近、よくある SW-HUB はストアアンドフォワードなんでエラーパケットは転送しないみたいですが、カットスルーだと、エラーパケットもしますよね。

最近のほとんどの SW-HUB はストアアンドフォーワードですが、いい SW-HUB はストアアンドフォワードと、カットスルーを組み合わせるなんて話も聞いた事があります。

投稿者:わちゃ

編集 履歴 (0)

こんにちは。

なにが問題なのか、ちょっと判り辛いのですが^^;

まず、

そもそもですが、STRATUS=AUTO、SW=10M全二重固定とした場合、(STRATUSメーカサ
イドの回答として)STRATUSは10M半二重で通信を行う仕様である、というのが前提と
なっています

ですが、これStratusの仕様じゃなくて、Ethernetの仕様ですよね?
詳しくはIEEE 802.3u参照の事。もしくはこのへんの過去スレ。

2.Catalyst2950 と Catalyst4507 でダメパケットに対する処理が違うとか、、
性能差はあれども、基本的には同じです(WS-C4000シリーズだと、話は違うのですが)。

Duplex Unmatchの場合、Trafficが混んでいない場合や片方向のTrafficの場合、症状がでないのが特徴です(だから判り辛いのですが)。
再現実験を行いたいのであれば、Server2台並べて双方向で負荷をかけてやる必要があるかとおもいます。
あと、当該障害が発生しているWS-C4507RのStratusが接続されているPortのsh intや、WS-C4507Rのlogなんかを確認するのが、切り分けの近道かもしれません。

# WS-C4507RのInterfaceの状態とWS-C2950のInterfaceの状態の比較も有効かも。

以上、何かの参考になれば

# Link先URLが間違っていたので修正
[ メッセージ編集済み 編集者: Wind 編集日時 2006-07-14 10:49 ]

投稿者:Wind

編集 履歴 (0)

わちゃ様、引き続きありがとうございます。

顧客要件としてStratus - SW間を10Mで固定する必要がある(将来、Stratus - SW間に10Mまでしか対応していない機器が入る予定のため)のですが、AUTOにすると1000Mでネゴされてしまうため、固定設定としています。

AUTO-全二重固定としていることがそもそもの誤りであることはいろいろ調べた結果間違いないと確信しているのですが、顧客を納得させるために、開発環境での再現→設定変更→問題解消というプロセスを見せる必要があり、まず再現を試みているところです。
(何が問題点かが判り難くなっていると思いますので、この後で整理します)

S&F、カットスルーについては、ご指摘のとおり、2950と4507Rで差があるかを確認してみようと思います。ありがとうございます。

Wind様、書き込み感謝致します。

ごちゃごちゃ書きすぎて私の疑問点が判りづらくなったため、整理します。以下、経緯です。

・本番環境でトレース採取の結果、CRCエラーフレームが多く採取された。

・調査の結果、Stratus=AUTO、SW=10M固定設定であることが判明。また、トレース解析の結果、CRCエラーが契機となり、アプリケーション側がデータ送信不能に陥っている可能性が高いことが判明。

・Stratus=10M固定にすることにより問題解決することを証明するため、まずは開発環境でAUTO-10M全二重固定として再現を行う。その結果、トレース上ではCRCエラーフレームが採取されなかった。また、Stratus側でコリジョン発生も検出できなかった。
【疑問1:本番環境と同じAUTO-全二重固定設定で事象が再現しないのは何故か?】

・本番環境ではDuplex Unmatchが発生していたと仮定し、Stratus=10M半二重、SW=10M全二重で試験を行った結果、Stratus側でコリジョンを検出できたが、トレース上ではCRCエラーフレームを採取できなかった。
【疑問2:Duplex Unmatchで本番同等の高負荷をかけてもCRCエラーが発生しないのは何故か?】

【疑問1】については、Stratus側の仕様にかかわると思うので、こちらでもう少し調査を継続します。Wind様に指摘頂いた過去ログでは、AUTO設定の挙動があやしい場合もあるとのことですので、手順によってはAUTOでも全二重になるケースがあるのではないかと考えています。

【疑問2】について、原因として考えているのは、
(1)CRCエラーは発生しているが、アナライザが拾えてないのではないか。または、本番SWと開発SWによって、欠損フレームの扱いが異なるのではないか。
(2)NIC、ケーブルの不良により、CRCエラーが発生しているのではないか。
があります。

(1)については、Windさん指摘のとおり、SW側のsh intコマンドによってCRCエラー発生が確認できると理解しましたので、試してみようと思います。コマンド上は発生しているにもかかわらずトレースに乗っていないのであれば、アナライザの設定やSWの仕様などを疑うことができると思います。

(2)について、(1)でCRCエラー発生が確認できなかった場合、本番機の同一NICを仕様して同様の試験を行おうと思います。それで発生した場合は、ハードに問題があると判断できると思います。

以上、皆様のご指摘を元に、今後の調査方法を考えてみました。
なにか誤解している点などあれば、改めてご指摘下さい。

最後に質問です。
>WS-C4507RのInterfaceの状態とWS-C2950のInterfaceの状態の比較も有効かも。

ここでおっしゃっている「状態の比較」とは、具体的にはどのような手順を踏むことを指しているのでしょうか?

以上、宜しくお願い致します。m(_ _)m

投稿者:kuro

編集 履歴 (0)

すみません、色々と裏取りしていて遅くなりました。

・【疑問1】【疑問2】に関して
手持ちのCatalystで実験してみました(さすがにWS-C4500は調達できなかったので、WS-C2924ですが)。
Node側(IBM Note)をAutoに設定してWS-C2924側をいろいろといじくったのですが、WS-C2924側をSpeedのみ10Baseに固定して、DuplexをAuto設定にすると10/Fullでネゴシエーションしますね。
検証環境のWS-C2950はSpeed 10、Duplex Fullコマンドははいっていますか?
Speed 10のみだと、上記のように10/Fullでネゴシエーションしてしまいます。
また、Duplex Unmatchの状態においてもCRCエラーが観測されない場合があります。
ここでご質問の比較の話になりますが、他方ではCRCエラーが観測され、他方では観測されなかった場合、複合障害が発生している可能性もあります。ケーブル不良、ノイズなども疑った方がいいかもしれません。

また、エラーフレームが拾えるか、というお話ですが、どのような形でキャプチャされているかわからないのでなんともいえないのですが、SPAN Portを設定してキャプチャされている場合、エラーフレームが拾えないのは仕様です。着信パケットがバッファに入ったタイミングでパケットを複製してSPAN Portに転送する仕掛けになっていたはずなので、バッファに入る前にドロップされてしまえば当然の事ながらSPAN Portでは拾う事ができません。
ですので、SPAN Portによるキャプチャでエラーフレームが観測できなかったといって、エラーフレームがないと断言するのは非常に危険です。必ずsh intやsh controller ethernet-controller等でステータスを確認してください。

以上、何かのご参考になれば

投稿者:Wind

編集 履歴 (0)

割り込み失礼します。
詳細環境になると弱いので、このスレッドにはコメントしないつもりでしたが、
途中の過去スレで紹介された続き部分、・・・便乗質問です。

Windさんの書き込み (2006-07-14 16:02) より:

手持ちのCatalystで実験してみました(さすがにWS-C4500は調達できなかったので、WS-C2924ですが)。

Node側(IBM Note)をAutoに設定してWS-C2924側をいろいろといじくったのですが、WS-C2924側をSpeedのみ10Baseに固定して、DuplexをAuto設定にすると10/Fullでネゴシエーションしますね。

この部分ですが、node側の特性によっても変化する可能性があると考えたほうが
良いのでしょうか?
→ 基幹SWに直接接続しているnode(主としてサーバ類)の約半数程度は速度を
  固定しないautoの状態です。対して基幹SW側は全て100full固定です。
  現状では特に問題になっていませんが、このまま放置でよろしいか、アドバイス
  願えると幸いです。

投稿者:BackDoor

編集 履歴 (0)

フレームエラーを捉えているのは、SW-HUB 経由ですよね?

STRATUS と SW-HUB の間にリピーター HUB を入れて調べてみてはいかがでしょうか?

あと、ネゴシエーションの問題であるとすると、中間機器を入れるとまた様子が変わってしまいそうな気が、、、

BackDoor さんの auto と固定の組み合わせって、なんかたまに相性問題があったりとかって噂を聞きます。

私も、auto と固定の組み合わせでトラブルがあって、どっちも固定にしたことがあります。ただ、その時は、機械のそばでノイズのひどい線だったので、あまり参考にならないかもしれませんが、それをやってちょっとだけ改善した気がします。

結局、その後で、配線、HUB、ケーブルを全部入れかえをやらなくてはいけなくなったので気休め程度かもしれません。

まぁ、どっちも固定か、どっちも auto かがいいかという噂は聞くかなって程度です。

投稿者:わちゃ

編集 履歴 (0)

Wind様:

検証環境のWS-C2950はSpeed 10、Duplex Fullコマンドははいっていますか?

SW側は我々の管理外になってしまうので自分で確認はできないのですが、担当者が言うにはSpeed, Duplexとも設定しているとのことです。

比較の件については、よく理解できました。実際、開発と本番で同一条件の試験を行ってみようと思います。

たびたびすいません、また質問ですが、

Duplex Unmatchの状態においてもCRCエラーが観測されない場合があります。

とのことですが、(A)half側でlate collisionを検出、または(B)full側でCRC errorを検出している場合、アナライザが全てのフレームをキャプチャできていれば必ず欠損フレームが観測できるはず、と考えてよいでしょうか?
それとも、(A)だけでは欠損フレームが発生しているとは言い切れないのでしょうか?(さすがに、(B)であれば発生していると考えてよいですよね?)

わちゃ様:

リピータハブの件も、検討してみたいと思います。その方法であれば、確実に全てのフレームをキャプチャできる、と考えられますよね。

余談ですが、中間機器というのは、まったくインテリジェンスの無い中継機器なので(そのくせサポートは10Mまでとか言ってるのですが)、大丈夫・・・だと思います。

投稿者:kuro

編集 履歴 (0)

リピーター HUB も、あんまりインテリジェントな感じがしないですけど、それでも通信速度のネゴシエーションには影響を与えますよね。

そういう意味で言ってみました。

そういえば、何年か前に「たこ足 HUB(正式名称不明)」ってのが、あって OA タップのように、LAN の信号を単に二股に分けるだけの電源要らずの HUB(?) がありました。

そこそこ使えるという噂で、ネットワークをモニタリングするときとか、HUB のポートを増やしたいけど、電源の確保が面倒な時を想定して買ってみたんですが、結局使わずにどこかに行ってしまいました。

今回みたいなネゴシエーションが絡んでいる問題の時は便利だったかもしれないですね。

投稿者:わちゃ

編集 履歴 (0)

1)障害内容

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

2)想定原因

STRATUS側がオートネゴシエーション、SW側が10M全二重固定となっているため、STRATUS側のデュプレックスモードが半二重で通信が行われている。

そのため、STRATUSがフレームを送出中にSW側からフレームを受信した際、STRATUSがコリジョンを検出して送出を中止し、その結果中途半端に送出されたフレームがチェックサムエラーとしてSW側で認識される。

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

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

#Stratus と Catalyst が泣きますぜ

投稿者:holic

編集 履歴 (0)

こんにちは。

改めてスレッドを読み返していたんですが、明示的に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発射しました。ご確認いただければ。

投稿者:Wind

編集 履歴 (0)

お疲れ様です。
Wind様、引き続きありがとうございます。
とりあえず、その後の経過を書いておきます。

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

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

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

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

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

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

Wind様

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

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

まだご覧になられていたら、ご回答頂ければ幸いです。

投稿者:kuro

編集 履歴 (0)

collision ですが、それなりに負荷のかかっているネットワークで、
single collision がほとんどであれば、毎秒1個ずつでもそんなに異常とは
思わないです。
(毎秒1個でも、線をフルに使っていたら、0.1% 程度の発生率です)

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

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

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

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

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

--- 追記

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

[ メッセージ編集済み 編集者: わちゃ 編集日時 2006-07-19 20:47 ]

投稿者:わちゃ

編集 履歴 (0)

うわ、失礼しました。

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

前回の回答は通常のcollisionカウンタのカウンタアップの場合で、late collisionはその限りでない、と訂正させて頂きますm(_ _)m

投稿者:Wind

編集 履歴 (0)

ぐはっ、失礼しました。

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

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

すいません。

投稿者:わちゃ

編集 履歴 (0)
ウォッチ

この質問への回答やコメントをメールでお知らせします。