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

» 2001年10月02日 00時00分 公開
[岡部泰一]
前のページへ 1|2|3|4|5       

 さてそれでは実際にネットワーク上を流れているイーサネット・フレームについて調べてみよう。実際のフレーム構造などを調べるためには、ネットワークを流れるデータ列をキャプチャして解析することができる、「ネットワーク・プロトコル・アナライザ」と呼ばれる装置やソフトウェアが必要である。さまざまな製品やアプリケーションが販売されているが、Windows 2000 Server(以上)にも「ネットワーク モニタ」という名称で用意されている。インストールされていない場合は、[コントロール パネル]の[Windowsコンポーネントの追加と削除]で、[管理とモニタ ツール]にある[ネットワーク モニタ ツール]をインストールしておこう。なお、この機能はWindows 2000 Professionalでは利用できない。

 この「ネットワーク モニタ」の上位版として、「Microsoft Systems Management Server 2.0」に、より高機能なネットワーク モニタ ツールが用意されている。Windows 2000 Server版のネットワーク モニタと比べると、より多くのプロトコルのサポート(HTTPのような高位レベルのプロトコルの解析も可能)や、リモート モニタ機能などが強化されている。Windows 2000 Server版では、キャプチャできるフレームは、ローカルのマシンに装着されているインターフェイス宛のものだけに限定されているが(つまり、自ステーション宛のフレームの受信と、ブロードキャスト・フレームの受信、および自ステーションからのすべての送信の3種類を取り込んで解析できる)、SMS版のネットワーク モニタでは、自ステーション宛でなくても、(同じネットワーク・ケーブル上に接続されている)他ステーション同士のフレームをキャプチャすることもできるし、ネットワーク モニタのドライバが動作しているマシン(このためのネットワーク モニタ ドライバはWindows ProfessionalやServerに含まれている)へネットワーク経由で接続して、別セグメント上のイーサネット・フレームをキャプチャすることもできる。

 以下では例として、Microsoft System Management Server 2.0に含まれるネットワーク モニタを使用して、ローカルのインターフェイス経由で送受信されているフレームをキャプチャしてみた。

 ネットワーク・モニタはキャプチャしたデータを各プロトコルに基づいて解析し、その結果をフレーム・ビューア・ウィンドウに表示する。フレーム・ビューア・ウィンドウには、キャプチャした順にフレームの概要を表示する概要ペイン、選択したフレームの詳細情報を表示する詳細ペイン、選択したフレームの16進ダンプを表示する16進ペインがある。

フレームのキャプチャ画面
Microsoft System Management Server 2.0に付属するネットワーク・モニタの使用例。Windows 2000 Serverに含まれるネットワーク モニタはこれのサブセット版であり、自ステーション宛のフレームしかキャプチャできないなどの制約がある。ここではキャプチャしたデータをフレーム ビューア ウィンドウに表示している。上段の概要ペインでフレームを選び、中央の詳細ペインで選択中のフレームの各フィールドを確認する。下段の16進ペインで選択中のフレームの16進ダンプを調べることができる。
 (1)概要ペイン。キャプチャしたフレームの情報を1行1パケットの形式で表示している。
 (2)詳細ペイン。(1)で選択したフレームをプロトコル階層に従って解析し、表示している。
 (3)16進ペイン。(1)で選択したフレームのデータを16進形式で表示している。(2)で選択している部分のプロトコル・データが反転表示される。

 概要ペインでフレームを選択すると、詳細ペインにそのフレームの各フィールドが表示されるので、内容を確認してみよう。ここではARP_RARPプロトコルのフレームを選択している。詳細ペインには、行頭に「+」や「-」マークが表示されている行があるが、「+」マークがある行はさらに詳細な情報を含んでいることを表し、その行をダブルクリックすると詳細情報が展開される。「-」マークがある行は詳細情報を展開して表示していることを表し、その行をダブルクリックすれば折りたたむことができる。ただし解析できるプロトコルには制約があり、Windows 2000 Serverに含まれているネットワーク モニタではHTTPのような高度なプロトコルは解析できない(単なる16進ダンプとしてのみ見ることができる)。SMS版ならばHTTPの解析なども可能であるし、必要ならば新たなプロトコルをサポートするために、SDKを使って機能を拡張することもできる。

 一番下の16進ペインには、受信したデータを16進数形式で表したものが表示される。また、その右側には文字コードで表示されるので、文字列データなどの内容を簡単に確認することができる(ただし漢字コードには未対応)。詳細ペインで行(プロトコル)を選択すると、その部分が16進ペインでは反転表示されるので、プロトコル・データの詳細な調査には非常に便利である。以下にその16進データ部分だけを取り出したものを掲載しておく。

