帯域幅とネットワークの最適化

ここでは、次のトピックについて説明します。

概要

目的

ネットワークオペレータは、帯域幅の最適化を自動化し、ほぼ介入せずにトラフィックを誘導でき、輻輳を避けるための十分な帯域幅を重要なリンクに常に確保できるツールセットを必要としています。

Challenge

サービスプロバイダーにとって、帯域幅の問題の管理は、以前は事後対応型の手動プロセスであり、問題解決のプレッシャーは非常に大きなものでした。ネットワークの輻輳は、エンドカスタマー エクスペリエンスの低下につながります。リンクの輻輳、高遅延、およびその他のネットワーク障害により、ネットワークで伝送されるサービスに対する認識が低下したり、お客様とのサービスレベル契約（SLA）を満たせなくなったりします。最悪のシナリオでは、ネットワークの問題が SLA 違反や契約違反につながり、ブランド価値が失われます。

ソリューション

LCM と回線型ポリシーを使用して、サービスプロバイダーは、これらのリンクの帯域幅の予約を目的として、ビジネスに不可欠なリンクを指定できるようになりました。重要なリンクとオペレータの意図を特定することで、ネットワークをリアルタイムで自動的に最適化できます。

Crosswork Network Controller は次の両方を提供します。

  • ローカル輻輳緩和（LCM）は、帯域幅管理と輻輳緩和のための戦術的なソリューションです。LCM は、デバイス自体で輻輳の問題を直接解決する場合に最適なソリューションであり、フルスケールのトラフィックマトリックスや高度な計画は不要です。

  • 回線型セグメントルーティング（CS-SR）は、重要なリンク用に帯域幅を事前に予約できる戦略的なトラフィック エンジニアリング ソリューションであり、優先順位の高いサービスに関する輻輳の問題を完全に回避できます。

ローカル輻輳緩和（LCM）

LCM では、ネットワーク全体のトラフィックを再ルーティングしてネットワークの帯域幅リソースを最適化する（エンドツーエンドのパスの最適化）代わりに、インターフェイスレベルのキャパシティをローカルに、輻輳エリア内およびその周辺でチェックし、輻輳したインターフェイスのエンドポイント間のトラフィックを再ルーティングします（ローカルなインターフェイスレベルの最適化）。問題に対してローカルに焦点を当てることで、完全なトラフィックマトリックスを使用してネットワーク内のエッジツーエッジのトラフィックフローをシミュレートする必要がなくなります。このシミュレーションは手間がかかり、ノード数の増加に伴い拡張性が低くなります。

ネットワークに輻輳が検出された場合、LCM は、輻輳が発生したインターフェイスから最小量のトラフィックを転送することで推奨事項を提供します。LCM は、SNMP を介して SR-TE ポリシーおよびインターフェイスカウンタを収集します。転送するトラフィックの量を予想し、ユーザーが承認すると、戦術的トラフィック エンジニアリング（TTE）SR-TE ポリシーの展開を通じて緩和を実行します。輻輳をローカルで緩和するのに、完全なセグメント ルーティング トラフィック マトリックス（SR-TM）を使用する必要はありません。TTE SR-TE ポリシーは、輻輳したリンクのいずれかの側のデバイスでのみ作成され、他の場所ではインターフェイスを輻輳させない最短パスで作成されます。

LCM の仕組み

  1. まず、ネットワークオペレータは、ネットワークの「ローカル」部分を定義するドメインを作成します。ネットワーク全体をドメインにすることもできますが、より一般的には、1 つ以上の地理的領域またはデバイスインターフェイスのグループと一致させます。この例では、4 つのデバイスとそのすべてのインターフェイスを持つドメインを定義しています。また、このドメイン内のすべてのリンクが 1Gpbs であると想定しています。

  2. 演算子は、特定のドメインの「輻輳」の意味を定義するしきい値を指定します。この例では、オペレータはドメインの輻輳しきい値を 70% に設定しています。決定する輻輳しきい値は異なる場合があります。ネットワークとそのドメインアーキテクチャに最適な輻輳しきい値を決定する方法のガイダンスについては、シスコの『Local Congestion Mitigation (LCM) White Paper』を参照してください。

  3. LCM は、まず、Optimization Engine モデル（物理ネットワーク、トポロジおよびトラフィックのリアルタイム表現）を定期的に分析します。輻輳の確認間隔の後、ノード 2 の使用率が 70% の使用率しきい値を超えると、LCM が輻輳を検出します。

    図 1. LCM の仕組み
    LCM の仕組み

  4. LCM は、転送に適したトラフィック量を計算ます。LCM は、推奨事項における次のルールと制限に従います。

    LCM は、既存の SR ポリシーによってルーティングされていないトラフィックのみを転送します（ラベルなし、IGP ルーティング、または FlexAlgo-0 SID 経由で伝送など）。SR ポリシー内のトラフィックは、LCM 計算には含まれず、元のプログラムされたパスを通過し続けます。

    LCM により、ディバージョン対象トラフィックは、インターフェイス上のすべてのトラフィックのインターフェイス トラフィック統計情報を取得し、インターフェイスを通過するすべての SR-TE ポリシーのトラフィック統計情報の合計を引いて計算されます。

    合計インターフェイス トラフィック － SR ポリシートラフィック = 最適化できる対象トラフィック

    このプロセスでは、SR ポリシーの ECMP 分割を考慮して、SR ポリシートラフィックを適切にアカウンティングする必要があります。この例では、輻輳したノード 2 の合計トラフィックは 800 Mbps であり、ノード 2 を介してルーティングされるすべての SR ポリシーの合計トラフィックは 500 Mbps です。

    この例で LCM が転送できる合計トラフィックは 240 Mbps です。つまり、800 Mbps – 560 Mbps = 240 Mbps

  5. LCM は、インターフェイス上の合計トラフィックからしきい値相当のトラフィックを差し引くことにより、代替パスを介して送信する必要があるトラフィック量を計算します。この例では、転送される量は 100 Mbps です。

    800 Mbps – 640 Mbps（しきい値 70%）= 100 Mbps

    LCM は、300 Mbps のうちの 100 Mbps（対象トラフィック）を別のパスにルーティングする必要があります。

  6. 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）] にリストされます。

図 2. LCM 運用ダッシュボードの推奨ポリシー
LCM 運用ダッシュボードの推奨ポリシー

LCM はこれらの TTE SR ポリシーを展開すると想定して、 展開された TTE ポリシーを引き続きモニターし、[LCM 運用ダッシュボード（LCM Operational Dashboard）] で必要に応じて変更または削除することを推奨します。TTE SR ポリシーの削除は、これらのポリシーが削除された（保留マージンを差し引く）場合に、緩和されたインターフェイスが輻輳しない場合に推奨されます。これにより、LCM の操作全体で不必要な TTE SR ポリシーのチャーンを回避できます。

回線型ポリシー

回線型セグメント ルーティング ポリシー（CS-SR または CS ポリシー）は、「回線エミュレーション」または「専用回線」と呼ばれる機能を実装するために使用できる接続指向のトランスポートサービスです。セグメントルーティング アーキテクチャの隣接関係 SID とステートフル PCEP パス計算を組み合わせることで、CS ポリシーは次の機能を提供します。

  • 双方向の予測可能な遅延およびその他のパフォーマンスメトリックを備えた、永続的、専用、双方向の、相互にルーティングされたトランスポートパス。

  • これらのパスを使用するトラフィック エンジニアリング サービスの保証された帯域幅コミットメント。

  • エンドツーエンドのパス保護により、サービスレベル契約に影響を与えないようにします。

  • パス整合性の自動モニタリング、メンテナンス、および復元。

  • 回線型パスの柔軟な運用および管理。

  • SONET/SDH などの古い CEM インフラストラクチャのソフトウェア定義の代替品。

回線型ポリシーの仕組み

CS ポリシーの初期設定は、次の手順で行います。

  1. Crosswork Network Controller とそのアプリケーションは、ネットワークトポロジを検出してマッピングします。

  2. Crosswork ユーザーは、CS ポリシーのサポートを有効にして、CS ポリシー全体に割り当てる基本帯域幅と、CS 計算パスで超過した場合にアラームを生成する帯域幅使用率のしきい値の割合を指定します。したがって、たとえば、回線型の使用のために帯域幅の 20% が予約されている 1 GB リンクでは、CS ポリシーはそのリンクの最大 200 Mbps を使用できます。ただし、帯域幅の最小しきい値がデフォルトの 80% に設定されている場合は、リンクの 160 Mbps が使用されるとすぐにアラームが生成されることに注意してください。

  3. ネットワークオペレータは、保証されたパスを確立するノードのセットごとに CS ポリシーを作成します。ポリシーは、メインパスによってリンクされる 2 つのノード、予約される帯域幅、およびバックアップパスを指定します。帯域幅とパスの障害に対応するには、設定に双方向性、パス保護、および performance-management liveness-detection 設定を含める必要があります。

  4. オペレータが CS ポリシーをコミットすると、デバイス常駐のパス計算クライアント（PCC）は、CS ポリシーの帯域幅およびその他の制約に準拠する候補の現用パスと保護パスを計算するように Crosswork 常駐 PCE サーバーに要求します（単一の PCEP 要求メッセージを使用）。

  5. CS ポリシーのサポートが有効になっている場合、PCC は両方のパスを計算し、割り当てられた使用可能な帯域幅から CS ポリシー保証帯域幅を差し引きます。

  6. Crosswork は、プライマリの現用パスおよび保護パスのリストを使用して PCC に応答し、それらにコミット、つまり「委任」します。トポロジマップには、CS ポリシーの設定時に設定された色を使用して、2 つのノード間の現在のアクティブパスと保護パスが表示され、CS ポリシーエンドポイントとして識別できるように 2 つのエンドポイントノードにラベルが付けられます。

