Cisco Prime Provisioning 6.3ユーザ ガイド

診断の概要

Diagnostics はワークフローに基づいた自動ネットワーク管理アプリケーションで、マルチプロトコル ラベル スイッチング（MPLS）VPN の問題をトラブルシューティングおよび診断します。Diagnostics は、MPLS に関連するネットワーク停止の診断に要する時間を削減するための機能を提供します。多くの場合、時間単位から分単位に短縮されます。診断は、ネットワーク障害シナリオに基づいて、MPLS のアクセス、エッジ、およびコアの各ネットワーク間で実行されます。サービス プロバイダーおよび企業の「自己導入」の、両方の MPLS VPN ネットワークに同様に適用できます。Network Operations Center（NOC; ネットワーク オペレーション センター）は技術者をサポートします。本製品以降は、第 2 次および第 3 次のサポートも受けることができるようになりました。Diagnostics は、オプションで、Prime Provisioning MPLS VPN プロビジョニング コンポーネントと統合できます。MPLS VPN の中核となる問題を診断するには、Label-Switched Path（LSP; ラベルスイッチド パス）ping および LSP traceroute など、MPLS のオペレーションおよびメンテナンス（OAM）機能をサポートする Cisco IOS ソフトウェア リリースおよび IOS XR ソフトウェア リリースが必要です。

障害の発見やトラブルシューティングを効果的に行うため、次の 5 つのステップを踏みます。

1. 検知

2. 分離

3. 診断

4. 修復

5. 確認

Diagnostics は、エンド カスタマーが VPN サービスを使用して問題をレポートするような、反応的な状況をサポートすることを目的として設計されています。これは、基本的に、図 11-1 の「診断」のステップに該当します。ルータ デバイスに加えられた変更を徹底して自ら管理し、それを行うための社内手順を定めているプロバイダーが多いため、「修復」機能はサポートされません。

図 11-1 反応的な障害ライフサイクル

（注） ステップ 2、3、および 5 は Diagnostics によって実行されます。ステップ 1 と 4 は手動で実行する必要があります。

Diagnostics では、「分離」、「診断」、および「検証」のステップを重点的に扱います。ネットワークでの障害の分離および診断、障害の発生したデバイスの特定、適切なデバイス ステータスのチェック、および障害発生の考えられる理由を特定するための設定を行うための貴重な機能を提供します。また、Diagnostics は、デバイス設定に加えた変更によって問題が解決されたことを検証するため、テストを再実行する機能も提供します。

この機能は、Prime Provisioning のその他のモジュール（VPN プロビジョニングや Traffic Engineering Management など）に依存せず、単独で使用できます。また、その他の Prime Provisioning モジュールが一部またはすべて使用されている Prime Provisioning インストールでも使用できます。MPLS VPN プロビジョニング機能が使用された場合は、カスタマー データおよび VPN データをトラブルシューティングの開始点として使用し、どのエンドポイント（カスタマー エッジ デバイスなど）間の接続をテストするかを特定できます。

Diagnostics はトラブルシューティングだけでなく、VPN ポストプロビジョニング チェックにも使用できます。VPN を展開した後、手動でまたは Prime Provisioning VPN プロビジョニング機能を使用して接続テストを実行し、VPN が正常にプロビジョニングされているかどうかを検証できます。

（注） Diagnostics では、基礎となる設定またはルーティングのトラブルシューティング中の変更がサポートされません。Diagnostics の実行中にオペレータまたはルータのコントロール プレーンにより加えられた変更は、いずれも実行される実際のトラブルシューティングには反映されません。このような変更が加えられた場合、Diagnostics で正しい障害シナリオや観察の結果が得られるとは限りません。

前提となる知識

Diagnostics は、MPLS VPN について最低限の知識を持ったユーザによる使用を前提として設計されています。Diagnostics の MPLS VPN 接続性検証テストは、MPLS VPN についてほとんど、またはまったく知らないユーザでも実行できます。また、必要に応じてテスト結果をエクスポートし、MPLS VPN に詳しいエンジニアに解釈してもらうこともできます。ただし、MPLS VPN はもともと複雑であるため、RFC 2547 に従って MPLS VPN について習熟し、Diagnostics の利点を最大限に生かすことを推奨します。特に、RFC 2547 アークテクチャ、トポロジ、制御、およびデータ プレーンの知識は、アプリケーションを最大限に利用する方法を理解し、結果を解釈するうえで役立ちます。

Diagnostics は現在、IETF RFC 4379 準拠のラベル スイッチド パス（LSP）ping および LSP traceroute を使用するシスコ デバイスおよびネットワークを診断します。Diagnostics は、Cisco IOS で使用可能な先行のドラフト（ドラフト 3）も継続してサポートしています。ネットワーク内のすべてのデバイスで、一貫した LSP ping および traceroute のドラフトを使用する必要があります。

推奨文献：

• 『MPLS and VPN Architectures』Ivan Pepelnjak、Jim Guichard（Cisco Press）

• 『Troubleshooting Virtual Private Networks』Mark Lewis（Cisco Press）

• LSP ping/trace RFC： http://www.ietf.org/rfc/rfc4379.txt

• RFC 2547： http://www.ietf.org/rfc/rfc2547.txt?number=2547

• RFC 4379： http://www.ietf.org/rfc/rfc4379.txt?number=4379

• MPLS Embedded Management：LSP Ping/Traceroute and AToM VCCV: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/gslsppt.html

サポートされているハードウェア、IOS、および IOS XR バージョン

サポートされているプロバイダー（P）およびプロバイダー エッジ（PE）ネットワーク デバイスのタイプおよび関連する Cisco IOS および IOS XR バージョンの詳細については、 『Cisco Prime Provisioning 6.3 Installation Guide』 を参照してください。

（注） その他のデバイス タイプ、IOS、および IOS XR バージョンのサポートが、パッチ リリースで追加される場合があります。最新のパッチ リリースとサポートされているデバイス タイプ、IOS、および IOS VR バージョンの詳細については、 Cisco.com を参照してください。

で説明されているデバイス タイプ、IOS、および IOS XR バージョンは、MPLS ラベル スイッチド パス（LSP）の ping および traceroute 機能をサポートしています。この機能は、Diagnostics のトラブルシューティングに必要です。すべての P および PE デバイスがサポートされているデバイス タイプ、IOS、および IOS XR バージョンのリストに準拠していれば、Diagnostics はアクセス回線、MPLS VPN、および MPLS コアの問題をトラブルシューティングできます。Diagnostics は、他社製品などのその他のデバイス タイプ、IOS、および IOS XR バージョンにも対応できます。ただし、ネットワーク内にこのリストに準拠していない P または PE デバイスが含まれている場合、完全な診断ができない場合があります。 表 11-1 に、可能性のあるシナリオとその結果を示します。

Diagnostics は、すべてのベンダーの管理対象および管理対象外の CE ルータをサポートしています。CE デバイスについては、デバイス タイプ、IOS、または IOS XR バージョンの要件はありません。

Diagnostics は、MPLS LSP ping および traceroute 機能をサポートしている他のデバイス タイプ、IOS および IOS XR バージョンで動作できます。この機能をサポートしているデバイス タイプ、IOS、および IOS XR のバージョンの詳細については、Cisco Feature Navigator を使用してください。 http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp を参照してください。

（注） PE デバイスが、サポートされていない IOS または IOS XR バージョン（MPLS ping および traceroute 機能を実装していないもの）を実行している場合は、アクセス回線および VPN エッジのトラブルシューティングは実行されますが、MPLS コアのトラブルシューティングはできません。このシナリオでは、コアの障害は PE デバイス上のラベル転送情報ベース（LFIB）不一致としてレポートされます。LFIB 不一致はコア障害の症状ですが、コアはトラブルシューティングできないため、実際のコア障害は診断できません。

IPv6

Internet Assigned Numbers Authority（IANA）が管理する IPv4 アドレス フリー プールが残り少なくなってきています。シスコは、この事態に対応するため、IPv6 アドレス指定を採用しています。

Diagnostics は、IPv4 と IPv6 の両方のアドレスを持つデバイスの、設定および選択をサポートしています。Diagnostics は、接続回線が次のような状態の MPLS VPN サービスをトラブルシューティングできます。

• IPv6 アドレス指定を使用する場合

• デュアルスタックの IPv4/IPv6 アドレス指定を使用する場合

デュアルスタックは、同じインターフェイス上に IPv4 と IPv6 の両方を共存させるための技術です。インターネット上には、永久ではないものの、今後長年にわたって IPv6 と IPv4 ノードが混在します。このため、IPv4 ノードを大規模に展開している企業では、IPv4 から IPv6 への移行を成功させることがとても重要です。たとえば、単一のインターフェイスを、IPv4 アドレスと IPv6 アドレスの両方を持つように設定できます。「デュアルスタック」と呼ばれるあらゆる要素（プロバイダー エッジやカスタマー エッジ ルータなど）は、IPv4 だけでなく、IPv6 アドレス指定およびルーティング プロトコルも実行します。

（注） Diagnostics は、グローバル ユニキャスト IPv6 アドレスのみをサポートします。グローバル ユニキャスト アドレスの機能は、131.107.1.100 のような IPv4 ユニキャスト アドレスと類似しています。つまり、これらのアドレスは、従来型の、公的にルーティング可能なアドレスであると言えます。グローバル ユニキャスト アドレスには、グローバル ルーティング プレフィックス、サブネット ID、およびインターフェイス ID が含まれます。

（注） Diagnostics では、接続回線エンドポイントが IPv6 と IPv6 の場合、IPv4 と IPv4 の場合のいずれにおいてもテストを起動できます。両方のアドレス指定を混在させることはできません。

IPv6 アドレスでテストを開始する場合の詳細については、「Diagnostics 接続テストの概要」を参照してください。

診断機能

Diagnostics のトラブルシューティングおよび診断は、次の 4 つのドメインをサポートしています。

• アクセス回線：アクセス回線のトラブルシューティングには、ATM、フレーム リレー、およびイーサネットのルーティング プロトコルの基本的なトラブルシューティング、レイヤ 1 およびレイヤ 3 の基本的なトラブルシューティング、およびレイヤ 2 の高度なトラブルシューティングが含まれます。

• MPLS VPN：MPLS VPN のトラブルシューティングは、RFC2547 に基づいて MPLS/MP-BGP VPN をサポートしています。サポートされているトポロジは、ハブ アンド スポーク、セントラル サービス、フル メッシュ、およびイントラネットまたはエクストラネット VPN です。

• MPLS コア：MPLS コアのトラブルシューティングは、データ プレーンおよびコントロール プレーンのトラブルシューティングをサポートしています。この機能は、MPLS 運用管理および保守（OAM）がサポートされている Cisco IOS または Cisco IOS XR バージョンを実行するすべての MPLS コアおよびエッジ デバイス（検出されたすべての MPLS トラフィック エンジニアリング トンネルのトラブルシューティングを含む）用として用意されています。MPLS OAM がサポートされている Cisco IOS、および Cisco IOS XR のバージョンの詳細については、「サポートされているハードウェア、IOS、および IOS XR バージョン」を参照してください。

（注） Diagnostics では、コア内のルーティング プロトコル（ただし IGP プロトコルが OSPF の場合はファースト ホップおよび PE-P-PE トポロジでの OSPF 障害を除く）、コア内の IP 接続性、および相互自律システム（AS）または Carrier-Supporting-Carrier（CsC）の一部のバリエーション（特に LSP が存在しない相互 AS オプション B および CsC）はトラブルシューティングされません。

ユーザ ロール

Prime Provisioning ユーザが使用できる機能は、割り当てられているユーザ ロールによって決まります。ユーザ ロールによって、デバイスの作成と削除やデバイス設定の収集、MPLS VPN 接続性検証テストの実行を行うこともできます。

Diagnostics 機能を使用するには、実行する権利が与えられる接続性テストのタイプに応じて、次の定義済み Diagnostics ロールの 1 つ以上が割り当てられている必要があります。

1. MplsDiagnosticsRole：2 つの CE 間で MPLS VPN 接続性テストを実行できます。

2. MplsDiagnosticsPeToAttachedCeTestRole：PE と接続された CE との間で MPLS VPN 接続性テストを実行できます。

3. MplsDiagnosticsCetoPeAcrossCoreTestRole：MPLS コアをまたぐ CE および PE 間で MPLS VPN 接続性テストを実行できます。

4. MplsDiagnosticsPetoPeInVrfTestRole：2 つの PE 間で MPLS VPN 接続性テストを実行できます。

5. MplsDiagnosticsPeToPeCoreTestRole：2 つの PE 間でコア MPLS VPN 接続性テストを実行できます。

（注） すべての Diagnostics ロールで、デバイスの作成と削除やデバイス設定の収集、MPLS VPN 接続性検証テストの実行を行うことができます。

ユーザの作成

Prime Provisioning ユーザの作成方法については、 『Cisco Prime Provisioning 6.3 Administration Guide』 を参照してください。

