Cisco VPN Solutions Center: MPLS Solution プロビジョニング ガイド
VPNSC: MPLS Solution トラブル シューティング ガイド
VPNSC: MPLS Solution トラブルシューティング ガイド
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

VPNSC: MPLS Solution トラブルシューティング ガイド

一般的なトピック

プロビジョニングの問題

監査の問題

VPNSC: MPLS Solution トラブルシューティング ガイド

この章では、VPN Solutions Center: MPLS Solution VPN サービスを展開したときに発生する可能性のある問題を認識し、トラブルシューティングする方法について説明します。

一般的なトピック

1. 質問:サービス展開状態とは何ですか。何を意味しますか。

回答: 表 15-1 で、VPN サービス要求の展開状態について説明します。

 

表 15-1 VPN Solutions Center サービス要求状態のサマリー

サービス要求の
タイプ
説明

Broken

ルータは正しく設定されていますが、サービスが利用できません(たとえば、ケーブルの切断やレイヤ 2 で問題が発生した場合)。オーディタがこのサービスに対するルーティング/転送テーブルを検出しても、サービスの目的に一致しない場合、このサービス要求は Broken 状態に移行します。

Closed

サービス要求がプロビジョニング プロセスまたは監査プロセスで使用されなくなると、サービス要求は Closed に移行します。削除要求が正常に監査された場合にだけ、サービス要求が Closed 状態に移行します。VPNSC:MPLS Solution は、拡張監査を可能にするため、サービス要求をデータベースから削除しません。サービス要求の削除は、特定の管理者アクションだけが実行できます。

Deployed

コンフィグレット コマンドが、ルータ コンフィギュレーション ファイルに記述されている通りに確認されると、サービス要求は Deployed に移行します。Deployed は、ルータのコンフィギュレーション ファイルが、VPNSC のサービス要求に指定されている情報と一致していることを示します。

Failed Audit

VPNSC がコンフィグレットをルータに正常にダウンロードしたにもかかわらず、サービス要求が監査をパスしなかった場合は、Failed Audit 状態になります。したがって、サービスは Functional 状態または Deployed 状態には移行しません。Failed Audit 状態は、Pending 状態から発生します。サービス要求が正常に展開れると、Failed Audit 状態に再び入ることはありません(サービス要求が、再展開された場合を除く)。

Failed Deploy

プロビジョニングが行われた後で、サービス要求がコンフィグレットをルータにダウンロードできなかった状態です。Telnet Gateway Server(TGS)が、展開プロセス中にエラーを検出すると、サービス要求は Failed Deploy に移行します。コンフィグレットをダウンロードするときに TGS が使用されず、VPNSC によってコンフィグレットがディレクトリにエクスポートされただけの場合は、サービス要求の Failed Deploy 状態と Pending 状態を区別する方法はありません。Failed Deploy 状態になるには 2 つの原因があります。

TGS が Provisioning Driver にダウンロード失敗を報告した(接続の切断、パスワードの誤りなど)。

オブジェクトが意図したコンフィギュレーション レベルの検証を確立できなかった。

コンフィグレットがディレクトリにエクスポートされた場合、サービス要求が Failed Deploy 状態に移行することはありません。

Functional

オーディタがこのサービスに対するルーティング/転送テーブルを検出し、サービスの目的と一致した場合、サービス要求は Functional に移行します。この状態になるには、コンフィギュレーション ファイル監査およびルーティング監査の両方が成功する必要があります。

Invalid

サービス要求情報における、何らかの誤りを示します。サービス要求が Invalid に移行するのは、要求が内部的に矛盾している場合、または既存のネットワーク/ルータのコンフィギュレーションの他の部分(たとえば、これ以上ルータで利用可能なインターフェイスがないなど)に対して矛盾している場合です。Provisioning Driver は、この要求に対するサービスを実行するコンフィグレットを生成できません。

Lost

オーディタが、目的のコンフィギュレーション レベルをルータのコンフィギュレーション ファイルで確認できない場合、サービス要求は Lost に移行します。サービス要求は展開されていますが、一部またはすべてのルータ コンフィギュレーション情報は失われています。サービス要求は、それまでサービス要求が Deployed または Functional であった場合にだけ Lost 状態に移行します。