初期設定後に、次のことが行われます。

  1. Crosswork は、委任されたパスとアクティブな CS ポリシーをモニターします。ネットワークで使用可能で予約可能な帯域幅をほぼリアルタイムで更新します。

  2. 帯域幅使用率または追加の CS ポリシー要件が、設定された予約済み帯域幅または帯域幅使用率のしきい値を超えると、Crosswork はしきい値超過アラームを生成します。

  3. 委任されたパスが何らかの理由で失敗した場合、Crosswork は必要に応じてパスを再計算します。

シナリオ：LCM を使用して、過剰に使用されているリンクでトラフィックを再ルーティングする

このシナリオでは、ローカル輻輳緩和（LCM）を有効にし、輻輳緩和の推奨事項を確認します。LCM は、使用率が定義されたしきい値を超えた場合に、デバイスのインターフェイスに戦術的トラフィック エンジニアリング セグメント ルーティング（TTE SR）ポリシーを展開することを推奨します。コミットする前に、推奨される TTE SR ポリシーをプレビューします。

この例では、次のトポロジを使用します：
図 3. 初期使用率

初期使用率

（注）  

このガイドの HTML バージョンを表示している場合は、画像をクリックしてフルサイズで表示してください。

cw-xrv54 と cw-xrv55 間のリンクが過剰に使用される設定で LCM を有効にします。次に、Crosswork が計算する緩和ソリューションを確認します。この例では、オペレータがソリューションを適用するかどうかを決定します。

仮定と前提条件

次の項では、LCM が適切に動作するために満たす必要がある高レベルの要件を示します。

輻輳評価要件

LCM には、次のトラフィック統計情報が必要です。

  • インターフェイス トラフィックの測定値

  • ヘッドエンド SR-TE ポリシートラフィックの設定値

LCM がこれらのトラフィック統計を受信していることを確認するには、次の手順を実行します。

  • トラフィックをモニターするデバイス（ヘッドエンドデバイスを含む）で SNMP を有効にします。このタスクの詳細については、「Configuring SNMP Support」を参照してください。gNMI は、トラフィック測定値を収集するためのオプションでもあることに注意してください。

  • SNMP 対応デバイスがすべて Crosswork Data Gateway から到達可能であることを確認します。このタスクの詳細については、「Check Connectivity to the Destination」を参照してください。

  • SR ポリシーに厳密な SID ラベルを使用するようにヘッドエンドデバイスを設定します。このタスクを実行するには、次の手順を実行します。

    1. ヘッドエンドデバイスでセグメントルーティングを有効にし、セグメント ルーティング グローバル ブロック（SRGB）とセグメント ルーティング ローカル ブロック（SRLB）の範囲を設定します。次に例を示します。
      segment-routing
 mpls
  global-block 16000 23999
  node-msd 16
 !
 srlb 15000 15999
    2. 厳密な SID ラベルを使用するように SR ポリシー候補パスを設定します。明示的なパスまたは制約付きのダイナミックパスのいずれかを使用できます。次に例を示します。
      segment-routing
 traffic-eng
  policy COLOR-100-TO-10.0.0.1
   color 100 end-point ipv4 10.0.0.1
   candidate-paths
    preference 100
     explicit segment-list SL1
    !
    preference 200
     dynamic
      constraints
       affinity include-any RED BLUE
       sid-algorithm strict-spf
      !
     !
    !
   !
  !
 !
!
segment-list SL1
 index 10 mpls label 16001 node 10.0.0.2 strict
 index 20 mpls label 16002 node 10.0.0.3 strict
 index 30 mpls label 16003 node 10.0.0.4 strict
!
    3. バインディング SID と自動ルーティング アナウンス オプションを使用して、SR ポリシーヘッドエンドの動作を設定します。次に例を示します。
      
!segment-routing
traffic-eng
pcc
profile 1
autoroute
include ipv4 all
force-sr-include
!
!
!
!

輻輳緩和要件

ヘッドエンドデバイスは、autoroute のステアリングで PCE によって開始された SR-TE ポリシーをサポートする必要があります。ただし、ヘッドエンドデバイスが Cisco NCS デバイスであり、ネットワークに L2VPN トラフィックがある場合、LCM は機能しません。

autoroute を使用して SR-TE ポリシーへのトラフィックステアリングを有効にするには、force-sr-iinclude を使用してデバイスを設定する必要があります。次に例を示します。 
segment-routing traffic-eng pcc profile ID autoroute force-sr-include

このコマンドの ID パラメータは、PCE がプロビジョニングした SR-TE ポリシーに関連付けられた PCC プロファイルを識別します。ID 値には 1 ～ 65,535 の任意の整数を指定できますが、PCE がポリシーをインスタンス化するために使用するプロファイル ID と一致させる必要があります。一致しない場合、ポリシーはアクティブ化されません。たとえば、PCE がプロファイル ID 10 のポリシーをプロビジョニングするとします。そのポリシーの autoroute アナウンスを有効にするには、ヘッドエンドルータで segment-routing traffic-eng pcc profile 10 autoroute force-sr-include を設定する必要があります。詳細については、『Segment Routing Configuration Guide, Cisco IOS XE 17 (Cisco ASR 920 Series)』、『COE-PCE Initiated SR Policy with OSPF and IS-IS SR-TE Autoroute Announce』を参照してください。


（注）  

PCC プロファイルで設定された ID は、[LCM設定（LCM Configuration）] ページで設定された [プロファイルID（Profile ID）] オプションと一致する必要があります。

ヘッドエンドデバイスは、複数のパラレル SR-TE ポリシー全体で等コストマルチパス（ECMP）をサポートする必要があります。ECMP を使用して、デバイスが SR-TE ポリシーをサポートできることを確認するには、デバイスで以下の状態になっていることを確認します。

  • SR-TE ポリシーのヘッドエンドルータとテールエンドルータのセグメント ルーティング グローバル ブロック（SRGB）と一致する SRGB を使用して、セグメントルーティングが有効化および設定されている。デバイスの SRGB 設定を確認するには、show segment-routing mpls state コマンドを使用します。

  • BGP-LS が有効になっていて、SR-TE ポリシーのヘッドエンドルータとテールエンドルータからリンクステート情報をアドバタイズして受信するように設定されている。BGP-LS ステータスを確認するには show bgp link-state link-state コマンドを使用し、デバイスのリンクステート情報を確認するには show bgp link-state link-state database コマンドを使用します。

  • ECMP が、フローに基づいて複数の等コストパス間でトラフィックをロードバランシングするように有効化および設定されている。ECMP ルートを確認するには show ip route コマンドを使用し、デバイスの ECMP ロードバランシング アルゴリズムを確認するには show ip cef コマンドを使用します。

これらの条件がすべて満たされている場合、デバイスは ECMP を使用して SR-TE ポリシーをサポートできます。

関連項目

SR-TE ポリシーを設定および確認する方法の詳細と例については、次を参照してください。

ステップ 1：LCM を有効にし、使用率しきい値を設定する

このステップでは、LCM を有効にし、グローバル使用率のしきい値を設定します。

手順

ステップ 1

メインメニューから、[トラフィックエンジニアリング（Traffic Engineering）] > [ローカル輻輳緩和（Local Congestion Mitigation）] > [Domain-ID] を選択し、[設定（Configuration）] をクリックします。

ステップ 2

[有効化（Enable）] スイッチを [True] に切り替え、希望するグローバル使用率しきい値を入力します。この事例では、しきい値を 80% に設定し、[モニターするインターフェイス（Interfaces to Monitor）] > [すべてのインターフェイス（All Interfaces）] オプションを選択します。各構成のその他の設定オプションに関する情報を表示するには、マウスを [i]（ヘルプアイコン）の上に合わせます。

図 4. 基本 LCM 設定

基本 LCM 設定

ステップ 3

[変更を確定（Commit Changes）] をクリックします。

（注）  

 

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

ステップ 4

個別のインターフェイスしきい値も定義できます。[インターフェイスのしきい値（Interface Thresholds）] ページに移動します（[トラフィックエンジニアリング（Traffic Engineering）] > [ローカル輻輳緩和（Local Congestion Mitigation）] > [Domain-ID] > > [インターフェイスのしきい値（Interface Thresholds）]）。インターフェイスを個別に追加したり、カスタムの使用率しきい値を持つノードとインターフェイスのリストを含む CSV ファイルをアップロードしたりできます。詳細については、「個別のインターフェイスしきい値の追加」を参照してください。

次の例を参照してください。インターフェイス GigabitEthernet0/0/0/1 を使用する cw-xrv54 の定義済みしきい値は 20% です。

（注）  

 

