第9回 イーサネット（その４） - フロー制御とVLAN、トラブルシューティング：詳説 TCP/IPプロトコル（5/5 ページ）
TCP/IPにともに広く普及したイーサネット。今回はイーサネット編の最終回として、フロー制御やVLAN、トラブルシューティング方法について解説。
さてそれでは実際にネットワーク上を流れているイーサネット・フレームについて調べてみよう。実際のフレーム構造などを調べるためには、ネットワークを流れるデータ列をキャプチャして解析することができる、「ネットワーク・プロトコル・アナライザ」と呼ばれる装置やソフトウェアが必要である。さまざまな製品やアプリケーションが販売されているが、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コマンドでイーサネット・ドライバの統計情報を調べたり、ネットワーク モニタでフレームをキャプチャして調べたりすることが大切である
Copyright© Digital Advantage Corp. All Rights Reserved.