ジョン・ピータース著

このシリーズのパート1（「iSeriesを使用するTCP/IPネットワークのデバッグ」
http://www.e-bellnet.com/special/vision/vision_0208.html を参照）では、TCP/IPネットワークにおいてリモートホストに対する応答が得られないという問題の原因を探るための手順は4つのステップに分けられるということを解説しました。以下の4つがそのステップです。

1. ループバックをPINGする
2. ローカルアドレスをPINGする
3. ルータアドレスをPINGする
4. ホストアドレスをPINGする

これらのステップを踏むことにより、クライアント、ネットワーク自体、中間ルータ、ターゲットホストのいずれに問題があるのかを特定することができます。この非常に強力なコマンドは恐らく最も広く使われているネットワーク診断ツールであり、このコマンドをうまく使いこなせればトラブル処理のエキスパートとなることができます。

この稿ではPINGについてもう少し詳しく解説すると共に、OS/400のもう1つのツール、通信トレース機能の使用方法を説明します。これらのトラブルシューティング方法をスキルに加えれば、ネットワークに関連して毎日発生する困難かつ複雑な問題に対応できるだけの能力を身に付けることができます。

まずPINGから開始
問題となっているサーバを特定することができたら、さらにそのサーバの何が問題になっているのかを付きとめなければなりません。これを調べる最も簡単な方法は、そのサーバが自分自身との通信を設定できるかどうかを調べてみることです。PINGは一種のアプリケーションであり、FTPやTelnetなどの別のアプリケーションについてもPINGと同じ方法を使用して問題を確認することができます。

「Never WorksシステムにFTPできない」（よく聞くセリフだと思います）という連絡があったとしましょう。この場合は、問題となっているホストに対して次の操作を行ってみてください。

1. ループバックをFTPする
2. ローカルアドレスをFTPする

これらの操作は両方とも正常にできなければなりません。もしもこれらの操作ができなければ、そのFTPサーバはシステム上で実行されていないと考えた方がいいでしょう。この場合は、FTPサーバを起動すればすべてうまく行くはずです。

問題のマシンが別の場所に置かれていて自分のいる場所にないとしても問題はありません。PINGはどこからでもできますので、そのシステムに対してまずPINGが可能であるかどうかを確認してからFTPを試してみます。PINGができてFTPだけができない場合は、おそらくそのマシン上でサーバがダウンしているのです。

トレース証跡
さて、サーバは起動されて正常に動作していることを確認したとします。しかし、相変わらずユーザは特定のマシンに対して他のマシンからアクセスすることができません。この場合は、通信トレース機能を実行してください。この機能は、コムトレース（Comm Trace）とも呼ばれます。コムトレースは、2台（あるいはそれ以上）のホスト間で行われたパケット交換に関する正確な履歴を記録します。この情報を利用すれば、問題についてより詳しい解析を行うことができます。

どのマシンからトレースを行うかは問題になりませんが、どのマシンを基準に問題を解き明かしていくのかについてはしっかりと認識しておく必要があります。この例では、RCHAS645からRCHAS27AへのFTPができないという苦情が寄せられているものとします。それでは、コムトレースを設定してこれら2つのマシン間のトラフィックを記録する方法を以下に示します。

ステップ1. 起動はクライアントから行い、そこから外部に対して操作を行うようにします。この例では、RCHAS645がクライアントで、そのホストとなるRCHAS27Aからの応答が得られないものとします。まずRCHAS645上で、ローカルIPアドレスを確認することによってトレースが必要な回線を決定します。特定のホスト名に対するIPアドレスは、NSLOOKUPまたはPINGいずれかのコマンドを使用して調べることができます。