この例の使用率のしきい値は非常に低く、ラボ環境での使用に最適です。
図 5. カスタマイズされたインターフェイスのしきい値
カスタマイズされたインターフェイスのしきい値

ステップ 2 マップ上でリンクの輻輳を表示する

cw-xrv60 と cw-xrv62 間のリンクが輻輳しています。

手順

ステップ 1

メインメニューから、[サービスとトラフィックエンジニアリング（Services & Traffic Engineering）] > [トラフィックエンジニアリング（Traffic Engineering）] の順に選択します。

ステップ 2

リンクをクリックすると、使用率情報を含むリンクの詳細が表示されます。使用率が、GigabitEthernet0/0/0/5 インターフェイスのノード cw-xrv54 に対して 20% で定義されたカスタム LCM しきい値を超えています。

図 6. マップ上のリンクの輻輳
マップ上のリンクの輻輳

ステップ 3：[LCM運用ダッシュボード（LCM Operational Dashboard）] で TTE SR ポリシーの推奨事項を表示する

LCM が輻輳を検出し、それを軽減するための戦術ポリシーを計算しました。これらのポリシーをプレビューしてから、確定するかどうかを決定できます。

このシナリオでは、輻輳したデバイスは正常で、到達可能であり、Crosswork と同期しています。輻輳に加えて、デバイスがダウン、到達不能、または同期していない場合は、実行するアクションと実装するポリシーが異なります。

手順

ステップ 1

メインメニューから、[サービスとトラフィックエンジニアリング（Services & Traffic Engineering）] > [ローカルでの輻輳緩和（Local Congestion Mitigation）] を選択します。

輻輳が検出されると、ドメインには緊急度のタイプと利用可能な推奨事項が表示されます。疑問符アイコンをクリックすると、緊急度のタイプと、最新の推奨事項が提示された時期に関する詳細が表示されます。

図 7. 検出された輻輳と LCM の推奨事項
検出された輻輳と LCM の推奨事項

ステップ 2

[運用ダッシュボード（Operational Dashboard）] を開きます（[サービスとトラフィックエンジニアリング（Services & Traffic Engineering）] > [ローカルでの輻輳緩和（Local Congestion Mitigation）] > [ドメインID（Domain-ID）] > [...]> [運用ダッシュボード（Operational Dashboard）]）。

cw-xrv54 の使用率が 20% を超えていて、29.46% であることがダッシュボードに表示されます。[推奨処置（Recommended Action）] 列では、LCM により、インターフェイスの輻輳に対処するために TTE ポリシーのソリューションセット（[推奨処置（Recommended action）]：[セットの作成（Create set）]）を展開することが推奨されています。

ステップ 3

TTE ポリシーをコミットする前に、各 TTE ポリシー ソリューション セットの展開をプレビューできます。[アクション（Actions）] 列で をクリックし、[解決策のプレビュー（Preview Solution）] を選択します。

図 8. [運用ダッシュボード（Operational Dashboard）]：[ソリューションのプレビュー（preview solution）]
[運用ダッシュボード（Operational Dashboard）]：[ソリューションのプレビュー（Preview Solution）]

各 TTE ポリシーのノード、インターフェイス、および推奨アクションがウィンドウに表示されます。[プレビュー（Preview）] ウィンドウから、個々の TTE ポリシーを選択し、トポロジマップで通常行っているように、さまざまな側面と情報を表示できます。各ポリシーを展開して、個々のセグメントを表示できます。ネットワークへの潜在的な影響を検討してから、LCM が推奨するバイパスポリシーを展開するかどうかを決定できます。

次の図は、ノード cw-xrv54 の推奨 TTE ポリシーを示しています。

図 9. 推奨 TTE ポリシーのプレビュー
推奨 TTE ポリシーのプレビュー

ステップ 4

マップ上で推奨される TTE ポリシーを確認したら、[運用ダッシュボード（Operational dashboard）] に戻り、[すべて確定（Commit All）] をクリックします。LCM の [ステータス（Status）] 列が [緩和中（Mitigating）] に変化します。

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

図 10. 運用ダッシュボード（Operational dashboard）
運用ダッシュボード（Operational dashboard）

ステップ 4：TTE SR ポリシーの展開を検証する

TTE SR ポリシーの展開を検証するには、次の手順に従います。

手順

ステップ 1

[運用ダッシュボード（Operational dashboard）] が表示されている状態で、ユーザーインターフェイスの右上にある 通知アイコン をクリックして [アラーム（Alarms）] ウィンドウを開き、[イベント（Events）] タブを選択します。これらの 2 つのタブを使用して、LCM アラームとイベントをモニターできます。[イベント（Events）] タブには、LCM の推奨事項、コミットアクション、および例外のイベントが表示されます。

Crosswork は、ユーザーが有効にしたポリシーと機能に基づいて検出されたネットワークイベントを報告します。たとえば、リンクがドロップしたことで SR-TE ポリシーがダウンした場合や、LCM が輻輳を検出した場合は、UI にイベントが表示されます。

ステップ 2

[運用ダッシュボード（Operational dashboard）] に戻り、すべての TTE ポリシー ソリューション セットの LCM の状態が [緩和済み（Mitigated）] に変化したことを確認します。

（注）  

 

LCM の状態が変化するまでに、SNMP パターンの 2 倍の時間がかかることがあります。

ステップ 3

トポロジマップを表示して、TTE ポリシーの展開を確認します。[アクション（Actions）] 列の をクリックし、[展開されたポリシーを表示（View Deployed Policies）] を選択します。展開されたポリシーは、トポロジマップ内で強調表示されます。他のすべてのポリシーは淡色表示されます。

ステップ 5：LCM の推奨に従って TTE SR ポリシーを削除する

しばらくすると、展開された TTE SR ポリシーが不要になる場合があります。これは、LCM によって開始された TTE ポリシーがなくても、使用率がしきい値を下回り続ける状況が続く場合に発生します。この場合、LCM は TTE SR ポリシーセットを削除するための新しい推奨処置を生成します。

LCM 推奨時に TTE SR ポリシーを削除するには、次の手順に従います。

手順

ステップ 1

必要に応じて、トポロジマップを表示し、[アクション（Actions）] 列の をクリックします。[展開されたポリシーの表示（View deployed policies）] を選択します。

ステップ 2

以前に展開された TTE SR ポリシーを削除するには、[すべて確定（Commit all）] をクリックします。

ステップ 3

トポロジマップと [SRポリシー（SR Policy）] テーブルを表示して、削除を確認します。

LCM シナリオ：まとめと結論

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

シナリオ：CS-SR ポリシーを使用して帯域幅を予約する

このシナリオでは、回線型セグメント ルーティング トラフィック エンジニアリング（CS-SR または CS SR-TE）ポリシーを有効にし、帯域幅予約パラメータを設定してから、CS-SR ポリシーを設定し、トポロジマップ上で可視化します。計算されたアクティブ（現行）および保護された（保護）パスを含むポリシーの詳細を検査します。

このシナリオの例では、次のトポロジを使用しています。

デフォルトのトポロジマップ

NCS1 ノードと NCS3 ノード間のアクティブな帯域幅予約パスに障害が発生した場合に何が起こるかを観察します。その後、障害が発生したパスを再度最適化します。

仮定と前提条件

次のセクションでは、各 CS-SR ポリシーで設定されたポリシー属性値の要件と制約、およびパスの復帰時に従う処理ロジックなど、適切な CS-SR 動作の高レベルの要件を示します。

次の項で説明する制約に加えて、

  • Crosswork Circuit Style Manager（CSM）機能パックは、Crosswork Network Controller Essentials の機能です。ライセンスされたすべての機能を、90 日間のトライアル期間中に使用できます。トライアル期間の後、CSM を引き続き使用するには、Crosswork Network Controller Optimization Engine のライセンスが必要です。

  • 回線型ポリシー設定は、Crosswork Network Controller 5.0 で導入されました。これを使用するには、デバイスに Cisco IOS-XR パス計算クライアント（PCC）のバージョン 7.9.1（またはそれ以降）をインストールする必要があります。以前のバージョンの CNC を IOS-XR バージョン 7.7.1 以前で使用していた場合は、CS-SR ポリシーを設定する前にバージョン 7.9.1 以降にアップグレードしてください。

  • Crosswork Network Controller で CSM を使用する場合、UI ナビゲーションは [トラフィックエンジニアリングとサービス（Traffic Engineering & Services）] から開始されます。Crosswork Network Controller Optimization Engine で CSM を使用する場合、ナビゲーションは [トラフィックエンジニアリング（Traffic Engineering）] から開始されます。

CS ポリシー属性の制約

