Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

OSPFでセグメントルーティングトラフィック制御のための柔軟なアルゴリズムを設定する方法

柔軟なアルゴリズムにより、IGP単独でネットワーク上の制約ベースのパスを計算できるため、ネットワークコントローラを使用せずに、シンプルなトラフィック制御を行うことができます。本格的なセグメントルーティングを備えたコントローラを実装していないが、ネットワークでセグメントルーティングのメリットを享受したいネットワーク向けの軽量ソリューションです。

次のステップ

柔軟なアルゴリズムの設定の詳細については、OSPF User Guideを参照してください

セグメントルーティングのためのOSPFフレキシブルアルゴリズムの理解

Junos OS リリース 21.1R1 以降では、要件に基づいてさまざまなパラメーターとリンク制約を使用してパスを計算する柔軟なアルゴリズムを定義することで、ネットワークをシンスライスできます。例えば、IGPメトリックを最小化するパスを計算する柔軟なアルゴリズムを定義し、トラフィック制御メトリックに基づいてパスを計算する別の柔軟なアルゴリズムを定義して、ネットワークを別々のプレーンに分割することができます。この機能により、コントローラを持たないネットワークは、ネットワークコントローラを実際に実装することなく、セグメントルーティングを使用してトラフィック制御を設定することができます。プレフィックスSIDを使用して、パケットを制約ベースのパスに誘導することができます。デバイスからも削除されます 柔軟なアルゴリズムのためにプレフィックスSIDを設定できます。

IGPプロトコルは、リンクメトリックを使用して最適経路を計算します。しかし、最適なIGPパスが、特定のタイプのトラフィックに対して常に最適なパスであるとは限りません。そのため、最短のIGPメトリックに基づいて計算されたIGPが計算した最適なパスは、IGPメトリックに反映されないトラフィック要件のために、トラフィックエンジニアリングパスに置き換えられることがよくあります。通常、RSVP-TEまたはSR TEは、この制限を克服するために、追加のメトリックと制約に基づいてパスを計算するために使用されます。Junosは、IGPによって計算された元のパスに加えて、または元のパスの代替として、このようなパスを転送テーブルにインストールします。

柔軟なアルゴリズムを設定する利点

  • ネットワークのコアで使用できるセグメントルーティングトラフィック制御の軽量バージョンです。

  • ネットワークコントローラを設置しなくても、セグメントルーティングを使用してトラフィック制御を設定できます。

  • BGP-LSやスタティックパスを設定せずに、スライスごとに等価コストマルチパス(ECMP)とTI-LFAを活用します。

  • 同じ柔軟なアルゴリズム定義と制約計算を使用して、TI-LFA バックアップ パスを計算します。

  • RSVP や LDP を設定せずに、OSPFv2 のみを使用したセグメント ルーティング トラフィック制御を活用します。

  • 単一ラベルに基づいて制約付きプライマリパスをプロビジョニングする機能。

Flexible Algorithm Definition(FAD)とは?

柔軟なアルゴリズムにより、IGPは指定された制約に基づいて追加の最適パスを計算できるため、ネットワークコントローラを使用せずにシンプルなトラフィック制御を行うことができます。本格的なセグメントルーティングを備えたコントローラを実装していないが、ネットワークでセグメントルーティングのメリットを享受したいネットワーク向けの軽量ソリューションです。すべてのオペレーターは、要件に応じて個別の制約または色を定義できます。

