ローカル輻輳緩和（LCM）を使用したローカルでのネットワーク輻輳の緩和

（注）

この項で説明する機能は、Advanced RTM ライセンスパッケージの一部としてのみ使用できます。
この項では、ナビゲーションを [トラフィックエンジニアリング（Traffic Engineering）] > [トラフィックエンジニアリング（Traffic Engineering）] と記載しています。ただし、Crosswork Network Controller ソリューション内で Crosswork 最適化エンジンを使用する場合、ナビゲーションは [トラフィックエンジニアリング＆サービス（Traffic Engineering＆Services）] > [トラフィックエンジニアリング（Traffic Engineering）] になります。

ローカル輻輳緩和の概要

ローカル輻輳緩和（LCM）は、（トリガーされたイベントとは対照的に）設定可能な頻度で輻輳を検索し、ドメイン内の周囲のインターフェイスでローカライズされた緩和の推奨事項（ローカルインターフェイスレベルの最適化）を提供します。LCM は、1 つ以上の戦術的ポリシーの最短パスを計算して、輻輳したインターフェイス上の最小量のトラフィックを、十分な帯域幅を持つ代替パスに迂回させます。また、元の IGP パス上のトラフィックをできるだけ多く保持しようとします。ユーザーが承認すると、LCM は戦術的トラフィックエンジニアリング（TTE）SR ポリシーの展開を通じて緩和を実行します。LCM は、輻輳を緩和するために SR ポリシーの既存の展開のパスを変更しません。LCM を使用すると、次のことが可能になります。

戦術的トラフィックエンジニアリング（TTE）SR ポリシーの展開をコミットするかどうかを決定する前に、ネットワーク上で LCM の推奨事項を視覚的にプレビューできます。
LCM ソリューションの設定に基づいて輻輳とネットワーク障害に対処するために、LCM がネットワークに変更を自動的に展開できるようにします。詳細については、LCM の設定の詳細な設定オプション（[Auto Repair Solution] および [Adjacency Hop Type]）を参照してください。

LCM を使用すると、パスの計算が簡素になり、特定のネットワーク要素に制限されるため、複数の IGP エリアを含むなど、さまざまなネットワークトポロジでソリューションをより幅広く適用できます。ドメイン内の問題にローカルに焦点を当てることにより、完全なトラフィックマトリックスを通じてネットワーク内のエッジツーエッジトラフィックフローをシミュレートする必要がなくなり、大規模ネットワークの拡張性が向上します。また、LCM では、SNMP を介して TTE SR ポリシーおよびインターフェイスカウンタの収集が実行されるため、SR-TM を使用する必要はありません。

TTE トンネルの推奨事項は、[LCM運用ダッシュボード（LCM Operational Dashboard）] にリストされます。このダッシュボードから、TTE SR ポリシーを展開する前に推奨を視覚的にプレビューできます。輻輳を解決するための TTE SR ポリシーの展開は自動化されていません。LCM 推奨アクションを承認してコミットする必要があります。LCM では、以前の TTE SR ポリシー（LCM によってインスタンス化）が不要になった場合は削除することも推奨されます。

LCM に関する特記事項

LCM を使用する場合は、次の情報を考慮してください。