ネットワーク設定

この項では、ネットワークのトラブルシューティングを Diagnostics で行うために必要なネットワーク設定を説明します。

MPLS IP 存続可能時間伝搬

MPLS IP 存続可能時間（TTL）伝搬は、シスコ デバイスではデフォルトでイネーブルになっています。Diagnostics では、MPLS IP TTL 伝搬が MPLS コア内でイネーブルになっている必要があります。MPLS IP TTL 伝搬がイネーブルになっていない場合、Diagnostics は MPLS コア内で問題のトラブルシューティングを実行できません。その状態でも、アクセス回線の問題、または MPLS コアのエッジにおける問題のトラブルシューティングは可能です。

Cisco IOS では、IOS コマンドの no mpls ttl-propagate forward を使用すると、MPLS コアに転送されるパケットの MPLS IP TTL 伝搬をディセーブルにできます。このコマンドでは、MPLS コアに転送されるパケットの TTL 伝搬が停止されますが、MPLS コア内部から送信されるパケットの TTL 伝搬は許可されます。Diagnostics は、この状況で正しく機能します。

Cisco IOS コマンドの no mpls ip propagate-ttl を使用して、または Cisco IOS XR コマンドの mpls ip-ttl-propagate disable を使用して TTL 伝搬をディセーブルにしている場合は、すべての TTL 伝搬がディセーブルになるため、Diagnostics は MPLS ネットワークをトラブルシューティングできません。

（注） トラブルシューティング対象に選択したデバイスと、同じネットワークの一部であるデバイスに対して、タイムスタンプをディセーブルにする必要があります。

MPLS LSP ping/traceroute のリビジョン

Diagnostics は、バージョン 3 の IETF LSP ping ドラフト（draft-ietf-mpls-lsp-ping-03.txt）に基づいて、IOS MPLS LSP ping/traceroute 実装をサポートします。それよりも後のバージョンの IETF LSP ping ドラフトはサポートされません。最新の IOS バージョン（12.4(6)T を含む）および IOS XR は、以降のバージョンの IETF LSP ping ドラフト/RFC 4379 を実装しています。これらの IOS または IOS XR バージョンで Diagnostics を使用するには、バージョン 3 の IETF LSP ping ドラフトを使用するように IOS または IOS XR を設定する必要があります。そのためには、IOS または IOS XR グローバル コンフィギュレーション モードで mpls oam コマンドに続けて echo revision 3 コマンドを入力する必要があります。必要に応じて、コアのすべてのルータが同じバージョンの IEFT LSP ping ドラフトまたは RFC を使用していることを確認します。

ポイントツーポイント アクセス回線リンクでの 31 ビット プレフィックス

IPv4 アドレッシングを使用するアクセス回線リンクに対して、Diagnostics は、31 ビット プレフィックスで設定されたアクセス回線リンクによるトラブルシューティングをサポートします。ただし、各クラスフル ネットワークに対して、Diagnostics は可能性のある 2 つの 31 ビット プレフィックス設定によるトラブルシューティングをサポートしません。その 2 つとは、クラスフル ネットワーク アドレスまたはネットワーク ブロードキャスト アドレスをホスト アドレスとして使用するサブネットです。たとえば、クラス A ネットワーク 10.0.0.0 において、IP アドレス 10.0.0.0 と 10.0.0.1 をホスト アドレスとして使用する 31 ビット プレフィックス サブネット、および IP アドレス 10.255.255.254 と 10.255.255.255 をホスト アドレスとして使用するサブネットはサポートされません。これらの範囲の間にあるすべてのサブネットはサポートされます。

サポートされていない 31 ビット プレフィックス サブネットを使用して Diagnostics テストが設定された場合は、テストは実行されず、サポートされていない 31 ビット プレフィックス設定であることを通知するメッセージが表示されます。このような状況では、このリンクを手動でトラブルシューティングするか、リンクを再設定してサポートされるサブネット設定を使用する必要があります。

インベントリの設定

Diagnostics は、他の Prime Provisioning モジュールにまったく依存することなく使用できます。ただし、使用する前に、Prime Provisioning リポジトリに多数のオブジェクトを入力する必要があります。最低でも、これにはプロバイダー、プロバイダー リージョン、デバイスおよび PE デバイス オブジェクトが含まれます。これらの各オブジェクトのロールについて、以下で説明します。

• プロバイダー：一般的にプロバイダーとは、ネットワーク サービスをカスタマーに提供するサービス プロバイダーまたは大企業です。プロバイダーは、特定のプロバイダーを表した論理インベントリ オブジェクトです。

• プロバイダー リージョン：プロバイダー リージョンは、1 つのボーダー ゲートウェイ プロトコル（BGP）自律システム内のプロバイダー エッジ ルータ（PE）のグループであると見なされます。プロバイダー リージョンを定義する主な目的は、プロバイダーがヨーロッパ、アジア太平洋などの広い地域で一意の IP アドレス プールを使用できるようにすることです。

• デバイス：Prime Provisioning のデバイスは、ネットワーク内の物理デバイスを論理的に表したものです。Prime Provisioning が管理するすべてのネットワーク要素は、システム内でデバイスとして定義する必要があります。

• PE デバイス：PE デバイスは、特定のプロバイダー リージョンに関連付けられたプロバイダー エッジ（PE）またはプロバイダー（P）ルータを論理的に表したものです。PE デバイスは最初にデバイスとして追加してから、そこに PE デバイス タイプを割り当てる必要があります。

MPLS ネットワークのすべてのプロバイダー エッジ（PE）およびプロバイダー（P）ルータを Prime Provisioning インベントリに追加する必要があります。各プロバイダー エッジ ルータはデバイスとして作成してから、ロール タイプ N-PE（ネットワーク方向の PE）を割り当てた PE デバイスとする必要があります。各プロバイダー デバイスはデバイスとして作成してから、ロール タイプ P（プロバイダー）を割り当てた PE デバイスとする必要があります。Prime Provisioning インベントリへの顧客宅内装置（CPE）デバイスの追加はオプションです。

（注） デバイスがプロバイダー デバイスおよびプロバイダー エッジ デバイスの両方として動作する場合は、そのデバイスを、ロール タイプ N-PE（ネットワーク方向の PE）を割り当てた PE デバイスとして作成する必要があります。

多くの MPLS VPN ネットワークがルータ リフレクタを使用します。ルータ リフレクタを Prime Provisioning インベントリに追加することを推奨します。ルータ リフレクタはデバイスとして追加してから、ロール タイプが P の PE デバイスとして追加する必要があります。ルータ リフレクタを Prime Provisioning インベントリに追加することにより、Diagnostics は、このデバイスを含む潜在的な障害を識別できます。

（注） その他の Prime Provisioning の機能を使用して MPLS ネットワークを管理している場合は、必要なインベントリ オブジェクトの多くがすでに存在している可能性があります。たとえば、Prime Provisioning MPLS VPN 機能を使用している場合に、必要なプロバイダー、プロバイダー リージョン、およびプロバイダー エッジ デバイスはすでに存在することがあります。その場合は、プロバイダー デバイスのみを追加する必要があります。

必要なインベントリ オブジェクトを作成するための、多数のオプションがあります。これらのオブジェクトは Prime Provisioning GUI により手動で作成することも、Prime Provisioning Discovery 機能、インベントリ マネージャのデバイス インポート機能、あるいは Prime Provisioning API を利用するサードパーティの Operations Support System（OSS）クライアント プログラムを使用して作成することもできます。これらのオプションについては、それぞれ次の項を参照してください。

• 「手動作成」

• 「Discovery」

• 「インベントリ マネージャ デバイスのインポート」

• 「Prime Provisioning API」

• 「Prime Provisioning API」

（注） デバイスの作成時に、デバイス アクセス情報（ログインおよびパスワード）が、物理デバイスに設定されている情報と一致している必要があります。

手動作成

手動作成では、必要な設定を Prime Provisioning グラフィカル ユーザ インターフェイス（GUI）により入力することで、オブジェクトを Prime Provisioning リポジトリに追加できます。オブジェクトの手動作成は、Prime Provisioning リポジトリに追加するオブジェクト数が少ない場合に推奨されます。オブジェクトの手動作成の手順を次に示します。

1. プロバイダーを作成します。

2. プロバイダー リージョンを作成します。

3. デバイスを作成します。

4. インターフェイス設定などのデバイス設定を収集します

5. PE デバイスを作成し、プロバイダー デバイスおよびプロバイダー エッジ デバイスのロールを割り当てます。

（注） Provider（P; プロバイダー）デバイスおよびプロバイダー エッジ（PE）デバイスは、いずれも適切な PE ロール タイプが割り当てられた PE デバイス オブジェクトとして Prime Provisioning リポジトリに追加する必要があります。プロバイダー デバイスおよびプロバイダー エッジ デバイスに割り当てる必要のある PE ロール タイプの詳細については、「インベントリの設定」を参照してください。Prime Provisioning サーバおよびデバイス間で使用するトランスポート メカニズムを選択する場合、Cisco CNS Configuration Engine は Diagnostics に必要なコマンドをサポートしないため、MDE と組み合わせて使用できません。Cisco CNS Configuration Engine を Diagnostics と使用しようとすると、Diagnostics はデバイスに接続できないと間違って報告します。

プロバイダー、プロバイダー リージョン、デバイス、および PE デバイス オブジェクトを手動で作成する方法については、 を参照してください。

デバイスを手動作成する場合は、対象のデバイスのインターフェイス設定も追加する必要があります。

インターフェイス設定は、デバイス作成時に手動で追加することも、タスク マネージャの Collect Configuration タスクを使用して追加することもできます。タスク マネージャの Collect Configuration タスクの実行方法の詳細については、「デバイス設定の収集」を参照してください。Collect Configuration タスクを使用することを推奨します。

Discovery

Discovery では、XML ファイルに最低限のデバイスおよびトポロジ情報を設定することにより、ネットワークのデバイスを Prime Provisioning リポジトリに追加できます。次に、Discovery プロセスはこれらのデバイスを照会し、必要なデバイスおよびトポロジ情報を Prime Provisioning リポジトリに入力します。リポジトリに追加するオブジェクト数が多い場合は、Discovery の使用を推奨します。

Prime Provisioning Discovery には、デバイスを検出するための方法として CDP とデバイス/トポロジの 2 つが用意されています。デバイス検出を実行する前に、Discovery に必要な XML コンフィギュレーション ファイルを作成することが必要です。デバイスを検出する方法の詳細については、 付録 E「インベントリ - ディスカバリ」 を参照してください。

（注） Provider（P; プロバイダー）デバイスおよびプロバイダー エッジ（PE）デバイスは、いずれも適切な PE ロール タイプが割り当てられた PE デバイス オブジェクトとして Prime Provisioning リポジトリに追加する必要があります。プロバイダー デバイスおよびプロバイダー エッジ デバイスに割り当てる必要のある PE ロール タイプの詳細については、「インベントリの設定」を参照してください。

（注） Discovery の完了後に、検出されたすべてのデバイスに対してタスク マネージャの Collect Configuration タスクを実行する必要があります。Collect Configuration タスクを実行しないと、Diagnostics は検出されたデバイスにログインして、トラブルシューティングを実行できません。タスク マネージャの Collect Configuration タスクの実行方法の詳細については、「デバイス設定の収集」を参照してください。

インベントリ マネージャ デバイスのインポート

インベントリ マネージャのデバイス インポート機能を使用すると、デバイスの Cisco IOS 実行コンフィギュレーションを含むファイルから Prime Provisioning リポジトリに複数のデバイスをインポートできます。リポジトリに追加するオブジェクト数が多い場合は、インベントリ マネージャのデバイス インポート機能の使用を推奨します。デバイスをインポートする方法の詳細については、 付録 E「インベントリ - ディスカバリ」 を参照してください。

プロバイダー（P）およびプロバイダー エッジ（PE）デバイスをインポートする前に、必要なプロバイダーおよびプロバイダー リージョン オブジェクトを作成する必要があります。プロバイダーおよびプロバイダー リージョンオブジェクトを手動で作成する方法については、 付録 E「インベントリ - ディスカバリ」 を参照してください。

デバイスをインポートするときは、Cisco IOS 実行コンフィギュレーションを含むファイルがあるディレクトリを指定する必要があります。ファイル名は指定しないでください。ファイルは、Prime Provisioning サーバからアクセスできるファイル システムのディレクトリに存在する必要があります。

（注） Provider（P; プロバイダー）デバイスおよびプロバイダー エッジ（PE）デバイスは、いずれも適切な PE ロール タイプが割り当てられた PE デバイス オブジェクトとして Prime Provisioning リポジトリに追加する必要があります。プロバイダー デバイスおよびプロバイダー エッジ デバイスに割り当てる必要のある PE ロール タイプの詳細については、「インベントリの設定」を参照してください。