柔軟なアルゴリズムを定義するには、[edit routing-options]階層レベルでflex-algorithm idステートメントを含めます。フレキシブル・アルゴリズム定義 (FAD) には、128 から 255 までの識別子が割り当てられます。この柔軟なアルゴリズムは、ネットワーク内の 1 つ以上のルーターで定義できます。柔軟なアルゴリズムにより、次のパラメータに基づいて最適経路が計算されます。

  • Calculation type- SPF と Strict SPF の 2 つの計算タイプ オプションを使用できます。FAD では、これらの計算タイプのいずれかを指定できます。トラフィック制御のショートカットなど、特定のローカルポリシーに基づいてデバイスのSPF計算に影響を与える場合は、SPF計算タイプを選択します。厳密なSPFを選択した場合、ローカルポリシーはSPFパスの選択に影響を与えることはできません。

  • Metric type- IGPメトリックまたはTEメトリックは、使用可能なメトリックタイプのオプションです。ネットワーク要件に応じて、FAD でこれらのメトリックタイプの 1 つを指定できます。特定のリンクに IGP メトリックを使用しない場合は、OSPFv2 がルートの計算に使用できる TE メトリックを設定できます。

  • Priority- 要件に従って FAD にプライオリティを割り当てることができ、OSPFv2 は割り当てられたプライオリティに基づいて、特定の FAD アドバタイズメントを別の FAD よりも優先します。

  • Set of Link constraints- [edit protocols mpls admin-groups]階層レベルで多くのプロトコルのadmin-groupsを設定して、個々のリンクに色を付けることができます。これらのadmin-groupsは、[edit routing-options flex-algorithm definition admin-groups] 階層レベルでinclude anyinclude-all、またはexcludeとして定義できます。

冗長性を確保し、競合を避けるために、少数のルーターでのみ柔軟なアルゴリズムを設定することをお勧めします。柔軟なアルゴリズム定義は、IGPで FAD sub-TLVsとしてアドバタイズされます。非常に大規模なネットワークでは、各柔軟なアルゴリズムが独自のパスを計算し、それを超えるとパフォーマンスの問題を引き起こす可能性があるため、8 を超える柔軟なアルゴリズム定義を設定することはお勧めしません。

デフォルトの FAD には、次のパラメーターがあります。

  • 計算タイプ: SPF

  • メトリックタイプ:IGP-Metric

  • 優先度:0

  • リンク制約: なし

手記:

ライブネットワークで、またはその場で柔軟なアルゴリズム定義を変更すると、すべてのノードが新しいパスに収束するまで、トラフィックが中断する可能性があります。

Junos OS 21.4R1以降、TEDでは「柔軟なアルゴリズム定義(FAD)」と「柔軟なアルゴリズムプレフィックスメトリック(FAPM)」をサポートし、BGP-LSでは対応する2つの新しいTLV「FAD TLV」と「FAPM TLV」を実装しています。FAD TLV の値には、Flex-Algorithm、Metric-Type、Calculation-Type、および Priority が含まれ、これらはすべてそれぞれ 1 バイトです。TLV には、0 個以上のサブ TLV が含まれている場合があります。5 つのサブ TLV とは、フレックス アルゴ除外任意のアフィニティ、フレックス アルゴ任意のアフィニティを含む、フレックス アルゴすべてのアフィニティを含む、フレックス アルゴ定義フラグ、フレックス アルゴ除外 SRLG です。

FAD TLV は、対応するノードが基礎となる IGP TLV またはサブ TLV に由来する場合にのみ、ノード NLRI の BGP-LS 属性に追加できます。ノードNLRIに関連付けられたBGP-LS属性には、ノードがアドバタイズしている各アルゴリズムのフレキシブルアルゴリズム定義に対応する1つ以上のFAD TLVが含まれる場合があります。

FAPM TLV の値には、Flex-Algorithm (1 バイト)、Reserved (3 バイト)、および Metric (4 バイト) が含まれます。FAPM TLV は、対応するノードがプレフィックスから発信された場合のみ、ノードから発信されたプレフィックス NLRI の BGP-LS 属性に追加できます。

Junos OS リリース 22.4R1 以降、エリア間プレフィックスに最適なエンドツーエンドのパスを許可するために、FAPM(柔軟なアルゴリズム プレフィックス メトリック)が定義されました。エリア境界ルーター (ABR) は、特定のフレキシブル アルゴリズム (フレックス アルゴ) で到達可能なエリア間のプレフィックスをアドバタイズする場合、FAPM を含める必要があります。プレフィックスが到達できない場合、ABR はエリア間で広告するときに、そのプレフィックスをフレックス アルゴに含めてはなりません。定義された FAPM は、エリア間サポートを提供します。

柔軟なアルゴリズムへの参加