LCM を使用するには、Advanced RTM ライセンスパッケージが必要です。
帯域幅最適化が有効になっている場合は、LCM を有効にできません。
LCM は、最大 2000 台のデバイスを持つドメインをサポートします。ドメインは、IGP プロセスに割り当てられる識別子です。ドメインはネットワークから学習されます。ドメイン ID は、BGP-LS で IGP をアドバタイズするために使用するルータ設定（link-state instance-id）から取得されます。
LCM 推奨ソリューションでは、単一ドメイン内のリソースのみ使用されます。
LCM は、5 分以上の通常の設定可能な頻度でネットワーク使用率を評価します。頻度は通常、SNMP トラフィックのポーリング間隔以上に設定されます。デフォルトの頻度は 10 分です。
LCM は、パラレル TTE SR ポリシー全体で ECMP を活用し、トラフィックのほぼ均等な分割を想定します。実際の ECMP 分割がこの想定に従う程度は、大規模なエレファントフローの存在とレベルトラフィックの集約によって異なります。
最適化できるトラフィックは、既存の SR-TE ポリシーで伝送しないでください。
ドメインインターフェイスとリンクが（意図的または非意図的に）削除されると、次のようになります。
- リンクがダウンする（LINK_DOWN 状態になる）と、LCM 設定とドメイン UI カード（LCM の設定を参照）は、リンクがエージアウトする（4 時間後）まで使用できます。この動作は意図的なもので、誤って実行された場合にドメインインターフェイスとリンクを回復する時間が与えられます。
- リンクがエージアウトする前にドメインを強制的に削除する場合は、UI から手動でリンクを削除できます。ドメインは、最後のリンクが削除されるまで「削除準備完了」ステータスのままになります。

LCM プラットフォームの要件

次に、LCM を適切に動作させるための大まかな要件のリストを示します。

輻輳評価：

LCM には、次のトラフィック統計情報が必要です。
- SNMP インターフェイストラフィックの測定値
- SNMP ヘッドエンド SR-TE ポリシートラフィックの設定値
SR にはストリクト SID ラベルを設定する必要があります。

輻輳緩和：

ヘッドエンドデバイスは、複数のパラレル SR-TE ポリシー全体で等コストマルチパス（ECMP）をサポートする必要があります。
ヘッドエンドデバイスは、autoroute のステアリングで PCE によって開始された SR-TE ポリシーをサポートする必要があります。

autoroute を使用して SR-TE ポリシーへのトラフィックステアリングを有効にするには、force-sr-iinclude を使用してデバイスを設定する必要があります。次に例を示します。
```
segment-routing traffic-eng pcc profile <id> autoroute force-sr-include
```
特定のデバイスの SR 設定のマニュアルを参照して、説明とサポートされている設定コマンドを確認してください（『Segment Routing Configuration Guide for Cisco ASR 9000 Series Routers』など）。

プラットフォーム要件の完全なリストについては、シスコの営業担当者にお問い合わせください。

ASBR 間の専用 IGP インスタンスでの複数 AS ネットワークに対する BGP-LS のスピーカー配置

SR-PCE（または出力ピアエンジニアリング（EPE）がサポートされていないその他のユースケース）によるドメイン間遅延最適化 SR ポリシーパスの計算をサポートするために、異なる ASN の自律システム境界ルータ（ASBR）間で専用 IGP インスタンスを設定できます。このような場合、適切なトポロジ検出のために、BGP-LS 経由でトポロジを報告する ASBR を特定することが重要です。

次の例では、専用 AS 間 IGP（ドメイン 100）に参加している各 AS の少なくとも 1 つの ASBR で、各 ASBR 間の IGP を報告する BGP-LS が有効になっている必要があります。各 ASBR は、同じ BGP-LS 識別子を持つドメインを報告する必要があります。

（注）

BGP-LS トポロジを報告する AS ごとに複数の ASBR もサポートされます。

アップグレード後における以前のモニター対象インターフェイスの欠落

Crosswork 最適化エンジン 2.0 でホスト名の変更が発生し、そのシステムのバックアップを使用して Crosswork 最適化エンジン 3.0 にアップグレードした場合、ホスト名が更新されたノードに属する、以前のモニター対象 LCM インターフェイスは移行されません。それらのインターフェイスは LCM モニター対象インターフェイスのリストからドロップされ、LCM ログに警告が表示されます。この問題を回避するために、移行が完了してシステムが安定した後、モニターする LCM のインターフェイスを手動で追加できます。

LCM 計算のワークフロー

この例では、輻輳の検出から LCM が実行する計算を説明した後に、戦術的トンネル展開を推奨します。Crosswork Optimization Engine 3.0 のリリースでは、計算はドメイン単位で実行されるため、大規模なネットワークの拡張性が向上し、計算が高速になります。

