John Peters 著

ますます複雑になる今日のネットワーク環境は、ネットワーク管理者やプログラマーにとって興味深いチャレンジの場となっています。TCP/IPパケットは発信元から宛先まで多くのデバイスを介さなければならないため、ちょっとした構成エラーによってデータの宛先ミスや損失が引き起こされてしまいます。セッションがランダムに切断される、パフォーマンスの低下、トラフィックの高負荷時における予期しないネットワーク障害など、困った症状に悩まされる場合もあります。

通常、これらの問題をデバッグする最良の方法は、パケット・レベルでのデバッグです。パケット・レベルでのデバッグと聞くと複雑に思われますが、そうとは限りません。その上、ネットワークのプロにとっては、パケットやプロトコルの基礎を学ぶ絶好の機会でもあるのです。 ネットワーク問題のデバッグは、4つの単純なステップに分けられます。これらをマスターすれば、どんなネットワーク問題が起こってもiSeriesとコマンドとここで説明する方法を使うだけで解決できるようになります。

コミュニケーションの高速道路
パケット・レベルでのデバッグという概念は、皆さんがよくご存知の類似例を使って分かりやすく説明できます。通信ネットワークを高速道路に置き換えて考えてみましょう。高速道路上の交通を支援する基本的な構造があります。LAN（イントラネット）構造は市内で利用されている主要道路に似ていますが、これらは、コンクリート（トークンリング）、アスファルト（イーサネット）、土（非同期）などさまざまな素材で建設されています。

この地元の高速道路は、より大規模な高速道路システムや州間高速道路（WAN）と合流する場合があります。州間高速道路システムは異なる建設素材（たとえば、フレーム・リレー、ATMテクノロジーなど）を使用しており、LANプロトコルの内容をカプセル化したり内容全体を包括したりしています。車両（パケット）は州間高速道路（WAN）を使って州を越えて移動し、地元の高速道路システム（LAN）を経て、最後には特定の道の住所に行き着きます。ここで、車両（パケット）は、その積み荷（情報）を配送するわけです。e-コマースのシナリオでは、ベンダー（アプリケーション）は、この積み荷（ユーザー購買情報）を使ってユーザー宛に送付される製品を製造することになっています。

いったん高速道路が構築されれば、車両（パケット）は高速道路が続く限りそれに沿って目的地を目指します。さまざまな機能を持つさまざまな車両タイプ（プロトコル）もほとんど同時に同じ高速道路を行き交えるようになります。各車両タイプ（プロトコル）には、目的地に着き次第、その車両の積み荷の中身を判断してくれる独自のサービス・ステーション（ホスト）が必要です。

高速道路のインターチェンジ（ルーターやスイッチ）は、交通を経路指定して適切な場所に導いたり、時には入り口を封鎖して交通（フィルター・パケット）を止めたりすることさえあります。何らかの理由で目的地に到達できなかった車両は、乗り捨てられてしまいます（脱落パケット）。ここで、脱落パケットの原因を定義する方法と脱落パケットを防ぐ方法をご説明しましょう。

乗り捨てられた車両の発見
図1のフローチャートは、クライアントが、アプリケーション（たとえばFTP、Telnet、SMTP、PINGなど）にセッションをスタートさせることで、どのようにアウトバウンド・トラフィックを開始するかを示すものです。TCP/IPスタックはこの試行を見つけ、まずハードウェアに、次にネットワークに、さらに巨大なファストパケット・ネットワーク、すなわちクラウドへの配置のための交換に渡されるネットワーク言語にその要求を変換します。

たとえば、ネットワークの反対側にあるホストに対してTelnet（アプリケーション・レイヤー）セッションをスタートできないという問題をデバッグすると仮定してみます。パケットがどこかに捨てられようとしているのです。理論的に言えば、ネットワークのこちら側、ネットワークの向こう側、その途中のレイヤーのいずれかに問題があることになります。それでは、どうすれば乗り捨てられた車両を見つけられるのでしょうか。

ネットワークを小さい部分に分け、ひとつひとつをPINGを使ってテストしてみましょう。PINGとは、インターネット制御メッセージ・プロトコル（ICMP）を使う下層レイヤーのTCPプロトコルです。ICMPは保証済みのパケット送達を必要としないため、ネットワークの問題を明らかにするには最適です。iSeries PINGコマンドを使用するアプリケーションは、ICMPパケットを一定のインターバルで、たとえば毎秒1つという割合で送信してから、直ちに応答を待機します。各PINGパケットがネットワーク上で応答を確認されるチャンスは1度だけです。応答が返ってこないと、「No Response From Host（ホストから応答がありません）」という状況が知らされます。

ステップ1. ループバックにPINGする。クライアントからPINGを使ってTCP/IPスタックが正常に応答しているかを確認するには、ループバック・アドレス127.0.0.1にPINGします。すべてのパケットが応答することを確認できるはずです。この基本テストは、ステップ2に進む前に実行しなければなりません。テストが失敗した場合、次のうちのいずれかを実行します。

1. インターフェースをいったん停止してから開始して再生する。

2. ENDTCPの後にSTRTCPと入力してTCPを再生する。