要件に応じて、特定の柔軟なアルゴリズムに参加するように特定のルーターを設定できます。柔軟なアルゴリズム定義に基づいて計算されたパスは、さまざまなアプリケーションによって使用され、そのようなパスを介してデータを転送するために、それぞれが独自の特定のデータプレーンを使用する可能性があります。参加デバイスは、OSPFv2 のセグメント ルーティング フレキシブル アルゴリズム サブ TLV のすべてのアプリケーションに、特定のフレキシブル アルゴリズムへの参加を明示的にアドバタイズする必要があります。その FAD で指定された制約をサポートできる場合は、特定の柔軟なアルゴリズムに参加するようにノードを構成できます。

柔軟なアルゴリズムへの参加を設定するには、[edit protocols isis source-packet- routing]階層レベルでflex-algorithmステートメントを含めます。同じデバイスがFADをアドバタイズし、柔軟なアルゴリズムに参加できます。

柔軟なアルゴリズム定義で設定されたネットワークトポロジー

図 1 はサンプルのトポロジーを示しており、R0、R1、R2、R3、R4、R5、R6、および R7 の 8 つのルータがあります。4つの柔軟なアルゴリズム、128、129、130、および135は、次の表に示すようにadmin-groupsで定義および設定されます。

フレックスアルゴリズム定義(FAD)

128

赤を含める

129

任意の緑を含める

130

緑と青を含めます

135

赤を除外

図1:柔軟なアルゴリズムトポロジー Flexible Algorithm Topology

図 2 は、管理グループ red で設定されたインターフェイス上で FAD 128 がトラフィックをルーティングする方法を示しています。

図 2: 柔軟なアルゴリズム定義のためのトラフィック フロー 128 Traffic Flow for Flexible Algorithm Definition 128

図 3 は、管理グループ green で設定されたインターフェイスで FAD 129 がトラフィックをルーティングする方法を示しています。

図 3: 柔軟なアルゴリズム定義のトラフィック フロー 129 Traffic Flow for Flexible Algorithm Definition 129

図 4 は、管理グループ green と blue で設定されたインターフェイスで FAD 130 がトラフィックをルーティングする方法を示しています。

図4:Flexible Algorithm定義130Traffic flow for Flexible Algorithm Definition 130のトラフィックフロー

図 5 は、FAD 135 が管理グループ red で設定されていないインターフェイスでトラフィックをルーティングする方法を示しています。

図 5: 柔軟なアルゴリズム定義のためのトラフィック フロー 135 Traffic Flow for Flexible Algorithm Definition 135

柔軟なアルゴリズムRIB

ルーターが対応するフレキシブル アルゴリズムに参加するたびに、対応するフレキシブル アルゴリズム RIB グループ(ルーティング テーブルとも呼ばれる)にルートがインストールされます。デフォルトでは、ラベル付きOSPFv2フレキシブルアルゴリズムルートは、inet.color、 inet(6)color.0 、および mpls.0 RIBにインストールされます。

BGPコミュニティと柔軟なアルゴリズム

柔軟なアルゴリズムは、VPNサービスなどの他のサービスのルートを解決するために、BGPカラーコミュニティを関連付けることができます。デフォルトでは、関連するBGPカラーコミュニティは、フレキシブルアルゴリズムIDと同じです。inet(6)color.0 テーブルにインストールされている柔軟なアルゴリズムのイングレスルートは、ルート内にこのカラーコミュニティを持ちます。ただし、 [edit routing-options flex-algorithm id color desired color community value] 階層レベルで異なるBGPカラーコミュニティを設定することができます。

手記:

柔軟なアルゴリズムのためにBGPカラーコミュニティを変更すると、トラフィックが中断する可能性があります。BGP カラー コミュニティをフレキシブル アルゴリズムに変更すると、そのフレキシブル アルゴリズムに関連するすべてのルートが RIB から削除され、新しいカラーで再度追加されます。

サポートされている機能とサポートされていない機能

Junos OSは、次のシナリオで柔軟なアルゴリズムをサポートします。

  • さまざまな柔軟なアルゴリズムのプレフィックスSIDの設定とアドバタイズのサポート。

  • IGPフレキシブルアルゴリズム draft-ietf-lsr-flex-algo-05.txtインターネットドラフトを部分的にサポート

  • 柔軟なアルゴリズムの現在の実装は、OSPFv2 のみがセグメント ルーティングをサポートしているため、OSPFv2 のみでサポートされています。