手順

ステップ 1	LCM は、まず、Optimization Engine モデル（物理ネットワークのリアルタイムトポロジとトラフィックの表現）を定期的に分析します。
ステップ 2	この例では、輻輳の確認間隔の後、ノード 2 の使用率が 70% の使用率しきい値を超えると、LCM が輻輳を検出します。
ステップ 3	LCM は、転送に適したトラフィック量を計算ます。 LCM は、既存の SR ポリシーでルーティングされていないトラフィックのみを転送します（ラベルなし、IGP ルーティング、または FlexAlgo-0 SID 経由で伝送など）。SR-TE ポリシート内のラフィックは、LCM 計算には含まれず、元のプログラムされたパスを通過し続けます。対象トラフィックは、インターフェイス上のすべてのトラフィックを考慮したインターフェイストラフィック統計情報を取得し、インターフェイスを通過するすべての SR-TE ポリシーのトラフィック統計情報の合計を引いて計算されます。合計インターフェイストラフィック－ SR ポリシートラフィック = 最適化できる対象トラフィックこのプロセスでは、SR ポリシーの ECMP 分割を考慮して、SR ポリシートラフィックを適切にアカウンティングする必要があります。この例では、輻輳したノード 2 の合計トラフィックは 800 Mbps です。ノード 2 経由でルーティングされるすべての SR ポリシーの合計トラフィックは 500 Mbps です。この例で LCM が転送できる合計トラフィックは 300 Mbps（800 Mbps – 500 Mbps = 300 Mbps）です。
ステップ 4	LCM は、インターフェイス上の合計トラフィックからしきい値相当のトラフィックを差し引くことにより、代替パスを介して送信する必要がある量を計算します。この例では、転送される量は 100 Mbps です。 800 Mbps – 700 Mbps（しきい値 70%）= 100 Mbps LCM は、300 Mbps のうちの 100 Mbps（対象トラフィック）を別のパスにルーティングする必要があります。オーバープロビジョニング係数（OPF）のパーセンテージが 10 に設定されている場合、LCM は対象トラフィックの 110（100 Mbps X 1.10）をルーティングする必要があることに注意してください。OPF は、[LCM Configuration] ウィンドウの [Advanced] タブで設定できます。詳細については、LCM の設定を参照してください。
ステップ 5	LCM は、必要な TTE SR ポリシーの数とそのパスを決定します。迂回する必要がある量に対して最短パスに留まることができる LCM 対象トラフィックの割合によって、最短パスと代替パスでそれぞれ必要な TTE SR ポリシーの数が決まります。この例では、LCM は輻輳したリンクから対象トラフィックの合計の 1/3（300 Mbps のうち 100 Mbps）を転送する必要があります。LCM は完全な ECMP を想定し、このトラフィック分割には 3 つの戦術的 SR-TE ポリシーが必要だと予測します。1 つの戦術的 SR-TE ポリシーが転送パスをとり、2 つの戦術的 SR-TE ポリシーが元のパスをとります。ノード 2 とノード 4 の間のパスに十分な容量があります。したがって、LCM では、SR-PCE を介してノード 2 からノード 3 に展開する 3 つの TTE SR ポリシー（それぞれ約 100 Mbps をルーティングすると想定）を推奨しています。ノード 3（200 Mbps）への直接パスを取る 2 つの TTE SR ポリシー TTE SR ポリシーの 1 つはノード 4（100 Mbps）を介してホップします。これらの推奨事項は、[LCM運用ダッシュボード（LCM Operational Dashboard）] にリストされます。
ステップ 6	LCM はこれらの TTE SR ポリシーを展開すると想定して、展開された TTE ポリシーを引き続きモニターし、[LCM Operational Dashboard] で必要に応じて変更または削除することを推奨します。TTE SR ポリシーの削除は、これらのポリシーが削除された（保留マージンを差し引く）場合に、緩和されたインターフェイスが輻輳しない場合に推奨されます。これにより、LCM の操作全体で不必要な TTE SR ポリシーのチャーンを回避できます。