（注） イネーブル シークレット パスワードは、Cisco IOS 実行コンフィギュレーションに追加される前に暗号化されます。その結果、デバイス インポート機能は、Prime Provisioning リポジトリにインポートするデバイスに対してイネーブル シークレット パスワードを設定できません。インポートするデバイスにイネーブル シークレット パスワードが設定されている場合は、Prime Provisioning リポジトリでこれらのデバイスに手動でイネーブル パスワードを設定する必要があります。イネーブル シークレット パスワードとイネーブル パスワードの両方がデバイスに設定されている場合、インベントリ マネージャのデバイス インポート機能は Prime Provisioning リポジトリに追加するデバイスにイネーブル パスワードを使用します。このパスワードは正しいイネーブル シークレット パスワードで上書きする必要があります。Prime Provisioning リポジトリのデバイスのイネーブル パスワードは、デバイスのインポート中にも、デバイスのインポート後にも設定できます。

（注） デバイス インポートの完了後に、インポートされたすべてのデバイスに対してタスク マネージャの Collect Configuration タスクを実行する必要があります。Collect Configuration タスクを実行しないと、Diagnostics はインポートされたデバイスにログインして、トラブルシューティングを実行できません。タスク マネージャの Collect Configuration タスクの実行方法の詳細については、「デバイス設定の収集」を参照してください。

Prime Provisioning API

Prime Provisioning アプリケーション プログラム インターフェイス（API）は、Prime Provisioning システムに接続するために Operations Support System（OSS）クライアント プログラムを使用することができます。Prime Provisioning API は、Prime Provisioning サーバからデータの挿入、取得、更新、および削除を行うためのメカニズムを提供します。API を使用して、必要なプロバイダー、プロバイダー リージョン、デバイスおよび PE デバイス オブジェクトを追加できます。

（注） Prime Provisioning API は Diagnostics に標準には含まれておらず、別途購入できます。

Prime Provisioning API の使用方法の詳細については、 『Cisco Prime Provisioning 6.3 API Programmer Guide』 および 『Cisco Prime Provisioning API 6.3 Programmer Reference』を参照してください。

デバイス設定の収集

タスク マネージャの Collect Configuration タスクを使用して、Prime Provisioning リポジトリのデバイスにインターフェイス設定を追加することを推奨します。タスク マネージャの Collect Configuration タスクはネットワークの物理デバイスに接続し、ルータからデバイス情報（インターフェイス設定を含む）を収集して、その情報を Prime Provisioning リポジトリに入力します。

タスク マネージャの Collect Configuration タスクを使用してデバイス インターフェイスの設定を追加する方法の詳細については、を参照してください 。

デバイス設定と Prime Provisioning リポジトリの同期

（注） 診断の精度は最新のデバイス情報に依存します。デバイス設定に何らかの変更を加えた後および定期的に、デバイス設定を物理デバイスと再同期することを推奨します。これにより、Prime Provisioning インベントリに保持されているデバイス設定がネットワークの物理デバイスと一致します。

タスク マネージャのスケジュール タスクを使用して、デバイス設定を最新に保つことを推奨します。Collect Configuration と Collect Configuration from File のどちらでも使用できます。タスク マネージャの Collect Configuration スケジュール タスクの作成方法の詳細については、を参照してください。MPLS ネットワークの PE および P ルータは、すべてがタスク マネージャのスケジュール タスク Collect Configuration を使用してその設定を収集する必要があります。タスク マネージャの Collect Configuration タスクでは、インターフェイス設定およびその他のデバイス属性の詳細が収集されます。タスク マネージャの Collect Configuration タスクの実行スケジュール間隔は、ネットワークに対する設定変更の頻度に依存します。タスク マネージャの Collect Configuration タスクを各 P および PE ルータで毎日実行することを推奨します。

Diagnostics 接続テストの概要

接続性テストは、CE - CE 間ネットワーク全体のサブセクションのトラブルシューティングを目的としています。次の接続性テストが用意されています。

1. L3VPN - CE to CE：2 つの CE 間の MPLS VPN 接続性をチェックします。「L3VPN - CE to CE 接続性テスト」を参照してください。

2. L3VPN - PE to attached CE：PE と、接続されている CE の間の MPLS VPN 接続性をチェックします。「L3VPN - PE to attached CE 接続性テスト」を参照してください。

3. L3VPN - CE to PE across Core：MPLS コアをまたがる CE と PE 間の MPLS VPN 接続性をチェックします。「L3VPN - CE to PE across Core 接続性テスト」を参照してください。

4. L3VPN - PE to PE in VRF：2 つの PE 間の MPLS VPN 接続性をチェックします。「L3VPN - PE to PE in VRF 接続性テスト」を参照してください。

5. MPLS - PE to PE：2 つの PE 間の MPLS コア接続性をチェックします。「L3VPN - PE to PE 接続テスト」を参照してください。

L3VPN - CE to CE 接続性テスト

L3VPN - CE to CE テスト（図 11-4）は、2 つの CE 間またはカスタマー デバイス IP アドレスが既知のカスタマー デバイス間の MPLS VPN 接続性をチェックします。

図 11-4 L3VPN - CE to CE 接続性テスト

この場合、Diagnostics はコア、エッジ、および接続回線のトラブルシューティングを実行します。

IPv6 トラブルシューティング

L3VPN - CE to CE テストでは、次のすべての条件が満たされている場合に、IPv6 セグメントのトラブルシューティングを起動します。

• インターフェイス選択画面でグローバル ユニキャスト IPv6 アドレスが入力された行を選択した、または指定したローカルおよびリモート PE アクセス回線インターフェイスがグローバル ユニキャスト IPv6 アドレスを持っている、またはデータベースでインターフェイスの詳細情報を使用できない場合。

• ローカルサイトおよびリモートサイトに指定した CE アクセス回線インターフェイス IP アドレスの両方がグローバル ユニキャスト IPv6 アドレスの場合。

• オプションで、ローカル サイトおよびリモート サイトの両方またはいずれか一方に指定したカスタマー デバイス IP アドレスがグローバル ユニキャスト IPv6 アドレスの場合。

L3VPN - PE to attached CE 接続性テスト

L3VPN - PE to attached CE 接続テスト（図 11-5）は、PE とローカルに接続された CE 間の VPN 接続性テストを実行します。この場合、Diagnostics はエッジおよび接続回線のトラブルシューティングを実行します。

図 11-5 L3VPN - PE to attached CE 接続性テスト

L3VPN - PE to attached CE 接続性テストは、逆の方向には実行できません。

接続の問題は、多くの場合ローカルの接続回線に原因があります。利用できない可能のあるリモート サイトの PE および CE の詳細を必要とせずに、ローカルの接続回線を単独でテストできます。

L3VPN - PE to attached CE 接続性テストによって、VRF 対応 IP SLA プローブで報告されるものと同じ接続回線の接続断を診断できます。この通知には、Diagnostics で対応するアクセス回線の接続性テストを設定するために必要な、すべての情報が含まれています。

IPv6 トラブルシューティング

L3VPN - PE to attached CE テストでは、次のすべての条件が満たされている場合に、IPv6 セグメントのトラブルシューティングを起動します。

• インターフェイス選択画面でグローバル ユニキャスト IPv6 アドレスが入力された行を選択した、または指定した PE アクセス回線インターフェイスがグローバル ユニキャスト IPv6 アドレスを持っている、またはデータベースでインターフェイスの詳細情報を使用できない場合。

• 指定した CE アクセス回線インターフェイス IP アドレスがグローバル ユニキャスト IPv6 アドレスの場合。

• オプションで、指定したカスタマー デバイス IP アドレスがグローバル ユニキャスト IPv6 アドレスの場合。

L3VPN - CE to PE across Core 接続性テスト

L3VPN - CE to PE across Core 接続性テスト（図 11-6）は、MPLS コアをまたいだ、CE またはカスタマーデバイス（カスタマー デバイス IP アドレスが既知のもの）と PE 間の MPLS VPN 接続性をチェックします。

図 11-6 L3VPN - CE to PE across Core 接続性テスト

この場合、Diagnostics はコア、両方のエッジ、および接続回線のトラブルシューティングを実行します。

IPv6 トラブルシューティング

L3VPN - CE to PE across Core テストでは、次のすべての条件が満たされている場合に、IPv6 セグメントのトラブルシューティングを起動します。

• インターフェイス選択画面でグローバル ユニキャスト IPv6 アドレスが入力された行を選択した、または指定した PE アクセス回線インターフェイスがグローバル ユニキャスト IPv6 アドレスを持っている、またはデータベースでインターフェイスの詳細情報を使用できない場合。

• 指定した CE アクセス回線インターフェイス IP アドレスがグローバル ユニキャスト IPv6 アドレスの場合。

• オプションで、指定したカスタマー デバイス IP アドレスがグローバル ユニキャスト IPv6 アドレスの場合。

• 選択または指定された PE アクセス回線インターフェイスにグローバル ユニキャスト IPv6 アドレスがあるか、インターフェイス詳細がデータベースにない場合。

L3VPN - PE to PE in VRF 接続性テスト

VRF 接続性テストの L3VPN - PE to PE（図 11-7）は、2 つの PE 間の MPLS 接続性をチェックします。Diagnostics はコアおよび両側のエッジのトラブルシューティングを実行します。

図 11-7 L3VPN - PE to PE in VRF 接続性テスト

組織によっては、コアまたはエッジ ネットワークをプロビジョニングしても、すぐには CE を割り当てないことがあります。L3VPN - PE to PE in VRF 接続性テストを使用すると、段階的にネットワークを展開してテストできます。また、このテスト オプションでは高い柔軟性も提供され、CE 情報の準備ができていないときにエッジまたはコア ネットワーク セグメントをテストできます。

さらに、L3VPN - PE to PE in VRF 接続性テストによって、VRF 対応 IP SLA プローブで報告されるものと同じ短距離（PE からリモート PE）VPN 接続断も診断できます。この通知には、Diagnostics で対応するエッジの接続性テストを設定するために必要な、すべての情報が含まれています。

IPv6 トラブルシューティング

L3VPN - PE to PE in VRF テストでは、次のすべての条件が満たされている場合に、IPv6 セグメントのトラブルシューティングを起動します。

• グローバル ユニキャスト IPv6 アドレスを持つローカル サイト PE アクセス回線インターフェイスまたはリモート サイト PE アクセス回線インターフェイスのいずれかを、インターフェイス選択画面で選択する必要がある場合。

• インターフェイス選択画面でグローバル ユニキャスト IPv6 アドレスが入力された行を選択した、または指定したローカル PE アクセス回線インターフェイスがグローバル ユニキャスト IPv6 アドレスしか持っていない場合。

• インターフェイス選択画面でグローバル ユニキャスト IPv6 アドレスが入力された行を選択した、または指定したリモート PE アクセス回線インターフェイス IP アドレスがグローバル ユニキャスト IPv6 アドレスしか持っていない場合。

L3VPN - PE to PE 接続テスト

L3VPN - PE to PE コア接続性テスト（図 11-8）は、2 つの PE 間の MPLS 接続性をチェックします。

図 11-8 L3VPN - PE to PE コア接続性テスト

L3VPN - PE to PE コア テストは、CE インターフェイスへのアクセスがブロックされている場合（たとえばアクセス リストの使用によるもの）または組織内の異なるグループが、それぞれ別のネットワーク セグメントについて責任を負っている場合を対象にしています。たとえば、Core グループの P に問題があるが、完全な CE-CE または PE-PE テストを実行するためのエンド カスタマーのコンテキストがない場合が該当します。

L3VPN - PE to PE コア テストによって、MPLS 対応 PE 間の接続性をテストする IP SLA ヘルス モニタ プローブで報告されるものと同じコア接続断を診断できます。この通知には、Diagnostics で対応するコアの接続性テストを設定するために必要な、すべての情報が含まれています。

IPv6 トラブルシューティング

コア内の L3VPN - PE to PE テストの場合、このテスト タイプは IPv4 アドレスのみを使用するため、IPv6 トラブルシューティングは開始できません。

MPLS VPN 接続性検証テストの実行

この項では、MPLS VPN 接続性検証テストの実行方法について説明します。ここでは、次の項目について説明します。

• 「[MPLS Diagnostics Expert Feature Selection] ウィンドウを開く」

• 「L3VPN - CE to CE テストの選択、設定および実行」

• 「L3VPN - PE to attached CE テストの選択、設定および実行」

• 「L3VPN - CE to PE across Core テストの選択、設定、および実行」

• 「L3VPN - PE to PE テストの選択、設定および実行」

• 「MPLS - PE to PE テストの選択、設定および実行」

（注） IOS XR バージョン 3.8.0 以降のデバイスで実行される各コマンドでは、出力の最初の行に、Diagnostics が処理できなかったデバイスの現在のタイムスタンプが表示されます。XR デバイスのタイムスタンプを無効にするには、テストを起動する前に、timestamp disable コマンドを使用する必要があります。

