Cisco Prime Fulfillment 動作理論ガイド 6.1

Managed/Unmanaged プライマリ トンネル

Prime Fulfillment では、Managed トンネルの概念が TE 計画作業の中心を成します。

次のような違いを理解する必要があります。

• Managed TE トンネル：

– （設定/保持）優先順位 0

– 0 以外の RSVP 帯域幅

– 最初のパス オプションが明示パス

– 自動帯域幅には最大値が必要

• Unmanaged トンネル：その他すべてのトンネル

Prime Fulfillment の Graphical User Interface（GUI; グラフィカル ユーザ インターフェイス）には、Managed トンネルと Unmanaged トンネルを操作するための別個のエントリ ポイントがあります。

Conformant/Non-Conformant トンネル

Conformant トンネルと Non-Conformant トンネルについて理解することは、Prime Fulfillment を効率的に使用するために不可欠です。

Prime Fulfillment では、Conformant トンネルのみ作成できます。Non-conformant トンネルは、TE 検出プロセスを介して導入できます（ユーザ ガイドのを参照）。

Conformant/Non-Conformant トンネルの定義

Prime Fulfillment の設計では、Conformant トンネルと Non-Conformant トンネルが次のように厳格に区別されています。

• Conformant トンネル：Prime Fulfillment の TE 管理パラダイム（下記を参照）を満たす正常に動作するトンネルです。Managed トンネルは Conformant トンネルにのみなることができます。優先順位が 0 以外である Unmanaged トンネルも Conformant トンネルになることがあります。ただし、Conformant トンネルは必ずしも Managed トンネルではありません。

接続保護トンネルは、トンネル帯域幅が 0 で、バックアップ帯域幅が無制限であり、最初のパス オプションが「exclude address」である場合は、Conformant = true とマークされます。BW Protected 設定では、トンネルのバックアップ帯域幅が 0 以外に設定され、ストリクト パス オプション 1 が選択されている必要があります。

• Non-Conformant トンネル：Prime Fulfillment の帯域幅保証を満たす能力に影響する可能性のある TE トンネルです。自動帯域幅に最大帯域幅が未設定、プリエンプションの可能性、ダイナミック パスなど、未知の帯域幅要件が原因で発生することがあります。優先順位が 0 である Unmanaged トンネルも Non-Conformant トンネルになることがあります。

次に、Non-Conformant トンネルの例を示します。

– 設定および保持優先順位が 0 で、最初のパス オプションが明示パスであるが、帯域幅は 0 であるトンネル

– 設定および保持優先順位が 0 で、帯域幅は 0 以外であるが、最初のパス オプションがダイナミック パスであるトンネル

– 設定および保持優先順位が 0 で、明示パス オプションが 1 であり、自動帯域幅の最大値が定義されていないトンネル

– Conformant = false とマークされた接続保護トンネルは、バックアップ トンネルのために予約されており、トンネル帯域幅 0、無制限のバックアップ帯域幅、最初のパス オプション「exclude address」のいずれも設定されていません。

上記のトンネルは、なぜ Non-Conformant なのでしょうか。Prime Fulfillment は、設定および保持優先順位が 0 であるトンネルをすべて管理し、それらが通過するリンクがいずれも十分な帯域幅を持ち、アフィニティが一致、TE ポリシーに定義された遅延または FRR 制約に違反しないことを確認するからです。

ただし、トンネルのパスがダイナミック パスであるか、トンネルが必要とする帯域幅の量が定義されていない場合、Prime Fulfillment はトンネルの管理に必要な情報を得られないため、そのトンネルを Non-Conformant とマークします。すべての Non-Conformant トンネルは [TE Unmanaged Primary Tunnels SR] ウィンドウに表示されます。

Non-Conformant トンネルの管理

Non-Conformant トンネルは、SLA 違反の原因となる可能性があるだけでなく、Managed トンネルに悪影響（帯域幅を奪うなど）を与えるおそれもあることを理解しておくことが重要です。

ただし、Non-Conformant トンネルが検出されたときには、警告が記録されます。Prime Fulfillment は、Non-Conformant トンネルを追跡して廃棄します。

したがって、Conformant トンネルの方が望ましいと言えます。Conformant トンネルによって、システムは Managed トンネルの帯域幅保証を提供できます。Unmanaged Non-Conformant トンネルは、必要な帯域幅を提供したりしなかったりするため、帯域幅保証は提供されません。