Pending

要求に一貫性があり、必要なコンフィグレットが生成可能であることを Provisioning Driver が判断すると、サービス要求は Pending に移行します。Pending は、サービス要求がコンフィグレットを生成し、また生成されたコンフィグレットが正常にルータにダウンロードされたことを示します。

オーディタは、Pending のサービス要求を新しい要求と判断し、監査を開始します。サービスが新規に設定され、まだ監査されていない場合はエラーではありません(監査の Pending)。ただし、監査が完了しているにもかかわらずサービスが Pending である場合はエラー状態です。

Requested

サービスが新しく登録され、展開されていない場合は、エラーではありません。ただし、Deploy が完了しても Requested 状態が継続する場合、そのサービスはエラー状態です。

表 15-2および表 15-3に、VPN Solutions Center サービス要求の状態遷移のパスを示します。リストの最初のカラムには、サービス要求の開始時の状態が示されています。見出しの行には、サービス要求による遷移が可能な状態が示されています。

たとえば、 表 15-2 を使用して Pending のサービス要求を Functional までトレースするには、左端のカラムで「 Pending 」を探し、見出しの「 Functional 」を検出するまで、右に移動します。Pending から Functional に移行するサービス要求について、実行が必要である正常なルーティング監査を確認できます。

表 15-2 は、 Requested から Lost までの、サービス要求の遷移を示します。

 

表 15-2 VPNSC サービス要求の状態遷移パス(パート 1)

サービス要求の状態
Requested
Pending
Failed Audit
Deployed
Functional
Lost
Requested

Requested への遷移はなし

サービス要求の展開に成功

Failed Audit への遷移はなし

Deployed への遷移はなし

Functional への遷移はなし

Lost への遷移はなし

Pending

Requested への遷移はなし

--サービス要求の展開に成功

--監査エラー

監査の失敗

監査に成功

ルーティング監査に成功

Lost への遷移はなし

Failed Audit

Requested への遷移はなし

サービス要求の再展開に成功

Failed Audit への遷移はなし

監査に成功

ルーティング監査に成功

Lost への遷移はなし

Deployed

Requested への遷移はなし

サービス要求の再展開に成功

Failed Audit への遷移はなし

監査に成功

ルーティング監査に成功

監査でエラーを発見

Functional

Requested への遷移はなし

サービス要求の再展開に成功

Failed Audit への遷移はなし

Deployed への遷移はなし

ルーティング監査に成功

監査でエラーを発見

Lost

Requested への遷移はなし

サービス要求の再展開に成功

Failed Audit への遷移はなし

監査に成功

ルーティング監査に成功

監査でエラーを発見

Broken

Requested への遷移はなし

サービス要求の再展開に成功

Failed Audit への遷移はなし

Deployed への遷移はなし

ルーティング監査に成功

監査でエラーを発見

Invalid

Requested への遷移はなし

サービス要求の再展開に成功

再展開が原因のサービス要求エラー

Deployed への遷移はなし

Functional への遷移はなし

Lost への遷移はなし

Failed Deploy

Requested への遷移はなし

サービス要求の再展開に成功

サービス要求の再展開が失敗した。コンフィグレットをダウンロードできない。

Deployed への遷移はなし

Functional への遷移はなし

Lost への遷移はなし

Closed

Requested への遷移はなし

Pending への遷移はなし

Failed Audit への遷移はなし

Deployed への遷移はなし

Functional への遷移はなし

Lost への遷移はなし

表 15-3 は、 Broken から Closed までの、サービス要求の遷移を示します。

 

表 15-3 VPNSC サービス要求の状態遷移パス(パート 2)

サービス要求の状態
Broken
Invalid
Failed Deploy
Closed
Requested

Broken への遷移はなし

サービス要求の展開エラー

展開の失敗

Closed への遷移はなし

Pending

ルーティング監査に失敗コンフィグレットは正しい。

再展開が原因のサービス要求エラー