[MPLS Diagnostics Expert Feature Selection] ウィンドウを開く

（注） 同じクライアント マシンで並行して複数の MPLS VPN 接続性検証テストを実行する場合は、各テストを異なる HTTP セッションで実行する必要があります。そのためには、コマンドライン、またはデスクトップのブラウザのアイコン、または [Start] メニューから起動した個別のブラウザで各テストを実行します。同じブラウザ ウィンドウの別のタブ、または既存のブラウザ ウィンドウから起動したブラウザ ウィンドウで、複数のテストを並行して実行しないでください。

ステップ 1 Prime Provisioning にログインします。ログイン方法の詳細については、 『Cisco Prime Provisioning 6.3 Installation Guide』 を参照してください（「 Installing and Logging Into Prime Provisioning 」 > 「 Logging In for the First Time 」）。

Prime Provisioning のホーム ウィンドウが表示されます。

ステップ 2 [Diagnostics] タブをクリックします。

[MPLS Diagnostics Expert Feature Selection] ウィンドウが表示され、使用できる MPLS VPN 接続性検証テスト タイプが示されます。

（注） また、少なくとも 1 つの Diagnostics ユーザ ロールが割り当てられていることを確認する必要があります。「ユーザ ロール」を参照してください。

（注） 使用できるテスト タイプは、割り当てられているユーザ ロールによって決まります。ユーザ ロールは、テスト タイプごとに定義する必要があります。テスト タイプにアクセスできない場合、そのテスト タイプは [MPLS Diagnostics Expert Feature Selection] ウィンドウに表示されません。詳細については、「ユーザ ロール」を参照してください。

L3VPN - CE to CE テストの選択、設定および実行

この項では、L3VPN - CE to CE テスト タイプを選択、設定、および実行する方法の詳細について説明します。

ステップ 1 [Diagnostics] メニューから、[L3VPN - CE to CE] テスト タイプを選択します。

ステップ 2 [L3VPN - CE to CE] 接続性検証テスト タイプをクリックします。

L3VPN - CE to CE 接続性検証テスト タイプの詳細については、「L3VPN - CE to CE 接続性テスト」を参照してください。[L3VPN - CE to CE] ウィンドウが表示され、L3VPN - CE to CE テスト タイプに対応する入力ウィンドウが表示されます。

ヒント 使用できるテスト タイプごとに独自の入力ウィンドウがあり、異なるパラメータのセットを必要とします。たとえば、L3VPN - CE to CE テストにはローカル サイトとリモート サイトの両方の情報が必要で、L3VPN - PE to attached CE テストのテスト設定ウィンドウではローカル サイトの詳細だけが要求されます。

図 11-9 L3VPN - CE to CE テスト タイプ

[L3VPN - CE to CE] ウィンドウを使用して、実行する接続性テストを設定できます。

このウィンドウには、次のコンポーネントが表示されます。

• ネットワーク図

• ローカル サイト設定領域

• リモート サイト設定領域

ネットワーク図は、テストを設定するために入力する必要がある情報のコンテキストを提供する静的なイメージです。

MPLS VPN 接続性検証は、VPN 内にある 2 つのサイト間の接続性をテストします。テストを通じて、これらのサイトはローカル サイトおよびリモート サイトと呼ばれます。接続性の問題は、特定のサイトの視点から報告または検出されることが予想されます。通常は、この特定のサイトをローカル サイトとして使用し、このサイトからテストを実行します。ただし、これは必須ではありません。接続性は両方向でテストできるため、どちらのサイトもローカル サイトまたはリモート サイトとして使用できます。

L3 VPN 接続性テストの範囲（図 11-10 を参照）は、サイトごとに変更できます。サイトごとに、そのサイト内にあるカスタマー デバイスへの接続性（図 11-10 の 1 ）、または CE アクセス回線インターフェイスへの接続性（図 11-10 の 2 ）をテストできます。テスト範囲は、指定した設定によって決まります。

カスタマー デバイスの IP アドレスが既知の場合は、そのデバイスへの接続性検証テストを実行することを推奨します。カスタマー デバイスの IP アドレスが未知の場合は、サイトの CE までの接続性検証テストを実行できます。

図 11-10 テスト範囲

1. カスタマー デバイス。

2. CE アクセス回線インターフェイス。

カスタマー サイトのサブネットワーク内にあるデバイスへの接続性をテストするには、[Customer Device IP Address] フィールドにデバイスの IP アドレスを入力します。デフォルトでは、サイトの必須フィールドだけを指定した場合、CE アクセス回線インターフェイスへのテストが実行されます。

（注） 必須フィールドは、[L3VPN - CE to CE Diagnostics - Test Setup] ウィンドウに、青いアスタリスクで示されています。すべての必須フィールドに有効な情報が入力されるまでは、次に進めません。

（注） /30 または /31 アドレッシングが使用されている場合は、[CE Access Circuit Interface IP Address] フィールドは Diagnostics により自動的に入力されます。

Cisco IOS および Cisco IOS XR アクセス コントロール リスト（ACL）により、さまざまな基準に基づいて選択したトラフィックがブロックされるようにできます。カスタマー デバイスまたは CE インターフェイスへの MPLS VPN 接続性検証テストを実行したときに、CE 上で設定されている ACL が原因で、矛盾した結果が報告される場合があります。可能な場合、MPLS VPN 接続性検証テストは、CE デバイス上で設定されている ACL によってトラフィックがブロックされたことを報告します。ただし ACL の設定によっては、CE デバイス上で設定されている ACL によってトラフィックがブロックされたことを識別できない場合があります。場合によっては、MPLS VPN 接続性検証テストでアクセス回線の障害または不明な障害が報告されることがあります。トラフィックが CE でブロックされている疑いがある場合は、そのサイトの [Pings Ignored] チェックボックスをオンにしてください。このようにすると、Diagnostics はトラブルシューティング時にブロッキング アクセス ACL を考慮し、見つかった問題についてより正確な診断が返されます。

（注） サイトの [Pings Ignored] チェックボックスをオンにした場合は、CE IP アドレスとオプションで [Customer Device IP Address] フィールドを使用して、PE デバイスでトラブルシューティングおよび設定チェックが実行されます。

ステップ 3 必要に応じて [L3VPN - CE to CE] ウィンドウのフィールドを設定します。

表 11-3 には、[L3VPN - CE to CE] ウィンドウのフィールド説明が表示されています。

（注） 表示されるフィールドは、選択したテスト タイプによって異なります。たとえば、CE to CE テストにはローカル サイトとリモート サイトの両方の情報が必要で、PE to attached CE テストのテスト設定ウィンドウではローカル サイトの詳細だけが要求されます。

（注） テストを設定する別の方法として、カスタマー VPN 情報を使用する方法があります。詳細については、「カスタマー VPN/VRF 情報を使用した設定」を参照してください。

ステップ 4 すべての必須フィールドに入力したら、[OK] をクリックしてテストを実行します。

[Progress] ウィンドウが表示されます。「[Progress] ウィンドウ」を参照してください。

PE デバイスの選択

（ローカルまたはリモートの [PE Device Name] の）[Select] ボタンをクリックすると、[Select PE Device] ウィンドウ（図 11-11を参照）が開き、ローカルまたはリモート サイト PE を選択できます。[Select PE Device] ウィンドウには、インベントリで使用できるすべての PE デバイスを含むテーブルが表示されます。

（注） Diagnostics デバイス セレクタのデフォルト値を設定できます。図 11-11 を参照してください。設定可能な値は、[Device Name]、[Provider]、および [PE Region Name] です。

図 11-11 [Select PE Device] ウィンドウ

（注） PE 表に表示されるすべての PE 属性について、ワイルドカードを使用した文字列検索を実行できます。Prime Provisioning インベントリからローカルまたはリモート サイトの PE を選択すると、ローカルまたはリモートの [PE Device Name] フィールドに入力されたすべての値が上書きされます（図 11-9 を参照）。この検索機能は、大量の PE がある大規模なネットワークで便利です。

PE アクセス回線インターフェイスの選択

（ローカルまたはリモートの [PE Access Circuit Interface] の）[Select] ボタンをクリックすると、[Select Device Interface] ウィンドウ（図 11-12を参照）が開き、インターフェイス名を選択できます。[Select Device Interface] ウィンドウには、選択されたローカルまたはリモート PE デバイスのすべてのインターフェイスを含むテーブルが表示されます。

図 11-12 [Select Device Interface] ウィンドウ

表に表示されるすべての属性について、ワイルドカードを使用した文字列検索を実行できます。Prime Provisioning インベントリからローカルまたはリモートの PE アクセス回線インターフェイスを選択すると、ローカルまたはリモートの [PE Access Circuit Interface] フィールドに入力されたすべての値が上書きされます（図 11-9を参照）。

表 11-4 に、[Select Device Interface] ウィンドウのフィールドの説明を示します。

ワンポイント アドバイス [Show Device Interfaces with] ドロップダウン ボックスと [matching] フィールドを使用して、最初に適切な検索パターンを入力します（図 11-12 を参照）。これによって、大規模なネットワークで発生する、大きくて時間がかかる余分な検索をせずに済みます。表 11-4 に、[Select Device Interface] ウィンドウのフィールドの説明を示します。

ヒント [Interface Description] を使用して、カスタマー接続の詳細を記述することを推奨します。Diagnostics では、[Interface Description] の検索ができます（カスタマー回線 ID など）。詳細については、「L3VPN - CE to PE across Core テストの選択、設定、および実行」および「L3VPN - PE to PE テストの選択、設定および実行」を参照してください。

IOS マルチリンク アクセス回線インターフェイス間のテスト

Diagnostics では、Cisco IOS マルチリンク アクセス回線インターフェイスをまたがるトラブルシューティングがサポートされます。トラブルシューティングは、マルチリンク バンドル インターフェイスでのみ実行されます。個別のバンドル リンクのトラブルシューティング、またはマルチリンク固有のトラブルシューティングは実行されません。次のマルチリンク技術がサポートされます。

• マルチリンク PPP over Frame Relay（マルチリンク グループ インターフェイス設定）

• マルチリンク PPP over Frame Relay（仮想テンプレート インターフェイス設定）

• マルチリンク PPP over ATM（マルチリンク グループ インターフェイス設定）

• マルチリンク PPP over ATM（仮想テンプレート インターフェイス設定）

• シリアル上のマルチリンク PPP

• マルチリンク フレームリレー

（注） マルチリンクは Cisco IOS でのみサポートされ、Cisco IOS XR ではサポートされません。

（注） マルチリンク アクセス回線インターフェイスでは、レイヤ 2 フレーム リレー、ATM、およびイーサネットのトラブルシューティングは実行されません。

各マルチリンク バンドルには、関連付けられている多数のインターフェイスがあります。マルチリンク アクセス回線で MPLS VPN 接続性検証テストを設定するときは、正しいインターフェイスを [MPLS VPN Test Configuration] ウィンドウの [PE Access Circuit Interface] フィールドに入力する必要があります。入力する必要があるインターフェイスは、使用するマルチリンク設定に応じて異なります。 表 11-5 で、[PE Access Circuit Interface] フィールドに入力する必要があるインターフェイスについてマルチリンク技術ごとに説明します。

マルチリンク フレーム リレー（MFR）を除き、マルチリンク バンドルを表すインターフェイスを [PE Access Circuit Interface] フィールドに入力する必要があります。マルチリンク フレーム リレーの場合は、フレーム リレー インターフェイス、または仮想回線が設定されているサブインターフェイスを入力する必要があります。これは、MFR インターフェイスまたは MFR インターフェイスのサブインターフェイスの場合があります。いずれの場合も、[PE Access Circuit Interface] フィールドに入力されたインターフェイスには IP アドレスと VRF が必要で、アップ/アップ状態になっている必要があります。

PE デバイスの有効なマルチリンク バンドル インターフェイスを判別するには、 show ppp multilink または show frame-relay multilink IOS コマンドを使用します。PE デバイスにアクティブなマルチリンク バンドルがない場合、設定済みマルチリンク バンドルがないか、設定済みマルチリンク バンドルのすべてのバンドル リンクがダウン/ダウン状態になっている可能性があります。

（注） 仮想アクセス インターフェイスは、動的に作成されて、割り当てられます。仮想アクセス インターフェイスが属するマルチリンク バンドルと、その役割は、インターフェイスの状態が変化するに従って変化することがあります。そのため、仮想アクセス インターフェイスは Prime Provisioning/Diagnostics リポジトリに保存されません。仮想アクセス インターフェイスを使用して VPN 接続性検証テストを設定するときは、手動でインターフェイス名を [MPLS VPN Test Configuration] ウィンドウの [PE Access Circuit Interface] フィールドに入力する必要があります。[Interface Selection] ポップアップ ダイアログボックスから仮想アクセス インターフェイスを選択することはできません。

カスタマー VRF 情報を使用した設定