ローカルインターフェイスでの輻輳の緩和の例

この例では、LCM を有効にし、定義された使用率のしきい値をデバイスのインターフェイスの使用率が超えた場合に TTE SR ポリシーを展開するための輻輳緩和の推奨事項を確認します。輻輳の緩和をコミットする前に、推奨される TTE SR ポリシーをプレビューします。この例では、次のワークフローを示します。

輻輳していないトポロジを表示します。
LCM を有効にして設定します。
LCM が輻輳を検出した後、[Operational Dashboard] で LCM の推奨事項を表示します。
LCM TTE ポリシーをトポロジマップで視覚的にプレビューします。
すべての LCM TTE ポリシーの推奨事項をコミットして展開し、輻輳を緩和します。
LCM TTE ポリシーが展開されていることを確認します。

（注）

この例で使用される使用率のしきい値は非常に低く（12%）、ラボ環境での使用に最適です。

次の図は、この例で使用されるトポロジを示しています。

手順

ステップ 1

LCM 設定前の初期トポロジと使用率を表示します。

リンクの詳細を表示するには、P4-NCS5501 と P1-ASR9k の間のリンクをクリックします。P4-NCS5501 の使用率は 11.57% です。

図 4. 初期使用率

ステップ 2

LCM を有効にし、グローバルおよびカスタムインターフェイスの使用率のしきい値を設定します。

メインメニューから、[Traffic Engineering] > [Local Congestion Mitigation] > [Domain-ID] > > [Configuration] を選択します。この例では、しきい値を 12% に設定し、[Interfaces to Monitor] > [Selected Interfaces] オプションを選択します。詳細については、LCM の設定を参照してください。

図 5. LCM 設定ページ
[Commit Changes] をクリックして、設定を保存します。設定の変更をコミットすると、LCM はモニター対象インターフェイスで輻輳が発生した場合、[LCM Operational Dashboard] に推奨事項を表示します。LCM は新しい TTE ポリシーを自動的にコミットまたは展開しません。後で、推奨される TTE ポリシーをプレビューし、それらのポリシーをコミットしてネットワークに展開するかどうかを決定できます。

[Interfaces to Monitor] > [Selected Interfaces] を選択した場合は、[Link Management] ページ（[Traffic Engineering] >[ Local Congestion Mitigation] > [Domain-ID] > > [Link Management]）に移動し、カスタム使用率しきい値を持つインターフェイスのリストをアップロードします。このページにリストされているインターフェイスの輻輳のみモニターされます。次の例を参照してください。

（注）

[Interfaces to Monitor] > [All Interfaces] を選択した場合、LCM はすべてのインターフェイスをモニターします。対象には、[Link Management] ページにインポートされた個々のしきい値が含まれます。残りのインターフェイスは、[Configuration] ページで定義されたグローバル [Utilization Threshold] を使用してモニターされます。

ステップ 3

しばらくすると、設定された LCM しきい値を超えて輻輳が発生します。この例では、使用率が 12% を超えています。

ステップ 4

[LCM Operational Dashboard] で TTE SR ポリシーの推奨事項を表示します。

[Traffic Engineering] > [Local Congestion Mitigation] に移動します。輻輳が検出されると、ドメインに推奨アクションのタイムスタンプが表示されます。
（オプション） > [Events] タブをクリックして、新しいイベントを表示します。このウィンドウをモニターして、発生した LCM イベントを表示することもできます。LCM の推奨事項、コミットアクション、および例外のイベントを確認する必要があります。LCM イベントの例を次に示します。
[Operational Dashboard] を開きます（[Traffic Engineering] > [Local Congestion Mitigation] > [Domain-ID] > > [Operational Dashboard]）。