Junos OSは、柔軟なアルゴリズムと組み合わせて以下の機能をサポートしていません。

  • リンク遅延メトリックはサポートされていません。

  • 柔軟なアルゴリズムは、デフォルトのユニキャスト トポロジーにのみ適用され、OSPFv2 マルチトポロジーはサポートされていません。

  • OSPFv2 のショートカットおよびその他の OSPFv2 トラフィック制御設定オプションは、柔軟なアルゴリズム計算には適用されません。.
  • 柔軟なアルゴリズムの現在の実装は、OSPFv3ではサポートされていません。
  • フレキシブルアルゴリズムプレフィックスSIDのエリア間(OSPFv2)リークはサポートされていません。

  • プレフィックスと SID の競合の解決はサポートされていません。

  • TI-LFA が優先 FRR 計算であるため、リモート ループ フリーの代替機能はサポートされていません。

  • 柔軟なアルゴリズム参加がない場合の柔軟なアルゴリズム定義のアドバタイズはサポートされていません。

  • アプリケーション固有のリンク属性アドバタイズメントを使用したフレックスアルゴリズムのリンク属性アドバタイズメントはサポートされていません。

  • トランスポートクラスRIBはサポートされていません。

アプリケーション固有のリンク属性ベースの柔軟なアルゴリズム

Junos OSおよびJunos OS Evolvedリリース22.2R1以降、同じリンク上でRSVPおよび柔軟なアルゴリズム用に、te-metric、delay-metric、admin-groupsなどの異なるte属性をアドバタイズできます。これは、RFC 8920 で定義されている柔軟なアルゴリズム固有のアプリケーション固有のリンク属性を使用して行われます。

柔軟なアルゴリズムのアプリケーション固有のリンク属性で te-metric、delay-metric、または admin-groups をアドバタイズする利点は、単一のリンクで、RSVP などのレガシー アプリケーションに対して異なる te-link-attributes をアドバタイズし、柔軟なアルゴリズムに対して異なる te-link-attributes をアドバタイズできることです。

柔軟なアルゴリズムのアプリケーション固有のte-attributeを設定するには、[edit protocols ospf area interface]階層レベルでapplication-specificステートメントを、[edit protocols ospf source-packet-routing]階層レベルでstrict-asla-based-flex-algorithmステートメントを含めます。この実装では、トラフィック制御属性をアドバタイズする既存の動作の場合のように、リンクでRSVPを有効にし、[edit protocols ospf traffic-engineering advertisement always]を設定することは必須ではなくなりました。

手記:

アプリケーション固有のリンク属性の Junos OS および Junos OS Evolved の実装は、柔軟なアルゴリズムのアプリケーションのみをサポートします。

厳密なアプリケーション固有のリンク属性ベースの柔軟なアルゴリズム

アプリケーション固有の柔軟なアルゴリズムのデフォルトの動作は、柔軟なアルゴリズムのアプリケーション固有の te 属性が使用可能な場合はリンクに使用し、使用できない場合は共通のアプリケーション固有の te 属性にフォールバックし、どちらも使用できない場合は従来の te 属性を使用します。

[edit protocols ospf source-packet-routing]strict-asla-based-flex-algorithm設定ステートメントは、ルーティングループを回避するために、ネットワーク内のデバイスで実行されるすべての柔軟なアルゴリズムに適用する必要があります。

すべてのデバイスで strict-asla-based-flex-algorithm が設定されている場合は、共通のアプリケーション固有の te 属性または柔軟なアルゴリズムの te 属性のいずれかを、各柔軟なアルゴリズム リンクに対してアドバタイズする必要があります。アプリケーション固有の te 属性がない場合、デバイスは従来の te 属性にフォールバックせず、単にリンクを無視します。

オペレーティングシステムは、アプリケーション固有のリンク属性ベースの柔軟なアルゴリズムと組み合わせて、次の機能をサポートします。

  • RFC 8920 に準拠するためのアプリケーション固有の te-attribute subTLV。アプリケーション固有の te 属性サブ TLV は、RFC 7684 で定義された OSPFv2 拡張リンク TLV のサブ TLV です。

  • 標準的なアプリケーション識別子ビットマスクを部分的にサポートし、柔軟なアルゴリズムのためにXビットをアドバタイズします。te-metric、delay-metric、または admin-groups のみが、アプリケーション固有のリンク属性サブ TLV の一部としてアドバタイズされます。