このシナリオでは、ノード NCS1 とノード NCS 3 の間に CS ポリシーを作成します。ポリシーは次の設定と制約を使用します。

  • PolicyName：NCS1-NCS3

  • ヘッドエンドデバイス：NCS1

  • ヘッドエンド IP アドレス：192.168.20.4

  • テールエンドデバイス：NCS3

  • テールエンド IP アドレス：192.168.20.14

  • [Color-choice]：1000

  • [帯域幅（Bandwidth）]：10000

  • path-protection：有効

  • disjoint-path：有効

  • disjoint-path forward-path タイプ：リンク

  • disjoint-path forward-path group-id：531

  • disjoint-path reverse-path タイプ：リンク

  • disjoint-path reverse-path group-id：5311

  • performance-measurement：有効。

  • performance-measurement profile-type：活性状態

  • performance-measurement liveness-detection：有効

  • performance-measurement プロファイル：CS-active

  • working-path：有効

  • working-path 設定：100

  • working-path dynamic-path：有効

  • working-path dynamic-path pce：有効

  • working-path dynamic-path メトリックタイプ：igp

  • working-path dynamic-path bidirectional-association-choice：有効

  • working-path dynamic-path bidirectional-association-id：230

  • working-path 動的制約セグメント：有効

  • working-path 制約セグメント保護：unprotected-only

  • protect-path：有効

  • protect-path 設定：100

  • protect-path dynamic-path：有効

  • protect-path dynamic-path pce：有効

  • protect-path dynamic-path メトリックタイプ：igp

  • protect-path dynamic-path bidirectional-association-choice：有効

  • protect-path dynamic-path bidirectional-association-id：231

  • protect-path 動的制約セグメント：有効

  • protect-path 制約セグメント保護：unprotected-only

  • restore-path：有効

  • restore-path 設定：100

  • restore-path dynamic-path：有効

  • restore-path dynamic-path pce：有効

  • restore-path dynamic-path メトリックタイプ：igp

  • restore-path dynamic-path bidirectional-association-choice：有効

  • restore-path dynamic-path bidirectional-association-id：232

  • restore-path 動的制約セグメント：有効

  • restore-path 制約セグメント保護：unprotected-only

次の表に、ポリシーを作成するときに選択できるすべてのオプションを示します。次の表に記載されている属性が制約として機能することを理解することが重要です。各属性が、回線型パスのホップの計算方法を制御するために Cisco Crosswork で使用される設定の要素に対応します。各値で、パスの必須プロパティを指定するか、そのパスの可能な選択肢を除外するため、各値は事実上パス計算や最適化の制約になります。

満たす必要がある依存関係と、許可されない組み合わせがあります。このような問題が発生すると、システムから警告が表示されます。提供するサービスのタイプに一致するサービスをネットワークでプロビジョニングする方法を試して学習することをお勧めします。

表 1. サポートされる回線型 SR-TE ポリシーの属性値と制約

属性

説明

ポリシーのパス保護

パス保護の制約は、回線型 SR-TE ポリシーの両側に必要です。

帯域幅の制約

帯域幅の制約は必須であり、回線型 SR-TE ポリシーの両側で同じである必要があります。帯域幅の変更は、既存のポリシーに対して実行でき、次のような効果があります。

  • 両側で新しい帯域幅を設定すると、Crosswork によりパスが評価されますが、パスは再計算されません。

  • 新しい帯域幅の方が高い場合、Crosswork が既存のパスをチェックして十分なリソースを確保します。現在委任されているすべてのパスが新しい帯域幅に対応できるとします。この場合、Crosswork から新しい帯域幅値を持つ同じパスが返され、パス計算クライアント（PCC）が成功したことが示されます。現在のパスのいずれかが新しい帯域幅に対応できない場合、パスが失敗したことを示す古い帯域幅値が返されます。帯域幅が再度変更されない限り、再評価は行われません。

  • 帯域幅の方が低い場合、Crosswork が新しい帯域幅値を使用して同じパスを返し、成功したことが PCC に示されます。

ポリシーの詳細を表示すると、ユーザーインターフェイスの各候補パスの下に要求された帯域幅と予約済みの帯域幅の両方が表示されます。各値は、要求された帯域幅が増加し、1 つ以上のパスで使用可能な CS プール帯域幅が不足している場合は異なる可能性があります。

候補パスとロール

現用パスは、優先順位が最も高い候補（CP）パスとして定義されます。

保護パスは、優先順位が 2 番目に高い CP として定義されます。

復元パスは、優先順位が最も低い CP として定義されます。ヘッドエンドには backup-inligible が設定されている必要があります。

各方向で同じロールの CP については、CP の優先順位が同じである必要があります。

双方向

すべてのパスを相互ルーティングとして設定する必要があります。

両側にある同じロールのパスには、グローバルに一意の同じ双方向アソシエーション ID が必要です。

分離

同じ PCC 上の現用パスと保護パスは、同じ分離アソシエーション ID と分離タイプを使用する分離制約で設定する必要があります。

ある方向の現用パスと保護パスのペアの分離アソシエーション ID は、反対方向の対応するペアと比較して一意である必要があります。

ノードおよびリンク分離タイプのみがサポートされています。分離タイプは、同じポリシーの両方向で同じである必要があります。

復元パスには分離制約を設定できません。

Crosswork では厳密なフォールバック動作に従い、すべての現用パスと保護パスの分離が計算されます。つまり、ノードタイプの分離が設定されていて、使用可能なパスがない場合、Crosswork では制限の緩いリンクタイプの分離パスは自動的に計算されません。

メトリック タイプ

TE、IGP、および遅延メトリックタイプのみがサポートされています。使用されるメトリックタイプは、両方向の現用パス、保護パス、および復元パスで一致する必要があります。

セグメントの制約

すべての現用パス、保護パス、および復元パスには、次のセグメントの制約が必要です。

  • protection unprotected-only

  • adjacency-sid-only

リンク障害が発生しても永続性を確保するには、回線型ポリシーで使用可能なすべてのインターフェイスで静的隣接関係 SID を設定します。

サポートされているポリシーの変更

以前に委任された運用上「アップ」の回線型 SR-TE ポリシーでは、次の制約が変更される可能性があります。

  • メトリックタイプ

  • 分離タイプ

  • MSD

  • アフィニティ

設定の変更がすべての CP と両方の PCC で一貫すると（たとえば、すべての CP と両側の新しいメトリックタイプを同じにする）、Crosswork が再計算を開始し、現用パス、保護パス、および復元パスが新しくなります。

同じ PCC 上のパス間または PCC 間で設定が同期されていない過渡期には、パス更新は PCC に送信されません。

パス計算

Crosswork は、完全な双方向のパス保護された一連の候補パス（両側の現用パスと保護パスを含む）が委任されて初めて、回線型ポリシーのパスを計算します。

Crosswork は、現用パスと保護パスがダウンして初めて復元パスを計算します。SR 回線型マネージャ機能パック設定インターフェイスには、復元パスが両側から委任されてから、パスが計算されるまで待機する時間を制御する設定可能な遅延タイマーがあります。この遅延により、トポロジと SR ポリシーの状態変更によって復元パスの委任がトリガーされた場合、それらの変更が Crosswork に完全に伝達されます。

パス計算は、エリア内/エリア間、レベル内/レベル間および IGP ドメイン内/IGP ドメイン間（同じ AS）でサポートされています。

復帰動作

復帰動作は、保護パスと復元パスの WTR ロックタイマーオプションの設定によって制御されます（現用パスには関係ありません）。

  • ロックなし設定：デフォルトの 5 分間のロック後に復帰

  • 期間の指定がないロック：復帰なし

  • ロック期間 <value>：指定した秒数後に復帰

サポートされていない CS ポリシーのオプション

次の表に、このバージョンの CSM でサポートされていない CS ポリシーのオプション、属性、および制約を示します。

表 2. サポートされていない回線型 SR-TE ポリシーのオプション

属性

説明

サポートされていない設定

次の設定はサポートされていません。

  • メトリックバウンド

  • SID-Algo の制約

  • 部分的なリカバリは 7.8.x ではサポートされていません。

  • 高可用性ペアの PCE 間の状態同期設定。これらは、回線型 SR-TE ポリシーでは必要ありません。この機能を使用すると、パフォーマンスが低下する可能性があります。

  • 色は同じでエンドポイント IP が異なる同じノード間の複数の回線型 SR-TE ポリシー。

サポートされていないポリシーの変更

以前に委任され、運用上「アップ」の回線型 SR-TE ポリシーに対する次の設定変更はサポートされていません。

  • CP 優先順位

  • 分離アソシエーション ID

  • 双方向アソシエーション ID

既存のポリシーに関するこれらの設定を変更するには、まず両側でポリシーをシャットダウンしてから変更を加え（整合性の観点から前述の制限に準拠）、ポリシーを「no shut」にする必要があります。

サポートされていないパス計算

自動再最適化は、トポロジ、LSP の状態、または定期的なイベントの変更に基づくパスではサポートされません。パス計算は AS 間ではサポートされていません。

パスの復帰ロジック

パスの復帰は、現用パス、保護パス、復帰パスの初期状態と、各パスに影響するイベントによって異なります。次の表のシナリオに、一般的な復帰動作の例を示します。

表 3. パスの復帰のシナリオ

初期状態

イベント

動作

現用パスがダウン、保護パスがアップ/アクティブ

現用パスが復旧する

  1. 現用パスがアップ/スタンバイ状態に回復します。

  2. WTR タイマーが切れた後、各 PCC によって現用パスがアクティブに移行します。

  3. 保護パスがアップ/スタンバイに移行します。

現用パスがダウン、保護パスがダウン、復帰パスがアップ/アクティブ