[MPLS VPN Connectivity Verification] ウィンドウに情報を入力するときは、PE ホスト名または PE インターフェイスの詳細を入力する必要があります。場合によっては、PE ホスト名または PE インターフェイスの詳細がわからないことがあります。ただし、この情報は対応する既知の VRF 名によって識別できます。対応する VRF 名は、VRF 検索を使用して識別できます。

（注） VRF 名でインターフェイスを検索するには、あらかじめ Prime Provisioning タスク マネージャの Collect Configuration タスクを実行し、VRF 名を Prime Provisioning にアップロードしておく必要があります。VRF 検索は、最後に実行した Collect Configuration タスク内の情報に基づきます。タスク マネージャの Collect Configuration タスクの実行方法の詳細については、「デバイス設定の収集」を参照してください。

ステップ 1 [MPLS VPN Connectivity Verification] ウィンドウの [Find by VRF] ボタンをクリックします。

[Select Device for VRF Search] ウィンドウが表示されます。

（注） [Select Device for VRF Search] ウィンドウに表示されるフィールドは、PE データ フィールドに入力されているかどうかにかかわらず、最初は空です。

ステップ 2 [Select Device for VRF Search] ウィンドウに表示されるフィールドを設定します。

表 11-6 に、[Select Device for VRF Search] ウィンドウのフィールドの説明を示します。

ワンポイント アドバイス まず、該当する検索パターンを入力します。これによって、大規模なネットワークで発生する、大きくて時間がかかる余分な検索をせずに済みます。VRF 名のパターンを入力し、[Find] ボタンをクリックします。たとえば、t* と入力して [Find] をクリックすると、文字 t で始まるすべての VRF のリストが表示されます。[Show Devices with] ドロップダウン ボックスから選択し、[matching] フィールドに情報を入力して [Find] をクリックすると、結果リストをさらにフィルタリングできます。表 11-6 に、[Select Device for VRF Search] ウィンドウのフィールドの説明を示します。

ステップ 3 [Find] をクリックして、検索を開始します。

[Select Device for VRF Search] ウィンドウに表示されるテーブルに、検索結果が入力されます。

ヒント 各カラムに表示されている情報をソートするには、カラム見出しをクリックします。

ヒント [VRF Name] および [Interface Description] カラムの情報を表示するため、必要に応じてテーブルの幅が自動的に拡大されます。テーブルの幅が拡大された場合は、水平方向のスクロールバーを使用してウィンドウの右側にスクロールします。

ステップ 4 （任意）[Show Devices with] ドロップダウン ボックスおよび [matching] フィールドを設定して、検索結果を調整します。

[Find] をクリックして、検索結果でテーブルを更新します。

ステップ 5 オプション ボタンをクリックして、必要な PE デバイス名とインターフェイス名を選択します。

ステップ 6 [Select] をクリックします。

[Select Device for VRF Search] ウィンドウが閉じます。選択した値が [PE Device Name] および [PE Access Circuit Interface] フィールドに入力された状態で、[L3VPN - CE to CE Diagnostics - Test Setup] ウィンドウが表示されます。

カスタマー VPN/VRF 情報を使用した設定

Diagnostics は、他の Prime Provisioning 機能から独立して、スタンドアロンで使用できます。ただし、Prime Provisioning VPN/VRF プロビジョニング機能を使用してネットワーク内で VPN/VRF をプロビジョニングしている場合は、MPLS VPN 接続性検証テストを設定する代替手段として、カスタマーおよび VPN/VRF に関連付けられているこのプロビジョニング情報を使用できます。デバイス固有の設定を指定するのではなく、カスタマー、VPN/VRF、ローカル サイト、およびリモート サイトを指定します。必要なすべてのテスト設定は、この情報から取得されます。

（注） カスタマー VPN/VRF 情報を使用して MPLS VPN 接続性検証テストを設定するオプションは、Prime Provisioning VPN/VRF プロビジョニング機能を使用してネットワーク内で VPN/VRF をプロビジョニングしている場合にのみ使用できます。

ステップ 1 [L3VPN - CE to CE Diagnostics - Test Setup] ウィンドウの [Find by Service] ボタンをクリックします。

[Populate using VPN/VRF] ウィンドウが表示されます。

ステップ 2 [Populate using VPN/VRF] ウィンドウに表示されるフィールドを設定します。

表 11-7 に、[Populate using VPN/VRF] ウィンドウのフィールドの説明を示します。

ステップ 3 [OK] をクリックします。

[L3VPN - CE to CE Diagnostics - Test Setup] ウィンドウが再表示されます。[Populate using VPN/VRF] ウィンドウで指定したカスタマー VPN/VRF 情報に基づいて、必要なフィールドが入力されます。

（注） カスタマー デバイスをテストする場合は、ローカルまたはリモート サイトの [Customer Device IP Address] フィールドに IP アドレスを入力できます。

（注） 自動入力された [L3VPN - CE to CE Diagnostics - Test Setup] ウィンドウの任意のフィールドを編集できます。

ステップ 4 [L3VPN - CE to CE Diagnostics - Test Setup] ウィンドウの [OK] をクリックして、テストを実行します。

[Progress] ウィンドウが表示されます（「[Progress] ウィンドウ」を参照）。

VPN トポロジ

デフォルトで、MPLS VPN 接続性検証テストでは、ローカル サイトとリモート サイトはフル メッシュ VPN トポロジで接続され、これらのサイトは直接通信できると見なされます。テストするサイトがフル メッシュ以外の VPN トポロジで接続されている場合、MPLS VPN 接続性検証テストに必要な設定が異なる場合があります。この場合、テストから誤った結果が得られることがあります。そのため、テスト結果を解釈するときには注意が必要です。サポートされる各 VPN トポロジで必要な設定の詳細、およびテスト結果の解釈方法については、「VPN トポロジ」を参照してください。

L3VPN - PE to attached CE テストの選択、設定および実行

この項では、L3VPN - PE to attached CE テスト タイプを選択、設定、および実行する方法の詳細について説明します。

ステップ 1 [Diagnostics] メニューから、[L3VPN - PE to Attached CE] テスト タイプを選択します。

ステップ 2 [L3VPN - PE to attached CE] 接続性検証テスト タイプをクリックします。

PE to attached CE 接続性検証テスト タイプの詳細については、「L3VPN - PE to attached CE 接続性テスト」を参照してください。

[MPLS VPN Connectivity Verification Configuration] ウィンドウ（図 11-13 を参照）が表示され、PE to attached CE テスト タイプに対応したフィールドが表示されます。[MPLS VPN Connectivity Verification Configuration] ウィンドウで、実行する接続性テストを設定できます。

図 11-13 L3VPN - PE to Attached CE テスト タイプ

[L3VPN - PE to Attached CE] ウィンドウには、次のコンポーネントが表示されます。

• ネットワーク図

• ローカル サイト設定領域

これらのコンポーネントおよびテスト範囲については、「L3VPN - CE to CE テストの選択、設定および実行」に詳しい説明があります。

ステップ 3 必要に応じて [L3VPN - PE to Attached CE] ウィンドウのフィールドを設定します。

表 11-3 に、L3VPN - PE to attached CE テスト タイプに対応するフィールドの説明を示します。

ステップ 4 すべての必須フィールドに入力したら、[OK] をクリックしてテストを実行します。[Progress] ウィンドウが表示されます。「[Progress] ウィンドウ」を参照してください。

L3VPN - CE to PE across Core テストの選択、設定、および実行

この項では、L3VPN - CE to PE across Core テスト タイプを選択、設定、および実行する方法の詳細について説明します。

ステップ 1 [Diagnostics] メニューから、[L3VPN - CE to PE across Core] テスト タイプを選択します。

ステップ 2 [L3VPN - CE to PE across Core] 接続性検証テスト タイプをクリックします。

[L3VPN - CE to PE across core] 接続性検証テスト タイプの詳細については、「L3VPN - CE to PE across Core 接続性テスト」を参照してください。

[L3VPN - CE to PE Across MPLS Core Diagnostics - Test Setup] ウィンドウ（図 11-14 を参照）が表示され、L3VPN - CE to PE across Core テスト タイプに対応したフィールドが表示されます。[L3VPN - CE to PE Across MPLS Core Diagnostics - Test Setup] ウィンドウで、実行する接続性テストを設定できます。

図 11-14 L3VPN - CE to PE across Core テスト タイプ

[L3VPN - CE to PE Across Core] ウィンドウには、次のコンポーネントが表示されます。

• ネットワーク図

• ローカル サイト設定領域

• リモート サイト設定領域

これらのコンポーネントおよびテスト範囲については、「L3VPN - CE to CE テストの選択、設定および実行」に詳しい説明があります。

ステップ 3 必要に応じて [L3VPN - CE to PE across Core] ウィンドウのフィールドを設定します。

表 11-3 に、L3VPN - CE to PE across core テスト タイプに対応するフィールドの説明を示します。

ステップ 4 すべての必須フィールドに入力したら、[OK] をクリックしてテストを実行します。

[Progress] ウィンドウが表示されます。「[Progress] ウィンドウ」を参照してください。

L3VPN - PE to PE テストの選択、設定および実行

この項では、L3VPN - PE to PE テスト タイプを選択、設定、および実行する方法の詳細について説明します。

ステップ 1 [Diagnostics] メニューから、[L3VPN - PE to PE] テスト タイプを選択します。

L3VPN- PE to PE in VRF 接続性検証テスト タイプの詳細については、「L3VPN - PE to PE in VRF 接続性テスト」を参照してください。

[L3VPN- PE to PE in VRF Diagnostics - Test Setup] ウィンドウ（図 11-15 を参照）が表示され、L3VPN - PE to PE in VRF テスト タイプに対応したフィールドが表示されます。[L3VPN- PE to PE in VRF Diagnostics - Test Setup] ウィンドウで、実行する接続性テストを設定できます。

図 11-15 L3VPN - PE to PE テスト タイプ

[L3VPN - PE to PE in VRF Diagnostics - Test Setup] ウィンドウには、次のコンポーネントが表示されます。

• ネットワーク図

• ローカル サイト設定領域

• リモート サイト設定領域

これらのコンポーネントおよびテスト範囲については、「L3VPN - CE to CE テストの選択、設定および実行」に詳しい説明があります。

ステップ 2 必要に応じて [L3VPN - PE to PE in VRF Diagnostics - Test Setup] ウィンドウのフィールドを設定します。

表 11-3 に、L3VPN - PE to PE in VRF テスト タイプに対応するフィールドの説明を示します。

ステップ 3 すべての必須フィールドに入力したら、[OK] をクリックしてテストを実行します。

[Progress] ウィンドウが表示されます。「[Progress] ウィンドウ」を参照してください。

MPLS - PE to PE テストの選択、設定および実行

この項では、L3VPN - PE to PE（コア）テスト タイプを選択、設定、および実行する方法の詳細について説明します。

ステップ 1 [Diagnostics] メニューから、[MPLS - PE to PE] テスト タイプを選択します。

ステップ 2 [MPLS - PE to PE] 接続性検証テスト タイプをクリックします。

PE to PE 接続性検証テスト タイプの詳細については、「L3VPN - PE to PE 接続テスト」を参照してください。

[MPLS - PE to PE] ウィンドウ（図 11-16 を参照）が表示され、MPLS - PE to PE テスト タイプに対応したフィールドが表示されます。[MPLS - PE to PE] ウィンドウを使用して、実行する接続性テストを設定できます。

図 11-16 MPLS - PE to PE テスト タイプ

[MPLS - PE to PE] ウィンドウには、次のコンポーネントが表示されます。

• ネットワーク図

• ローカル サイト設定領域

• リモート サイト設定領域

これらのコンポーネントおよびテスト範囲については、「L3VPN - CE to CE テストの選択、設定および実行」に詳しい説明があります。

ステップ 3 必要に応じて [MPLS - PE to PE] ウィンドウのフィールドを設定します。

表 11-3 に、L3VPN - PE to PE テスト タイプに対応するフィールドの説明を示します。

ステップ 4 すべての必須フィールドに入力したら、[OK] をクリックしてテストを実行します。

[Progress] ウィンドウが表示されます。「[Progress] ウィンドウ」を参照してください。

MPLS - PE to PE テストへの LSP エンドポイント ループバック IP アドレスの設定

この項では、MPLS - PE to PE テスト タイプで LSP エンドポイント ループバック インターフェイスおよび IP アドレスを設定する方法の詳細について説明します。

リモート LSP エンドポイント ループバック IP アドレス

L3 VPN カスタマー トラフィックは、カスタマー ルートの BGP ネクスト ホップ アドレスを使用して LSP を選択します。コアをテストするときは、ローカル PE からリモート PE に MPLS OAM ping およびトレースが実行されます。トラフィックが経由するものと同じ LSP を Diagnostics でテストするには、Diagnostics がテストする IP プレフィックスがカスタマー ルートの BGP ネクスト ホップ アドレスになるようにします。