Non-Conformant トンネルがある場合は、設定および保持優先順位を 0 以外の値に変更する（Managed トンネルに対するプリエンプション処理を実行できないようにするため）か、Managed トンネルに移行させてツールが適切な明示パスを検出できるようにします。

複数の同時実行ユーザ

以前のリリースでは、TEM は単一の GUI ユーザしかサポートしていませんでした。本リリースは、ブラウジング、更新、プロビジョニングのいずれの操作においても複数の同時実行ユーザをサポートします。

Managed トンネルと Unmanaged トンネルの同時使用

複数ユーザ機能が TEM にどのように実装されているかを理解するためには、Managed トンネルと Unmanaged トンネルの違いを理解することが重要です。これについては、F-2 ページの「Managed/Unmanaged プライマリ トンネル」を参照してください。

複数ユーザのサポートに関しては、Managed トンネルと Unmanaged トンネルの処理方法に大きな違いがあります。

• Managed トンネルは、すべて SR によってカプセル化されます。SR の操作により、Router Generator サーバによるパス計算の後にスナップショット内のすべてのオブジェクトが最適化される可能性があります。

• Unmanaged トンネルの場合、SR はトンネルヘッド エンド ルータとして定義されます。そのため、Unmanaged トンネルには、いくつかの制限があります。たとえば、2 人のユーザが同じデバイスで同時にプロビジョニングすることはできません。

• TEM は、Unmanaged トンネル SR が同じデバイスで同時にプロビジョニングすることを許可しませんが、Unmanaged トンネル SR による複数のデバイスでの同時プロビジョニングはサポートします。

• Managed トンネルは、すべて各 TE プロバイダーの共有 Managed TE トンネル SR 内に存在します。Unmanaged トンネルの場合は、ヘッド デバイスごとに別個の Unmanaged TE トンネル サービス要求が作成されます。TEM は、1 つの TE プロバイダーにつき複数の SR をサポートします。

複数の TEM ユーザが TEM でブラウジングおよびプロビジョニングを実行できます。最大 20 人までの同時ユーザがサポートされ、そのうちの 7 人までがプロビジョニング タスクを実行できます。

以前は、Managed と Unmanaged の両方のプライマリ トンネルがすべて TE プロバイダーごとに 1 つの TE トンネル SR に存在していました。現在は、Managed トンネルへの複数の同時変更を可能にするために、TE トンネル SR が TE プロバイダーあたり 1 つの Managed トンネル SR とヘッド TE ルータあたり 1 つの Unmanaged トンネル SR に分割されています。

同じ SR で並行プロビジョニングを行うことはできませんが、Unmanaged トンネルについては SR がルータ レベルで存在するため、Unmanaged トンネルを同時に複数のルータにプロビジョニングすることができます。

ロッキング メカニズム

Unmanaged トンネルをプロビジョニングすると、そのトンネルのヘッド TE ルータがロックされます。ロックされていることは、[TE Nodes] ウィンドウの [System Lock Status] 列で確認できます。ロッキングによって、プロビジョニング タスクが完了し、TE ルータのロックが解除されるまで、他のユーザはそのルータにどのような種類のトンネルも配置できなくなります。

ロッキング メカニズムは、バックアップ トンネル、リソース SR、リンク削除、TE トラフィック アドミッションなどの Prime Fulfillment 機能にも適用されます。リソース SR には、明示パスの削除/編集、保護要素の削除、SRLG の削除/編集などが含まれます。

リンク削除の場合、一定レベルのインテリジェンス機能が組み込まれています。ユーザまたは Prime Fulfillment によって再ルーティングまたは削除できるトンネルが存在せず、TE 関連オブジェクトだけが残っている場合、リンクを削除するためには、ユーザによる介入が必要となります。このとき、削除対象として選択されたインターフェイスを保護するバックアップ トンネルがある場合は、バックアップ トンネルを配置する操作の実行中、ロッキング メカニズムが働きます。TE リンクの削除の詳細については、ユーザ ガイドの を参照してください。

発生する可能性のあるエラーについては、ユーザ ガイドの を参照してください。

