第9回 イーサネット(その4) - フロー制御とVLAN、トラブルシューティング詳説 TCP/IPプロトコル(4/5 ページ)

» 2001年10月02日 00時00分 公開
[岡部泰一]

 Windows 2000では、イーサネット・デバイスの動作状態(統計情報)を「netstatコマンド」で確認することができる。netstatコマンドはTCP/IPプロトコル・スタックの統計情報を確認するために、コマンド プロンプト上で使用するユーティリティだが、オプションとして“-e”を与えるとイーサネット(のドライバ)に関する情報を出力することができる。

C:\>netstat -e
Interface Statistics

                           Received            Sent

Bytes                    2133003706      2700929773
Unicast packets            41603100        44717111
Non-unicast packets          396857           30733
Discards                          0               0
Errors                            0              20
Unknown protocols            125277

netstatコマンドによるイーサネットの統計情報の表示

 ここで表示される各出力項目についての説明はWindows 2000のヘルプには記述されていないようだが、これはWindows 2000が管理している「MIB-II (STD17)」の「Interfacesグループ」のオブジェクトを表示しているようである。ここではMIB-IIのオブジェクトを参考にして各項目の意味を見てみよう。

・Bytes
 インターフェイスが受信、送信した総オクテット数(フレーム・ヘッダなどを含む)。どの程度のトラフィックがあるのか確認することができる。どちらか一方がまったく0だとすると、例えば送信か受信用の線が切断しているなどのトラブルが考えられる。また、例えばインターフェイス・カードの割り込み(IRQ)の設定が間違っていると、送信はできるが受信ができない(送信はネットワーク・コントローラのバッファにデータを書き込めば自動的に行われるが、受信は割り込みによって通知するのが一般的だから)、というような症状が出ることがあるが、それもこの値から判断することができる(これは次のフレーム数からも判断できる)。

・Unicast packets
 インターフェイスが受信して、上位層に渡したユニキャスト・フレームの数と、上位層から送信要求が行われたユニキャスト・フレームの数。後者には送信できずに破棄されたものも含まれる。ユニキャスト・フレームとは、連載第7回の「イーサネットのフレーム構造――1.MACアドレス」で述べたように、マルチキャスト宛ではないフレームのことを指す(MACアドレスの先頭バイトの最下位ビットが0になっているアドレス宛の通信のこと)。

・Non-unicast packets
 インターフェイスが受信して上位層に渡したマルチキャスト・フレームの数と、上位層から送信要求が行われたマルチキャスト・フレームの数。後者には送信できずに破棄されたものも含まれる。TCP/IPで使われる「ブロードキャスト・アドレス」宛の送信は、これに含まれる。

 マルチキャスト・フレームはブロードキャスト・ドメイン全体に到達し、トラフィック量の増加につながる可能性があるため、その利用は最小限にとどめるべきものである。全フレーム数のうちマルチキャスト・フレームの占める割合が多い場合は、注意が必要である。不要なマルチキャストを行っていないか確認した方がよいだろう。

・Discards
 インターフェイスが受信したフレームと上位層から送出要求されたフレームのうち、エラーではないが廃棄されたフレームの数。これはバッファ・スペースが不足するなど、何らかの理由でステーションのリソースが不足したりした場合に起こる可能性がある。ステーションの処理能力を超えた通信を行っていると考えられる。

 ただしWindows 2000のリソースキット中のドキュメントでは、「Discards」には受信したエラー・パケット(不正なフレームなど)も含むと記述されているので、エラー・フレームの受信数もDiscardsにカウントされているようだ。

・Error
 インターフェイスが受信したフレームと、上位層から送出要求が行われたフレームのうち、エラーがあったフレームの総数。受信の場合はFCSが合わないものやフレーム長が長すぎるもの、送信の場合は再送が16回失敗したものや何らかの理由でステーションの送信バッファ中で破棄/破壊されてしまったものなどがある。ステーションが属するセグメントのトラフィック量が多すぎるか、ネットワーク・インターフェイスに過負荷がかかっている、物理的な障害があるなどが考えられる。

 トラフィック量が多すぎる場合は、トラフィックのパターンに応じてネットワークを構成しなおす必要がある。

 過負荷がかかって、ネットワークのエラーが発生している場合は、ネットワーク・インターフェイスやシステムの性能を向上させたり(高速なCPUやバス、メモリに変更するなど)、ネットワークの設計を見直したりする必要がある。

 物理的な障害としては、どこかの接続で不良個所があるか、ケーブルが断線しているなど、ハードウェアの故障などが考えられる。そのステーションのイーサネット・インターフェイスやケーブルの接続や、使用しているケーブルの結線、ドライバの設定に問題がないか調べてみる。それでも問題が解決しない場合は、他のステーションも同様に発生しているかどうかを確認する必要がある。

 バッファ中のフレームが破壊されてしまうというのは、関連するソフトウェアやハードウェアの障害によるものであるが、確認するのは困難である。インターフェイス・カード・ベンダやOSベンダの障害情報などを参照して、既知の報告がないかどうか確認してみる。

・Unknown protocols
 インターフェイスが受信した(ユニキャスト)フレームのうち、サポートしないプロトコルを含むフレームであったために、破棄されたフレームの総数。受信したフレームの中でサポートしないプロトコルの割合が高い場合は、その理由を調査し、必要に応じてネットワークの構成を変更、調整した方がよいだろう。

Copyright© Digital Advantage Corp. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。