オペレーティングシステムは、アプリケーション固有のリンク属性ベースの柔軟なアルゴリズムとともに、次の機能をサポートしていません。

  • ユーザー定義のアプリケーション識別子ビットマスクのアドバタイズはサポートされていません。
  • トラフィック制御データベース(TED)はアプリケーション固有のリンク属性をサポートしていないため、柔軟なアルゴリズムのアプリケーション固有のリンク属性、というかBGP-LSを使用したアプリケーション固有のリンク属性を再アドバタイズすることはできません。
  • 標準のアプリケーション識別子ビットマスクとユーザー定義のアプリケーション識別子ビットマスク長がゼロに設定された、共通のアプリケーション固有のリンク属性のアドバタイズはサポートされていません。

  • フレキシブル アルゴリズムでの SRLG リンク制約のアドバタイズはサポートされていません。

  • 柔軟なアルゴリズムを除き、複数のアプリケーションのトラフィック制御のサポートはサポートされていません。

  • MPLS から独立した admin-groups の定義はサポートされていません。

例:OSPF フレキシブル アルゴリズム

概要

この例では、OSPFv2 ネットワークで柔軟なアルゴリズムを設定する方法を示しています。柔軟なアルゴリズムにより、コントローラのないネットワークは、ネットワークコントローラを実際に実装することなく、セグメントルーティングを使用してトラフィック制御を設定できます。

Junos OS リリース 21.1R1 以降では、要件に基づいてさまざまなパラメーターとリンク制約を使用してパスを計算する柔軟なアルゴリズムを定義することで、ネットワークをシンスライスできます。calculation-type、metric-type、および制約のセットで構成されるセットは、柔軟なアルゴリズム定義 (FAD) と呼ばれます。FAD を定義し、OSPFv2 ネットワークでアドバタイズできます。デバイスは、その特定の FAD の制約をサポートしていれば、特定の柔軟なアルゴリズムに参加するように構成することもできます。

位相幾何学

図 6 は、6 つのデバイス R0、R1、R2、R3、R4、および R5 が存在する柔軟なアルゴリズム トポロジーを示しています。2つの柔軟なアルゴリズム128および129は、これらのデバイスのそれぞれにおいて定義される。デバイスには、赤、青、緑の管理者グループが設定されています。メトリックタイプ、計算タイプ、リンク制約などの異なるパラメーターを持つ FAD は、各デバイスで定義されます。

図6:柔軟なアルゴリズムトポロジー Flexible Algorithm Topology

必要条件

この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。

  • MXシリーズルーター6台。
  • すべてのデバイスで実行されているJunos OS リリース 21.1R1 以降。

構成

CLIクイック構成

この例を素早く設定するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除し、ネットワーク設定に合わせて必要な詳細を変更し、コマンドを[edit]階層レベルのCLIにコピー&ペーストしてください。

デバイスR0

デバイスR1

デバイスR2

デバイスR3

デバイス R4

デバイス R5

デバイス R0 の設定

