QoS RSVP のトラブルシューティング

[アーティクル]
07/12/2010

QoS の導入プロセスの間には、以下のトラブルシューティングの手順をいくつか実行することが必要になる可能性があります。

トピック

QoS ACS サーバーの動作の検証
セッションに対する QoS RSVP 要求がポリシーによって拒絶されているかどうかの検証
クライアントの間のネットワークパスの検証
ルーターを経由する QoS RSVP パケットの検証
QoS RSVP のトレース
レイヤ 2 スイッチにおける 802.1p タグの検証
パスに含まれる RSVP 対応のノードの検証

QoS ACS サーバーの動作の検証

QoS ACS サーバー (SEA-NA-FP-04 と SEA-NA-FP-05、および MIL-EU-FP-03 と MIL-EU-FP-04) が正常に動作していることを検証する際には、QoS 受付制御サービスが既に開始されていれば手動で停止し、改めて開始する必要があります。これらの操作を行うには、[サービス] スナップインを使用するか、または [コマンドプロンプト] に次のコマンドを入力して実行します。

net stop rsvp
net start rsvp

QoS 受付制御サービスを手動で開始した後でシステムログを表示すると、QoS 受付制御サービスが正常にロードされていることを検証できます。

システム ログを表示するには

[スタート] メニューから [プログラム] をポイントし、[管理ツール] をポイントして、[イベントビューア] をクリックします。
[システムログ] をクリックし、[ソース] 列に [RSVP] と表示されている [情報] ログファイルを探し出します。
最初に作成された [情報] ログファイルをダブルクリックします。QoS 受付制御サービスが開始されたことを示す図 1 のような [情報] ログファイルが表示されます。QoS 受付制御サービスが正常に開始されたことは、さらに図 2 と図 3 を含む一連の [情報] ログファイルの内容によって確認できます。

図 1: QoS ACS RSVP サービスの最初のイベントログ

QoS ACS が正常に開始された後でイベントログに記録される 2 つ目のイベントは、図 2 のようになります。

qos01-07
図 2: QoS ACS の 2 つ目のイベントログ

QoS ACS が正常に開始された後でイベントログに記録される 3 つ目のイベントは、図 3 のようになります。

qos01-08
図 3: QoS ACS の 3 つ目のイベントログ

これらの 3 つのイベントログの内容を表示すると、QoS ACS サーバー上の QoS 受付制御サービスが正常に動作していることを確認できます。

NetMeeting セッションが初めて開始されるとき、すべての QoS RSVP 要求は、そのサブネットの QoS ACS サーバーに宛てて転送されます。QoS ACS サーバーでは、要求を発行したのが、ネットワーク上の認証されているユーザーなのか、認証されていないユーザーなのかを検証します。トラブルシューティングの手順としては、[QoS 受付制御] スナップインで、 [認証されていないユーザーのプロパティ] の既定の設定を変更できます。

セッションに対する QoS RSVP 要求がポリシーによって拒絶されているかどうかの検証

[スタート] メニューから [プログラム] をポイントし、[管理ツール] をポイントして、[QoS 受付制御] をクリックします。
[エンタプライズ設定] をクリックします。
[認証されていないユーザー] をダブルクリックし、[フローの制限] タブをクリックします。
[データ速度] と [ピークのデータ速度] の [リソースの許容範囲内の最高速度] をクリックします。
[期間] の [制限なし] をクリックします。
[統計の制限] タブをクリックし、[データ速度] ボックスと [ピークのデータ速度] ボックスの、 [リソースの許容範囲内の最高速度] をクリックします。
[フローの数] の [制限なし] をクリックします。
[OK] を 2 回クリックします。

上記の[認証されていないユーザーのプロパティ] ダイアログボックスの設定変更を QoS 対応の NetMeeting セッションに対して行う場合、クライアントにログオンしているユーザーは認証されていないことになります。この問題を解決するには、ユーザーアカウントが Active Directory に登録されていることを確認し、登録されていない場合は登録します。

また、QoS ACS サーバーでは、サブネットに対して制限力を持つポリシーが存在するかどうかも検証されます。サブネットに対して設定されているポリシーによって、 QoS RSVP 要求が拒絶されているかどうかを確認するには、問題となっているサブネットに設定されているポリシーを削除してみます。

QoS ACS のサブネットに対する既存のポリシーを削除するには

[スタート] メニューから [プログラム] をポイントし、[管理ツール] をポイントして、[QoS 受付制御] をクリックします。
[サブネットワークの設定] をクリックします。
対象となるサブネットを右クリックします (たとえば、Seattle サイトの QoS サブネットが対象となる場合は、[172.16.20.0/22] を右クリックします) 。
[プロパティ] をクリックし、[トラフィック] タブをクリックします。
[サービスの制限] の中から任意のポリシーを選択し、[削除] をクリックします。
[OK] を 2 回クリックします。

クライアントの間のネットワークパスの検証

トラブルシューティングを行っていると、2 台のクライアント間のネットワークパスを検証することが必要になる可能性もあります。この情報は、2 台の QoS RSVP クライアント間で通信を行うときに、データが順番に通過していくネットワークコンポーネントを判断する場合に使用できます。このシナリオでは、2 台のクライアントの間のホップを判断するために、tracert ツールを使用します。

最初に、SEA-NA-CLNT-01 の [コマンドプロンプト] で、次のように入力します。

tracert 172.16.132.56

このコマンドを実行すると、SEA-NA-CLNT-01 と MIL-EU-CLNT-01 の間で転送された経路のネットワークホップに関して、図 4 に示すような情報が表示されます。