両方を実行しても問題が解決しなかった場合は、下記URLのIBMサポート・センターにアクセスして、さらなるデバッグ方法を見つけてください。 http://www-912.ibm.com/（英文サイト）

ステップ2. ローカルIPアドレスにPINGする。このステップでは、図1で示すモデルのアプリケーション、スタックおよびハードウェア・コンポーネントをテストします。（いよいよ私道から実際の車道に出ます。）IPアドレス（ホスト名ではなく）を使ってネットワークのDNS問題を除外することに注意してください。CFGTCP（TCP/IPの構成）コマンドを使い、オプション1を指定すればシステムのIPアドレスがわかります。IPアドレスが10.10.10.17であれば、PING 10.10.10.17というコマンドを発行します。注意：iSeriesではTCPアドレスを単一引用符で囲まなければなりません。

このステップは、100パーセント正常に動作しなければなりません。そうでない場合は、次の方法でスタックからハードウェアに至るまで「詰まったパイプを掃除」します。

1. このアドレスに対するインターフェースを終了してから、回線をオフに変更してもう一度元に戻す。

2. 必要に応じてTCPを開始してから停止する。

F11キーを押すと、CFGTCPオプション1でネットワーク・インターフェース状況が表示されます（図2および図3）。インターフェースがアクティブであれば、回線記述やTCP/IPもアクティブです。

ステップ3. ルーターのIPアドレスにPINGする。周辺も少しドライブしてみましょう。ルーターのIPアドレスを見つけるには、iSeriesのコマンド・ラインにCFGTCPと入力します。オプション2を選択して、iSeriesの*DFTROUTE（ゲートウェイ）アドレスを表示させます。これは、「Next Hop（次のホップ）」という名前を持つフィールドに表示されるルーターのアドレスのことです（図4）。

すべてのPINGは100パーセント正常に動作しなければなりません。そうでない場合は、ハードウェアとルーター間に問題があります。この場合（ルーターへのPINGが失敗した場合）、スイッチ、MAU（マルチステーション・アクセス装置）、ハブ、ワイヤー、トランシーバー、ルーターそのもののいずれかまたは複数のものに問題が発生している可能性があります。またネットワーク・トラフィックへの高負荷により、ルーターで輻輳が起こっている可能性も考えられます。ネットワーク管理者と協力して問題を解決してください。あなた自身がネットワーク管理者の場合は、ルーターの統計カウンターにアクセスして、ルーターのトラフィック量が多すぎないかやルーターがパケットを除去していないかを確認してください。

この時点で依然としてPINGが正常に動作していない場合は、iSeriesの製品活動記録ログ（Product Activity Log、PAL）を調べてみてください。PALには、ハードウェアからネットワークに至るまでに起こった問題が示されています（図1参照）。PALを確認するには、STRSST（Start System Service Tools、システム・サービス・ツールの開始）と入力してから、オプション（1、1、1、5、1）を順番に選択します。オプションを入力するたびにEnterキーを押してください。ここで、問題のあるインターフェースに関連する回線名を探します。問題がLANレベル（たとえば、輻輳、ハードウェア限界、トランシーバーに関する問題）にあれば、そのことが分かるはずです。

PALの入力項目を見ているときに、図5のようなものに気づく場合があります。ここから詳細なレポートを表示できるようになっています。図6は、フレーム・リレー・パケットに予期しない問題が発生したことを示すレポートです。この場合、ユーザーはIBMサポート・センターに連絡してエラーの原因を究明してもらう必要があります。図7は、トークンリング・ネットワークに輻輳タイプの問題が発生していることを示すレポートです。このような問題は重大ではないにしろ、引き続きアプリケーション・レイヤーにも問題が発生していないかさらに調べてみる方がよいでしょう。

ステップ4. リモートIPアドレスにPINGする。さて、ルーターまではすべてが正常に作動しているようです。それでは、ネットワーク全体を越えて最終地点の宛先まで行ってみましょう。通常、宛先までのパス上のルーターは、透過状態になっています。リモートIPアドレスにPINGできない場合は、ゲートウェイ・ルーターにPINGできるかどうか確認してください。

このステップで問題があった場合は、ISP（インターネット・サービス・プロバイダー）または宛先のネットワーク管理者に連絡して、なぜPINGパケットに対する応答が得られないかを問い合わせた方がよいでしょう。障害の原因のひとつとして、宛先ネットワーク側のパケット・フィルターやファイアウォールの存在が考えられます。

ネットワーク・トラフィックの問題解決
これら4つのステップは、あらゆるTCP/IPの問題を判別するときの基礎となります。これらのステップに従えば、ネットワーク問題の発生源を特定し、当て推量ではなくご自身で問題を解決できるようになるでしょう。
iSeries通信トレース機能を使ってパケットを詳しく見る方法については、近い将来ご報告します。お見逃しなく。

John Peters Minnesota州RochesterのAS/400 LNE（大規模ネットワーク環境）研究所に勤務するKeane, Inc.の主任コンサルタント。1987年以来IBM関連のコンサルタントとして、AS/400 TCP/IP、非同期、BISYNC（2進データ同期）およびSNAに対するサポートを提供。また、S/36ディスケット、テープおよびプリンター・データ管理に対する製品サポートも行っています。