PE to PE コア テスト タイプでは、Diagnostics はカスタマー ルート情報を持っていません。そのため、Diagnostics は BGP ネクスト ホップを識別できません。デフォルトで、Diagnostics は ping およびトレースの宛先をネクスト ホップではなくリモート PE の BGP ルータ ID に基づいて選択します。複数のコアがある、複数のループバック アドレスが制御トラフィックおよびデータ プレーン トラフィックに使用されるなど一部のネットワーク設定では、この BGP ルータ ID がカスタマー トラフィックで使用されるネクスト ホップと一致せず、不正な LSP がテストされる（または、どの LSP もテストされない）ことがあります。

ローカル LSP エンドポイント ループバック IP アドレス

進行方向で実行したテストで問題を検出できなかった場合は、MPLS - PE to PE テスト タイプで逆方向のテストを実行できます。ローカル LSP エンドポイント ループバック IP アドレスを設定すると、逆方向のテストを実行するときに、正しい LSP が選択されます。

LSP エンドポイント ループバック IP アドレスを指定する場合

次の場合に、LSP エンドポイント ループバック IP アドレスを指定します。

• BGP ルータ ID が、LSP が割り当てられていないループバックのアドレスである。

• BGP ルータ ID がループバックのアドレスでない。

• 複数の LSP が定義されており、トラフィックはルータ ID により与えられた LSP 以外の LSP を使用している。

• 複数の定義済み LSP があり、トラフィックがルートマップに基づいて LSP を切り替える。

（注） リモート LSP エンドポイントを指定するときは、正しい BGP ネクスト ホップを指定する必要があります。

図 11-17 に、[LSP Endpoint Loopback IP Address] フィールドの使用方法を表したネットワーク トポロジの例を示します。このネットワーク トポロジの例には 3 つの論理 MPLS コアが存在し、一部の PE BGP ルータ ID はループバック インターフェイスに関連付けられていません。さらに、2 つの CE は、別々のコアにデュアルホーム接続されています。

図 11-17 ネットワーク トポロジの例

表 11-8 に、図 11-17 に示されているネットワーク トポロジの例に関連する IP アドレッシング情報を示します。

表 11-9 に、各 LSP をテストするときにリモート LSP エンドポイント IP アドレスとして使用できる IP アドレスを示します。

[Progress] ウィンドウ

テストの実行中に、[Progress] ウィンドウ（図 11-18 を参照）が表示されます。

（注） MPLS VPN 接続性検証テストの実行時間は、場合によって異なります。ネットワークのサイズ、選択したテスト タイプ、接続性の問題が識別されたかどうか、および、この接続性の問題の性質によっては、テストの完了までにしばらく時間がかかることがあります。

[Progress] ウィンドウには、完了した各ステップに関する 1 行のテキストによるサマリーと、現在実行中のステップが表示されます。

図 11-18 [Progress] ウィンドウ

必要な場合、[Cancel] ボタンをクリックするとテストがキャンセルされます。[Cancel] をクリックすると、テストを本当にキャンセルするかどうかの確認を求められます。確認すると、現在のステップが完了し次第、テストがキャンセルされます。現在のステップでデバイス間のやり取りが行われている場合は、それが完了してからテストがキャンセルされます。キャンセルを実行すると、[Test Results] ウィンドウが表示され、テストをキャンセルしたことが表示されます。テスト ログには、完了したステップすべてが表示されます。

テストが完了すると、[Test Results] ウィンドウが表示されます。詳細については、「テスト結果の解釈」を参照してください。

テスト結果の解釈

この項では、テスト結果の解釈方法について説明します。ここでは、次の項目について説明します。

• 「データ パス」

• 「Test Details」

• 「Test Log」

• 「Export」

MPLS VPN 接続性検証テストが完了すると、[Test Results] ウィンドウが表示されます（図 11-19 を参照）。

図 11-19 障害固有の追加情報が表示された [Test Results] ウィンドウ

[Test Result] ウィンドウには、見つかった問題の場所、原因、推奨されるアクション、観察結果、および実行された自動トラブルシューティングと診断ステップの詳細が表示されます。また、[Test Result] ウィンドウから、必要に応じて高度なトラブルシューティング オプションを起動できます（ 表 11-10 を参照）。

[Test Results] ウィンドウは、次のコンポーネントで構成されています。

テストしたパスに複数の障害がある場合、報告される障害は、Diagnostics が実行するトラブルシューティングの順序によって決まります。CE to CE 接続性テスト タイプの場合、Diagnostics トラブルシューティングは次の順序で実行されます。

1. アクセス回線（ローカルおよびリモート）。

2. MPLS Traffic Engineered（TE）トンネル。

3. MPLS コア。

4. MPLS VPN エッジ。

その他のテスト タイプも同じ順序でトラブルシューティングを実行しますが、すべてのステップを実行するわけではありません。

（注） [Test Result] ウィンドウには、最初に見つかった障害の詳細が表示されます。複数の障害が存在する場合は、現在の障害を修復してテストを再実行しないと、後続の障害はレポートされません。

データ パス

データ パス（図 11-20 を参照）は、テスト対象の 2 つのサイト間のパスを図で示します。MPLS Traffic Engineered トンネルで障害が見つかった場合は、データ パスにはトンネルが表示されます。パス内の障害ポイントよりも前で見つかった、重複していない P-P、PE-P、または P-PE MPLS TE トンネルも、データパスに表示されます。

図 11-20 データ パス

1. デバイスのロール（CE、PE、または P）。

2. MPLS ラベル（入力/出力）。

3. 障害の発生したデバイス。

4. トンネルの方向を示す矢印。

5. トンネル名。

6. トンネル ラベル。

7. デバイスのホスト名。

8. インターフェイス名。

MPLS TE トンネルが存在する場合は、デバイス パスの下に表示されます。

カスタマー デバイス IP アドレスを指定した場合は、この IP アドレスは「Customer Device」という文字の横に表示されます。

（注） MPLS TE トンネルは、そのトンネルが接続の問題の原因であると判明した場合のみ表示されます。

障害が見つかった場合は、データ パスで障害のあるデバイスまたはリンクが強調表示されます。データ パス内で使用されるデバイスの色については、 表 11-11 を参照してください。

表 11-11 データ パスのデバイス カラー コード

色	アイコン	説明
緑色		デバイスはテスト済みで、正常に機能しています。
青色		デバイスはテストされていないか、ステータスが不明です。
赤		デバイスに障害が発生しています。
黄色		デバイスに障害が発生している可能性があります。
グレー		デバイスにアクセスできません。

データ パス内で使用されるリンクの色については、 表 11-12 を参照してください。

表 11-12 データ パスのリンク カラー コード

色	アイコン	説明
赤		接続の問題が見つかっています。この障害の原因は、接続されているデバイスの片方または両方の問題である可能性があります。

各コア PE および P デバイスの場合は、次の情報が表示されます。

• ロール（PE または P）

• デバイス名

• インターフェイス名

• 入力および出力 MPLS ラベル（MPLS コアの障害のみ）

CE デバイスおよびカスタマー デバイスについては、最小限の情報しか表示されません。通常、これらのデバイスについては、テストの設定時に指定された情報だけが表示されます。

MPLS Traffic Engineered トンネルについては、次の情報が表示されます。

• トンネル名

• トンネルの方向（方向を示す矢印）

• トンネル ラベル

（注） [Test Result] ウィンドウのデータ パスからは、デバイスには Telnet 接続できません。

Test Details

[Test Results] ウィンドウの [Test Details] セクション（図 11-19 を参照）には、自動トラブルシューティングおよび診断結果の概要、トラブルシューティング中の観察結果、その他の障害固有の情報、および推奨アクションが表示されます。Diagnostics によってレポートされる障害および観察結果の詳細について、およびトラブルシューティングの一環として Diagnostics により実行される IOS および IOS XR コマンドすべてのリストの詳細については、 「障害シナリオ」 を参照してください。

テストの詳細の概要は、すべての場合で表示されます。テストの詳細の概要は、次の 3 つの詳細説明フィールドで構成されています。

• [Summary]：見つかった障害の簡単な概要が表示されます。

• [Possible Cause(s)]：考えられる障害の原因です。

• [Recommended Action]：問題を解決するために推奨されるアクションです。

その他の障害固有の情報は、必要に応じて概要の下に表示されます。これが表示された場合は、見つかった問題についてのその他の情報が提供されます。たとえば、Forwarding Information Base（FIB; 転送情報ベース）、ラベル転送情報ベース（LFIB）、ボーダー ゲートウェイ プロトコル（BGP）のテーブル エントリおよびルート ターゲット インポート/エクスポートです。このその他の障害固有の情報は、FIB、LFIB、BGP の矛盾およびルート ターゲット インポート/エクスポートの不一致などの問題を明確にするために役立ちます。一部の障害については、その他の情報は表示されません。

図 11-19 に、テストの詳細の概要の下に障害固有の情報が表示された [Test Results] ウィンドウの例を示します。[Test Details] オプション ボタンはデフォルトで選択されています。

トラブルシューティング中に観察された内容は、テストの詳細の概要の下に注記として表示されます。観察の注記は、障害に関連する可能性のある、トラブルシューティング中に観察された内容の詳細を示します。この内容は、追加のトラブルシューティング情報と見なします。図 11-21 に、観察の注記が 2 つ表示された [Test Results] ウィンドウの例を示します。観察の注記は、まったく表示されない場合、または複数表示される場合があります。

図 11-21 観察の注記が表示された [Test Results] ウィンドウ

Test Log

[Test Log]（図 11-22 を参照）オプション ボタンをクリックして、すべてのトラブルシューティングおよび診断ステップの詳細を、実行された順序で表示します。

図 11-22 [Test Results] ウィンドウ：テスト ログ

一部のステップでは、IOS または IOS XR CLI コマンドの実行など、デバイスからの入力が必要な場合があります。これらのステップは、テスト ログではハイパーリンクとして表示されます。ハイパーリンクをクリックすると、そのステップの IOS または IOS XR CLI トランスクリプトを示したポップアップ ウィンドウが表示されます（図 11-23 を参照）。このトランスクリプトには、実行された IOS または IOS XR コマンドおよびすべての結果の出力が含まれます。

図 11-23 [IOS CLI Transcript] ウィンドウ

Export

テスト ログをエクスポートして、トラブル チケットに含めたり、問題をエスカレーションしたり、または Cisco TAC に問い合わせしたりする際に使用できます。テスト ログは、テスト ログの下部にある [Export] ボタン（図 11-22 を参照）を使用してファイルにエクスポートできます。IOS および IOS XR CLI トランスクリプトを含め、テスト ログに表示されるすべてのステップはテキスト形式でエクスポートされます。

ステップ 1 [Export] ボタンをクリックします。

ブラウザ標準のファイル ダウンロード ウィンドウが表示され、ファイル名はデフォルトで「 export.rtf 」と表示されます。

ステップ 2 ファイルを保存します。

高度なトラブルシューティング オプション

この項では、次の高度なトラブルシューティング オプションについて説明します。

• 「リバース パス テスト」

• 「LSP 可視化」

高度なトラブルシューティングにより提供される追加オプションを、ネットワークのトラブルシューティングに使用できます。

サポートされている高度なトラブルシューティング オプションの詳細については、 表 11-13 を参照してください。

高度なトラブルシューティング オプションは、[Test Results] ウィンドウの下部にある [Advanced] ドロップダウン ボタンを使用して適切なものを使用できます。

リバース パス テスト

（注） リバース パス テスト オプションは、PE to attached CE テスト タイプ以外のすべてのテスト タイプで使用できます。

場合によっては、MPLS VPN 接続性検証テストは接続の問題を検出しても、障害の原因を特定できない場合があります。逆方向（つまり、ローカル サイトとリモート サイトの設定を逆にした状態）でテストを繰り返すことにより、問題の原因を特定できる場合があります。その他の場合では、逆方向でテストを繰り返すことにより、結果として見つかった問題がさらに正確に診断される場合もあります。たとえば、接続性テストを進行方向で実行している間に、LSP 接続の問題がデバイスで特定される場合があります。しかし、この問題はダウンストリームの LSP ネイバーでの LDP 誤設定によって引き起こされた可能性もあります。逆方向でテストを繰り返すことにより、誤設定されたダウンストリーム ルータに最初に遭遇し、LDP 後設定が診断されます。この状況が発生した場合、[Test Results] ウィンドウに表示されるテストの詳細には、テストを逆方向で実行するように勧めるメッセージが表示されます。リバース テスト オプションは、[Test Results] ウィンドウの [Advanced] ドロップダウン ボタンから使用できます。

高度なトラブルシューティングのリバース テスト オプションを選択すると、逆方向状態で MPLS VPN 接続性検証テストが起動されます。それ以上の設定は必要ありません。

リバース パス テストの結果は、[Test Results] ウィンドウに表示されます。

LSP 可視化

（注） LSP 可視化は、PE to attached CE テスト タイプ以外のすべてのテスト タイプで使用できます。