サービス要求の再展開が失敗した。コンフィグレットをダウンロードできない。

サービス要求の削除に成功。

Failed Audit

ルーティング監査に失敗コンフィグレットは正しい。

再展開が原因のサービス要求エラー

サービス要求の再展開が失敗した。コンフィグレットをダウンロードできない。

Closed への遷移はなし

Deployed

ルーティング監査に失敗コンフィグレットは正しい。

再展開が原因のサービス要求エラー

サービス要求の再展開が失敗した。コンフィグレットをダウンロードできない。

Closed への遷移はなし

Functional

ルーティング監査に失敗コンフィグレットは正しい。

再展開が原因のサービス要求エラー

サービス要求の再展開が失敗した。コンフィグレットをダウンロードできない。

Closed への遷移はなし

Lost

ルーティング監査に失敗コンフィグレットは正しい。

再展開が原因のサービス要求エラー

サービス要求の再展開が失敗した。コンフィグレットをダウンロードできない。

Closed への遷移はなし

Broken

ルーティング監査に失敗コンフィグレットは正しい。

再展開が原因のサービス要求エラー

サービス要求の再展開が失敗した。コンフィグレットをダウンロードできない。

Closed への遷移はなし

Invalid

Broken への遷移はなし

再展開が原因のサービス要求エラー

サービス要求の再展開が失敗した。コンフィグレットをダウンロードできない。

Closed への遷移はなし

Failed Deploy

Broken への遷移はなし

サービス要求の再展開エラー

サービス要求の再展開が失敗した。コンフィグレットをダウンロードできない。

Closed への遷移はなし

Closed

Broken への遷移はなし

Invalid への遷移はなし

Failed Deploy への遷移はなし

Closed への遷移はなし

2. 質問:どのエラー状態がプロビジョニングによるもので、どれが監査によるものですか。

回答:プロビジョニング後の状態で、プロビジョニング プロセス中に発見されたエラー条件によるものは、Requested、Invalid、および Failed Deploy です。監査後の状態で、監査プロセス中に発見されたエラー条件によるものは、Pending、Failed Audit、Lost、および Broken です。

3. 質問: Add VPN Service to CE および Deploy Service Requests を続けて実行し、その後 Generate Audit Reports を選択しました。しかし、All VPN Service Requests Report では、サービス要求が Deployed 状態でも Functional 状態でもありません。どこを調べれば良いですか。

回答:サービス要求の状態が Requested、Invalid、Failed Deploy のいずれかである場合は、「プロビジョニングの問題」を参照してください。ただし、サービス要求が Failed Audit 状態であったら、「監査の問題」を参照してください。

プロビジョニングの問題

VPNSC: MPLS Solution プロビジョニング システムには、次の機能があります。

機能 1:PE ルータ コンフィギュレーション ファイルを収集する(PE-upload)

機能 2:CE ルータ コンフィギュレーション ファイルを収集する(CE-upload)

機能 3:プロビジョニング

機能 4: 変更された構成情報を PE に書き込む(PE-DownLoad)

機能 5: 変更された構成情報を CE に書き込む(CE-DownLoad)

機能 1、2、4、および 5 は、Telnet Gateway Server(TGS)と呼ばれるサーバによって実行されます。

機能 1 または 2 でエラーが発生すると、機能 3、4、および 5 はスキップされます。

プロビジョニング エンジンには、ルータのモデルがあります。このルータ モデルは必要に応じて修正され、サービス要求をサポートするためのアトリビュートを導入します。

1. 質問:プロビジョニング操作のフローはどのようになっていますか。

回答:

これらのすべての機能を実行するプログラムは、Provisioning Driver と呼ばれます。Provisioning Driver は TGS サーバをコールして、機能 1 および 2 を実行します(PE および CE コンフィギュレーション ファイルを収集)。VPN Solutions Center は、新しいコンフィギュレーション ファイルをルータからアップロードした後、サービス要求のプロビジョニングを行います。

必要な変更内容でコンフィグレットをアップデートする操作に成功した後、Provisioning Driver は Telnet Gateway Server を呼び出して新しいコンフィグレットをルータにダウンロードします(機能 4 および 5)。