現用パスが復旧し、保護パスが復旧する

  1. 現用パスが回復し、アップ/アクティブになります。

  2. 復帰パスが削除されました

  3. 保護パスが回復し、アップ/スタンバイになります。

現用パスがダウン、保護パスがダウン、復帰パスがアップ/アクティブ

保護パスが復旧し、現用パスが復旧する

サイド A：現用パス障害はローカル障害です（SegList の最初の Adj SID が無効です）。

  1. 保護パスが回復し、アップ/アクティブになります。

  2. 復元パスが削除されました。

  3. 現用パスが回復し、アップ/スタンバイになります。

  4. WTR タイマーが切れた後、各 PCC によって現用パスがアクティブに移行し、保護パスがアップ/スタンバイに移行します。

サイド Z：現用パス障害はリモート詳細です（SegList の最初の Adj SID が有効）。

  1. 保護パスは回復しますが、起動せず、復帰パスはアップ/アクティブのままです。

  2. 現用パスが回復し、アップ/アクティブになります。

  3. 復帰パスが削除されました。

  4. 保護パスがアップ/スタンバイになります。

パス障害が発生するとどうなりますか。

Cisco Crosswork は、完全な双方向のパス保護された一連の候補パスが委任されて初めて、CS ポリシーのパスを計算します。パスが「障害」と見なされるのには、さまざまな理由があります。たとえば、ネットワーク内の他の場所での輻輳が原因でワークロードが一時的に変化した場合や、パスが期待される帯域幅を満たさない状態が発生した場合などです。原因に関係なく、これらの種類の障害では 3 種類のパスが使用されます。Crosswork は、優先順位の設定に従って、必要に応じてそれらをアクティブにします。

  • 現用：優先順位の値が最も高いパスです。Crosswork は常に、アクティブパスとして最も優先順位の高い動作中（動作状態がアップ）パスを維持しようとします。

  • 保護：優先順位が 2 番目に高いパスです。現用パスがダウンすると、（優先順位値が低い）保護パスがアクティブになります。現用パスが回復しても、デフォルトのロック期間が経過するまで、保護パスはアクティブのままであり、経過した後で現用パスがアクティブになります。

  • 復元：優先順位が最も低いパスです。Crosswork は、現用パスと保護パスがダウンした場合にのみ復元パスを計算します。復元パスが委任された後、パスが計算されるまで待機する時間を制御できます。この遅延により、トポロジとポリシーの状態の変更がネットワーク全体に完全に伝播され、Crosswork がテレメトリを収集および分析してネットワークの正常性を判断できるようになります。

障害に効果的に対応し、現用パスから保護パスへの切り替えを実行するために、パフォーマンス測定（PM）を CS ポリシーの一部として設定できます。詳細については、ステップ 4：インポートを使用して 回線型 SR-TE ポリシーを設定するを参照してください。

次の画像は、例の CS ポリシーの現用パスと保護パスが動作していることを示しています。アクティブなパスは、[候補パス（Candidate Path）] リストの [状態（State）] 列のパスの横に表示される「A」アイコンで示されます。

図 11. 初期候補パス：現用パスがアクティブ
初期候補パス：現用パスがアクティブ

現用パスのパフォーマンスが期待値を下回った場合、保護パスがすぐにアクティブになります（通常は 50 ミリ秒未満）。

図 12. 保護パスがアクティブになる
保護パスがアクティブになる

現用パスが復旧すると、保護パスが再び「保護」のロールに戻り、現用パス（優先順位 100）が再度アクティブになります。

現用パスと保護パスの両方がダウンした場合、Crosswork によって復元パスが計算され、アクティブなパスになります。復元パスの最も低い優先順位値は 10 です。復元パスは特定の場合にのみ表示されます。現用パスまたは保護パスが再び動作可能になると、Crosswork によりアクティブにされ、復元パスはトポロジマップおよび候補パスリストから消えます。

図 13. 復元パスがアクティブになる
復元パスがアクティブになる

ステップ 1：回線型マネージャを有効化する

トポロジマップで 回線型 SR-TE ポリシーを管理および可視化するには、まず SR 回線型マネージャ（CSM）を有効にし、帯域幅予約設定を行う必要があります。これらの設定を定義するとすぐに、CSM は、要求された CSM 帯域幅としきい値の設定、および 回線型 SR-TE ポリシーで定義された制約を監視しながら、2 つのノード間の最適な双方向フェールオーバーパスを計算します。次の手順は、これを行う方法を示しています。

CSM は、すべてのインターフェイスで予約済み帯域幅の合計がネットワーク全体のリソースプール以下になるようにします。すべてのインターフェイスの合計使用率が設定したしきい値を超えると、CSM はしきい値超過アラームを生成します。

組織の実装に適した 回線型 SR-TE 帯域幅プールとしきい値の設定を見積もるのに役立つように、帯域幅プールサイズまたはプールサイズとアラームしきい値の両方を超えるポリシーを CSM がどのように処理するかを示す 2 つの例を示します。このシナリオでは、これらの例のいずれかを入力するか、実際の実装で超過する可能性が低い設定を選択できます。

CSM を有効にした後、回線型 SR-TE ポリシー設定を作成する必要があります。回線型 SR-TE ポリシーを作成するには、次のいずれかの方法を使用できます。このシナリオでは、毎回同じポリシーを作成しますが、ニーズに最適な方法を決定できるように、各方法について説明します。

手順

ステップ 1

メインメニューから、[サービスとトラフィックエンジニアリング（Services & Traffic Engineering）] > [回線型SR-TE（Circuit Style SR-TE）] > [設定（Configuration）] > [基本（Basic）]の順に選択します。

ステップ 2

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

図 14. 基本回線型 SR-TE 設定
基本回線型 SR-TE 設定

ステップ 3

次の表の説明に従って、必要な帯域幅プールサイズとしきい値情報を入力します。以下の例も参照し、いずれかを選択して入力します。

フィールド 説明

リンク CS BW プールサイズ（Link CS BW Pool Size）

回線型 SR-TE ポリシー用に予約可能な各リンクの帯域幅の割合。

リンク CS BW 最小しきい値（Link CS BW Min Threshold）

Crosswork でしきい値超過イベント通知が生成されるリンク CS BW プール使用率の割合。

ステップ 4

[変更を確定（Commit Changes）] をクリックして、基本設定を保存します。

ステップ 5

（オプション）：[詳細（Advanced）] タブをクリックして、追加の CS-SR 設定値を表示します。

図 15. 回線型 SR-TE 設定：[詳細（Advanced）] タブ
回線型 SR-TE 設定：[詳細（Advanced）] タブ

  1. 次の表の説明に従って、[詳細（Advanced）] タブの値を変更します。

    フィールド 説明

    検証間隔（Validation Interval）

    これは、委任されていないポリシー用に予約されている帯域幅が 回線型 SR-TE ポリシー帯域幅プールに返される前に、CSM が待機する間隔です。

    タイムアウト

    期間 CSM は、しきい値超過アラームを生成する前に委任要求を待機します。

    委任の復元の遅延（Restore Delegation Delay）

    CSM が復元パスの委任を処理する前に一時停止する期間。

    デバッグオプティマイザ

    スイッチを [True] に切り替えて、すべての CS-SR ポリシーのデバッグオプティマイザをオンにします。デバッグオプティマイザは、指定した最大ファイル数までルートを計算するたびに、ログファイルを Crosswork ファイルシステムに書き込みます。

    デバッグ最適化最大ファイル数

    デバッグオプティマイザが書き込むログファイルの最大数を入力します。最大数に達すると、オプティマイザは既存のファイルを上書きします。

  2. 詳細設定値の入力が完了したら、[変更を確定（Commit Changes）] をクリックして設定を保存します。

例

例：帯域幅使用率が定義されたしきい値を超えている場合

この例では、予約済み帯域幅の設定が次のようになっているとします。

  • 帯域幅プールサイズ：10%

  • 帯域幅プールのしきい値：1%

2 つのノードに 10 Gbps イーサネット インターフェイスがあり、帯域幅プールサイズは 1 Gbps で、アラームしきい値は 100 Mbps に設定されています。

  1. ノード 5501-02 からノード 5501-01（r02 - r01）へ接続する CS ポリシーを、100 Mbps の帯域幅で作成します。

    図 16. CS-SR ポリシー 10 Mbps アップ
    CS-SR ポリシー 10 Mbps アップ

  2. その後、ポリシーに要求される帯域幅は 500 Mbps に増加します。更新された CS ポリシーが作成され、運用状態になります（[運用状態アップ（Oper State Up）]）。

    図 17. CS-SR ポリシー 500 Mbps アップ
    CS-SR ポリシー 500 Mbps アップ

  3. 更新されたポリシーでの 500 Mbps の帯域幅使用率が設定された帯域幅しきい値（100 Mbps）を超えると、Crosswork はアラートをトリガーします。

    図 18. しきい値アラート
    しきい値アラート

例：帯域幅プールサイズと使用率を超えた場合

この例では、予約済み帯域幅の設定が次のようになっているとします。

  • 帯域幅プールサイズ：10%

  • 帯域幅プールのしきい値：10%