PING rchas645
Verifying connection to host system
（ホストシステムへの接続を確認しています）
RCHAS645.RCHLAND.IBM.COM at address 9.5.176.78.
（アドレス9.5.176.78のRCHAS645.RCHLAND.IBM.COM）
No response from host within 1 seconds for connection verification 1. . . .
（接続確認1に対し、1秒以内に応答が得られませんでした）
No response from host within 1 seconds for connection verification 5.
（接続確認5に対し、1秒以内に応答が得られませんでした）
Connection verification statistics: 0 of 5 successful (0 %).
（接続確認の結果：5回中0回成功しました−0%）

この例では、DNSから9.5.176.78というアドレスが返されています。RCHAS27AへのPINGによって返されたホストアドレスは9.5.177.24です。2回のPINGにより、問題となっている2つのIPアドレスが得られました。これら2つのアドレスは異なるIPネットワークに属している、という点に注意してください。つまり、これらのアドレス間でやり取りされるトラフィックは、少なくとも1個のルータを通過することになります。

ステップ2. クライアントであるRCHAS645上で、キーボードからCFGTCPと入力してオプション1を選択してください。図1に示すような画面が表示されます。さて、場合によっては、パケット送出にどのインターフェースが使用されているのかが分かりにくいことがありますが、TCPではいくつかの規則が使用されます。

1. iSeriesがそのネットワーク上にインターフェースを持っていれば、それがそのネットワーク上にパケットを送出します。

2. ネットワーク上にインターフェースがない場合は、デフォルトのゲートウェイを使用する必要があります。

3. 使用しているiSeriesが「1つの物理インターフェースに1つのネットワーク」という原則に則ったものであれば、処理は簡単です。そうでなければ複数のトレースを実行して、どのインターフェースが使用されているのかを決定する必要があります。また、パケットが送出されたインターフェースに再びパケットが戻ってくるとは限りません。これらの問題については、コムトレースの経験を積んでいくことでその解決方法を習得することができます。幸いほとんどのiSeriesホストは、同じインターフェース上でトラフィックの送受信が行われるように設定されています。

ステップ3. すでに記録されている古いコムトレースはすべて消去してください。残っているデータは、ほとんどの場合以前に行われたデバッギング時のものです。コムトレースがすでに設定されているかどうかをコマンドラインから確認することはできません。したがって、古いコムトレースを消去して何もない状態から開始することにより、時間を節約し、混乱を避けることができます。トレースを消去するには、キーボードから次のコマンドを入力してください。

DLTCMNTRC NGBETH933B *LIN

コムトレースが何も記録されていない場合は、「No Communications Trace Exists（通信トレースは何も記録されていません）」というメッセージが表示されます。トレースが存在する場合は、すべてのトレースが消去されます。

ステップ4. STRCMNTRC（Start Communications Trace）コマンドを使用して新たにコムトレースを起動し、特定通信回線における送受信データを記録します（図2）。Configuration objectに対しては回線名、つまりNGETH933Bを指定します。例に示すように、アドレス9.5.177.24にフィルタを設定した場合、Bufferサイズはデフォルトの128Kで問題ありません。Data direction引数を使用すれば、必要に応じて送受信両方のパケットをトレースしたり、一方向のパケットだけをトレースしたりすることができます。場合によっては、送信トラフィックまたは受信トラフィックのどちらかだけをトレースする方が問題を特定しやすくなることがあります。
トレース出力はバッファがいっぱいになるまで蓄積されます。デフォルトでは、データがいっぱいになるとバッファの最初にデータが「ラップ」されます（トレース自体が重ね書きされる）。ラッピングが行われると問題診断に必要なデータが失われることがありますので、トレースするイベントに関する全データを記録することができるように、バッファは十分な容量に設定してください。Number of user bytes to trace引数を指定することにより、各パケットにおいてキャプチャするバイト数を指定することができます。この場合、*MAXを指定するとトレースがすぐにいっぱいになってしまいますので注意してください（ギガビットイーサネットを使用したネットワークの場合は特に）。

最終的な解析
Enterキーを2回押すと、コムトレースの設定が行われてパケットのキャプチャが開始されます。この状態で、問題を再現します。無関係なデータでトレースがいっぱいになってしまわないように、この操作はできるだけ迅速に行ってください。