qos01-09
図 4: tracert 172.16.132.56 の実行結果

次に、MIL-EU-CLNT-01 の [コマンドプロンプト] で、次のように入力します。

tracert 172.16.20.56

このコマンドを実行すると、MIL-EU-CLNT-01 と SEA-NA-CLNT-01 の間で転送された経路のネットワークホップに関して、図 5 に示すような情報が表示されます。

qos01-10
図 5: tracert 172.16.20.56 の実行結果

tracert ツールの実行結果として得られるこれらの情報を使用すれば、ネットワークパスに含まれる、ルーターのインターフェイスに関するトラブルシューティングを集中的に行うことができます。

ルーターを経由する QoS RSVP パケットの検証

ルーティング経路として構成されているルーターとレイヤ 3 スイッチにおいて、RSVP 対応の各インターフェイス上で QoS RSVP パケットが正常に送信および受信されていることを検証するには、次に紹介するスクリプトを実行します。

注意
次のスクリプトは、Telnet 接続を使用してルーターやスイッチにログオンするか、または直接コンソールポートにスクリプトを入力することによって、ユーザーモードとイネーブルモードのどちらからでも実行できます。

!check status of rsvp

sh ip rsvp  request
sh ip rsvp  reservation
sh ip rsvp  sender

図 6 は、SEA-NA-CLNT-01 と MIL-EU-CLNT-01 の間に、 QoS 対応の NetMeeting セッションが確立されているときに、上に紹介したスクリプトを SEA-NA-CISCO-01 に対して実行した場合に得られた出力を示しています。

qos01-15
図 6: SEA-NA-CISCO-01 に対してスクリプトを実行した場合の出力

QoS RSVP のトレース

これまでに紹介した手順を実行してトラブルシューティングを試みたにもかかわらず、QoS RSVP が正常に動作するようにならない場合は、2 台のクライアントの間で通信の同時トレースを実行することが推奨されています。ネットワークモニタを使用すると、2 台のクライアントの間の QoS RSVP 通信を詳細に分析できます。

トレースを開始する前に、NetMeeting を起動しておきます。ただし、この時点ではまだ 2 台のクライアントの間にセッションを確立しません。次に、転送パスに含まれている、 QoS ACS サーバー上の QoS 受付制御サービスを一度停止してから、改めて開始します。その後で、各クライアント上のネットワークモニタでトレースを開始してから、 NetMeeting セッションを開始します。各クライアントが通話に参加したことが NetMeeting によって示された後で、約 60 秒待機してから通話を終了します。これだけの時間待機すれば、通話に関連するすべてのネットワークコンポーネントの間で QoS RSVP 通信が十分に行われます。通話を終了したすぐ後で、2 台のクライアントで実行しているトレースを停止します。

ネットワーク モニタを使用してクライアントの間の QoS RSPV 通信をトレースするには

[スタート] メニューから [プログラム] をポイントし、[管理ツール] をポイントして、[ネットワークモニタ] をクリックします。
[キャプチャ] メニューの [ネットワーク] をクリックします。次に、トレースする対象のネットワークをクリックし、[OK] をクリックします。
トレースを開始するために、[キャプチャ] メニューの [開始] をクリックします。
2 つのクライアント上で NetMeeting を開始し、セッションを確立します。次に、セッションが確立した状態で 60 秒待機してから、セッションを終了し、[キャプチャ] メニューの [停止] をクリックします。

レイヤ 2 スイッチにおける 802.1p タグの検証

802.1p 対応のネットワークと 802.1p に対応していないネットワークの間でパケットを転送する際に、パケットに 802.1p タグを添付して送信した場合、これらのネットワークを接続しているスイッチは、802.1p に対応していないネットワークにパケットを転送する前に、タグを削除するように構成できます。このように構成していない場合、802.1p に対応していないデバイスではタグを認識できないために、パケットが破損していると誤って解釈され、パケット自体が破棄される可能性があります。

タグが添付されたパケットを破棄しているネットワークコンポーネントを識別するには、TCP/IP ツールの pathping にパラメータ -T を指定して実行します。このパラメータを指定すると、タグが添付されたパケットを破棄しているネットワークコンポーネントを識別するためのタグが、パケットに添付されて送信されます。

パスに含まれる RSVP 対応のノードの検証

2 台のクライアントの間のパスに含まれるノードのうちで RSVP 対応のノードを識別するには、TCP/IP ツールの pathping にパラメータ -R を指定して実行します。このパラメータを指定すると、パスに含まれる各ノードが RSVP に対応しているかどうかがテストされます。

ノードが RSVP に対応していると認識されるのは、プロトコル 46 メッセージに応答する (または、タイムアウトになる) 場合です。反対に、ICMP プロトコルの非到達エラーメッセージが送信される場合は、RSVP に対応していないと認識されます。ただし、ノード上で RSVP サービスが実行されていない場合は ICMP プロトコルの非到達エラーメッセージが返されるので注意が必要です。

関連資料

Windows 2000 Server リソースキット購入ページ
Windows 2000 Professional リソースキット購入ページ
Windows 2000 リソースキットの詳細については、こちらを参照してください。

注意
このシナリオにおいて、コンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして紹介したものです。実際のネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、目的とする機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になる、その他の手順については取り上げていません。すべてのシナリオは、特に表記しない限り Windows 2000 を使用してテストされています。また、ブラウザとして Microsoft Internet Explorer 5 以上を推奨します。