機能 1 または 2(PE または CE コンフィギュレーション ファイルの収集)が失敗した場合は、ほかの機能はスキップされ、サービス要求は Requested 状態にとどまります。

機能 3(プロビジョニング)が失敗した場合は、サービス要求は Invalid 状態になります。

機能 3 が成功したが機能 4 または 5(変更した構成情報の書き込み)が失敗した場合は、サービス要求は Failed Deploy 状態に移行します。

2. 質問:監査でプロビジョニング機能がどのように実行されたかについては、どこを調べれば良いのですか。

回答:最初に Task Logs を調べてください。

a. VPN コンソールから、 Tools > Task Logs を選択します。

ブラウザが開き、図 15-1 に示す VPN Solutions Center Task Logs が表示されます。

図 15-1 VPNSC: MPLS Solution Task Logs ブラウザ

 

b. この展開について実行されたタスクを選択します。

タスク名は、オペレータが割り当てた名前です。タスクは、逆時間的順予にリストされます(最新のものが最初)。

c. Log リンク(右端のカラム)をクリックします。

要約情報が左側のペインに表示されます(図 15-2 を参照)。

図 15-2 Task Log Summary Information および Action Report

 

d. Action Report を表示するには、 Actions 見出しの下のリンクをクリックします。

図 15-2 に示すように、右側のペインに Action Report が表示されます。

3. 質問:自分のサービス要求が Requested 状態にとどまっています。エラーについてどこを調べれば良いですか。

回答:Task Log Summary Table で、そのサービス要求に関する PE-UpLoad 情報および CE-UpLoad 情報を調べてください。これらのいずれかまたは両方が「Fail」となっているはずです。これが理由で、以降の処理は「スキップ」されました。したがって、このサービス要求は Requested 状態のままになっています。

4. 質問: Task Log にタスクがありません。どうしたのでしょうか。

多くの場合は次の理由によります。

Task Scheduler がクラッシュし、ディセーブルになった。

Task Scheduler が正常に機能していない。

Task Scheduler が「disabled-dependent」である。

これらのケースのいずれかが当てはまる場合は、スケジュールされたジョブは実行されず、タスク ログは生成されません。

a. Watch Dog(wdgui)を使用して、Task Scheduler の状態をチェックします。

b. Task Scheduler がディセーブルになっている場合は、次のコマンドを発行します。

wdclient start scheduler

c. Task Scheduler が「disabled-dependent」の場合は、一部の依存サーバ(lock_manager や
EventServiceServer monitor poller など)が始動していません。次のコマンドを発行して、そのサーバを起動します。

wdclient start server_name

依存サーバを起動すると、Task Scheduler も自動的に始動します。

5. 質問:wdlog では、Task Scheduler は起動し、動作していることになっています。しかし、スケジュールされたタスクは実行されていません。どこに問題があるのでしょうか。

回答:Task Scheduler は始動すると、自動的にペンディング状態の要求を再起動します。ただし、これには一部例外があります。Task Scheduler に関する wdgui メッセージを数分間確認してください。数分たっても Task Scheduler が始動しない場合、タスクを再スケジュールしてください。

Task Scheduler が正常に動作しない場合は、次を実行します。

a. Task Scheduler に関する wdgui 情報をチェックします。何か異常がありますか。

b. 異常がない場合は、Task ダイアログボックスに進みリフレッシュを実行します。

c. タスクはまだアクティブと表示されていますか。

d. 開始予定の時刻に着目します。

その時刻はすでに経過していますか(Task Scheduler が実行されるシステム クロックで表示されるとおりに)。

e. 経過していれば、古いタスクを削除して再スケジュールします。数分後、wdgui Task Scheduler 情報をチェックして何らかのアクティビティまたはメッセージがないかどうか確認します。

f. Task Scheduler に異常なエラー メッセージがある場合は、そのメッセージを読み推奨処置を講じます。

g. メッセージがない、またはメッセージが理解できない場合は、Task ダイアログボックスから古いタスクを削除し、コマンド wdclient restart Task Scheduler を使用して Task Scheduler をリスタートします。

