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

柔軟なアルゴリズムを設定するメリット

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

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

• BGP-LSやスタティックパスを設定することなく、スライスごとの等価コストマルチパス(ECMP)とTI-LFAを利用できます。

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

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

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

フレキシブルアルゴリズム定義(FAD)とは何ですか?

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

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

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

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

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

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

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

既定の FAD には、次のパラメーターがあります。

• 計算タイプ: SPF

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

• 優先度: 0

• リンク制約: なし

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

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

FAPM TLV の値には、フレックスアルゴリズム (1 バイト)、予約済み (3 バイト)、メトリック (4 バイト) が含まれています。FAPM TLV は、対応するノードがプレフィックスから発信された場合にのみ、ノードが発信したプレフィックス NLRI の BGP-LS 属性に追加できます。

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

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

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

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

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

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

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

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

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

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

図3: 柔軟なアルゴリズム定義のためのトラフィックフロー 129

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

図4: フレキシブルアルゴリズム定義のトラフィックフロー 130

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

図5: 柔軟なアルゴリズム定義のためのトラフィックフロー 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カラーコミュニティを設定することができます。

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

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 計算であるため、リモート ループ フリーの代替機能はサポートされていません。

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

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

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

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

Junos OSおよびJunos OS Evolvedリリース22.2R1以降、同じリンク上でRSVPおよびフレキシブルアルゴリズムのTEメトリック、遅延メトリック、管理グループなどの異なるTE属性をアドバタイズできるようになりました。これは、RFC 8920で定義されている柔軟なアルゴリズム固有のアプリケーション固有のリンク属性を使用して行われます。

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

柔軟なアルゴリズムのアプリケーション固有の te 属性を設定するには、[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]を設定することは必須ではなくなりました。

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

アプリケーション固有のフレキシブル・アルゴリズムのデフォルトの動作は、リンクにフレキシブル・アルゴリズムのアプリケーション固有の 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属性サブTLV。アプリケーション固有の TE 属性サブ TLV は、RFC 7684 で定義されている OSPFv2 拡張リンク TLV のサブ TLV です。

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

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

• ユーザー定義アプリケーション識別子ビット マスクのアドバタイズはサポートされていません。
• トラフィック制御データベース(TED)はアプリケーション固有のリンク属性をサポートしていないため、柔軟なアルゴリズムのアプリケーション固有のリンク属性、またはBGP-LSでのアプリケーション固有のリンク属性の再アドバタイズはサポートされていません。

• 標準アプリケーション識別子ビット マスクおよびユーザー定義アプリケーション識別子ビット マスク長がゼロに設定された共通のアプリケーション固有リンク属性のアドバタイズはサポートされていません。

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

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

• MPLS に依存しない管理グループの定義はサポートされていません。