Managed プライマリ トンネルまたはバックアップ トンネルをプロビジョニングすると、そのトンネルに関連付けられている TE プロバイダーがロックされます。ロックされていることは、[TE Provider] ウィンドウの [System Lock Status] 列で確認できます。TE プロバイダー レベルのロックによって、トンネルがどの TE ルータを起点としているかに関係なく、別のユーザがその TE プロバイダーでトンネルを変更することを防止できます。

Managed トンネルおよびバックアップ トンネルのロッキング メカニズムと Unmanaged トンネルのロッキング メカニズムが異なるのは、Managed トンネルとバックアップ トンネルがすべての制約を満たす最適なルートを見つけるためにパス生成アルゴリズムを使用し、そのアルゴリズムが、ルーティング決定基準として、TE トポロジとそこに含まれるすべてのトンネルの安定したグローバル ビューを必要とするからです。これを実現する唯一の方法は、一度に 1 人のユーザだけが変更を実行できるようにすることです。

Prime Fulfillment のロッキング メカニズムを管理する方法の詳細については、ユーザ ガイドの を参照してください。

複数の OSPF 領域

Prime Fulfillment は、複数の Open Shortest Path First（OSPF）内での TE トンネルの検出、管理、プロビジョニングをサポートします。

Prime Fulfillment の管理対象となるのは、OSPF 領域の範囲内にあるプライマリ TE トンネルとバックアップ TE トンネルだけです。複数の OSPF 領域にまたがる検出および作成はサポートしていません。

Prime Fulfillment では、OSPF 領域は TE プロバイダーによって表されます。領域を TE プロバイダーに割り当てた後で変更することはできません。1 つの Prime Fulfillment プロバイダーに複数の TE プロバイダーを関連付けることができます。

TE 検出に適したデバイス

複数の OSPF 領域があるネットワークでは、各 OSPF 領域が TE プロバイダーで表されるため、OSPF 領域内のどのルータでも TE 検出に使用できます。1 つのプロバイダーに属する複数の TE プロバイダー（複数の OSPF 領域）を使用することにより、複数の領域にまたがる L3VPN のプロビジョニングが可能になります。

（注） Prime Fulfillment は、複数の領域にまたがる TE トンネル（ある領域にヘッド ルータがあり、別の領域にテール ルータがあるトンネル）を検出またはプロビジョニングしません。

複数の領域があるネットワークを検出するためには、TE 検出を使用して各領域を順に検出する必要があります（ユーザ ガイドのを参照）。シード ノードは、Area Border Router（ABR; エリア境界ルータ）を含め、領域内のどのデバイスでもかまいません。

TE 検出と TE 領域 ID

TE 検出には TE プロバイダーが関連付けられ、各 TE プロバイダーには領域が割り当てられます。この領域は TE プロバイダーの作成プロセスで割り当てられます（ユーザ ガイドの を参照）。この領域は単純な整数値またはドット付き 10 進表記（領域 0.6.0.0 など）です。

TE プロバイダー オブジェクトは、作成時の指定または検出時の自動入力によって対象とする領域を認識し、ドット表記と 10 進表記の変換に対応します。デフォルトはネットワークで使用されている表記です。

選択した TE プロバイダーがある領域に対して検出を実行すると、その領域に関連付けられたすべてのトンネルおよび明示パスが Prime Fulfillment データベースにインポートされます。領域単位の検出の実行手順については、ユーザ ガイドの を参照してください。

複数の OSPF 領域があるネットワークの例

TE プロバイダー内の TE ルータを複数のリージョン（地域など）に割り当てることにより、デバイスを論理的な基準に基づいてリージョンにグループ化できます。また、Prime Fulfillment ではリージョンに基づくフィルタリングが可能です。オブジェクトを特定のリージョンに割り当てるには、検出の実行後、[Inventory] > [Provider Devices] から手動で行います。PE デバイスのリージョンは、[Select Region] ポップアップ ウィンドウで変更できます。

次の図 3-1 に示す例では、2 つの TE プロバイダーがそれぞれ 1 つの Prime Fulfillment プロバイダー内に作成され、視覚化された 1 つの OSPF 領域を担当します。

図 3-1 複数の OSPF 領域があるネットワーク

TE の管理方法については、ユーザ ガイドの を参照してください。

帯域幅プール

各 TE 対応のインターフェイスの帯域幅には、ネストされた複数の帯域幅プールが割り当てられます。現在、IOS は、グローバル プールとサブ プールという 2 種類の帯域幅プールをサポートしています。

