Etherbeat ver.2.0 - The Ethernet traffic generator that inspects redandant network system
Etherbeat ver.2.0 - 冗長化システムを検査するイーサネット・トラフィック・ジェネレーター
2009年11月14日
目次
- はじめに
- Etherbeatの概要
- 2.1 主な働き
- 2.2 バージョン
- 2.3 ソフトウェア構成
- 2.4 ユーザーインターフェース
- 特徴
- 3.1 試験パケットの送信間隔
- 3.2 片方向の疎通判定
- 3.3 仮想アドレス
- 操作方法
- 4.1 サーバープログラムの起動
- 4.2 クライアントプログラムの起動
- 4.3 クライアントの操作
- 4.4 実行例
- 使用上の注意
- 5.1 使用環境
- 5.2 試験パケットの上位プロトコル
- 5.3 間隔のゆらぎ
- 5.4 間隔の最小値
- 5.5 Ethernetスイッチのエージングタイム
- 5.6 受信タイムアウト
- 5.7 近隣ルーターの検索
- 動作環境
- ダウンロード
- より良く使用するために
- 使用許諾
- 保証
- 責任
- 著作権
1 はじめに
昨日までいつもどおりに使っていたパソコンが、ある日突然立ち上がらなくなってしまった。このようなことは多くのパソコン利用者が経験していることと思います。コンピュータは何の前触れもなく突然故障してしまうことがあります。ハードウェアが故障したり、ファイルシステムに記録しているデータが破損したり、原因は様々です。
パソコンだけに限らず、ルーターやスイッチングハブなどのネットワーク機器も突然故障することがあります。ネットワーク機器が故障した場合はパソコンが故障したときと違って、その影響は広範囲に及びます。インターネットサービスプロバイダー（ISP）と接続している唯一のルーターが故障すると、故障したルーターが修理されるまで、LANのすべての利用者がインターネットを通じて電子メールを送受信することができなくなってしまいます。 ネットワークの規模や重要性にもよりますが、ネットワーク設計者はネットワークシステムの中の重要な機器を二重化して、冗長経路をあらかじめ用意し、万一の事態が起きてもネットワークが長時間停止しないように創意工夫します。
機器および通信経路を冗長化する際によく用いられる技術として、RIPやOSPF, STPやRSTP, それにVRRPやCARPなどがあります。RIPならびにOSPFは経路情報プロトコルの一種で、これらを用いることによってOSI参照モデルにおける第3層（ネットワーク層）の通信経路を冗長化することができます。STPとRSTPは第2層（データリンク層）の冗長化に用いられるプロトコルです。VRRPとCARPは先のプロトコルとは少し趣きが異なり、一つのIPアドレスを複数のホストで共有するためのプロトコルです。
STPを利用した場合、通常使用している経路が使えなくなったら、障害発生から30秒後あるいは50秒後に冗長経路が有効になり、通信が再開します。Keep Aliveを使うプロトコル、例えば大型ホストコンピュータの端末制御プロトコルなどを使用している場合などを除いて、多くの事業所ではこれで充分でした。 しかし、それでも技術は進歩し、現在利用されているRSTPやVRRPなどの新しい技術では、常用機に障害が起きた場合、数秒程で予備機に切り替わります。さらに、メーカー独自の機能を用いることにより、障害発生から1秒未満（数百ミリ秒）で予備機を有効にすることが可能だという製品まであります。
ネットワークシステムを導入する事業所の担当者（ネットワーク管理者）にとって、自社ネットワークに万一の事態が起きたとき、何秒で通信が復活するのかは大変気になるところです。そこで、冗長化システムにおいて障害発生から何秒で冗長化経路へ切り替わるのかを計測するためのソフトウェアを作成し、「Etherbeat」と名づけました。
これから、Etherbeatの概要や特徴について説明します。
2 Etherbeatの概要
2.1 主な働き
Etherbeatは、連続してパケットを生成および送信するトラフィックジェネレーターです。Etherbeatは二つのEthernetインターフェースが装備されたホストを使用し、一つのインターフェースから他のインターフェースに向けて試験用パケットを連続して伝送し続けます。試験パケットの流れ（トラフィック）は片方向だけでなく、双方向に流すこともできます。ネットワーク機器の障害などにより試験パケットが消失したとき、受信プロセスは消失した試験パケットの数と時間を表示します。そして、最後の試験パケットが受信されたとき、受信したパケットの数とパケット間の平均時間を表示します。
【図 2-1】Etherbeatのイメージ（画像をクリックして拡大表示）
2.2 バージョン
Etherbeatの最新バージョンは ２.０ です。前のバージョンからの主な変更点は次のとおりです。
- 【追加した機能】
- ・ IPv6のパケットを送受信する機能
- 【削除した機能】
- ・ 復数の仮想アドレスを生成する機能
- 【修正したバグ】（修正後の動作）
- ・ 仮想アドレスへのARP要求に対してARP応答を返す。
- ・ クライアント/サーバー間のコネクションを保持したままクライアントを終了した場合でも、サーバーを異常終了させない。
- ・ 試験パケットの送受信を実行している最中は、クライアント/サーバー間のコネクションを切断させない。
2.3 ソフトウェア構成
Etherbeatはクライアント／サーバー型のソフトウェアです。
クライアント（プログラム）はX-Window上のグラフィカルユーザーインターフェースです。ユーザーはクライアントを使って、パケット送信の繰り返し回数やパケットとパケットの間の時間間隔などを設定し、サーバー（プログラム）に動作の開始や中断の指示を送ります。
サーバーはクライアントからの指示を受けてパケットの生成と送信を開始したり、中断したりするデーモンプログラムです。また、サーバーはパケットの送受信を実行している最中に起きた出来事、例えば試験パケットが100個消失したことなどをクライアントに知らせます。
クライアントとサーバーは2台のホストで別々に実行することも、1台のホストで同時に実行することもできます。クライアントとサーバーを異なるホストで実行する場合、サーバーを実行するホストでは試験パケットの送受信用LANインターフェースの他に、クライアントとの通信のためにもう一つLANインターフェースが必要です。
クライアントとサーバー間の通信にはTCPプロトコルを用いています。これは、サーバーからのメッセージを漏れなくクライアントに伝えるためです。サーバーがListenするTCPポート番号は固定されていません。サーバーを実行するホストの環境に応じて、未使用のポート番号を指定することができます。
クライアントとサーバー間の通信にはIPv4プロトコルを用いています。IPv6による通信はできません。
【図 2-2】サーバー／クライアント（画像をクリックして拡大表示）
2.4 ユーザーインターフェース
クライアントプログラムのスクリーンショットを以下に示します。
【図 2-3】スクリーンショット（画像をクリックして拡大表示）
ウィンド内にはいくつかの設定項目とボタン、そしてメッセージ欄があります。
| Server IP address | : | サーバー（プログラム）を実行しているホストのIPv4アドレスを指定します。 |
|---|---|---|
| TCP port | : | サーバーがListenしているポート番号を指定します。 |
| Interface name | : | サーバーが稼働しているホストに装備されているインターフェースの名前を設定します。 |
| Ethernet address | : | 試験パケットの送受信に使用するインターフェースのEthernetアドレスを設定します。 |
| IP address | : | 試験パケットの送受信に使用するインターフェースのIPv4/IPv6アドレスを設定します。 |
| IP netmask | : | 試験パケットの送受信に使用するインターフェースのネットマスクを設定します。 |
| Default gateway | : | 試験用インターフェースのためのデフォルトゲートウェイのIPアドレスを指定します。 |
| Direction | : | トラフィックを流す方向を選択します。 |
| Repetation | : | 試験パケットを送信する回数を指定します。 |
| Interval (sec.) | : | 試験パケットを何秒おきに送信するか、その時間間隔を指定します。 |
| Timeout (sec.) | : | インターフェースの受信タイムアウトの秒数を指定します。 | ARP for switches | : | IPv4を利用する場合、受信側インターフェースにおいて試験パケットを受信する前にARPを送信するかどうか選択します。 |
| Log file | : | サーバーからのメッセージをファイルに記録したいとき、そのファイル名を指定します。 |
| Open | : | 設定項目Log file:で指定した名前のファイルを開き、サーバーからのメッセージの記録を開始します。 |
|---|---|---|
| Close | : | 設定項目Log file:で指定した名前のファイルを閉じます。これ以降サーバーからのメッセージはファイルに記録されません。 |
| Connect | : | サーバーとの間でTCPコネクションを確立します。 |
| Disconnect | : | サーバーにTCPコネクションを閉じるように指示します。 |
| Read Config. | : | 設定ファイルethbeat.confに保持されている内容を読み込み、各種設定項目に反映します。 |
| Save Config. | : | 各種設定項目の内容を設定ファイルethbeat.confに保存します。 |
| Start | : | サーバーに試験パケットの送受信を開始するように指示します。 |
| Cancel | : | サーバーに実行中のプロセスを中断するように指示します。 |
| Version | : | プログラムのバージョンを表示します。 |
| Clear Message | : | メッセージ欄に表示されている内容を消去します。 |
3 特徴
3.1 試験パケットの送信間隔
送信プログラムは試験パケットを送信したあと指定された時間スリープします。この時間は10億分の1秒（1ナノ秒）単位で指定することができます。値は小数を用いて指定ます。たとえば、1000分の1秒（1ミリ秒）を指定したいときは、0.001と指定します。
間隔に設定する時間には少し注意してください。仮に間隔を0.001（秒）に設定したとします。このとき、送信プログラムから1秒間に送信されるパケットは1000パケットにはならず、1000パケット未満になります。別の言い方をするなら、間隔を0.001秒に設定しても、ちょうど1ミリ秒毎にパケットが送信される訳ではないということです。
ユーザープログラムからパケットを送信するとき、プログラム内でシステムコールを呼び出す関数、一般的にはsend()またはsendto()を用いますが、実はこの関数やシステムコールを実行すること自体に時間が掛かります。さらに、スリープ状態からの復帰にも時間を要します。
例えば以下のようなプログラムコードの場合、パケットとパケットの間はちょうど1ミリ秒（1,000,000ナノ秒）にはなりません。ホストのハードウェア性能にもよりますが、必ずプログラム自身の実行に時間を要しますので、パケットの間隔は1ミリ秒以上になります。できるだけパケット間隔を1ミリ秒に近づけたいときは、パケット間隔に1ミリ秒未満の値、例えば0.000985を設定します。
----------------------------------------------------------------------
int s;
char buff[1514];
struct timespec ts;
s = socket(PF_PACKET, ...);
ts.tv_sec = 0;
ts.tv_nsec = 1000000;
while (1)｛
if (sendto(s, buff, ...) < 0) {
perror("...");
return;
}
nanosleep(&ts, NULL);
}
----------------------------------------------------------------------
【図 3-1】プログラムコードの例1
3.2 片方向の疎通判定
pingの場合、先ず発信元インターフェースからICMP Echo Requestパケットを送り、その後相手先インターフェースからICMP Echo Replayパケットが帰って来たときに通信経路が使用可能であると判断します。これに対し、Etherbeatでは、一つのインターフェースから送信した試験パケットが他方のインターフェースで受信できたか否かで、片方向の通信経路が使用可能にあるかどうかを判断します。このことは、通信が不通になっている時間を詳しく知るためにとても有効です。
pingの問題点は、片方向の通信だけが可能な状態を認識できないことです。つまり、発信元インターフェースから相手先インターフェースにICMP Echo Requestパケットが転送されても、その応答が転送されない状態のとき、あるいはその逆の状態を知ることができません。
一般的には、二つのホスト間で通信経路の往路と復路が異なっている状態はほとんどありません。ですが、まったく無い訳ではなく、OSPFやBGPなどの経路制御プロトコルを使って意図的に往路と復路を同じにしていない場合があります。また、冗長化プロトコルによっては障害が発生したとき常用機から予備機への切り替わりにおいて、上りと下りの経路の切り替わりに時間差が生じます。CARPはまさにこのような特徴を持っています。
※ CARP: Common Address Redundancy Protocolの略称。一つのIPアドレスを異なるホストにで共有してシステムの冗長化を実現するプロトコル。BSD系UNIXで利用できる。
3.3 仮想アドレス
Etherbeatは、オペレーティングシステム（OS）に設定されているインターフェースのアドレスとは異なるアドレス（仮想アドレス）を使用して試験パケットの送受信ができます。仮想アドレスは、Ethernetアドレス、IPv4/IPv6アドレスに設定することができます。（以前のバージョンのEtherbeatでは、複数の仮想アドレスを生成して、あたかも複数のホストが存在しているかのようなトラフィックを生成することができましたが、バージョン２.０ではその機能を廃止しました。）
インターフェースの名前をリストメニューから選択するとEthernetアドレスが自動的に設定されますが、その後、自由にアドレスに変更することができます。ただし、Ethernetアドレスを変更した後にインターフェースの名前を変更すると、Ethernetアドレスは変更後のインターフェースのアドレスに再設定されます。また、IPアドレスも同様で、IPアドレスを変更した後にインターフェースの名前を変更すると、IPアドレスは変更後のインターフェースのアドレスに再設定されます。
Ethernetアドレスに仮想アドレスを設定するときは、第1オクテットの下位第2ビットが1であるプライベートアドレスを設定すると、他の正規のアドレスと衝突する心配がなくなります。
4 操作方法
4.1 サーバープログラムの起動
サーバーのプログラム名はethbeatdです。ethbeatdの実行にはスーパーユーザーの権利が必要です。
ethbeatdを実行するとき、listenするTCPポート番号をパラメータとして与えてください。
host# ./ethbeatd -p 1440
-p クライアントとの通信に使用するTCPポート番号
4.2 クライアントプログラムの起動
クライアントのプログラム名はethbeatxです。ethbeatxは一般ユーザーで実行します。
ethbeatxを実行するとき、パラメータは何も要りません。
host$ ./ethbeatx
4.3 クライアントの操作手順
- サーバー（プログラム）を実行しているホストのIPv4アドレスとListenしているポート番号を入力して、Connectボタンをクリックします。クライアント（プログラム）とサーバーを同じホストで実行している場合はIPアドレスにローカルホストアドレス127.0.0.1を指定することができます。
- クライアントがサーバーに接続したとき、サーバーのホストに装備されているインターフェースのメニューリストが作成されます。試験に使用するインターフェースの名前をメニューリストから選択してください。ここでメニューリストにない名前を入力すると、選択したIPアドレスに応じたネットマスクを自動的に設定できなくなるなどの不具合が生じますので、注意してください。
- インターフェースの名前をメニューリストから選択して変更したとき、選択されたインターフェースのEthernetアドレスが自動的に設定されます。必要があれば、Ethernetアドレスを変更します。通常は変更しません。
- インターフェースの名前をメニューリストから選択して変更したとき、そのインターフェースに設定されているIPv4/IPv6アドレスのメニューリストが作成されます。試験に使用するアドレスをメニューリストから選択してください。または、入力フィールドに直接アドレスを入力してください。
- IPアドレスをメニューリストから選択して変更したとき、そのアドレスのネットマスクが自動的に設定されます。必要があれば、ネットマスクを変更します。通常は変更しません。 IPv4/IPv6アドレスフィールドでメニューリストにないアドレスを指定した場合は、適切なネットマスクを入力してください。
- 試験用インターフェースのためのデフォルトゲートウェイのIPアドレスを指定します。インターフェースAとインターフェースBのIPアドレスのネットワーク部が異なる場合、IPv6の近隣ルーターの検索機能を利用する場合を除いて、ゲートウェイのIPアドレスを指定する必要があります。インターフェースA/BのIPアドレスにIPv6のアドレスを設定したときは、ゲートウェイのIPアドレスが空白のままでも構いません。この場合、サーバーが自動的に近隣ルーターを検索します。
- トラフィックを流す方向を選択します。
- IPアドレスにIPv4のアドレスを指定した場合、[ARP for switches]チェックボックスにチェックすることで、受信側インターフェースから事前にARPを送出することができます。
- 試験パケットを送信する回数を指定します。入力できる最大値は 1,000,000,000です。（入力する時はカンマなしで数時だけを入力してください。）
- 試験パケットを何秒おきに送信するか、その時間間隔を定します。1秒より短い時間を指定したい場合は、小数点を使って入力してください。例えば、1000分の1秒（1ミリ秒）を指定したいときは、0.001と入力します。
- インターフェースの受信タイムアウトの秒数を指定します。タイムアウトは秒単位で指定します。例えば5分を指定したい場合は、300 と入力します。
- 以上の設定が終わったらStartボタンをクリックしてください。入力項目がすべて正しければサーバーに試験パケットの送受信を開始するように指示を送ります。
4.4 実行例
簡単な動作試験を行いたいときは、Ethernetスイッチを二つ用意して図4-1に示すような構成を組んで、試験を行ってください。
【図 4-1】試験環境の構成例（画像をクリックして拡大表示）
以下に実行結果の例を示します。
【図 4-2】実行結果例（画像をクリックして拡大表示）
5 使用上の注意
5.1 使用環境
Etherbeatは、大量のパケットを生成することができます。ネットワークシステムに負荷を掛ける実験は、必ず閉ざされた実験用システムの中で行ってください。実際に運用されている環境では使用しないでください。
仮想IPv4/IPv6アドレスを使用する場合は、他のホストやネットワーク機器の実アドレスと衝突しないように設定してください。
5.2 試験パケットの上位プロトコル
Etherbeatが生成する試験パケットはIPの標準ヘッダーを持っています。IPでカプセル化されているデータは独自のデータで、UDPでもICMPでもありません。IPヘッダーのプロトコルフィールドには実験用の番号253（RFC3692）が入っています。スクリーニングルーターを経由する実験を行う場合、上位プロトコル番号が253のパケットを通過させてください。
IPv6でも実験用プロトコル番号253ならびに254は有効です。これは、RFC4727でも確認されています。しかしながら、IPv6プロトコルの実装によっては、IPv6基本ヘッダーのNext Headerフィールドに253が入ったパケットを破棄してしまうことがあります。このことから、EtherbeatでIPv6を利用する場合、IPv6基本ヘッダーのNext Headerフィールドに「宛先オプション(IPPROTO_DSTOPTS)」を指定し、IPオプションヘッダーのNext Headerフィールドに253を含めた試験パケットを生成します。IPオプションのタイプは0x5eです。IPオプションのタイプについてはRFC2460をご覧ください。
IPv4を使用する場合は、DS(Differentiated Services)フィールドに0x03を入れます。一方、IPv6を使用する場合はTC(Traffic class)フィールドに0x03を入れます。この点についてはRFC4727をご覧ください。
5.3 間隔のゆらぎ
プログラムを繰り返し実行すると、実行結果として表示されるパケットの間隔は常に同じではなく、毎回に異なります。
複数のプロセスが同時に実行されているLinuxでは、スケジューラがプロセスの実行を制御します。プロセスがスリープ状態に入るとスケジューラは他のプロセスにCPUなどを使う権利を渡します。その後、スリープしているプロセスが目覚めて後続のタスクを実行しようとしたとき、即座に実行できるとは限りません。例えば、他に優先度の高いタスクが順番待ちをしている場合、スリープから目覚めた後続のタスクは待たされます。
【図 5ー1】に示すプログラムコードを実行すると、毎回違う結果が表示されます。
このコードをgccでコンパイルするときは、-lrt を添えてください。
host$ gcc -Wall -lrt -o nsleep nsleep.c
----------------------------------------------------------------------
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>
int main(int argc, char *argv[])
{
int i;
struct timespec sleep_ts, start_ts, end_ts, pass_ts;
if (argc < 2) {
printf("A numeric argument is required.\n");
return EXIT_FAILURE;
}
sleep_ts.tv_sec = 0;
sleep_ts.tv_nsec = strtol(argv[1], NULL, 10);
if (errno) {
perror("ERROR: strtol() in main ");
return EXIT_FAILURE;
}
for (i=0; i<10; i++) {
if (clock_gettime(CLOCK_REALTIME, &start_ts) < 0) {
perror("ERROR: clock_gettime() before nanosleep() ");
return EXIT_FAILURE;
}
if (nanosleep(&sleep_ts, NULL) < 0) {
if (errno != EINTR) {
perror("ERROR: nanosleep() in main ");
return EXIT_FAILURE;
}
}
if (clock_gettime(CLOCK_REALTIME, &end_ts) < 0) {
perror("ERROR: clock_gettime() after nanosleep() ");
return EXIT_FAILURE;
}
pass_ts.tv_sec = end_ts.tv_sec - start_ts.tv_sec;
pass_ts.tv_nsec = end_ts.tv_nsec - start_ts.tv_nsec;
if (pass_ts.tv_nsec < 0) {
pass_ts.tv_sec -= 1;
pass_ts.tv_nsec += 1000000000;
}
printf("%ld.%09ld sec.\n", pass_ts.tv_sec, pass_ts.tv_nsec);
}
return EXIT_SUCCESS;
}
----------------------------------------------------------------------
【図 5-1】プログラムコード nsleep.c
5.4 間隔の最小値
間隔に数マイクロ秒程度の短い時間を指定しても、期待通りの結果は得られません。
【図 5-1】に示したプログラムを、引数として1000000を添えて実行すると、ハードウェアの違いによりますが、その実行結果は1ミリ秒より数十（10?30）マイクロ秒大きな結果が表示されます。
----------------------------------------------------------------------
host$ ./nsleep 1000000
0.001018812
0.001015667
0.001009846
0.001009473
0.001009215
0.001007617
0.001008293
0.001018701
0.001015667
0.001028545
----------------------------------------------------------------------
【図 5-2】nsleep.cを実行した結果
この数十マイクロ秒の中にはclock_gettime()に要する時間が含まれていますが、それは1?2マイクロ秒程度に過ぎません。この遅延の大部分は、スリープ状態にあるプロセスが指定時間が経過してから再び実行可能になるまでに要する時間です。
Etherbeatを起動し、間隔に1マイクロ秒（0.000001000秒）を指定して片方向にパケットを流すと、実際のパケットの間隔は数十（20?30）マイクロ秒になります。これは、パケットを送信したり、受信したパケットを分析したりするのに時間を要し、かつスリープしていたプロセスがアクティブになる時に遅延が発生するからです。同じ1マイクロ秒の間隔でも双方向にパケットを流すと、実際の間隔はさらに大きくなります。これは送信プロセスと受信プロセスがそれぞれ1つ増えるからです。このときに結果的に得られる間隔はプログラムを実行するために必要な間隔であり、これよりも短い間隔で試験パケットを送受信することはできません。
また、試験パケットの間隔が短すぎると、受信処理が間に合わなくて試験パケットを取りこぼすことがあります。
5.5 Ethernetスイッチのエージングタイム
Ethernetスイッチを経由する実験を行う場合、EthernetスイッチのアドレステーブルにEthernetアドレスが何秒間保持されるか注意してください。EthernetスイッチはUnknownアドレス宛のフレームをすべてのポートに転送します。中には、転送効率の低下を回避するためにUnknownアドレスが発生したら自らARP Requestを発信するEthernetスイッチもあります。このようなEthernetスイッチの動作はEtherbeatの実行結果に影響を与えます。具体的には、Etherスイッチが宛先Ethernetアドレスを学習していない状態で高いトラフィックを掛けると、周期的に試験フレームを消失することがあります。
----------------------------------------------------------------------
2009/07/21 16:10:47 [ifA --> ifB] (Receiver) is ready.
2009/07/21 16:10:47 [ifA --> ifB] (Transmitter) is ready. Transmittig starts 3 seconds later.
2009/07/21 16:10:47 [ifA --> ifB] (Receiver) received the pre-packet.
2009/07/21 16:10:50 [ifA --> ifB] (Transmitter) start.
2009/07/21 16:10:52 [ifA --> ifB] (Receiver) 3 frame(s) were lost in 0.003995181 sec.
2009/07/21 16:10:54 [ifA --> ifB] (Receiver) 2 frame(s) were lost in 0.002996863 sec.
2009/07/21 16:10:56 [ifA --> ifB] (Receiver) 2 frame(s) were lost in 0.002997542 sec.
2009/07/21 16:10:58 [ifA --> ifB] (Receiver) 2 frame(s) were lost in 0.002997990 sec.
2009/07/21 16:11:00 [ifA --> ifB] (Receiver) 3 frame(s) were lost in 0.003995307 sec.
2009/07/21 16:11:00 [ifA --> ifB] (Receiver) finish. 9988 frames have been recived. the mean time is 0.000999958 sec.
2009/07/21 16:11:00 [ifA --> ifB] (Transmitter) finish. 10000 frames have been transmited.
----------------------------------------------------------------------
【図 5-3】周期的にパケットを失う例
Etherbeatでは、このような事態を避けるために試験パケットの送信に先立って、試験に用いる二つ（送信用と受信用）のインターフェースから自IPアドレスをターゲットにしたARPパケットを一斉同胞し、Ethernetスイッチが受信側インターフェースのEthernetアドレスを学習できるようにしています。
IPv6を用いる場合は、試験パケットの本格的な送受信を始める前に重複アドレスを検出 (Duplicate Address Detection) するために近隣要請 (Neighbor solicitation) メッセージを試験に用いるインターフェースから送信します。これによりEthernetスイッチが受信側インターフェースのEthernetアドレスを学習することを可能にしています。
ただし、試験パケットの送信が長時間におよび、EthernetスイッチがEthernetアドレスを保持している時間を越えたときは、その時点から周期的に試験パケットを消失することがあります。以下に示す例は、通信経路にあるEthernetスイッチのエージングタイムが約5分のときの例です。パケットの送信が始まって5分後から周期的にパケットを取りこぼしています。
----------------------------------------------------------------------
2009/07/21 17:20:54 [ifA --> ifB] (Receiver) is ready.
2009/07/21 17:20:54 [ifA --> ifB] (Transmitter) is ready. Transmittig starts 3 seconds later.
2009/07/21 17:20:54 [ifA --> ifB] (Receiver) received the pre-packet.
2009/07/21 17:20:57 [ifA --> ifB] (Transmitter) start.
2009/07/21 17:25:44 [ifA --> ifB] (Receiver) 2 frame(s) were lost in 0.002996762 sec.
2009/07/21 17:25:46 [ifA --> ifB] (Receiver) 3 frame(s) were lost in 0.003995214 sec.
2009/07/21 17:25:48 [ifA --> ifB] (Receiver) 3 frame(s) were lost in 0.003994715 sec.
2009/07/21 17:25:50 [ifA --> ifB] (Receiver) 2 frame(s) were lost in 0.002997202 sec.
2009/07/21 17:25:52 [ifA --> ifB] (Receiver) 3 frame(s) were lost in 0.003995296 sec.
2009/07/21 17:25:54 [ifA --> ifB] (Receiver) 2 frame(s) were lost in 0.002997061 sec.
2009/07/21 17:25:56 [ifA --> ifB] (Receiver) 2 frame(s) were lost in 0.002997494 sec.
2009/07/21 17:25:58 [ifA --> ifB] (Receiver) 2 frame(s) were lost in 0.002997296 sec.
2009/07/21 17:26:00 [ifA --> ifB] (Receiver) 3 frame(s) were lost in 0.003995416 sec.
2009/07/21 17:26:02 [ifA --> ifB] (Receiver) 2 frame(s) were lost in 0.002997680 sec.
2009/07/21 17:26:04 [ifA --> ifB] (Receiver) 3 frame(s) were lost in 0.003995390 sec.
2009/07/21 17:26:06 [ifA --> ifB] (Receiver) 3 frame(s) were lost in 0.003995073 sec.
2009/07/21 17:26:07 [ifA --> ifB] (Receiver) finish. 309970 frames have been received. The mean time is 0.000999969 sec.
2009/07/21 17:26:07 [ifA --> ifB] (Transmitter) finish. 310000 frames have been transmited.
----------------------------------------------------------------------
【図 5-4】スイッチのエージングタイムを越えてから周期的にパケットを失う例
なお、このような問題は片方向通信の試験を行うときに生じる問題で、双方向通信の試験を行うときはこのような問題を気にかける必要はありません。
5.6 受信タイムアウト
受信プロセスはTimeoutで指定された秒数の間、インターフェースに試験パケットがひとつも届かなければタイムアウトしてプロセスを停止します。
受信プロセスがタイムアウトを理由に停止した場合でも、送信プロセスは実行し続けている場合があります。このような場合はCANCELボタンで送信プロセスを停止してください。
片方向通信の場合と双方向通信の場合とではタイムアウトするタイミングが異なります。片方向通信の場合、受信インターフェースは他のインターフェースから送り出されたパケットを受信します。そのため、他のインターフェースからのパケットが届かなくなれば指定時間経過後にタイムアウトします。これに対して双方向通信の場合、他のインターフェースからのパケットが届かなくなってもタイムアウトしません。
双方向通信の場合、インターフェースは送信と受信の二つの働きを行います。双方向に働くインターフェースでは、外へ向かう（OUTGOING）パケットはデバイス内部でループバックされて、自インターフェースで受信されます。そのため、他のインターフェースからのパケットが届かなくてもループバックされたパケットを受信してしまうのでタイムアウトしないのです。双方向通信でタイムアウトが発生するのは、インターフェースで最後のパケットを送信したあと、秒数の間にパケットが一つも届かない場合です。
受信プロセスは最後の試験パケットの番号（連番）を知っており、通常、その番号を持った試験パケットを受信するとプロセスを終了します。逆にいうと、受信プロセスは最後の試験フレームが届くまで受信を繰り返します。
稀に、送信プロセスがすべての試験パケットを送出したにも関わらず、受信プロセスが指定された秒数の間、最後のパケットを待ち続けることがあります。
受信プロセスが最後の試験パケットを受信できない状況は2つ考えられます。一つは、試験環境下で通信経路がつながっていないときに最後の試験パケットが送出された場合。もう一つは、送信周期が速すぎるために受信処理が追いつかず、最後のフレームが到着してもシステムバッファがいっぱいになっている為にそれが破棄された場合です。
5.7 近隣ルーターの検索
IPv6の近隣ルーターを検索するとき、ルータがルーター広告（Router Advertisement）を送信できなければなりません。Linuxをルーターとして使用する場合は、radvd等のパッケージをインストールしてください。
Etherbeatは近隣ルーターを探すためにルーター要請（Router Solicitation）を送信し、500ミリ秒間、ルーター広告を待ちます。500ミリ秒の間にルーター広告がない場合は、もう一度ルーター要請を送信します。Etherbeatは2回まで再送を繰り返します。3回目のルーター要請の送信後も、ルーター応答が時間内に得られない場合は、近隣ルーターは使えないものとします。このような場合は、数秒待って、もう一度操作（Startボタンのクリック）を繰り返してみてください。
6 動作環境
- 【対象OS】
- ・ Linux 2.6 for x86
- 【動作確認済のディストリビューション】
- ・ Debian GNU/Linux 5.0.2
- ・ Ubuntu 9.04
- 【デスクトップ環境】
- ・ GNOME 2.22.1
- 【インターフェースの設定】
- ・ 試験用インターフェースは稼働中（状態がRUNNING）である必要があります。IPv4/IPv6アドレスは設定していても、いなくてもかまいません。
7 ダウンロード
ここから、本ソフトウェアを含んだファイルをダウンロードすることができます。
MD5(etherbeat_2-0-0.tar.gz)= fcb6428b883d2a46ee2e628cad8ea0f8
8 より良く使用するために
サーバー（プログラム）を実行するとき、リアルタイムアトリビュートを変更することをお勧めします。リアルタイムアトリビュートを変更してサーバーを実行したいときは、次のようにタイプしてください。
host# chrt 1 ./ethbeatd -p 1440
chrtの詳しい説明は、オンラインマニュアルchrt(1)をご覧ください。
リアルタイムアトリビュートを上の例のように変更してサーバーを起動したとき、間隔に0を指定すると大量のパケットを失う結果になります。この場合、送信プロセスは一つの試験パケットを送り出してもスリープせずに立て続けに試験パケットを送出します。受信プロセスは実行する機会を得られないまま、そのうち受信インターフェースでバッファがいっぱいになり、後続のパケットがこぼれ落ちて失われます。また、0に近い値、例えば10ナノ秒（0.000000010秒）などを設定した場合も、パケット間隔に0を指定したときと同様の結果になります。
また、高い負荷を掛ける場合は、サーバーとクライアントを別々のホストで実行し、サーバーを実行するホストでは、出来るだけ他のプロセスを停止させておくことをお勧めします。もっとも単純な方法はシステムをシングルユーザーモードに移行することです。
もし、試験パケットが原因不明で失われることがあれば、その設定を保存したあと、サーバーを実行しているホストの二つのインターフェースをクロスケーブルで直接相互接続し、同じ設定で何度か繰り返し試してみてください。やはり試験パケットが落ちるのであれば、原因はサーバーを実行しているホスト側にあると考えられます。もし、試験パケットが落ちないのであれば、原因はネットワーク機器側にあると考えられます。
9 使用許諾
このソフトウェアは、使用目的を問わず、以下に記す「11 責任」に同意するかぎり誰でも無料で使用することができます。
10 保証
有限会社立志コンピュータは本ソフトウェアに関して、実行および実行結果など一切保証しません。
11 責任
有限会社立志コンピュータはいかなる場合においても、ユーザが直接または間接的に被った損害、利益の喪失などについて、それらを賠償する責任を負わないものとします。これに同意しない場合は本ソフトウェアを使用しないでください。
12 著作権
本ソフトウェアの著作権はすべて有限会社立志コンピュータが保有しています。
著作権者の文書による承諾を得ずに、本記事の一部または全部を無断で複写・複製・転載することはできません。