h. Task Scheduler が始動したら、コマンドを再スケジュールします。

i. 問題が続く場合は、Watch Dog を停止します。

j. 2 分間待ち、その後 startwd コマンドを使用して Watch Dog をリスタートします。

Watch Dog をリスタートする前に、必ずアクティブ タスクを削除してください。サーバが安定するまで待ってから、タスクを再スケジュールします。

6. 質問:サービス要求が Invalid 状態にあります。この問題はどのように解決するのですか。

回答:サービス要求が Invalid に移行するのは、要求をサービスできないからです。サービス要求内の何らかの要求がサービス不能であるか、または内部エラーがあったためです。

a. Task Logs ブラウザ ページで Tools > Task Log s を選択して、Task Log Summary テーブルを起動します。

また、ブラウザから次の URL を入力しても、この情報にアクセスできます。

http://vpnsc_host:8080/servlet/TaskLogs

追加情報については、この章の質問 2 と 3 を参照してください。

b. Task Log Summary テーブルで、Fail ( Provisioning の下)をクリックします。

ここには、プロビジョニング中に検出されたエラー条件の説明が表示されます。場合によっては、さらに詳細なエラー メッセージが表示されることもあります。

また、VPN コンソールからも内部エラー情報を確認できます。

c. VPN コンソールから、Provisioning > List all Service Request s を選択します。

All VPN Service Requests Report が表示されます。サービス要求が Invalid であることに注目してください。

d. Request Detail s をクリックします。

e. Last State Change Comment に、このサービス要求が Invalid 状態にある理由が表示されます。場合によっては、エラー メッセージの要約が含まれることもあります。

f. エラー メッセージを読み、入力された不正値をメモします。

g. All VPN Service Request Report から、Provisioning をクリックして Modify VPN Service を選択します(「既存のサービス要求の修正」を参照)。

h. 修正済み要求のエラーを訂正し、サービス要求を再展開します。

7. 質問:サービス要求が Failed Deploy 状態にあります。この問題にはどのように対処すれば良いですか。

回答:Failed Deploy は、変更済みのコンフィグレットをルータにダウンロードし直すときにエラーが発生したことを示します(詳細は表 15-1 を参照)。

Invalid 要求(質問 8 を参照)について説明した手順が、ここでも当てはまります。ただし、Task Logs Summary テーブルでは、PE-Download または CE-Download 情報を調べます。エラーが発生した箇所です。そこからリンクを取得します。

問題の原因としては、1)コンフィギュレーションの変更がダウンロードされたが、ルータへのリンクが廃棄された、2)ルータに送信された設定コマンドが警告またはエラー メッセージを呼び出した、のいずれかが考えられます。

a. 最初にエラー メッセージを読み、理解します。通信エラーですか。

b. 通信エラーであれば、VPN Solutions Center ワークステーションからルータに Telnet 接続します。最初に機能する通信を使用します。

c. Provisioning > List All Service Request s を選択して、サービス要求を再展開します。

d. All VPN Service Requests Report から、 Provisioning をクリックし、Deploy VPN Service s を選択します。

エラーが、警告またはエラーを生成したコマンドによるものであれば、ルータ上の Cisco IOS バージョンでコマンドがサポートされていないため、ルータがコマンドを拒否した可能性があります。問題が解決しない場合は、Cisco Technical Assistance Center に連絡を取り、a)Command Rejected 情報、および b)ルータからの show version 出力を提出してください。

監査の問題

Audit new service requests Audit existing service requests の両方の監査タイプに、2 つのテストが用意されています。1 つは コンフィギュレーション テスト で、2 つ目は ルーティング テスト (Task ウィンドウで Use VPN routing information during audits をチェックして指定している場合)です。コンフィギュレーション テストが失敗すると、ルーティング テストは実行されません。

コンフィギュレーション テスト では、ルータのコンフィギュレーション ファイルが VPNSC サービス要求で指定されている情報と一致しているかどうかがチェックされます。VPNSC: MPLS Solution はコンフィギュレーション ファイルを取得し、構成情報から「モデル ルータ」を構築します。コンフィギュレーション テストは、ルータのソフトウェア モデルを構築し、それを監査します。コンフィギュレーション テストでは、サービスが実際に実行されているかどうかは判別できません。