帯域幅プールについての理解を深めるために、図 3-2 を参照してください。

図 3-2 帯域幅プール

図 3-2 に示すように、サブ プールはグローバル プール内にネストされています。したがって、プライマリ トンネルがサブ プールから帯域幅を予約すると、同じ帯域幅がグローバル プールでも予約されます。

サブ プールでの帯域予約（プライマリ トンネル）は、合計でサブ プールのサイズを超えてはなりません。同様に、グローバル プールでの帯域予約は、合計でグローバル プールのサイズを超えてはなりません。

計画ツール

ここでは、トラフィック エンジニアリングされたネットワークの改善計画を What-If シナリオを基づいて評価するためのツールについて説明します。

計画ツールには、次の機能が含まれます。

• プライマリ計画ツール：

– Tunnel Audit：トンネルまたはリソースの変更が提案されているかどうかにかかわらず、既存のネットワークのプライマリ配置に不一致がないかどうか調べます。

– Tunnel Placement：通常は、新しいトンネルに使用します。Tunnel Placement では、新しいルートを生成できます。この機能は、それまでパスがなく、配置することが必要なトンネルに使用できます。

– Tunnel Repair：Tunnel Audit の実行後（問題が検出された場合）に実行します。Tunnel Repair には再ルーティング機能があり、トンネルの移動に使用できます。

– Grooming：ネットワーク全体を対象とする最適化ツールです。トンネルの属性が変更されていない場合にのみ使用できます。

• 保護計画ツール：

– Audit SR：手動で追加、変更、削除されたバックアップ トンネルについて、配置前に保護の状態を調べます。

– Compute Backup：選択されたネットワーク要素に最適なバックアップ トンネルを自動的に計算します。

– Audit Protection：選択された要素の保護を既存のバックアップ トンネルの観点から監査します。

これらの計画ツールは Prime Fulfillment に完全に統合されており、次のような GUI のさまざまな場所から使用できます。

• TE Protected Elements（Compute Backup および Audit Protection）

• Create Managed TE Tunnel（Tunnel Audit、Tunnel Placement、Tunnel Repair、Grooming）

• Create TE Backup Tunnel（Audit SR）

接続保護（CSPF）バックアップ トンネル

TEM によって作成される帯域幅保護のバックアップ トンネルに加え、一連の CSPF-routed バックアップ トンネルも Prime Fulfillment 内に作成できます。CSPF-routed バックアップ トンネルは、[TE Protection SR] ウィンドウで管理します。

接続保護バックアップ トンネルは「exclude-address」明示パスを使用します。この明示パスは [TE Explicit Path List] ウィンドウで作成します。exclude address パスは、パスが使用するホップではなくパスが回避するホップを示す点で strict パスと異なります。どのパスが最適であるかはルータ上の CSPF アルゴリズムによって決定されますが、このアルゴリズムには exclude address パス設定のホップを使用できないという制約があります。この種のパスは、特にバックアップ トンネルで役に立ちます。exclude address パスが回避する必要のあるインターフェイスは、バックアップ トンネルの保護対象である可能性があるからです。

Prime Fulfillment では、これらのバックアップ トンネルに無制限のバックアップ帯域幅が設定されます。無制限とは帯域幅が保証されないことを意味しますが、障害発生時に使用可能な最大限の帯域幅が使用されます。そのため、帯域幅保護は実質的にベスト エフォートです。ただし、接続は保証されます。接続保護バックアップ トンネルは、帯域幅保護バックアップ トンネルへの追加または代替として使用できます。

帯域幅保護バックアップ トンネルと接続保護バックアップ トンネルには、次のような違いがあります。

• 帯域幅保護バックアップ トンネルの最初のパス オプションはストリクト明示パスであるのに対し、接続保護バックアップ トンネルの最初のパス オプションは exclude address 明示パスです。

• 帯域幅保護バックアップ トンネルにはバックアップ帯域幅が定義されているのに対し、接続保護バックアップ トンネルでは無制限のバックアップ帯域幅がベスト エフォート方式で使用されます。

• 帯域幅保護バックアップ トンネルは、最適なバックアップ トンネルを生成して既存のトンネルが要素を完全に保護することを確認するルート ジェネレータ アルゴリズムに渡されるのに対し、接続保護バックアップ トンネルはルート ジェネレータ アルゴリズムに渡されないため、トンネルが目的を果たしていることをユーザが確認する必要があります。