ダッシュボードには、使用率が 12% を超えていて、13.01% であることが示されます。[Recommended Action] 列には、インターフェイスの輻輳に対処するために TTE ポリシーソリューションセット（[Create Set]）を展開することが推奨されています。[Expected Util] 列には、推奨アクションがコミットされた場合の各インターフェイスの予想使用率が表示されます。詳細については、LCM 動作のモニターを参照してください。

図 7. [LCM Operational Dashboard]
TTE ポリシーをコミットする前に、各 TTE ポリシーソリューションセットの展開をプレビューできます。[Actions] 列でをクリックし、[Preview] を選択します。各 TTE ポリシーのノード、インターフェイス、および推奨アクションがウィンドウに表示されます。[Preview] ウィンドウから、個々の TTE ポリシーを選択し、トポロジマップで通常行っているように、さまざまな側面と情報を表示できます。次の図に、インターフェイス GigabitEthernet0/0/0/4 の推奨 TTE ポリシーを示します。後で TTE ポリシーの展開を確認するために、[Color ID] をメモします。

図 8. LCM TTE 展開のプレビュー

マップ上で推奨される TTE ポリシーを確認したら、[Operational Dashboard] に戻り、[Commit All] をクリックします。LCM の [Status] 列が [Mitigating] に変化します。

（注）

[Operational Dashboard] に示されているとおりに輻輳を緩和し、予想使用率を達成するには、ドメインごとに LCM のすべての推奨事項をコミットする必要があります。緩和ソリューションは、ソリューションセット間の依存関係により、コミットされているすべての LCM 推奨事項に基づいています。

ステップ 5

TTE SR ポリシーの展開を検証します。

通知アイコン > [Events] タブをクリックします。[Events] ウィンドウに表示される LCM イベントを確認します。

（注）

Crosswork Optimization Engine は、有効にしたポリシーと機能に基づいて検出されたネットワークイベントを報告します。たとえば、リンクドロップによって SR-TE ポリシーがダウンした場合や、LCM が輻輳を検出した場合に報告されます。これらのアラートは UI で報告され、必要に応じてサードパーティのアラート/モニタリングツールに転送できます。

[Operational Dashboard] に戻り、すべての TTE ポリシーソリューションセットの LCM の状態が [Mitigated] に変化したことを確認します。

LCM の状態が変化するには、SNMP 頻度の 2 倍の時間がかかることに注意してください。
トポロジマップと [SR Policy] テーブルを表示して、TTE ポリシーの展開を確認します（[Traffic Engineering] > [Traffic Engineering] > [SR-MPLS] タブ）。
新しい SR-TE ポリシーのいずれかを選択し、SR ポリシーの詳細を表示します（をクリックして [View Details] を選択）。

ステップ 6

LCM の推奨に従って TTE SR ポリシーを削除します。

しばらくすると、展開された TTE SR ポリシーが不要になる場合があります。これは、LCM によって開始された TTE トンネルがなくても、使用率がしきい値を下回らない場合に発生します。この場合、LCM は TTE SR ポリシーセットを削除するための新しい推奨アクションを生成します。展開された TTE SR ポリシーを削除するには、[すべてコミット（Commit All）] をクリックします。
SR ポリシーを削除するには、[すべてコミット（Commit All）] をクリックします。
トポロジマップと [SRポリシー（SR Policy）] テーブルを表示して、削除を確認します。

このシナリオでは、LCM を活用してネットワークのトラフィックの輻輳を軽減する方法を確認しました。LCM では、手動による追跡と計算は不要であり、同時に輻輳緩和の推奨事項を実装するかどうかを制御できます。推奨事項をプレビューして、展開する前にネットワークでの展開の有効性を確認できます。トラフィックが変化すると、LCM は展開された TTE SR-TE ポリシーを追跡し、それらのポリシーがまだ必要かどうかを判断します。必要でない場合、LCM は削除を推奨します。

LCM の設定

LCM を有効にして設定するには、次の手順を実行します。

始める前に