10 Gbps イーサネット インターフェイスの帯域幅プールサイズは 1 Gbps で、アラームしきい値は 100 Mbps です。

  1. ノード 5501-02 からノード 5501-01（r02 - r01）への既存の CS-SR ポリシーでは、500 Mbps の帯域幅が使用されます。

  2. その後、ノード 5501-02 からノード 5501-01、5501-2（r02 - r01 - r2）へのパスで 750 Mbps の帯域幅を必要とする新しいポリシーが要求されます。既存のポリシーとこの新しいポリシーの合計が帯域幅プールサイズとアラームしきい値の 1 Gbps（750 Mbps + 500 Mbps = 1250 Mbps）を超えるため、次の動作が発生します。

    • 新しい CS-SR ポリシー r02- r01- r2 が作成されましたが、運用状態ではありません（[運用状態ダウン（Oper State Down）]）。

      図 19. CS-SR ポリシーが帯域幅プールサイズを超過
      CS-SR ポリシーが帯域幅プールサイズを超過

    • アラートがトリガーされます。

      図 20. しきい値アラート
      しきい値アラート

  3. その後、CS-SR ポリシー（r02 - r01- r2）が更新され、10 Mbps のみが必要になります。次の動作が発生します。

    • 2 つのポリシーに必要な合計帯域幅（10 Mbps + 500 Mbps = 510 Mbps）は、帯域幅プールサイズ（1 Gbps）よりも少ないため、CS-SR ポリシー（r02 - r01 - r2）は、運用状態（[運用状態アップ（Oper State Up）]）になります。

      図 21. 更新された CS-SR ポリシーの運用状態
      更新された CS-SR ポリシーの運用状態

    • 更新されたポリシーでの帯域幅使用率（10 Mbps）が設定された帯域幅しきい値（1 Gbps）を下回っているため、アラートはクリアされます。

      図 22. クリアされたアラート
      クリアされたアラート

ステップ 2：デバイス CLI を使用して 回線型 SR-TE ポリシーを設定する

Cisco Crosswork を導入する前は、ほとんどのネットワークエンジニアは、適切なネットワーク オペレーティング システムの CLI コマンドを使用して、デバイス上で 回線型 SR-TE ポリシーを直接作成していました。シナリオのこのステップでは、シスコデバイスの CLI ポリシーの直接設定について説明します。これは、これらのポリシーを作成する正当な方法であるというだけの理由で示しているもので、この方法を使用して実装された設定が、このシナリオで示されている他の Crosswork ネイティブの方法による設定とどのように一致するかを確認できます。

Crosswork Network Controller のトポロジ検出は、デバイスに直接実装されている CS ポリシー設定を自動的に認識し、トポロジマップで視覚化するのに役立ちます。ただし、この方法にはいくつかの重要な欠点があります。まず、回線型 SR-TE ポリシーを適切に設定するために必要な CLI コマンドに精通している必要があります。さらに重要なことに、Crosswork はデバイスで直接設定された 回線型 SR-TE ポリシーを検出することはできますが、変更または削除することはできません。代わりに、追加またはインポートを使用する方法をお勧めします。これにより、Crosswork を使用して設定を管理および変更できます。 これらの方法の使用に関するヘルプについては、この手順をスキップし、「ステップ 3：追加を使用してポリシーを設定する」または「ステップ 4： インポートを使用してポリシーを設定する」に進んでください。

回線型 SR-TE ポリシーの設定には、接続先エンドポイント、要求された帯域幅の量、および双方向属性を含める必要があります。追加の要件や注目すべき制約については、仮定と前提条件を参照してください。

シスコデバイスで 回線型 SR-TE ポリシーを直接設定する場合は、設定にパフォーマンス測定（PM）活性状態プロファイルが含まれていることを確認してください。PM 活性状態プロファイルを使用すると、候補パスの活性状態が適切に検出され、パス保護が効果的に実行されます。パス計算クライアント（PCC）では最初の SID を過ぎると検証されないため、回線型 SR-TE ポリシー候補パス障害がセグメントリストの最初のホップの後に発生する場合、PM 活性状態がないとパス保護は実行されません。Crosswork は、ソフトウェアベースおよびハードウェアオフロードの PM 活性状態設定方法をサポートしています。PM 活性状態プロファイルと設定方法の背景については、「Configuring SR Policy Liveness Monitoring」を参照してください。

手順

ステップ 1

任意の方法でヘッドエンド デバイス コンソールにアクセスし、ログインします。

ステップ 2

該当する場合は、PM 設定用にデバイスのハードウェアモジュールを有効にします。

例:

hw-module profile offload 4

reload location all

ステップ 3

デバイスでパフォーマンス測定（PM）活性状態プロファイルを設定します。次に、ハードウェアオフロード設定を使用する例を示します。

例:

performance-measurement
 liveness-profile sr-policy name CS-active-path
  probe
   tx-interval 3300 
!
npu-offload enable   !! Required for hardware Offload only
  !
 !
 liveness-profile sr-policy name CS-protected-path
  probe
   tx-interval 3300
  !

npu-offload enable   !! Required for hardware Offload only
  !
 !
!

ステップ 4

回線型 SR-TE ポリシーを設定します。Crosswork の CSM 機能パックでポリシーを管理するには、示されているすべての設定エントリが必要です。ネットワーク（または PM 活性状態プロファイル）に合わせて適切に変更する必要があるエントリ値は、イタリック体で示されています。追加の要件や注目すべき制約については、仮定と前提条件を参照してください。

例:

segment-routing
 traffic-eng
  policy NCS1-NCS3

   performance-measurement
    liveness-detection
     liveness-profile backup name CS-protected      !! Name must match liveness profile defined for Protect path
     liveness-profile name CS-active               !! Name must match liveness profile defined for Active path
    !
   !
   bandwidth 10000
   color 1000 end-point ipv4 192.168.20.4
   path-protection
   ! Path protection is required on both ends of the candidate-paths
  ! Defining the Working path. Must have the highest CP preference
    preference 100
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
      disjoint-path group-id 3 type node
     !
     bidirectional
      co-routed
      association-id 230
 !
    ! Defining the Protect path. Must have second highest CP preference.
    preference 50
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
      disjoint-path group-id 3 type node
     !
     bidirectional
      co-routed
      association-id 231
     ! Defining the restore path. It must have both the lowest CP preference and backup-ineligible setting
    preference 10
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     backup-ineligible
     !

     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
     !
     bidirectional
      co-routed
      association-id 232
     !
    !
    !
    
     !
    !

   !
  !

 !
!

ステップ 3：追加を使用して 回線型 SR-TE ポリシーを設定する

Crosswork Network Controller の追加機能を使用して、任意の 2 つのノード間に 回線型 SR-TE ポリシーを作成できます。この方法は、Crosswork を使用して作成した 回線型 SR-TE ポリシーを編集または削除できるようにしたいユーザーにとって最も簡単です。

この方法では、回線型 SR-TE ポリシーを適切に設定するために必要な CLI コマンド属性に精通している必要はありません。ネットワーク全体でこれらのポリシーを標準化するのに役立つ、より高速な方法を使用する場合は、この手順をスキップし、「ステップ 4 インポートを使用してポリシーを設定する」の方法を使用します。

手順

ステップ 1

メインメニューから、[サービスとトラフィックエンジニアリング（Services and Traffic Engineering）] > [プロビジョニング（NSO）（Provisioning (NSO)）]を選択します。

ステップ 2

左側の [サービス/ポリシー（Services/Policies）] 列で、[SR-TE] > [回線型ポリシー（Circuit- Style Policy）]を選択します。Crosswork に [SR-TEの作成（Create SR-TE）] > [回線スタイルポリシー（Circuit Style Policy）] ウィンドウが表示されます。

ステップ 3

[追加（Add）] アイコン をクリックします。Crosswork に [SR-TEの作成（Create SR-TE）] > [回線スタイルポリシー（Circuit Style Policy）] ウィンドウが表示されます。

ステップ 4

このシナリオでは、NCS1-NCS3 という名前を使用します。[名前（Name）] フィールドに名前を入力し、[続行（Continue）] をクリックします。

ステップ 5

初めに、[SR-TEの作成（Create SR-TE）] > [回線型ポリシー（Circuit Style Policy）] の各フィールドに次のエントリを入力します。

  • [Name（名前）]：NCS1-NCS3

  • [Color-choice]：1000

  • [帯域幅（Bandwidth）]：10000

  • [path-protection]：チェックボックスをオンにします。

（注）  

 

ここに示す [color-choice] と帯域幅の値は例にすぎません。ネットワークでこの例に従うことにした場合は、まだ使用されていない [color-choice] の値と、CS ポリシー専用のパーセンテージ内で使用可能な帯域幅の値を使用します。

ステップ 6

次の表に示す 回線型 SR-TE ポリシーの制約と仕様を入力して、シナリオを続行します。[追加（Add）] 機能のユーザーインターフェイスは、ポリシーフィールドを関連するカテゴリにグループ化します。フィールドグループ名または右側の [>] アイコンをクリックしてカテゴリを展開し、その依存フィールドを表示します。

入力するデバイス名と IP アドレスは、ネットワーク上のデバイスと一致するように変更する必要があります。

表 4. 例：回線型 SR-TE policy ssing add

これを展開します。

これを指定するには、次の手順を実行します。