クラスベース トンネル選択

マルチプロトコル ラベル スイッチング トラフィック エンジニアリング Class-Based Tunnel Selection（CBTS; クラスベース トンネル選択）を使用すると、同一トンネル ヘッド エンドと同一テール エンド間でさまざまな TE トンネルに、さまざまな Class of Service（CoS; サービス クラス）値を指定して、トラフィックを動的にルーティングおよび転送できます。パケットの CoS 値は EXP ビット内にあります。8 個の EXP ビットがあり、0～7 の番号が付いています。

同一ヘッド エンドから同一テール エンドへの TE（または DS-TE）トンネルは、複数の CoS 値を持つように設定できます。設定後、CBTS は、次の要件を満たすトンネルに各パケットを動的にルーティングして転送します。

• 標準の自動ルートまたはスタティック ルートを使用してトラフィック アドミッションの対象として選択されている。

• EXP ビットがパケットの EXP ビットと一致している。

したがって、CBTS は、TE トンネルへの直接のトラフィック アドミッションではなく、トラフィックが TEM でサポートされる自動ルートまたはスタティック ルート メカニズムによってトンネルに入る前に満たす必要のある追加の基準です。

CBTS は DS-TE トンネル経由でダイナミック ルーティングを行い、設定が最小限で済むので、大規模なネットワークにおいて DS-TE の配置が大幅に軽減されます。CBTS は、すべての CoS 値をさまざまな種類のトンネルに配布できます。

CBTS 機能には次の制限があります。

• 1 つの宛先について、同じテール エンドで終端するトンネルを使用してすべての CoS 値が伝送されます。すべての CoS 値がトンネルで伝送されるか、またはトンネルでまったく値が伝送されないかのいずれかです。したがって、1 つの宛先について、一部の CoS 値を DS-TE トンネルでマッピングし、その他の CoS 値を Shortest Path First（SPF; 最短パス優先）Label Distribution Protocol（LDP; ラベル配布プロトコル）または SPF IP パスでマッピングすることはできません。

• CBTS では、複数のトンネルで特定の EXP 値のロードバランスを図ることはできません。2 つ以上のトンネルが特定の experimental（EXP）値を伝送するように設定されている場合、CBTS はその中から 1 つのトンネルを選択して、この EXP 値を伝送します。

• Any Transport over MPLS（AToM）、MPLS TE Automesh、または Label-Controlled（LC）-ATM では、CBTS の動作はサポートされません。

グローバル スタティック ルートを使用してトンネルへのトラフィック アドミッションが行われ、特定の宛先に対し、管理上の重みが同じであるトンネルが複数ある場合は、CBTS 属性がトンネルの選択基準となります（上記の CBTS でのロードバランスに関する説明を参照してください）。

ポリシーベース トンネル選択

マルチプロトコル ラベル スイッチング トラフィック エンジニアリング Policy-Based Tunnel Selection（PBTS; ポリシーベース トンネル選択）を使用すると、トラフィックを同一トンネル ヘッド エンドと同一テール エンド間でさまざまな TE トンネルにポリシーに基づいて動的にルーティングおよび転送できます。ルーティング アルゴリズムは、フォワーディング ルックアップの前にヘッドエンド ルータの入力インターフェイスで実行されます。

Prime Fulfillment のPBTS 実装では、トラフィックはインターフェイス コマンド policy-class を使用して特定の TE トンネルに転送されます。CBTS は IOS デバイスを対象としていますが、PBTS は IOS XR デバイス用に厳密に設計されています。

CBTS と同じように、PBTS は、TE トンネルへの直接のトラフィック アドミッションではなく、トラフィックが TEM でサポートされる自動ルートまたはスタティック ルート メカニズムによってトンネルに入る前に満たす必要のある追加の基準です。

（注） Prime Fulfillment は、ポリシー クラスをプロビジョニングするわけではなく、トンネルに既存のポリシー クラスを関連付けるだけです。そのためには、policy-class 属性を 1～7 の値に設定します。

CBTS の詳細については、「クラスベース トンネル選択」を参照してください。

PBTS および IOS XR の一般的な情報については、 http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.7/mpls/configuration/guide/gc37te.html#wp1325561 を参照してください。