LCM に関する特記事項を確認してください。

手順

ステップ 1

メインメニューから、[Traffic Engineering] > [Local Congestion Mitigation] > [Domain-ID-card] > > [Configuration] > [Basic] タブを選択します。

例:

ステップ 2

[有効化（Enable）] スイッチを [True] に切り替えます。

ステップ 3

必要な情報を入力します。各フィールドの説明を表示するには、 [フィールドヘルプ（Field Help）] アイコンの上にマウスポインタを合わせます。

次のリストに、追加のフィールド情報を示します。

[Utilization Threshold]：インターフェイスが輻輳していると LCM が判断する使用率を設定します。この値は、[Link Management] ページで個々のインターフェイスにしきい値を指定しない限り、すべてのインターフェイスに適用されます。
[Profile ID]：LCM ポリシーへのトラフィックステアリングを有効にするために必要な設定です。autoroute（LCM が作成する戦術的な SR-TE ポリシーへのトラフィックのステアリング）は、（プロファイル ID を autoroute 機能に関連付ける PCC 上の設定と一致させるために）ここで設定した適切な [Profile ID] オプションを介して SR-TE ポリシーに適用されます。
[輻輳確認間隔（Congestion Check Interval）]（秒単位）：この値は、LCM がネットワークの輻輳を評価する間隔を決定します。安定状態では、推奨のコミットがない場合、この間隔を使用してネットワークを再評価し、推奨事項を変更する必要があるかどうかを判断します。たとえば、間隔が 600 秒（10 分）に設定されている場合、LCM は 10 分ごとにネットワークを評価して新しい輻輳を確認し、新しい推奨事項、または既存の推奨事項に対する変更が必要かどうかを判断します。変更の例としては、以前に推奨された個々のポリシーの削除や更新などがあります。ネットワークを変更すると、情報が安定して LCM に伝達されるまでに時間がかかる場合があるため、間隔を SNMP 収集パターンの 2 倍以上に設定します。
[Interfaces to Monitor]：デフォルトでは、[Selected Interfaces] に設定されており、[Link Management] ページ（[Traffic Engineering] > [Local Congestion Mitigation] > [Domain-ID] > > [Link Management]）で CSV ファイルをインポートして、しきい値を個々のインターフェイスに追加する必要があります。[Link Management] ページで定義されたインターフェイスのみがモニターされます。[All Interfaces] に設定すると、LCM は、[Link Management] ページでアップロードされたカスタムしきい値を持つインターフェイスと、このページで設定された [Utilization Threshold] 値を使用して残りのインターフェイスをモニターします。
[詳細設定（Advanced）] > [輻輳チェック抑制間隔（秒）（Congestion Check Suspension Interval (seconds)]：この間隔によって、輻輳の検出と緩和を再開する前に（[すべてコミット（Commit All）] が実行された後）待機する時間が決まります。ネットワークモデルのコンバージェンスの時間を考慮する必要があるため、この間隔は SNMP 収集パターンの 2 倍以上に設定します。
[Advanced] > [Auto Repair Solution]：[True] に設定すると、LCM はダウン、失敗、またはコミットされていない LCM TTE ポリシーを自動的に削除します。これは、主にポリシーの障害に対処するためのオプションです。

このオプションが無効で、[LCM Operational Dashboard] に表示される推奨の [Urgency] ステータスが [High] の場合、推奨されるソリューションは [Auto Repair Solution] の候補です。これは、ソリューションが展開されていない場合にネットワーク障害が発生する可能性が高いことを意味します。

[Advanced] > [Adjacency Hop Type]：[Protected] に設定すると、LCM は保護された隣接関係 SID を使用して SR ポリシーを作成します。これにより、トポロジに依存しないループフリー代替（TI-LFA）で隣接関係の障害のパスを計算できます。

（注）

このオプションは、LCM が動作している同じ IGP エリア内のすべてのノードが厳密な SPF SID 対応である場合にのみ、[Protected] に設定する必要があります。