ルーティング テスト (「監査ルーティング」)は、実際に次の 3 つのテストを実行します。1)CE に向かうルートの有無をチェックする、2)CE から出るルートの有無をチェックする、3)管理 VPN 技法を使用して CE が管理されている場合は、管理 VPN 内の MCE へのルートの有無をチェックする。この監査は PE で見つかったルーティング情報に基づくもので、ルーティング テスト監査の詳細は PE に置かれます。

これらのテストはすべて、サービス要求が属する VRF に対して行われます。CE に向かうルートの有無をテストするため、VPNSC は、CE のプロバイダー側を向いている IP アドレスに向かうルートを検索します。

CE から出ているルートのテストでは、「VPN の反対側」に向かうルートが検索されます。このテストでは、リモート接続性ステータスがチェックされます。サービス要求が管理 VPN にある場合、最終テストでは、MCE へのルートがチェックされます。

サービス要求が Audit New Service Request に失敗すると、Failed Audit 状態に移行します。サービス要求がこの監査に合格し、監査ルーティングがイネーブルになっている場合(Task ウィンドウで Use VPN routing information during audits をオンにする)、VPNSC: MPLS Solution は、監査ルーティング用の妥当な VRF ルーティング情報があるかどうかを調べます。ルーティング監査に VRF ルーティング情報がない、または Use VPN routing information during audits オプションがオンになっていない場合は、サービス要求は、コンフィギュレーション監査時の状態にとどまります。

ルーティング テストに合格すると、サービス要求は Functional に移行します。ルーティング テストに失敗すると、サービス要求は Broken に移行します。

Audit Existing Service Request の開始時の状態は、Pending、Deployed、Failed Audit、Lost、Functional、または Broken です(表 15-1 を参照)。それぞれのケースで、展開テストとルーティング テストがこの順序で実行されます。

コンフィギュレーション テストに失敗すると、サービス要求は Lost 状態に移行します(または Lost 状態のままとなります)。ルーティング テストに失敗すると、サービス要求は Broken 状態に移行します(または Broken 状態のままとなります)。コンフィギュレーション テストに成功すると、サービス要求は Deployed 状態に移行します(または Deployed 状態のままとなります)。ルーティング テストに成功すると、サービス要求は Functional 状態に移行します(または Functional 状態のままとなります)。

1. 質問: サービス要求が Failed Audit または Lost 状態にあります。どのように問題点を発見できますか。

回答:

a. Failed Audit または Lost 監査状態にあるサービス要求については、 Provisioning > List All Service Requests を選択してサービス要求監査レポートを生成します。

b. All VPN Service Requests Report で、目的のサービス要求を選択し、 Request Details ボタンをクリックします。

c. このウィンドウで、 Audit Details ボタンをクリックします。

Audit Details レポートでは、PE および CE の監査トレースが表示されます。このレポートは 2 つの部分で構成され、一方は PE 用、もう一方が CE 用です。見つかったエラーは黄色で強調表示されます。

d. エラー情報を読みます。

多くの場合、ルータ上の構成情報が欠けていたり、誤っていることが問題となっています。コンフィグレット内にこの設定コマンドが生成されていますか。

e. コンフィグレットを見るには、まず Back をクリックし、次に Configlets ボタンをクリックします。

VPN Solutions Center が、現在のコンフィグレットを表示します。

f. コマンドが存在するかどうかを調べ、存在する場合はそれが正しいかどうかを調べます。

g. 生成されたコマンドが誤っていて変更が必要と思われる場合は、Cisco Technical Assistance Center に連絡してください。

h. コマンドが正しい場合は、コンフィグレット中の設定コマンド ライン(つまり、監査での検出時に明らかに欠如しているまたは誤っているライン)をチェックし、ルータにコマンド ラインが存在するかどうかを調べてください。