障害が見つからなかった場合、[Test Results] ウィンドウのデータ パスには、実行されたテストの概要が表示されます。テストされたコアを通過するパスの詳細は表示されません。LSP 可視化は、ローカル サイトとリモート サイト間の MPLS ラベル スイッチド パス（LSP）のホップバイホップ データ パスの図を表示します（図 11-24 を参照）。LSP 可視化では、転送パスの中間に見つかった、すべての重複していない PE-P 間、P-P 間、および P-PE 間のトンネルが表示されます。表示されるパスは、MPLS VPN 接続性検証テスト中にテストされたパスです。

図 11-24 [Test Results] ウィンドウ：LSP 可視化

データ パスには、テストされたパス内の各 PE および P デバイスについて、次の内容が表示されます。

• ロール（PE または P）

• デバイス名

• インターフェイス名

• 入力および出力ラベル

データ パスには、各 PE-PE 間の MPLS Traffic Engineered トンネルについて、次の内容が表示されます。

• トンネル名

• トンネルの方向（方向を示す矢印）

• トンネル ラベル

• トンネル タイプ

（注） 複数の MPLS TE トンネルが設定されている場合は、実際にトラフィックを伝送しているトンネルのみがデータパスに表示されます。

次の例では、Tunnel 7 は重複している（つまり、Tunnel 7 のヘッドエンドはアップストリーム ルータに設定されている Tunnel 15 のミッドポイントに設定されている）ため、表示されません。

図 11-25 複数の MPLS TE トンネル設定

データ パスに表示される内容についての詳細は、「データ パス」を参照してください。

LSP 可視化は、MPLS VPN 接続性検証テストで接続の問題が検出されなかった場合のみ提供されます。

（注） MPLS VPN 接続性検証テストをポストプロビジョニング検証に使用している場合は、LSP 可視化では MPLS コアを通過する LSP パスを表示することで、より高度な検証を提供します。

トンネル チェックのオフ：他社製 P ルータを使用したネットワークの場合

トンネルの診断中、Diagnostics はすべてのデバイスを確認して、そのポイントにトンネルが存在するかを確認する必要が生じる場合があります。Diagnostics は、他社製のデバイスにはログインしないため、他社製デバイスで発生している障害の誤診断を招き、（たとえそのデバイスが障害の実際の原因ではないとしても）トラブルシューティング ワークフローを進めることができなくなる場合があります。そのため、他社製デバイスが含まれるネットワークでは、トンネル診断をディセーブルにすることが役立ちます。

デフォルトでは、トンネル診断はイネーブルになっています。デフォルト値は、Admin ユーザが Prime Provisioning Control Center（[Administration] タブ > [Control Center] > [Hosts]）で変更できます。トンネル診断は、Command Flow Runner（CFR）コンポーネント（disableTunnelDiagnostics パラメータ）でイネーブルまたはディセーブルにできます。適切な disableTunnelDiagnostics パラメータが true に設定されている場合は、Diagnostics はトンネル診断を実行しません。

[Test Results] ウィンドウには、Diagnostics のトンネル診断がディセーブルであることを示す観察メッセージが表示されます。デバイスがインベントリに含まれていないことを示すエラー メッセージは、パス上の他社製デバイスが原因である可能性があること、およびエラーがこのデバイスまたはその近くのネイバーで発生していることを意味します。

フル メッシュ VPN トポロジでのテスト

デフォルトで、MPLS VPN 接続性検証テストでは、ローカル サイトとリモート サイトはフル メッシュ VPN トポロジで接続され、これらのサイトは直接通信できると見なされます。フル メッシュ VPN トポロジに MPLS VPN 接続性検証テストを設定する方法の詳細については、「MPLS VPN 接続性検証テストの実行」を参照してください。

ハブ アンド スポーク VPN トポロジでのテスト

ハブ アンド スポーク VPN で接続されたカスタマー サイト同士は直接通信できません。カスタマー サイト（スポーク）はハブ ルータで通信します。ハブ アンド スポーク VPN で接続された 2 サイト間の接続性をテストする場合は、次の手順でテストを実行します。

ステップ 1 ローカル サイトとリモート サイト間の MPLS VPN 接続性検証テスト。

ステップ 2 ローカル サイトと、ルートをインポートするハブ PE インターフェイスに接続されたハブ CE インターフェイス間の MPLS VPN 接続性検証テスト。

ステップ 3 リモート サイトと、ルートをインポートするハブ PE インターフェイスに接続されたハブ CE インターフェイス間の MPLS VPN 接続性検証テスト。

ステップ 4 ローカル サイトと、ルートをエクスポートするハブ PE インターフェイスに接続されたハブ CE インターフェイス間の MPLS VPN 接続性検証テスト。

ステップ 5 リモート サイトと、ルートをエクスポートするハブ PE インターフェイスに接続されたハブ CE インターフェイス間の MPLS VPN 接続性検証テスト。

各ステップでは、さまざまなポイント間で MPLS VPN 接続性検証テストを実行します。接続性障害があるかどうかと、この障害の場所によっては、5 つすべてのステップを実行する必要がない場合があります。図 11-27 に、ハブ アンド スポーク VPN をテストするワークフローを示します。

ステップ 1 からステップ 5 で報告された問題を解決してから、ステップ 1 を繰り返してサイト間の接続性が復元されたことを確認してください。

（注） アクセス回線または VPN エッジの問題に起因する接続性障害がステップ 1 で検出された場合、その問題は、ステップ 1 で実行した MPLS VPN 接続性検証テストによって正しく診断されます。テスト結果の説明に従って問題を解消してください。接続性障害がハブ アンド スポーク MPLS VPN のコア内部の問題に起因する場合、ステップ 1 で報告される結果は正しくないことがあるため無視してください。ステップ 2 からステップ 5 を、問題が正しく診断されるまで実行してください。

図 11-27 ワークフロー

1. ローカル サイトとリモート サイト間の MPLS VPN 接続性検証テストを実行します。このテストで接続性の問題が見つからなけば、トラブルシューティングはこれ以上必要ありません。このテストで MPLS の問題が原因による接続性障害が報告された場合は、テスト結果を無視して 2. に進みます。MPLS VPN 接続性検証テストはフル メッシュ VPN トポロジを前提としているため、報告される問題は正しくありません。ハブ アンド スポーク VPN での問題を識別するためにさらに MPLS VPN 接続性検証テストを実行する必要があります。このテストで MPLS 以外の問題（たとえば、アクセス回線または VPN エッジの障害）が原因による接続性障害が報告された場合は、報告されたとおりに問題を解決して再度テストを行います。

（注） 接続性障害がコアで見つかった場合、1. で実行した MPLS VPN 接続性検証テストでは、ハブ アンド スポーク VPN トポロジがテスト中であることが検出され、以下のステップで説明されている、ハブ アンド スポークに固有のトラブルシューティングの実行を提案されることがあります。MPLS VPN 接続性検証テストは、ルート ターゲットのインポートおよびエクスポートを調べることでハブ アンド スポーク VPN トポロジを検出します。同じルート ターゲットが一方または両方の PE ルータによってインポートおよびエクスポートされると、ハブ アンド スポーク VPN と見なされます。

図 11-28 に、ハブ アンド スポーク VPN の 2 サイト間の接続性をテストするために必要な MPLS VPN 接続性検証テストを示します。

図 11-28 ハブ アンド スポーク VPN トポロジのテスト：ステップ 1

2. ローカル サイト（スポーク）と、ルートをインポートするハブ PE インターフェイスに接続されたハブ CE インターフェイス（図 11-29 の B ）間の MPLS VPN 接続性検証テストを実行します。MPLS VPN 接続性検証テストを設定する際は、[MPLS VPN Connectivity Verification Configuration] ウィンドウの [Local Site] フィールドに、ローカル カスタマー サイトの詳細を設定する必要があります。[Remote Site] フィールドには、ルートをインポートするハブ PE および CE インターフェイス（図 11-29 の A および B ）の詳細を設定する必要があります（ 表 11-14 を参照）。

図 11-29 ハブ アンド スポーク VPN トポロジのテスト：ステップ 2

3. リモート サイト（スポーク）と、ルートをインポートするハブ PE インターフェイスに接続されたハブ CE インターフェイス（図 11-30 の B ）間の MPLS VPN 接続性検証テストを実行します。MPLS VPN 接続性検証テストを設定する際は、[Local Site] フィールドに、ルートをインポートするハブ PE および CE インターフェイス（図 11-30 の A および B ）の詳細を設定する必要があります（ 表 11-14 を参照）。[MPLS VPN Connectivity Verification Configuration] ウィンドウの [Remote Site] フィールドには、リモート カスタマー サイトの詳細を設定する必要があります。

図 11-30 ハブ アンド スポーク VPN トポロジのテスト：ステップ 3

4. ローカル サイト（スポーク）と、ルートをエクスポートするハブ PE インターフェイスに接続されたハブ CE インターフェイス（図 11-31 の D ）間の MPLS VPN 接続性検証テストを実行します。MPLS VPN 接続性検証テストを設定する際は、[MPLS VPN Connectivity Verification Configuration] ウィンドウの [Local Site] フィールドに、ローカル カスタマー サイトの詳細を設定する必要があります。[Remote Site] フィールドには、ルートをエクスポートするハブ PE および CE インターフェイス（図 11-31 の C および D ）の詳細を設定する必要があります（ 表 11-15 を参照）。

図 11-31 ハブ アンド スポーク VPN トポロジのテスト：ステップ 4

5. リモート サイト（スポーク）と、ルートをエクスポートするハブ PE インターフェイスに接続されたハブ CE インターフェイス（図 11-32 の D ）間の MPLS VPN 接続性検証テストを実行します。MPLS VPN 接続性検証テストを設定する際は、[Local Site] フィールドに、ルートをエクスポートするハブ PE および CE インターフェイス（図 11-32 の C および D ）の詳細を設定する必要があります（ 表 11-15 を参照）。[MPLS VPN Connectivity Verification Configuration] ウィンドウの [Remote Site] フィールドには、リモート カスタマー サイトの詳細を設定する必要があります。

図 11-32 ハブ アンド スポーク VPN トポロジのテスト：ステップ 5

Intranet/Extranet VPN トポロジでのテスト

Intranet/Extranet VPN トポロジを介して接続しているサイト間では、フル メッシュ VPN トポロジの場合と同様に、直接通信が可能です。Intranet/Extranet VPN で接続された 2 サイト間の MPLS VPN 接続性検証テストを設定する際は、通常どおりにテストを設定する必要があります。

Intranet/Extranet VPN で接続されたサイト間の接続性をテストすると、Diagnostics はアクセス回線、VPN エッジ、および MPLS コアの問題を含む MPLS VPN 接続性の問題をトラブルシューティングします。Diagnostics は、不足しているルート マップまたは誤設定されたルート マップなど、Intranet/Extranet VPN に固有の問題のトラブルシューティングは行いません。

MPLS VPN 接続性検証テストによって接続性障害が検出されたが、その障害の原因はアクセス回線、VPN エッジ、および MPLS コアの問題を含む MPLS VPN 接続性の問題にあると考えられない場合は、イントラネット/エクストラネット構成のトラブルシューティングが [Test Results] ウィンドウで推奨されます。

（注） いずれかの PE でルート マップが設定されていることを見つけると、Diagnostics は、Intranet/Extranet VPN トポロジであると見なします。

セントラル サービス VPN トポロジでのテスト

セントラル サービス VPN トポロジでは、クライアント サイトは 1 つ以上のセントラル サイトと直接通信できますが、クライアント サイト同士では通信できません。セントラル サービス VPN トポロジを介して接続しているクライアント サイトと中央サイト間では、MPLS VPN 接続性検証テストは実行できません。クライアント サイトはローカル サイト、中央サイトはリモート サイトとして入力することで、通常どおりにテストを設定する必要があります。

セントラル サービス VPN の 2 クライアント サイト間の MPLS VPN 接続性検証テストを実行することはできません。

障害シナリオ

この項では、Diagnostics によって報告される次の障害シナリオについて説明します。

• 「アクセス回線」

• 「MPLS エッジ」

• 「MPLS コア」

• 「カスタマー サイト」

各障害シナリオの表に、その障害シナリオが 5 つの Diagnostics テスト タイプそれぞれでサポートされているかどうかを示します。この表では、障害シナリオが IOS および IOS XR でサポートされているかどうかを示します。また、障害シナリオが IPv4 および IPv6 向けにサポートされるかどうかも示します。

（注） この表で、NA は該当なし、NS はサポート適用外を意味します。

アクセス回線

IP 接続をブロックするアクセス回線

プロバイダー（PE）ルータのアクセス回線インターフェイスから送信先への IP 接続を阻止するブロッキング アクセス リストがあります。

無効な PE インターフェイスが指定されている

PE ルータ上にインターフェイスが存在しません。

ATM インターフェイスに VPI/VCI がない