[Advanced] > [Over-provisioning Factor (OPF)]：このオプションは、不均等な ECMP トラフィック分散（エレファントフロー）に対処するのに役立ちます。この値により、バイパスポリシーのパスを計算するときに考慮する必要がある追加トラフィックの割合が決まります。LCM は、輻輳が原因でトラフィック量 x を転送させる必要がある場合、x *（1 + OPF）トラフィックをサポートできるパスを検索します。詳細については、LCM 計算のワークフローを参照してください。デフォルト値は 0 です

ステップ 4

設定を保存するには、[Commit Changes] をクリックします。モニター対象インターフェイスで輻輳が発生すると、LCM は [LCM Operational Dashboard] に推奨事項を表示します（LCM は新しい TTE ポリシーを自動的にコミットしたり、展開したりしません）。その後、推奨される TTE ポリシーをプレビューし、コミットしてネットワークに展開するかどうかを決定できます。

個別のインターフェイスしきい値の追加

ネットワークにはさまざまなリンク（10G、40G、100G）があり、異なるしきい値を設定する必要があります。LCM または帯域幅最適化を使用する場合に、個々のインターフェイスに特定のしきい値を割り当てるには、次の手順を実行します。

手順

ステップ 1	メインメニューから、次のいずれかを選択します。 [ローカルでの輻輳緩和（Local Congestion Mitigation）] > [リンク管理（Link Management）] [帯域幅最適化（Bandwidth Optimization）] > [リンク管理（Link Management）]
ステップ 2	をクリックします。
ステップ 3	[サンプル設定ファイルのダウンロード（Download sample configuration file）] リンクをクリックします。
ステップ 4	[キャンセル（Cancel）] をクリックします。
ステップ 5	ダウンロードした設定ファイル（sampleLcmLinkManagement.csv）を開き、編集します。サンプルテキストを特定のノード、インターフェイス、およびしきい値情報に置き換えます。
ステップ 6	ファイルの名前を変更して保存します。
ステップ 7	[リンク管理（Link Management）] ウィンドウに戻ります。
ステップ 8	をクリックして、編集した CSV ファイルに移動します。
ステップ 9	[インポート（Import）] をクリックします。
ステップ 10	[リンク管理（Link Management）] ウィンドウに情報が正しく表示されることを確認します。

LCM 動作のモニター

[LCM Operational Dashboard]（[Traffic Engineering] > [Local Congestion Mitigation] > [Domain-ID] > > [Operational Dashboard]）には、設定された使用率しきい値で定義された輻輳インターフェイスが表示されます。各インターフェイスについて、現在の使用率、推奨アクション、ステータス、推奨をコミットした後に予想される使用率などの詳細がリストされます。推奨事項はセットの一部としてリストされ、展開されている場合はすべての変更がコミットされます。[Urgency] は、推奨事項の展開またはアクションの重要性を示します。[Urgency] の値は次のいずれかになります。

[Low]：LCM インスタンス化ポリシーが不要になったために削除できること、または変更が不要であることを示します。
[Medium]：新規または変更された推奨事項を示します。
[High]：ネットワーク障害と推奨事項を展開する必要があることを示します。これは、[Auto Repair Solution] の詳細オプションが有効になっている場合に自動的に対処できる候補です。「LCM の設定」を参照してください。

各列に表示される情報のタイプの説明を表示するには、マウスポインタを [フィールドヘルプ（Field Help）] アイコンに合わせます。このダッシュボードから、TTE ポリシーの推奨事項をプレビュー（ > [Preview]）して展開することもできます。

[LCM Operational Dashboard] に加えて、通知アイコン > [Events] タブをクリックできます。[Events] ウィンドウに表示される LCM イベントを確認します。

Cisco Crosswork Optimization Engine 3.0 ユーザーガイド

偏向のない言語

翻訳について

Book Title

Cisco Crosswork Optimization Engine 3.0 ユーザーガイド

Chapter Title