i. ルータ上でコマンドラインが削除されている、最初からない、または誤って変更されている場合は、サービス要求を再展開して修正内容がルータに送信されるようにします。

j. しかし、コンフィグレットが正しいと思われ、ルータ上にも設定コマンドが存在する場合は、Cisco Technical Assistance Center に連絡してください。

2. 質問:サービス要求を Functional 状態に移行させる方法を教えてください。

回答:サービス要求を Functional に移行させるには、監査を実行します。監査が成功すると、サービス要求は Deployed に移行します。

a. 階層ペインで、 VPNs フォルダを開きます。

b. 目的の VPN を選択し、 右クリック します。

c. メニューから、 Audit Service Requests を選択します。

d. Audit VPN ダイアログボックスで、次を選択します。

All Service request(s)

これを選択すると、現在の VPN のすべてのサービス要求が監査されます。

プロンプト「Do you want to perform a just-in-time (jit) collection...」に対して、 Yes を選択します。

プロンプト「Do you want audit routing?」に対して、 Yes を選択します。

OK をクリックします。

e. Schedule タブを選択し、Schedule ダイアログボックスの各フィールドに入力して監査をスケジュールし、次に OK をクリックします。

3. 質問:「Use VPN routing info during audits」オプションを選択しましたが、「No VPN routing information found.」というメッセージが表示されました。

回答:使用する VPN ルーティング情報を収集する必要があります。Monitoring > Collect VPN Routing Informatio n を選択して、データ収集をスケジュールします。

4. 質問:サービス要求が Broken 状態にあります。この問題はどのように解決するのですか。

回答:ルータは正しく設定されていますが、サービスを利用できません(たとえば、ケーブルの破損やレイヤ 2 の問題が発生した場合)。オーディタがルータに対するルーティング テーブルおよび転送テーブルを検出したにもかかわらず、サービス要求のルーティング情報がルータの VRF ルーティング テーブルに存在しない場合、そのサービス要求は Broken に移行します。

ルーティング テスト (「監査ルーティング」)は、実際に次の 3 つのテストを実行します。1)CE に向かうルートの有無をチェックする、2)CE から出るルートの有無をチェックする、3)管理 VPN 技法を使用して CE が管理されている場合は、管理 VPN 内の Management CE(MCE)へのルートの有無をチェックする。

ルーティング テストに失敗すると、サービス要求は Broken に移行します。この監査は PE で検出されたルーティング情報に基づいているため、ルーティング テスト監査の詳細は PE に置かれます。ルーティング テストはレイヤ 3 機能テストであるため、ケーブルの破損やレイヤ 2 接続性の喪失など、そのレイヤで発生した問題の原因については VPNSC は認識できません。

5. 質問:2 つの CE を含む VPN があります。片方の PE-CE レイヤ 2 コネクションがダウンし、Broken または Lost 状態にあります。もう一方の PE-CE ペアのサービス要求も Broken 状態に移行したのはなぜですか。

回答:ルーティング テストでは、サービス要求がサイトから VPN へのルーティング レベルの接続を提供しているかどうかがチェックされます。VPN が存在するためには、少なくとも 2 つのサイトが必要です。そのため、2 つのサイトから成る VPN では、一方のサイトの接続性がダウンすると、VPN は存在できなくなります。したがって、VPN に対する他方のサイトの接続性も失われます。プロバイダーのコア ネットワークを経由するルートはありません。

6. 質問:VPN を作成し、最初のサイトを追加したところです。なぜサービス要求が Broken に移行するのですか。

回答:VPN に少なくとも 2 つのサイトを追加するまで、その VPN は完成したとはいえません。VPN がまだ存在していないことになるので、最初のサイトは VPN に参加できません。そのため、サービス要求は Broken に移行します。コア ネットワークの接続性が存在し機能していることを前提に、第 2 のサイトが VPN に接続されると、サービス要求は Functional に移行します。

7. 質問:Audit Reports に追加行があり、Repository Error と表示されています。これは何を意味していますか。

回答: リポジトリに対する読み取り/書き込み操作が失敗しました。Cisco Technical Assistance Center にこのエラーを報告し、現在のリポジトリを送ってください。