キャプチャ・フレームの16進ダンプ
16進表示ペインには、キャプチャしたフレームの16進形式のダンプが表示される。プロトコル内部の詳細なデータを検査したり、未サポートのプロトコルを調査したりするには、この16進ダンプを使用する。ここでは全体長が42オクテットであるが、この他にFCSが4オクテット付加される。それでもフレームの最小長64オクテットには、あと18オクテット分足りないが、足りない部分にはイーサネットのコントローラ・チップによって自動的にパディング用のデータが補われる。
 (1)宛先MACアドレス。先頭バイトの最下位ビットが1なので、これはイーサネットのマルチキャスト・アドレスを表す。この場合はすべてのビットが1の、ブロードキャスト・アドレス(全ステーション宛の送信)を表している。
 (2)送信元のMACアドレス。
 (3)長さ/タイプ。値が0x0600以上なので、これは「フレーム長」ではなく「フレームのタイプ」、つまりTCP/IPのARPプロトコルを表している。
 (4)データ部。この場合はARPプロトコルのデータを表している。

 さてそれでは詳細ペインを見ながら、キャプチャしたフレームの詳細について調べてみよう。

 最初のFRAMEはそのフレームをキャプチャした時間や、直前のフレームをキャプチャしてから経過した時間など、フレームに関する基本的な情報が含まれ、行を展開することでそれらの情報を確認することができる。

 次のETHERNET以降は、フレームに含まれるプロトコルを表している。ETHERNETはイーサネットに関する情報で、ここではイーサネット・フレームを確認することが目的なので、展開して詳細な情報を表示させてみた(ネットワーク モニタではイーサネット以外のプロトコルも解析できる)。

 順に見ていくと、Destination addressが宛先アドレス・フィールドで「FF:FF:FF:FF:FF:FF」、つまりブロードキャスト・アドレス(全ステーション宛の送信)となっている。Source addressが送信元アドレス・フィールドで「00:D0:09:20:09:F7」である(これは自ステーションのMACアドレス)。

 次のFrame Lengthは「長さ/タイプ」フィールドと間違えてしまいそうだが、フレーム自体のサイズが42オクテットであることを示したもので、データのサイズを示す「長さ/タイプ」フィールドではない。詳細ペインでいずれかの行を選択すると16進ペインの対応する部分が反転表示されるが、Frame Lengthを選択してもどこも反転しない。だからこのフレーム中には「長さ/タイプ」フィールドがないということが分かる。Ethernet Typeは「長さ/タイプ」フィールドで、この場合は「0x0806」となっている。これは0x0600以上なのでデータのサイズではなく、データのタイプを示している。つまりこのフレームは「DIXイーサネット形式」であることが分かる。タイプ0x0806は「ARP(Address Resolution Protocol)」を表すので、このフレームにはARPパケットが格納されていることが分かる。そしてEthernet Dataがデータ・フィールドで、ここには28オクテットのデータ(ARPのデータ)が格納されている。

 イーサネットの最小フレーム・サイズは64オクテット(フレーム最後の4オクテットのFCSを含む。だがプリアンブル部分は含まない)であることはすでに述べた。しかしこのデータ・フィールドには28オクテットしかない。これは46オクテット未満なので、全体で64オクテットになるようにパディング・データが(18オクテット分)付加されているはずであるが、16進ペインには表示されていない(もともとプリアンブルやFCS部分は表示されない)。これはなぜだろうか?

 実は、これはネットワーク・モニタとキャプチャ用ドライバの構造によっている。送信するデータが全体で64オクテット以下の場合、余分なパディング・データを付加するのは、イーサネット・インターフェイスのデバイス・ドライバやコントローラ・チップの責任である(一般的にはコントローラ・チップ側で自動的に付加するようになっている)。ネットワーク・モニタでは、NDISインターフェイスを使ってパケットをキャプチャしているが、パディング・データの付加はそれよりも下位で行われるため、送信前のパケットにはパディング・データが含まれておらず、このようなキャプチャ結果となる。

 これとは逆に、受信するフレームの場合は、すでにパディング・データが付加された後のフレーム・データがネットワークモニタに渡されるため(ネットワーク・ケーブル上のフレームを取り込むため)、64オクテット以上になっている。これについては実際にネットワーク・モニタを起動して、確認してみてほしい。

 さて以上のことから、このフレームはDIXイーサネット形式のフレームで「MACアドレスが00:D0:09:20:09:F7のステーションがARPパケットをブロードキャスト(ネットワーク上のすべてのステーション宛に送信)したフレームである」ことが分かる。

今回のまとめ

  • スイッチング・ハブなどのバッファがあふれたりしないように、フレームの送信を一時中止させたり、その後再開させたりすることをフロー制御という。半二重通信ではバックプレッシャ方式、全二重通信ではPAUSEフレーム方式が一般的に使われる。
  • VLANとは、スイッチング・ハブのポートやMACアドレスなどをベースに、仮想的なグループを作る機能。イーサネット・フレーム中には、VLANをサポートするためのオプション・フィールドがあり、その場合はフレームの最大長は1522オクテットとなる。
  • イーサネットのトラブルシューティングを行うには、ハブのLEDで物理的な状態を調べたり、(Windows 2000の)netstatコマンドでイーサネット・ドライバの統計情報を調べたり、ネットワーク モニタでフレームをキャプチャして調べたりすることが大切である

「ネットワーク技術解説講座詳説 TCP/IPプロトコル」のインデックス

ネットワーク技術解説講座詳説 TCP/IPプロトコル

前のページへ 1|2|3|4|5       

Copyright© Digital Advantage Corp. All Rights Reserved.

RSSについて

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

メールマガジン登録

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