セグメントルーティングのためのIGPの柔軟なアルゴリズム
柔軟なアルゴリズムにより、IGP単独でネットワーク上の制約ベースのパスを計算できるため、ネットワークコントローラを使用せずにシンプルなトラフィック制御を行うことができます。本格的なセグメントルーティングを備えたコントローラを実装していないが、ネットワークでセグメントルーティングのメリットを享受したいネットワーク向けの軽量ソリューションです。
セグメントルーティングのためのIGPフレキシブルアルゴリズムを理解する
さまざまなパラメーターとリンク制約を使用してパスを計算する柔軟なアルゴリズムを定義し、要件に基づいてネットワークを薄くします。例えば、IGPメトリックを最小化するパスを計算する柔軟なアルゴリズムを定義し、ネットワークを別々のプレーンに分割するためにトラフィック制御メトリックに基づいてパスを計算する別の柔軟なアルゴリズムを定義できます。この機能により、コントローラを持たないネットワークでも、実際にネットワークコントローラを実装することなく、セグメントルーティングを使用してトラフィック制御を設定することができます。プレフィックスSIDを使用して、制約ベースのパスに沿ってパケットを誘導できます。ポリシー設定により、柔軟なアルゴリズムのプレフィックスSIDを設定することができます。
IGPプロトコルは、リンクメトリックを使用して最適なパスを計算します。ただし、特定のタイプのトラフィックに対しては、最適な IGP パスが必ずしも最適なパスであるとは限りません。そのため、最短のIGPメトリックに基づいて計算されたIGP最適なパスは、IGPメトリックに反映されないトラフィック要件のために、トラフィックエンジニアリングパスに置き換えられることが多いIGPです。通常、RSVP-TE または SR TE を使用して、この制限を克服するための追加のメトリックと制約に基づいてパスを計算します。Junosは、IGPによって計算された元のパスに加えて、またはその代わりとして、このようなパスを転送テーブルにインストールします。
- フレキシブルアルゴリズムを設定するメリット
- フレキシブルアルゴリズム定義(FAD)とは?
- 柔軟なアルゴリズムへの参加
- 柔軟なアルゴリズム定義で構成されたネットワークトポロジー
- 柔軟なアルゴリズムRIB
- BGPコミュニティと柔軟なアルゴリズム
- アプリケーション固有のリンク属性ベースの柔軟なアルゴリズム
- 厳密なアプリケーション固有のリンク属性ベースの柔軟なアルゴリズム
- サポートされている機能とサポートされていない機能
フレキシブルアルゴリズムを設定するメリット
ネットワークのコアで使用できる、セグメントルーティングトラフィックエンジニアリングの軽量バージョンです。
ネットワークコントローラをインストールしなくても、セグメントルーティングによるトラフィック制御の設定が可能です。
同じ柔軟なアルゴリズム定義と制約計算を使用して、TI-LFAバックアップパスを計算します。
単一ラベルに基づいて制約付きプライマリパスをプロビジョニングする機能。
フレキシブルアルゴリズム定義(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 メトリックを使用したくない場合は、IS-IS がルートの計算に使用できる TE メトリックを設定することができます。
Priority- 要件に応じて FAD に優先順位を割り当てることができ、IS-IS は割り当てられた優先順位に基づいて特定の FAD アドバタイズメントを別の FAD よりも優先順位付けします。
注:リンク制約のあるFADが機能するためには、関連するすべてのリンクがIS-ISでadmin-colorをアドバタイズする必要があります。これは、インターフェイスでRSVPが有効になっているか、
set protocols isis traffic-engineering advertise alwaysが設定されていることを意味します。Set of Link constraints-
[edit protocols mpls admin-groups]階層レベルで多くのプロトコルのadmin-groupsを設定して、個々のリンクに色を付けることができます。これらのadmin-groupsは、[edit routing-options flex-algorithm definition admin-groups]階層レベルでinclude any、include-all、またはexcludeとして定義できます。
冗長性を確保し、競合を避けるために、少数のルーターでのみ柔軟なアルゴリズム定義を設定することをお勧めします。柔軟なアルゴリズムの定義は、 FAD sub-TLVsとしてIGPでアドバタイズされます。非常に大規模なネットワークでは、柔軟なアルゴリズムがそれぞれ独自のパスを計算し、それを超えるパフォーマンスの問題が発生する可能性があるため、8つを超える柔軟なアルゴリズムを設定することはお勧めしません。
また、デバイスをそのFADに参加するように設定する前に、特定のIS-ISレベルで複数のFADサーバーを設定することも推奨します。IS-IS L1/L2ノード(ABR)の場合、IS-ISレベル1とレベル2の両方でFADを設定することも推奨されます。FADが単一のABRでのみ設定されている場合、ルーティングプロセスがそのABRで再起動すると、フレックスアルゴリズムパス上のトラフィックドロップが発生する可能性があります。そのため、複数のABRを設定し、それぞれに両方のIS-ISレベルでFADが設定されていることを設計することをお勧めします。
デフォルトのFADには、以下のパラメータがあります。
計算タイプ:SPF
メトリックタイプ:IGP-Metric
優先度:0
リンク制約:なし
ライブネットワーク内またはその場で柔軟なアルゴリズムの定義を変更すると、すべてのノードが新しいパスに収束するまでトラフィックが中断する可能性があります。
TEDでは「flexible Algorithm Definition(FAD)」と「Flexible Algorithm Prefix Metric(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属性に追加できます。
エリア間プレフィックスに最適なエンドツーエンドのパスを可能にするために、柔軟なアルゴリズムプレフィックスメトリック(FAPM)を定義しました。エリアボーダールーター(ABR)は、指定されたフレキシブルアルゴリズム(フレックスアルゴ)で到達可能なエリア間でプレフィックスをアドバタイズする場合に、FAPMを含める必要があります。プレフィックスが到達できない場合、エリア間でアドバタイズする際に、ABRはそのフレックスアルゴリズムにそのプレフィックスを含めてはなりません。定義された FAPM は、エリア間サポートを提供します。
RFC 9350「IGPフレキシブルアルゴリズム」で定義されているように、管理グループとSRLG(共有リスクリンクグループ)に関連する遅延正規化とFAD(フレキシブルアルゴリズム定義)で定義された制約をサポートします。
柔軟なアルゴリズム計算中に、測定された遅延値が等しくなく、その差がわずかな場合、IS-IS はこのわずかに高い遅延値をメトリックとしてアドバタイズします。IS-IS は、測定された遅延値ではなく、この正規化された遅延遅延値を使用します。
柔軟なアルゴリズムアプリケーション固有のSRLG値を設定するには、[edit protocols isis interface interface-name level level]階層レベルでアプリケーション固有のステートメントを含めます。FADでSRLG制約を除外するには、[edit routing-options flex-algorithm name definition] 階層レベルでexclude-srlgステートメントを含めます。
inetcolor.0およびmpls.0ルーティングテーブルでOSPFフレキシブルアルゴリズムルートの優先度を設定することで、パス選択を制御できます。
[edit protocols ospf]階層レベルでflex-algorithm-preferenceステートメントを設定し、目的のルートに優先順位を付け、IPドメインとMPLSドメイン全体のトラフィック制御を改善します。
柔軟なアルゴリズムへの参加
要件に応じて、特定のルーターを特定の柔軟なアルゴリズムに参加するように設定できます。柔軟なアルゴリズムの定義に基づいて計算されたパスは、さまざまなアプリケーションによって使用され、それぞれが独自のデータプレーンを使用して、そのようなパスを介してデータを転送する可能性があります。参加デバイスは、IS-ISのセグメントルーティングフレキシブルアルゴリズムサブ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グループで定義および設定されます。
フレックスアルゴリズム定義(FAD) |
カラー |
|---|---|
128 |
任意の赤を含める |
129 |
緑色を含む |
130 |
緑と青を含める |
135 |
赤を除外する |
図2 は、FAD 128がadminグループredで設定された任意のインターフェイスでトラフィックをどのようにルーティングするかを示しています。
図3 は、FAD 129がadminグループgreenで設定されたインターフェイスでトラフィックをどのようにルーティングするかを示しています。
図4 は、FAD 130が管理グループ緑と青で設定された任意のインターフェイスでトラフィックをルーティングする方法を示しています。
図5 は、FAD 135がadminグループredで設定されていないインターフェイスでトラフィックをどのようにルーティングするかを示しています。
柔軟なアルゴリズムRIB
ルーターが参加するすべてのフレキシブル アルゴリズムについて、対応するフレキシブル アルゴリズム ルートは、対応するフレキシブル アルゴリズム RIB グループ(ルーティング テーブルとも呼ばれる)にインストールされます。デフォルトでは、ラベル付きのフレキシブルアルゴリズムルートが、inet.color、inet(6)color.0、およびmpls.0RIBにインストールされます。また、ステートメントがrouting-options flex-algorithm <id>で設定されている場合junos-rti-tc-<color>.inet(6).3などuse-transport-class色付きのRIBにインストールすることもできます。詳細については、Flexible AlgorithmおよびFlexible Algorithm Prefix Metrics Leaking across IS-IS Multi-Instanceを参照してください。
BGPコミュニティと柔軟なアルゴリズム
柔軟なアルゴリズムを色に関連付けることができます。VPN サービスなどのサービスプレフィックスが BGP カラー拡張コミュニティを伝送する場合、デフォルトでは、BGP サービスプレフィックスは、同じ関連カラー値を持つフレックスアルゴルートを解決します。 inet(6)color.0 テーブルにインストールされている柔軟なアルゴリズムイングレスルートには、このカラー値がルートに関連付けられます。ただし、 [edit routing-options flex-algorithm id color color] 階層レベルで異なる関連付けカラー値を設定できます。
柔軟なアルゴリズムで関連するカラー値を変更すると、トラフィックが中断する可能性があります。フレキシブルアルゴリズム定義のカラーを変更すると、そのフレキシブルアルゴリズムに関連するすべてのルートがRIBから削除され、新しいカラーで再度追加されます。
柔軟なアルゴリズムプレフィックスSIDを使用して、BGP-LUプレフィックスをIGPにリークできます。詳細については、「 柔軟なアルゴリズムへのBGP-LUプレフィックスのリーク」を参照してください。
BGP-CTプレフィックスを柔軟なアルゴリズムにリークしたり、その逆を行ったりできるようになりました。詳細については、「 柔軟なアルゴリズムへのBGP-CTプレフィックスのリーク」を参照してください。
アプリケーション固有のリンク属性ベースの柔軟なアルゴリズム
同じリンク上で、RSVP や柔軟なアルゴリズム用に te-metric、delay-metric、admin-groups などの異なる te 属性をアドバタイズできます。これは、RFC 8920で定義されている柔軟なアルゴリズム固有のアプリケーション固有のリンク属性を使用して行われます。
柔軟なアルゴリズムのアプリケーション固有のリンク属性でte-metric、delay-metric、またはadmin-groupsをアドバタイズする利点は、単一のリンクでRSVPなどのレガシーアプリケーション用の異なるte-link-attributeをアドバタイズしたり、柔軟なアルゴリズム用の異なるte-link-attributeをアドバタイズできることです。
柔軟なアルゴリズムのアプリケーション固有の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-attributeを使用し、使用可能な場合は一般的なアプリケーション固有のte-attributeにフォールバックし、どちらも使用できない場合は従来のte-attributeを使用することです。
[edit protocols ospf source-packet-routing]でstrict-asla-based-flex-algorithm設定ステートメントは、ルーティングループを回避するために、ネットワーク内のデバイスで実行されているすべての柔軟なアルゴリズムに適用する必要があります。
すべてのデバイスで strict-asla-based-flex-algorithm が設定されている場合、各フレキシブルアルゴリズムリンクに対して、共通のアプリケーション固有te属性またはフレキシブルアルゴリズムアプリケーション固有te属性のいずれかをアドバタイズする必要があります。アプリケーション固有のte属性がない場合、デバイスは従来のte属性にフォールバックせず、単にリンクを無視します。
オペレーティングシステムは、アプリケーション固有のリンク属性ベースの柔軟なアルゴリズムと組み合わせて、以下の機能をサポートしています。
RFC 8920に準拠したアプリケーション固有のte属性subTLV。アプリケーション固有のte属性サブTLVは、RFC 7684で定義されているOSPFv2拡張リンクTLVのサブTLVです。
柔軟なアルゴリズムのためにXビットをアドバタイズするための標準アプリケーション識別子ビットマスクを部分的にサポート。te-metric、delay-metric、またはadminグループのみが、アプリケーション固有のリンク属性sub-TLVの一部としてアドバタイズされます。
オペレーティングシステムは、アプリケーション固有のリンク属性ベースの柔軟なアルゴリズムと組み合わせた以下の機能をサポートしていません。
- ユーザー定義のアプリケーション識別子ビットマスクのアドバタイズはサポートされていません。
- トラフィック制御データベース(TED)はアプリケーション固有のリンク属性をサポートしていないため、BGP-LSを含む柔軟なアルゴリズム、アプリケーション固有のリンク属性、あるいはアプリケーション固有のリンク属性の再アドバタイズはサポートされていません。
標準アプリケーション識別子ビットマスクおよびユーザー定義のアプリケーション識別ビットマスク長をゼロに設定して、共通のアプリケーション固有のリンク属性をアドバタイズすることはサポートされていません。
フレキシブルアルゴリズムでのSRLGリンク制約のアドバタイズはサポートされていません。
複数のアプリケーションのトラフィックエンジニアリングのサポートは、柔軟なアルゴリズムを除き、サポートされていません。
MPLS から独立した管理グループの定義はサポートされていません。
サポートされている機能とサポートされていない機能
Junos OSは、以下のシナリオで柔軟なアルゴリズムをサポートします。
さまざまな柔軟なアルゴリズムのプレフィックスSIDの設定とアドバタイズのサポート。
RFC 9350、IGPフレキシブルアルゴリズムを部分的にサポート
フレキシブルアルゴリズムプレフィックスSIDのレベル間(IS_IS)リークはサポートされています。
- OSPFv2のみがセグメントルーティングをサポートしているため、柔軟なアルゴリズムの現在の実装はOSPFv2でのみサポートされています。
Junos OS は、柔軟なアルゴリズムと組み合わせた以下の機能をサポートしていません。
柔軟なアルゴリズムはデフォルトのユニキャストトポロジーにのみ適用可能で、OSPFv2マルチトポロジーはサポートされていません。
IS-ISショートカットおよびその他のIS-ISトラフィックエンジニアリング設定オプションは、柔軟なアルゴリズム計算には適用されません
プレフィックスとSIDの競合解決はサポートされていません。
TI-LFA が優先される FRR 計算であるため、リモート ループフリーの代替機能はサポートされていません
- OSPFv2ショートカットおよびその他のOSPFv2トラフィックエンジニアリング設定オプションは、柔軟なアルゴリズム計算には適用されません。
柔軟なアルゴリズムが参加しない場合の柔軟なアルゴリズム定義のアドバタイズは、OSPFv2ではサポートされていません。
拡張管理グループ(EAG)は、IS-IS でサポートされていないため、サポートされていません。
関連項目
変更履歴テーブル
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。
inetcolor.0 および
mpls.0 ルーティングテーブルでOSPFフレキシブルアルゴリズムルートの優先度を設定することで、パス選択を制御できるようになりました。