PE ルータ上の非同期転送モード（ATM）アクセス回線インターフェイスに Virtual Path Identifier（VPI; 仮想パス識別子）または Virtual Channel Identifier（VCI; 仮想チャネル識別子）が割り当てられていないか、VPI/VCI が宛先 IP アドレスにマッピングされていません。

ATM インターフェイスのプロトコルがダウン

PE ルータで ATM アクセス回線インターフェイスのプロトコルがダウンしています。「IOS XR サポート」を参照してください。

ATM サブインターフェイスのプロトコルがダウン

PE ルータで ATM アクセス回線サブインターフェイスのプロトコルがダウンしています。この障害は、間違ったサブインターフェイス パラメータか、あるいは障害を検出して自動的にインターフェイスをダウンさせる ATM Operation, Administration, and Maintenance（OAM; 運用管理および保守）機能が原因で発生することがあります。「IOS XR サポート」を参照してください。

CE アクセス回線インターフェイス IP アドレスの計算は、PE インターフェイスがアンナンバード インターフェイスではなく、PE に /30 サブネット マスク インターフェイスがある場合のみ可能

PE 用のカスタマー エッジ（CE）アクセス回線インターフェイス IP アドレスを計算できません。

詳細については、「IPv6 サポート」を参照してください。

ピアの eBGP 最大プレフィックスを超過

PE と CE 間で exterior Border Gateway Protocol（eBGP; 外部ボーダー ゲートウェイ プロトコル）が動作していますが、ボーダー ゲートウェイ プロトコル（BGP）ネイバーが確立されていません。ピアが設定されたプレフィックス最大数を超えました。

eBGP ネイバーが確立されていない、ルートが存在しない

PE と CE 間で eBGP が動作していますが、PE で BGP ネイバーが確立されていません。BGP ネイバーは PE とは異なるサブネット上にあり、VPN Routing/Forwarding（VRF; VPN ルーティング/転送）内にネイバーへのルートがありません。

eBGP ネイバーが確立されていない、設定ミスの可能性

PE と CE 間で eBGP が動作していますが、PE で BGP ネイバーが確立されていません。VRF 内に BGP ネイバーへのルートがあり、ping を介して BGP ネイバーに到達可能です。CE または PE BGP コンフィギュレーションに問題があります。

eBGP ネイバーが確立されていない、ルートは存在する

PE と CE 間で eBGP が動作していますが、PE で BGP ネイバーが確立されていません。BGP ネイバーは PE とは異なるサブネット上にあり、VRF 内にネイバーへのルートが存在します。ただし、ping を介してこの BGP ネイバーに到達できません。

複数の eBGP サイトが同じ AS 番号を使用している

ローカル サイトとリモート サイトが eBGP を使用し、同一の AS 番号を使用しており、ローカル PE ルータの VRF 内で BGP ネイバーに「allowas-in」も「as-override」も設定されていません。

EIGRP がルートを交換していない

PE と CE 間で Enhanced Interior Gateway Routing Protocol（EIGRP）が動作しており、ピア関係が確立されています。ただし、CE の EIGRP からルートを受信していません。

イーサネット インターフェイス プロトコルのダウン

PE ルータ プロトコルのイーサネット アクセス回線インターフェイスがダウンしています。

イーサネット サブインターフェイス プロトコルのダウン

PE ルータ プロトコルのイーサネット アクセス回線サブインターフェイスがダウンしています。

フレーム リレー インターフェイスに DLCI がない

PE ルータのフレーム リレー アクセス回線インターフェイスに Data-Dink Connection Identifier（DLCI; データリンク接続識別子）が割り当てられていないか、DLCI が宛先 IP アドレスにマッピングされていません。

フレーム リレー インターフェイス プロトコルのダウン

PE ルータ プロトコルのフレーム リレー アクセス回線インターフェイスがダウンしています。原因として、回線パラメータまたはケーブル配線のミスが考えられます。

フレーム リレー インターフェイスに DLCI がない

PE ルータ上のアクセス回線インターフェイスのマルチポイント フレーム リレー相手先固定接続（PVC）に、宛先 IP アドレスにマッピングされた DLCI がありません。

フレーム リレー インターフェイスに DLCI がない

PE ルータのアクセス回線インターフェイスで、ポイントツーポイント フレーム リレー PVC に DLCI が割り当てられていません。

フレーム リレー PVC が削除済みとしてマークされている

PE ルータのアクセス回線インターフェイスで、フレーム リレー PVC が削除済みとしてマークされています。

フレーム リレー PVC が停止中としてマークされている

PE ルータのアクセス回線インターフェイスで、マルチポイント フレーム リレー PVC が停止中としてマークされています。

フレーム リレー PVC が停止中としてマークされている

PE ルータのアクセス回線インターフェイスで、ポイントツーポイント フレーム リレー PVC が停止中としてマークされています。

シリアル インターフェイスの搬送波が不完全

PE ルータのシリアル アクセス回線インターフェイスに不完全な搬送波があります。

インターフェイスが管理上のダウン状態

PE ルータのアクセス回線インターフェイス（またはサブインターフェイス）が管理上の理由でダウンしています。

インターフェイスが管理上のダウン状態

PE ルータのアクセス回線サブインターフェイスが管理上の理由でダウンしています。

プロトコルのインターフェイスがダウン状態

PE ルータ プロトコルのアクセス回線インターフェイスがダウンしています。

PE のインターフェイスはバンドル リンクの仮想アクセス インターフェイスである

この PE のインターフェイスは、有効なアクセス回線インターフェイスではありません。

インターフェイスが運用停止状態

PE ルータのアクセス回線インターフェイスが動作を停止しています。

（ATM ネクスト ホップとの）断続的 ATM 障害

ATM アクセス回線は、ATM ネクスト ホップに断続的に ATM 接続しています。「IOS XR サポート」を参照してください。

（送信先との）断続的 ATM 障害

ATM アクセス回線は、送信先に断続的に ATM 接続しています。「IOS XR サポート」を参照してください。

無効なアクセス回線 IP アドレス コンフィギュレーション

CE ルータのアクセス回線インターフェイス IP アドレスが、接続先 PE のアクセス回線インターフェイス IP アドレスと同じサブネット内にありません。

無効なアクセス回線 IP アドレス コンフィギュレーション

この CE のアクセス回線インターフェイス IP アドレスがネットワーク アドレスです。

詳細については、「IPv6 サポート」を参照してください。

無効なアクセス回線 IP アドレス コンフィギュレーション

この CE のアクセス回線インターフェイス IP アドレスがネットワーク ブロードキャスト アドレスです。

詳細については、「IPv6 サポート」を参照してください。

無効なアクセス回線 IP アドレス コンフィギュレーション

CE のアクセス回線インターフェイス IP アドレスと、接続先 PE のアクセス回線インターフェイス IP アドレスが同じです。

IP 接続の問題

IP 接続に関する未知の問題。PE インターフェイスから CE への VRF インスタンスで、アクセス回線の接続に問題が生じています。

ルートの欠落

PE ルータのアクセス回線インターフェイスから送信先へのルートが存在しません。

ルートの欠落

PE ルータのアクセス回線インターフェイスからカスタマーの送信先へのルートが存在しません。

EIGRP ピア関係が確立されていない

PE と CE 間でルーティング プロトコル EIGRP は動作していますが、ピア関係が確立されていません。

EIGRP ピア関係が確立されていない

PE と CE 間では、ルーティング プロトコル EIGRP が動作しています。PE および CE インターフェイスは異なるサブネット上にあり、IP アンナンバードを使用していません。PE と CE が異なるサブネット上にあるため、ピア関係が確立されていません。

ルート再配布でルート ポリシーが指定されていない

PE と CE 間でルーティング プロトコル EIGRP が動作し、MP-BGP にルートが再配布されています。ただし、発信ルート ポリシーが指定されていないため、すべてのルートはアドバタイズされずにドロップされます。

OSPF ピアがない

PE と CE 間で Open Shortest Path First（OSPF）が動作していますが、PE にピアが存在しません。

ピア インターフェイスの OSPF がイネーブルでない

ルータ上のインターフェイスで OPSF がイネーブルになっていません。両方のネイバー インターフェイスで OSPF をイネーブルにしておく必要があります。

ピア インターフェイスの OSPF がパッシブ モード

ルータ上のインターフェイスで OSPF がパッシブ モードになっています。

OSPF エリアの不一致

ネイバー インターフェイス上で OSPF がイネーブルになっていますが、これらのインターフェイスは異なるエリア内に設定されています。

OSPF エリア タイプの不一致

ネイバー インターフェイス上で OSPF がイネーブルになっていますが、これらのインターフェイスは異なるエリア タイプに設定されています。

PE と CE 間で動作するルーティング プロトコルが確定しておらず、スタティック ルートが存在しない

VRF 内のアクセス回線に問題があります。

OSPF がルートを交換していない

PE と CE 間で OSPF が動作していますが、ピア関係が確立されています。ただし、CE の OSPF からルートを受信していません。

OSPF ピアが確立されていない

PE と CE 間で OSPF が動作していますが、ピア関係が確立されていません。

OSPF 時間の不一致

ネイバー インターフェイス上で OSPF はイネーブルになっていますが、これらのインターフェイスの [hello|dead] タイマーにはそれぞれ異なる値が設定されています。

OSPF ピアが確立されていない

PE と CE 間では OSPF が動作しています。ただし、PE および CE インターフェイスは異なるサブネット上にあり、IP アンナンバードを使用していないため、ピア関係が確立されていません。

ルート再配布でルート ポリシーが指定されていない

PE と CE 間でルーティング プロトコル OSPF が動作し、MP-BGP にルートが再配布されています。ただし、発信ルート ポリシーが指定されていないため、すべてのルートはアドバタイズされずにドロップされます。

PE に CE へのルートがない

接続されている PE および CE インターフェイスは、異なるサブネット上にあります。PE と CE 間で動作するルーティング プロトコルが確定しておらず、CE へのスタティック ルートが存在しません。

RIB 障害

PE から VRF 内の宛先へのルートが VRF ルーティング テーブルに設定されていません。これは Routing Information Base（RIB; ルーティング情報ベース）障害と見なされます。

RIP の設定ミス

PE と CE 間で Routing Information Protocol（RIP）が動作していますが、CE の RIP からルートを受信していません。

RIP がルートを交換していない

PE と CE 間で RIP が動作していますが、PE および CE インターフェイスは異なるサブネット上にあり、IP アンナンバードを使用していないため、CE の RIP からルートを受信していません。

ルート再配布でルート ポリシーが指定されていない

PE と CE 間でルーティング プロトコル RIP が動作し、MP-BGP にルートが再配布されています。ただし、発信ルート ポリシーが指定されていないため、すべてのルートはアドバタイズされずにドロップされます。

ループバック モードのシリアル インターフェイス

PE ルータのシリアル アクセス回線インターフェイスがループバック モードに設定されています。

シリアル インターフェイスが運用停止状態

PE ルータのシリアル アクセス回線インターフェイスが動作を停止しています。

ATM ポイントツーポイント インターフェイスのスタティック IP アドレス

ATM アクセス回線の ATM ポイントツーポイント サブインターフェイスに、スタティック IP アドレス マッピングが指定されています。ポイントツーポイント サブインターフェイスでは、トラフィックに対する VC とパスはそれぞれ 1 つだけなので、スタティック マッピングもアドレス解決プロトコル（ARP）も必要ありません。「IOS XR サポート」を参照してください。

プロトコルのサブインターフェイスがダウン状態

PE ルータ プロトコルのアクセス回線サブインターフェイスがダウンしています。

未診断の ATM 障害（ATM ping は失敗したが、ATM セグメントの ping は成功）

ATM アクセス回線の接続が中断されています。エンドツーエンド ATM ping は失敗しましたが、ATM セグメントの ping は成功しました。原因として、ATM 回線パラメータの間違い、ATM ルーティングの設定ミス、CE または ATM クラウド インターフェイスのダウン、デバイスの停止など、さまざまな問題が考えられます。「IOS XR サポート」を参照してください。

未診断の ATM 障害（エンドツーエンドおよびセグメント ATM ping が失敗）

ATM アクセス回線の接続が中断されています。エンドツーエンド ping とセグメント ATM ping がどちらも失敗しました。原因として、ATM 回線パラメータの間違い、ATM ネクスト ホップでの ATM ルーティングの設定ミス、ネクスト ホップ インターフェイスのダウン、デバイスの停止など、さまざまな問題が考えられます。「IOS XR サポート」を参照してください。

PE アクセス回線インターフェイスに仮想テンプレート インターフェイスが指定されている

この PE の PE インターフェイスは、有効なアクセス回線インターフェイスではありません。

MPLS エッジ

BGP ネクスト ホップ インターフェイスが管理上のダウン状態

PE の BGP ネクスト ホップがループバック インターフェイスに割り当てられています。ただし、このインターフェイスは管理上の理由でダウンしています。