OSPFv2 にフレキシブル アルゴリズムを設定するには、デバイス R0 で以下の手順を実行します。

  1. IPトランスポートを有効にするようにデバイスインターフェイスを設定します。

  2. OSPF セッションのルーター ID として使用されるループバック インターフェイス(lo0)アドレスを設定します。

  3. ルーターIDと自律システム(AS)番号を設定して、同じASに属する一連のルーティングデバイス内でルーティング情報を伝達します。

  4. パケットを負荷分散するポリシーを定義し、パケットごとのポリシーを適用してトラフィックのロードバランシングを有効にします。

  5. デバイス R0 が 192.168.255.10/32 ネットワークに到達できるようにするルーティングポリシー条件のルート フィルターを設定します。

  6. 管理インターフェイスを除くすべてのインターフェイスでMPLSを設定します。
  7. MPLSラベル範囲を設定して、リンクに静的ラベルを割り当てます。

  8. TI-LFA を設定し、リンクとノードの障害に対する保護を有効にします。TI-LFAを用いたSRでは、プライマリパスが故障したり利用できなくなった場合、バックアップや代替パスに瞬時にトラフィックをルーティングすることで、ネットワーク接続の早期復旧を実現します。

  9. バックアップの最短パスファースト属性を保護するため、セグメントルーティングルーティングパスのラベルの最大数を設定します。

  10. OSPFプロトコルのSPRINGで、セグメントルーティンググローバルブロック(SRGB)のプレフィックスセグメント属性、開始ラベル、インデックス範囲を設定します。

  11. コンバージェンス後のパスに続くOSPFインターフェイスでノードリンク保護を有効にします。

  12. プロトコルがループバックインターフェイス上で実行されないこと、およびループバックインターフェイスがネットワーク全体で正しくアドバタイズされるように、ループバックインターフェイスをパッシブとして設定します。

  13. デバイス R0 で柔軟なアルゴリズムを定義します。128 から 255 までの各 FAD に名前を割り当てます。

    定義のパラメータを指定します。OSPFv2 は、FAD のこれらの指定されたパラメーターに基づいてパスを計算します。

    1. OSPFv2プロトコルがパスを計算する際の基準となる計算タイプを指定します。

    2. OSPFv2 がパスを計算する基準となるメトリック タイプを指定します。

    3. RSVPトラフィック制御を有効にしている場合は、多くのプロトコルのadmin-groupsを設定して、個々のリンクを色付けできます。

    4. 設定したadmin-groupsポリシーをデバイスR0インターフェイスに割り当てます。

    5. 要件に従ってadmin-groupsを定義します。

      手記:

      リンク制約のある FAD が機能するためには、関連するすべてのリンクが OSPFv2 で admin-colors をアドバタイズする必要があります。インターフェイスでRSVPを有効にするか、トラフィック制御にRSVPを設定していない場合は、必ず [edit protocols ospf] 階層レベルでset traffic-engineering advertise alwaysを設定してください。

  14. デバイス R0 でフレキシブル アルゴリズムへの参加を設定します。同じデバイスがFADをアドバタイズし、柔軟なアルゴリズムに参加できます。
  15. ポリシー設定を通じて、プレフィックスセグメントをアドバタイズします。

業績

構成の結果を確認します。

設定モードから、、 show interfacesshow routing-optionsshow protocolsshow policy-options の各コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。

検証

設定が正常に機能していることを確認するには、次のタスクを実行します。

OSPF データベースの検証

目的

フレキシブル アルゴリズム シグナリングが OSPF データベースに表示されていることを確認します。

アクション

運用モードから、 show ospf database opaque-area extensive コマンドを実行します。

R0について

意味

R0 のこの出力は、次のことを示しています。

このデバイスによって、3つのセグメントルーティングアルゴリズム(2つの柔軟なアルゴリズムを含む)がアドバタイズされます。

このデバイスによって 2 つの FAD がアドバタイズされます。

フレキシブルアルゴリズムの詳細の検証

目的

フレキシブルアルゴリズムの詳細が表示されていることを確認します。

アクション

運用モードから、 show ospf spring flex-algorithm <flex-algorithm-id> コマンドを実行します。

R0について

意味

R0に設定されている柔軟なアルゴリズムの詳細が表示されます。

柔軟なアルゴリズム固有のOSPF内部ルートの検証

目的

fexible アルゴリズム固有の OSPF 内部ルートが表示されていることを確認します。

アクション

運用モードから、 show ospf route flex-algorithm <flex-algorithm-id> コマンドを実行します。

R0について

意味

show ospf routeコマンドが拡張されflex-algorithm柔軟なアルゴリズム固有のOSPF内部ルートを表示するオプションが追加されました。各ルートの前には flex-algo-id が付きます。

フレックスカラールートの検証

目的

fexible アルゴリズム固有の OSPF 内部ルートが表示されていることを確認します。

アクション

運用モードから、 show route protocol ospf コマンドを実行します。

R0について

意味

出力は、inetcolor.0テーブルでプログラムされたすべての色付きフレックスルートを次の形式で表示します:prefix_address-flex-algo-id<c>/64

OSPF ログの検証

目的

OSPF ログに flexible algorithm キーワードが表示されていることを確認します。

アクション

運用モードから、 show ospf log コマンドを実行します。

R0について

意味

出力には、SPF ログに追加された FlexAlgo キーワードが表示されます。