ポリシーベースのマルチパスルートの概要
セグメントルーティングネットワークは、コアに複数のトランスポートプロトコルを持つことができます。セグメントルーティング SR TE LDP または RSVP ルートと SR TE IP ルートを組み合わせて、ルーティング情報ベース (ルーティングテーブルとも呼ばれる) にマルチパスルートをインストールすることができます。その後、ポリシー設定を通じて、マルチクラウドパスルートを使用して、選択的サービストラフィックを誘導できます。
ポリシーベースのマルチパスルートについて
ネットワークには、サービストラフィックを解決するために使用される IGP、ラベル付き IGP、RSVP、LDP、セグメントルーティングトラフィックエンジニアリング (TE SR) プロトコルなど、さまざまなトランスポートプロトコルがあります。ただし、サービストラフィックを解決するために、トランスポートプロトコルの組み合わせを使用することはできませんでした。ポリシーベースのマルチパス機能の導入により、セグメントルーティングトラフィックエンジニアリング (SR TE) LDP または RSVP ルートと SR TE IP ルートを組み合わせることで、ルーティング情報ベースにインストールされたマルチパスルートを作成できます。ポリシー設定によってマルチパスルート上で BGP サービスルートを解決すると、プレフィックスが異なるとトラフィックを別の方法で誘導することができます。
マルチパスルートは、ロードバランシングに使用されるルートエントリーのホップを1つにまとめたものです。マルチパスルートエントリのサポートルートはすべて、同じルーティング情報ベースにする必要があります。サポートルートが異なるルーティング情報ベースにある場合、構成ステートメントを使用rib-groupして、特定のルーティング情報ベースにルートエントリを追加できます。
ポリシーを使用してマルチパスルートを構成し、次のホップを組み合わせるルートのリストを選択することができます。ステートメントを階層レベルpolicy-multipathのpolicy[edit routing-options rib routing-table-name]ステートメントとともに含めると、ポリシーベースのマルチパスルートが作成されます。
IP および IPv6 プロトコルの両方で、ポリシーベースのマルチパス機能がサポートされており、 [edit routing-instances]階層レベルの下で設定できます。
たとえば、以下のように記述します。
設定されたポリシーは、指定されたプレフィックスの各ルートエントリに適用されます。マルチパスルートは、複数のルート (アクティブルートを含む) がポリシーを通過する場合にのみ作成されます。ポリシーに設定されているすべてのアクションコマンド (適用など) は、アクティブなルートを使用して評価されます。非アクティブルートでは、ルートがマルチパスルートに参加できるかどうかを確認するポリシーが適用されます。マルチパスルートは、アクティブなルートのすべての属性を継承します。これらの属性は、マルチパスポリシー設定を使用して変更できます。
ポリシーベースのマルチパスルートのメリット
コアネットワークプロトコルを組み合わせて選択的なトラフィックを誘導する柔軟性を備えています。
マルチパスルートを使用して、重みの等しいコストマルチパスでネットワークパフォーマンスを最適化します。
ルート解決のためのポリシーベースのマルチパスルート
セグメントルーティングトラフィックエンジニアリング (SR TE) LDP または RSVP ルートと SR TE IP ルートを組み合わせると、ルーティング情報ベースにマルチパスルートをインストールできます。ポリシーベースのマルチパスルートは、ルーティング情報ベースでアクティブなエントリーではありません。マルチパスルートがポリシーの設定によって生成された場合、アクティブルートではなく、プロトコルの次回ホップを解決するために使用します。マルチパスルートの次ホップは、各構成ルートの次ホップのゲートウェイをマージすることで作成されます。
ルート解決のためのポリシーベースのマルチパスルートを構成する場合は、以下の点を考慮してください。
マルチパスルートのメンバールートがルーターのネクストホップ以外の次ホップを指す場合、または、ルーターのネクストホップへのフォワーディング次ホップを持つ間接的なネクストホップを指している場合、次のホップは無視されます。
構成要素ルートが間接的な次ホップにポイントすると、転送のネクストホップからのゲートウェイがマージされ、indirect next ホップは無視されます。
デバイスでmaximum-ecmpサポートされているゲートウェイの総数を超えた場合、 maximum-ecmpゲートウェイのみが保持され、他のゲートウェイはすべて無視されます。
低重量のゲートウェイが優先されます。メンバールートのいずれかが、間接的なネクストホップを持ち、次ホップのそれぞれが転送のネクストホップを指している場合、間接的なネクストホップと転送の次ホップのどちらにも重み値がある場合があります。このような場合、ゲートウェイの加重値は、両方のレベルで重みの組み合わせ効果を反映するように更新されます。
ポリシーベースのマルチパスルートを使用したルート解決のサンプル
例として、以下の出力に示すように、セグメントルーティングトラフィックエンジニアリングされた Lsp、ラベル IS-IS ルート、LDP Lsp の 1.1.1.1/32 を想定してみましょう。
1.1.1.1/32 *[SPRING-TE/8] 00:00:58, metric 1, metric2 30
> to 13.1.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:15:57, metric 10
> to 12.1.1.1 via ge-0/0/0.1
to 12.22.1.1 via ge-0/0/0.2
to 12.23.1.1 via ge-0/0/0.3
to 12.24.1.1 via ge-0/0/0.4
to 12.25.1.1 via ge-0/0/0.5
to 13.1.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:09:27, metric 1
> to 12.1.1.1 via ge-0/0/0.1
to 12.22.1.1 via ge-0/0/0.2
to 12.23.1.1 via ge-0/0/0.3
to 12.24.1.1 via ge-0/0/0.4
to 12.25.1.1 via ge-0/0/0.5
to 13.1.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
ここでは、セグメントルーティング LSP が1.1.1.1 宛先へのアクティブなルートエントリであり、デフォルトでは、このルートのみを使用して1.1.1.1 上で解決するすべてのサービスを解決しています。
サービスルートを解決するために複数のプロトコルを使用する必要がある場合、プロトコルを組み合わせるようにpolicy-multipathを構成することで、これを実現できます。たとえば、サービスを解決するためにセグメントルーティングと LDP パスが必要な場合はpolicy-multipath 、プレフィックス1.1.1.1 に対して segement ルーティングと ldp ルートの組み合わせを設定する必要があります。
たとえば、以下のように記述します。
この構成により、セグメントルーティングと LDP プロトコルの構成要素のルートエントリを使用するプレフィックス 1.1.1.1/32 に対して、ポリシーベースのマルチパスルートを作成します。
show routeコマンド出力を使用してマルチパスルートを表示するには、以下のようにします。
1.1.1.1/32 *[SPRING-TE/8] 00:10:28, metric 1, metric2 30
> to 13.1.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:25:27, metric 10
> to 12.1.1.1 via ge-0/0/0.1
to 12.22.1.1 via ge-0/0/0.2
to 12.23.1.1 via ge-0/0/0.3
to 12.24.1.1 via ge-0/0/0.4
to 12.25.1.1 via ge-0/0/0.5
to 13.1.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:18:57, metric 1
> to 12.1.1.1 via ge-0/0/0.1
to 12.22.1.1 via ge-0/0/0.2
to 12.23.1.1 via ge-0/0/0.3
to 12.24.1.1 via ge-0/0/0.4
to 12.25.1.1 via ge-0/0/0.5
to 13.1.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[Multipath/8] 00:03:13, metric 1, metric2 30
> to 12.1.1.1 via ge-0/0/0.1
to 12.22.1.1 via ge-0/0/0.2
to 12.23.1.1 via ge-0/0/0.3
to 12.24.1.1 via ge-0/0/0.4
to 12.25.1.1 via ge-0/0/0.5
to 13.1.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 13.1.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
マルチパスルートによって、セグメントルーティングと LDP パスの次のホップが組み合わされたコマンド出力が表示されます。マルチパスルートはアクティブではありません。デフォルトでは、ルートの優先度とメトリックは、アクティブルートと同じです。
Poilcy ベースのマルチパスルートには、以下の組み合わせを使用できます。しかし、アクティブルートがマルチパスの一部ではないため、LDP/L-ISIS のマルチパスを作成することはできません。
セグメントルーティングのトラフィックエンジニアリング Lsp および LDP Lsp。
セグメントルーティングトラフィックエンジニアリング Lsp、およびラベル IS-IS パス。
セグメントルーティングトラフィック-Lsp、LDP Lsp、ラベル IS-IS パス。
ただし、アクティブルートはマルチパスルートの一部ではないため、LDP および label IS-IS のマルチパスルートを作成することはできません。
同じ設定で、プロトコルネクストホップ1.1.1.1 が設定された静的ルート 1.2.3.4/32 を使用している場合、このルートはセグメントルーティングトラフィックエンジニアリングされた Lsp と LDP Lsp の両方でマルチパスルートで解決します。
たとえば、以下のように記述します。
1.2.3.4/32 *[Static/5] 00:00:12, metric2 1
to 12.1.1.1 via ge-0/0/0.1
> to 12.22.1.1 via ge-0/0/0.2
to 12.23.1.1 via ge-0/0/0.3
to 12.24.1.1 via ge-0/0/0.4
to 12.25.1.1 via ge-0/0/0.5
to 13.1.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 13.1.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
サービスクラスの転送 (CoS) の機能強化-ポリシー
サービスベースの転送では、 forwarding-policy next-hop-map構成ステートメントを使用する必要があります。
Junos OS リリース 19.1 R1 より前は、サービスベースの転送でサポートされている match 条件は以下のとおりです。
next-hop—アウトゴーイングインターフェイスまたは次ホップアドレスに基づいて次ホップを検索します。
lsp-next-hop—LSP 名の正規表現を使用して、名前付き Lsp を検索します。
non-lsp-next-hop—LSP 名なしですべての Lsp と一致します。
ポリシーベースのマルチパスルート機能を使用すると、特定のプレフィックスのラベルを使用せずに、すべてのネクストホップを照合することもできます。これを行うには、 non-labelled-next-hop[edit class-of-service forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name階層レベルでオプションを有効にする必要があります。
たとえば、以下のように記述します。
ポリシーマッチプロトコルの機能強化
Junos OS Release 19.1 R1 以前では、ポリシーを使用して階層レベルのfrom protocol[edit policy-options policy-statement statement-name]文を使用してプロトコルを照合すると、すべてのプロトコルルート (ラベル付けおよびラベルなし) が一致しています。ポリシーベースのマルチパスルート機能を使用すると、特にラベル付きプロトコルルートを照合できます。
ラベル付きプロトコルに対応するためのオプションは、以下のとおりです。
l-isis—ラベル付き IS-IS ルートを検索します。このisisオプションは、ラベル IS-IS ルートを除く IS-IS ルートを照合します。
l-ospf—OSPF ルートの照会に対応します。このospfオプションは、OSPFv2、OSPFv3、ラベル OSPF を含むすべての OSPF ルートと一致します。
たとえば、以下のように記述します。
ネットワークパフォーマンスに対するポリシーベースのマルチパスルートの構成の影響
ポリシーベースのマルチパスルートを構成する場合、ルーティング情報ベースのルートを変更すると、マルチパスルートを作成する必要があるかどうかを確認するポリシーの評価が実行されます。この機能では、メンバールートが同じルーティング情報ベースにある必要があるrib-groupため、異なるルーティング情報ベースからルートをマージするためにこのステートメントを使用しています。アプリケーションレベルrib-groupでステートメントを設定すると、システム内のルート数が増加します。
ルーティング情報ベースに多数のルートが存在する場合、ルートの継続的な変化によって、マルチパスポリシーが再評価されます。これにより、ネットワークのパフォーマンスに影響を与える可能性があります。必要な場合にのみ、ポリシーベースのマルチパスルート機能を構成することをお勧めします。