head-end

  • [デバイス（Device）]：NCS1 と入力します。

  • [Ip-address]：192.168.20.4 と入力します。

tail-end

  • [デバイス（Device）]：NCS3 と入力します。

  • [Ip-address]：192.168.20.14 と入力します。

disjoint-path

[disjoint-pathの有効化（Enable disjoint-path）] をクリックします。

disjoint-path > forward-path

  • [タイプ（Type）]：[リンク（Link）] を選択します。

  • [group-id]：531 と入力します。

disjoint-path > reverse-path

  • [タイプ（Type）]：[リンク（Link）] を選択します。

  • [group-id]：5311 と入力します。

performance-measurement

[performance-measurementの有効化（Enable performance-measurement）] をクリックします。

performance-measurement > Profile-type

[活性状態（liveness）] をクリックします。

performance-measurement > Profile-type > liveness-detection

[liveness-detectionの有効化（Enable liveness-detection）] をクリックします。次のアクションを実行します。

  • [プロファイル（Profile）]：CS-active と入力します。

  • [バックアップ（Backup）]：CS-protected と入力します。

working-path

[working-pathの有効化（Enable working-path）] をクリックします。次に、[dynamic-path] を選択します。

working path > dynamic

[dynamic-pathの有効化（Enable dynamic-path）] をクリックします。次のアクションを実行します。

  • [pce]：チェックボックスをオンにします。

  • [Metric-type]：[igp] を選択します

  • [Bidirectional-association-choice]：[bidirectional-association-id] を選択し、フィールドに 230 と入力します。

working path > dynamic > constraints > segments

[セグメントの有効化（Enable segment）] をクリックします。次に、[保護（Protection）] フィールドで、[unprotected-only] を選択します。

protect-path

[protect-pathの有効化（Enable protect-path）] をクリックします。次に、[dynamic-path] を選択します。

protect-path > dynamic

[dynamicの有効化（Enable dynamic）] をクリックします。次のアクションを実行します。

  • [pce]：チェックボックスをオンにします。

  • [Metric-type]：[igp] を選択します

  • [Bidirectional-association-choice]：[bidirectional-association-id] を選択し、フィールドに 231 と入力します。

protect-path > dynamic > constraints > segments

[セグメントの有効化（Enable segment）] をクリックします。次に、[保護（Protection）] フィールドで、[unprotected-only] を選択します。

restore-path

[restore-pathの有効化（Enable restore-path）] をクリックします。次に、[dynamic-path] を選択します。

restore-path > dynamic

[dynamic-pathの有効化（Enable dynamic-path）] をクリックします。次のアクションを実行します。

  • [pce]：チェックボックスをオンにします。

  • [Metric-type]：[igp] を選択します

  • [Bidirectional-association-choice]：[bidirectional-association-id] を選択し、フィールドに 232 と入力します。

restore-path > dynamic > constraints > segments

[セグメントの有効化（Enable segment）] をクリックします。次に、[保護（Protection）] フィールドで、[unprotected-only] を選択します。

ステップ 7

完了したら、[ドライラン（Dry Run）] をクリックして変更を検証し、保存します。Crosswork でポップアップウィンドウに変更が表示されます。

この例で説明されている要件と一致しない要件でサービスを設定する場合は、シスコのカスタマーエクスペリエンスにお問い合わせください。

ステップ 8

ポリシーをアクティブ化する準備ができたら、[変更を確定（Commit Changes）] をクリックします。

ステップ 4：インポートを使用して 回線型 SR-TE ポリシーを設定する

組織がすでに 回線型 SR-TE ポリシーを実装していて、より多くのネットワークデバイスに展開する場合は、Crosswork Network Controller のインポート機能を使用するのが最も簡単な方法です。インポートを使用してポリシー テンプレート ファイルを Crosswork からダウンロードできます。テンプレートファイルは JSON または XML 形式です。テンプレートを新しい名前で保存し、選択したポリシー値を挿入してから、変更したファイルをインポートできます。

インポート機能を使用すると、ネットワーク全体で 回線型 SR-TE ポリシーをすばやく標準化できます。同じテンプレートファイルを設定して、デバイスの複数のペア間で CS-SR ポリシーを確立できます。エンドポイント名とアドレス、および各回線に応じたその他の値のみを変更できます。

手順

ステップ 1

メインメニューから、[サービスとトラフィックエンジニアリング（Services and Traffic Engineering）] > [プロビジョニング（NSO）（Provisioning (NSO)）]を選択します。

ステップ 2

左側の [サービス/ポリシー（Services/Policies）] 列で、[SR-TE] > [回線型ポリシー（Circuit- Style Policy）]を選択します。

ステップ 3

[インポート（Import）] アイコン をクリックします。[サンプルJSONおよびXMLファイル（.zip）のダウンロード（Download sample JSON and XML files (.zip)）] リンクをクリックします。ダウンロードした ZIP ファイルには、回線型を含むすべての Crosswork サービスタイプのテンプレートが JSON および XML 形式で含まれています。

ステップ 4

samplePayload.zip を解凍し、CS-Policy.json および CS-Policy.xml テンプレートファイルを見つけます。

ステップ 5

任意の JSON または XML ファイルエディタを使用して、CS-Policy テンプレートファイルを開き、cs1-cs4 という名前で保存します。

ステップ 6

JSON テンプレートファイルを使用する場合は、次の例のように編集します。XML テンプレートを使用している場合は、次の手順に進みます。

例:

JSON の CS-SR ポリシー
{
  "name": "NCS1-NCS3",
  "head-end": {
    "device": "NCS1",
    "ip-address": "192.168.20.4"
  },
  "tail-end": {
    "device": "NCS3",
    "ip-address": "192.168.20.14"
},
  "color": 1000,
  "bandwidth": 10000,
  "disjoint-path": {
    "forward-path": {
      "type": "Link",
      "group-id": 531
    },
    "reverse-path": {
      "type": "Link",
      "group-id": 5311
    }
  },
  "performance-measurement": {
    "profile-type": "liveness",{
      "profile": "CS-active",
      "backup": "CS-protected"
    },
  },  
  "path-protection": {},
  "working-path": {
    "dynamic": {
      "constraints": {
        "segments": {
          "protection": "unprotected-only"
        }
      },
      "pce": {},
      "metric-type": "igp",
      "bidirectional-association-id": 230
    }
  },
  "protect-path": {
    "dynamic": {
      "constraints": {
        "segments": {
          "protection": "unprotected-only"
        }
      },
      "pce": {},
      "metric-type": "igp",
      "bidirectional-association-id": 231
    },
    "revertive": true
  },
  "restore-path": {
    "dynamic": {
      "constraints": {
        "segments": {
          "protection": "unprotected-only"
        }
      },
      "pce": {},
      "metric-type": "igp",
      "bidirectional-association-id": 232
    }
  }
}

ステップ 7

XML テンプレートファイルを使用している場合は、次の例のように編集します。

例:

XML の CS-SR ポリシー
<config xmlns="http://tail-f.com/ns/config/1.0">
  <cs-sr-te-policy xmlns="http://cisco.com/ns/nso/cfp/cisco-cs-sr-te-cfp">
    <name>NCS1-NCS3</name>
    <head-end>
      <device>cs1</device>
      <ip-address>192.168.20.4</ip-address>
    </head-end>
    <tail-end>
      <device>cs4<device>
      <ip-address>192.168.20.14<ip-address>
    <tail-end>
    <color>1000</color>
    <bandwidth>10000<bandwidth>
    <disjoint-path>
      <forward-path>
        <type>Link</type>
        <group-id>531</group-id>
      </forward-path>
      <reverse-path>
        <type>Link</type>
        <group-id>5311</group-id>
      </reverse-path>
    </disjoint-path>
    <performance-measurement>
      <profile-type>liveness
        <profile>CS-active</profile>
        <backup>CS-protected"</backup>
      </profile-type>
    </performance-measurement>
    <path-protection></path-protection>
    <working-path>
      <dynamic>
        <constraints>
          <segments>{
            <protection>unprotected-only</protection>
          </segments>{
        </constraints>{
          <pce></pce>       
          <metric-type>igp</metric-type>
          <bidirectional-association-id>230</bidirectional-association-id>
      </dynamic>
    </working-path>
    <protect-path>
      <dynamic>
        <constraints>
          <segments>
            <protection>unprotected-only</protection>
          </segments>
        </constraints>
        <pce></pce>       
        <metric-type>igp</metric-type>
        <bidirectional-association-id>231</bidirectional-association-id>
      </dynamic>
    </protect-path>
  <restore-path>
    <dynamic>
      <constraints>
        <segments>
          <protection>unprotected-only</protection>
          </segments>
        </constraints>
        <pce></pce>       
        <metric-type>igp</metric-type>
        <bidirectional-association-id>232</bidirectional-association-id>
      </dynamic>
    </restore-path>
  </cs-sr-te-policy>
</config>

ステップ 8

ファイルの編集が完了し、変更を保存したら、[サービスとトラフィックエンジニアリング（Services & Traffic Engineering）] > [プロビジョニング（Provisioning）] > [SR-TE] > [回線型ポリシー（Circuit- Style Policy）]に再度移動します。

ステップ 9

[インポート（Import）] アイコン を再度クリックします。[ファイル名（File Name）] フィールドに、変更したテンプレートファイルのパスとファイル名を入力するか、[参照（Browse）] をクリックしてファイルを見つけて選択します。次に [インポート（Import）] をクリックします。

ステップ 5：トポロジマップで 回線型 SR-TE ポリシーを表示する

次に、Crosswork を使用して NCS1-NCS3 回線型 SR-TE ポリシーを可視化し、マップ上で分離します。この手順をより現実的にし、1 つのポリシーのみに焦点を当てる方法を示すために、このシナリオでは、作成したポリシーだけでなく、複数のアクティブな 回線型 SR-TE ポリシーがあることを前提としています。回線型 SR-TE ポリシーの詳細（エンドポイント、帯域幅の制約、IGP メトリック、候補（アクティブ/現用および保護）パスなど）も表示します。

手順

ステップ 1

メインメニューから、[サービスとトラフィックエンジニアリング（Services & Traffic Engineering）] > [トラフィックエンジニアリング（Traffic Engineering）] > [SR-MPLS]の順に選択します。次に、[回線型（Circuit style）] をクリックします。

図 23. 回線型 SR-TE ポリシーの表示
回線型 SR-TE ポリシーの表示

ポリシーテーブルには、すべての 回線型 SR-TE ポリシーが一覧表示されます。

ステップ 2

[アクション（Actions）] 列で、いずれかの 回線型 SR-TE ポリシーに対して [回線型SR-TE（Circuit Style SR-TE）] > [詳細の表示（View Details）]の順にクリックします。

（注）  

 

デバイスで直接作成された 回線型 SR-TE ポリシーの設定は、編集または削除できません。


回線型 SR-TE ポリシーの詳細の表示

サイドパネルに [回線型ポリシーの詳細（Circuit Style Policy Details）] ウィンドウが表示されます。デフォルトでは、アクティブなパスがトポロジマップに表示され、トポロジマップに双方向パス（[双方向パス（Bi-Dir Path）] チェックボックスがオンの場合）が表示されます。[候補パス（Candidate Path）] リストには、アクティブ（現在トラフィックを受け取るパス）と保護パスが表示されます。


CS-SR ポリシーの詳細の概要

（注）  

 

帯域幅の制約値は、値が増え、すべてのアクティブおよび保護候補パスの要求を満たせる十分なリソースが存在しない場合、要求した帯域幅と異なる場合があります。

ステップ 3

候補パス設定の詳細を表示します。

  1. [回線型ポリシーの詳細（Circuit Style Policy Details）] ウィンドウでは、ドリルダウンして候補パスに関する詳細情報を表示できます。優先順位が最も高い動作中（動作状態がアップ）の候補パスは、常にアクティブなパスになります。この例では、保護パス（優先順位 50）が現在アクティブなパスであり、トポロジマップに表示されます。[状態（State）] の下に緑色の「A」アイコン付きで示され、現在動作中のアクティブなパスであることが明確に示されています。[すべて展開（Expand All）] をクリックして、両方のパスに関する詳細情報を表示します。


    トポロジマップ上の候補パス

    （注）  

     

    • 1 番目の優先パスは紫色のリンクで表示されます。

    • 2 番目の優先パスは青色のリンクで表示されます。

    • 3 番目の優先パスはピンク色のリンクで表示されます。
    UI を使用して 回線型 SR-TE ポリシーを設定した場合は、回線型 SR-TE ポリシーの設定を表示するオプションがあります。設定を表示するには、[設定ID（Config ID）] の横にあるリンクをクリックします。次に例を示します。
    候補パスの詳細の表示

ステップ 4

選択したポリシーのエンドポイント間の物理パスとメトリックを表示するには、[表示設定（Display Preferences）] アイコン をクリックして該当するメトリックをオンにし、[IGPパス（IGP path）] チェックボックスをオンにします。
IGP メトリック

ステップ 6：回線型 SR-TE ポリシーの帯域幅使用率を確認する

回線型 SR-TE を有効にするときに（ステップ 1：回線型マネージャを有効化するを参照）定義した予約済み帯域幅プールの設定が正しく設定されていることを確認できます。また、使用中またはまだ使用可能な帯域幅の量を確認することもできます。

手順

ステップ 1

メインメニューから、[サービスとトラフィックエンジニアリング（Services & Traffic Engineering）] > [トラフィックエンジニアリング（Traffic Engineering）] > [SR-MPLS]の順に選択します。次に、[SR-MPLS] 列で、[回線型（Circuit style）] をクリックします。[SRポリシー（SR Policy）] テーブルには、すべての CS SR ポリシーが一覧表示されます。

ステップ 2

[SRポリシー（SR Policy）] テーブルで、詳細を表示する参加デバイスの横にあるチェックボックスをオンにします。

ステップ 3

トポロジマップで、参加している 回線型 SR-TE ポリシーノードをクリックして、そのノードのデバイスの詳細を表示します。

ステップ 4

[デバイスの詳細（Device details）] ページで、[リンク（Links）] タブをクリックして、参加ノード上の CS-SR およびその他のリンクのリストを表示します。次に、詳細を表示するリンクをクリックします。[リンクの詳細（Link details）] リストには、リンク情報の [概要（Summary）] が表示されます。

ステップ 5

[リンクの詳細（Link details）] ページで、[トラフィックエンジニアリング（Traffic Engineering）] タブをクリックし、次に [全般（General）] タブをクリックします。[リンクの詳細（Link details）] リストには、リンクの詳細情報が表示されます。

回線型の帯域幅プールでは、予約済み帯域幅プールサイズ、現在使用されている帯域幅の量、および（回線型 SR-TE ポリシーに割り当てられている）まだ使用可能な帯域幅を確認できます。

この例では、予約済み帯域幅プールサイズを、NCS-3 および NCS1 に対して 800 Mbps と表示します。構成済みの設定は、帯域幅プールサイズの 80% として事前に定義されています。この回線のインターフェイスは 1 Gbps であるため、これらの 2 つのインターフェイスの帯域幅の 80% が 回線型 SR-TE によって正しく割り当てられていることを確認できます。

図 24.
CS-SR ポリシー帯域幅プール

ステップ 7：回線型 SR-TE パスの再計算をトリガーする

回線型ポリシーは本質的に静的です。つまり、パスが計算されると、Crosswork はそれらを自動的に再計算しません。ネットワークトポロジまたは動作ステータスの変更は、Crosswork が新しい状況に合わせて再計算して最適化する範囲で、以前に計算された現用パスと保護パスに影響を与える可能性があります。このステップでは、これらのタイプの変更に対応するためにパスを再最適化する方法を示します。

これらの場合に CSM が採用するロジックの詳細については、パス障害が発生するとどうなりますか。を参照してください。

手順

ステップ 1

メインメニューから、[サービスとトラフィックエンジニアリング（Services & Traffic Engineering）] > [トラフィックエンジニアリング（Traffic Engineering）] > [SR-MPLS]の順に選択し、[回線型（Circuit Style）] をクリックします。

図 25. [回線型の選択（Select Circuit Style）] タブ
[回線型の選択（Select Circuit Style）] タブ

ステップ 2

[SRポリシー（SR Policy）] テーブルには、アクティブな CS-SR ポリシーのそれぞれのステータスが表示されます。そのうちの 1 つは動作状態の [ダウン（down）] です。

ステップ 3

動作状態が [ダウン（Down）] である CS-SR TE ポリシーの横にある [アクション（Actions）] 列で、[その他（More）] アイコン > [詳細の表示（View details）] をクリックします。

Crosswork のサイドパネルに [回線型ポリシーの詳細（Circuit Style Policy Details）] ウィンドウが表示されます。デフォルトでは、アクティブなパスがトポロジマップに表示され、トポロジマップに双方向パス（トポロジマップの [表示（Show）] パネルの [双方向パス（Bi-Dir Path）] チェックボックスがオンである必要があります）が表示されます。サイドパネルの下部にある [候補パス（Candidate path）] リストには、アクティブ（現用）パスと保護パスが表示されます。

[概要（Summary）] パネルで、[詳細を表示（See more）] リンクをクリックして、利用可能な概要の詳細のタイプを詳しく確認します。[候補パス（Candidate Path）] リストには、アクティブパスと保護パスが表示されます。

ステップ 4

Crosswork でこれらのパスを再最適化するには、[回線型ポリシーの詳細（Circuit style policy details）] パネルの上部にある [その他（More）] アイコン をクリックし、[再最適化（Re-optimize）] を選択します。選択の確認を求めるプロンプトが表示されたら、[はい（Yes）] をクリックします。

まとめと結論

このシナリオでは、回線型セグメント ルーティング ポリシーを使用して、ネットワーク内の優先順位の高いサービスとトラフィック用に帯域幅を予約する方法を確認しました。CS-SR を使用すると、優先順位の高いトラフィックパスを手動で追跡および計算する必要がなくなりますが、それらのパスの計算方法を制御し、各パスの帯域幅使用率を最適化することもできます。これらのポリシーを使用して、帯域幅をこれらのサービス専用にすることができます。トラフィックの変化により、専用の「回線」パスに障害が発生すると、回線型ポリシーによって警告が表示され、必要に応じて再最適化できます。