すぐに問題を再現するために、失敗したPINGをもう一度実行します。

PING RCHAS27A

PINGが完了したら、すぐにコムトレースを終了します。

ENDCMNTRC CFGOBJ(NGETH933B)
　 CFGTYPE(*LIN)

以上の操作で、問題が発生した際にiSeriesからの送受信トラフィックがキャプチャされます。キャプチャしたトラフィックは、PRTCMNTRC（Print Communications Trace）コマンド（図3）を使用して印刷し、その内容を解析することができます。Configuration Object引数には使用している回線名を、Typeには*LINを、Outputには *PRINTを指定し、PINGなどのような非EBCDICアプリケーションの場合、Character codeにはASCIIを指定します。さらにTCP/IPには*YESを指定して、最後にEnterキーを押します。

PRTCMN TRCコマンドには、この他にも多くの引数があります。これらの引数を指定すれば、データにフィルタをかけてコムトレース出力のボリュームを制限し、必要なトラフィックだけを得ることもできます。たとえば、印刷出力を特定のTCP/IPポートだけに制限することが可能です（例：HTTP用の80）。

通常、トレースデータは項目ごとに分けた形で印刷出力されます（図4）。

項目1 トレースがパケットに割り当てたレコード番号を示します。この番号は1から始まって、受信パケットまたは送信パケットが記録されるたびに1つずつ加算されます。

項目2 送受信の別を示します。S = 送信パケット、R = 受信パケット（注：送受信の別は、トレースを実行したマシンを基準に決められます。）

項目3 パケットのデータ長を示します。

項目4 タイムスタンプを示します。

項目5 送信先のMacアドレスを示します。

項目6 送信元のMacアドレスを示します。

項目7 第1層のプロトコルタイプを示します。

印刷出力の2行目は、フレームタイプ（Frame Type）がIPフレームであること、パケット長（Length）が284バイトであること、プロトコル（Protocol）がICMPであることを示しています。その次の項目（Datagram ID）はデータグラムIDを示します。送信元IPアドレス（Src Addr）と送信先IPアドレス（Dest Addr）、およびフラグメントフラグ（Fragment Flags）は、IPヘッダからフォーマットされます。

IPヘッダの行（IP Header）は、回線上を流れる実際のデータを16進表示したものです。その次の行はIPオプション（IP options）で、さらにその下の行にはプロトコルタイプを示すICMPという値が表示されています。この例におけるプロトコルはICMPによるエコー要求（Echo Request）、すなわち、PINGと呼ばれるものです。

最後にパケットのペイロード部分が印刷されます。例ではDataと表示されています。

コムトレースの出力を見ると、このエコー要求に対して応答が返されていないことが分かります。このことから、問題は「ネットワーク」部分にあることがわかります。ネットワークはこの通信ページの物理的／論理的な部分を構成しており、iSeriesを基準に見るとiSeriesアダプタの外部にあります。それでは、なぜこの部分に問題があることが分かるのでしょう。それは、IOP層においてはコムトレースが最後に行われる処理だからです。トレースによって以上のことが分かれば、問題はほとんど解決したようなものです。

今後の予定
ここに挙げた簡単な例で、ネットワークに関する問題の原因を特定してこれを解決するために、PINGとコムトレースをどう使えば良いかがお分かりになると思います。これら2つのツールについては他にも多くの使い方があります。また、iSeriesにはこれらの他にもTCP/IPネットワークのデバッグに使用できるツールがあります。このシリーズでは、今後もこれらツールの使用方法をご説明していきます。引き続きご愛読ください。

ジョン・ピータースは、iSeriesにおけるネットワーク、PC、Linux環境ついて豊富な知識を持つミネソタ州カッスン在住のプログラミング／ネットワークコンサルタントで、JavaおよびPHPに深い関心を寄せています。。