カラーベースのトラフィック制御設定
BGPクラスフルトランスポートプレーンの概要
- BGPクラスフルトランスポートプレーンのメリット
- BGPクラスフルトランスポートプレーンの用語
- BGPクラスフルトランスポートプレーンを理解する
- BGPクラスフルトランスポートプレーンのAS内実装
- BGPクラスフルトランスポートプレーンのAS間実装
BGPクラスフルトランスポートプレーンのメリット
-
ネットワークスライシング - サービス層とトランスポート層はお互いと分離されており、複数のドメインにまたがるエンドツーエンドのスライシングによってネットワークスライシングと仮想化の基盤が築かれているため、CAPEXが大幅に削減されます。
- ドメイン間の相互運用性 - 各ドメイン内の異なるトランスポートシグナリングプロトコルが相互運用されるように、連携するドメイン全体にトランスポートクラスの導入を拡張します。各ドメインで使用される可能性のある拡張コミュニティ名前空間に差異があれば調整します。
-
フォールバックを備えた色付き解決 - ベストエフォートトンネルやその他の色付きトンネルを介した柔軟なフォールバックオプションを使用して、色付きトンネル(RSVP、IS-IS柔軟アルゴリズム)での解決トンネルを有効にします。
- サービス品質 - エンドツーエンドのSLA要件を達成するために、ネットワークをカスタマイズして最適化します。
- 既存の導入を活用 - RSVPなどの適切に導入されたトンネリングプロトコルと、IS-ISフレキシブルアルゴリズムなどの新しいプロトコルをサポートし、ROIを維持し、OpExを削減します。
BGPクラスフルトランスポートプレーンの用語
このセクションでは、BGPクラスフルトランスポートプレーンを理解するためによく使用される用語について簡潔に説明します。
-
サービスノード - サービスルート(インターネットおよびレイヤー3 VPN)を送受信するイングレスプロバイダエッジ(PE)デバイス。
-
ボーダーノード - 異なるドメイン(IGPエリアまたはAS)の接続ポイントにあるデバイス。
-
トランスポートノード - BGPラベル付きユニキャスト(LU)ルートを送受信する装置。
-
BGP-VPN - RFC4364メカニズムを使用して構築されたVPN。
-
ルートターゲット(RT)- VPNメンバーシップを定義するために使用される拡張コミュニティのタイプ。
-
ルート識別子(RD)- ルートがどのVPNまたは仮想プライベートLANサービス(VPLS)に属しているのかを区別するための識別子。各ルーティングインスタンスには、固有のルート識別が関連付けられている必要があります。
- 解決スキーム - フォールバックを提供する解決RIBでプロトコルネクストホップアドレス(PNH)を解決するために使用されます。
マッピングコミュニティに基づいて、ルートをシステム内の異なるトランスポートRIBにマップします。
-
サービスファミリー - トンネルではなく、データトラフィックのアドバタイズルートに使用されるBGPアドレスファミリー。
-
トランスポートファミリー - アドバタイズトンネルに使用されるBGPアドレスファミリーで、サービスルートによって解決のために使用されます。
-
トランスポートトンネル - GRE、UDP、LDP、RSVP、SR-TE、BGP-LUなどのトラフィックをサービスが配置する可能性のあるトンネル。
-
トンネルドメイン - 単一の管理制御下にあるサービスノードとボーダーノードを含むネットワークのトンネルドメイン。ラベルを使用してノードをステッチすることで、隣接する複数のトンネルドメインにまたがるエンドツーエンドのトンネルを作成できます。
-
トランスポートクラス - 同じサービスの種類を提供するトランスポートトンネルのグループ。
トランスポートクラスRT - 特定のトランスポートクラスを特定するために使用する、ルートターゲットの新しい形式。
特定のトランスポートクラスを特定するために使用する、ルートターゲットの新しい形式。-
トランスポートRIB - サービスノードとボーダーノードでは、トランスポートクラスには、そのトンネルルートを保持するトランスポートRIBが関連付けられます。
-
トランスポートRTI - ルーティングインスタンス。トランスポートRIBのコンテナ、および関連するトランスポートクラスのルートターゲットとルート識別素。
-
トランスポートプレーン - 同じトランスポートクラスRTIをインポートするトランスポートRTIのセット。これらが、Inter-AS option-bに類似したメカニズムを使用してトンネルドメイン境界をまたいて繋がり、境界ノード(ネクストホップ自体)でラベルが交換され、エンドツーエンドのトランスポートプレーンが形成されます。
-
マッピングコミュニティ - トランスポートクラス上の解決にマッピングされるサービスルート上のコミュニティ。
BGPクラスフルトランスポートプレーンを理解する
BGPクラスフルトランスポートプレーンを使用して、トラフィック制御の特性に基づいてAS内ネットワーク内の一連のトランスポートトンネルを分類するためのトランスポートクラスを設定し、これらのトランスポートトンネルを使用して、サービスルートを目的のSLAと意図したフォールバックにマッピングできます。
BGPクラスフルトランスポートプレーンは、トランスポートクラスを維持したまま、これらのトンネルを複数のドメイン(ASまたはIGPエリア)にまたがるドメイン間ネットワークに拡張できます。そのためには、ボーダーノードとサービスノードの間にBGPクラスフルトランスポート層のBGPファミリーを設定する必要があります。
AS間実装とAS内実装の両方で、サービスノードとボーダーノードから多くのトランスポートトンネル(MPLS LSP、IS-ISフレキシブルアルゴリズム、SR-TE)が作成されている場合があります。LSPは、異なるドメインの異なるシグナリングプロトコルを使用して信号を送信し、異なるトラフィック制御特性(クラスまたはカラー)で設定することができます。トランスポートトンネルエンドポイントはサービスエンドポイントとしても機能し、サービスイングレスノードと同じトンネルドメインに存在することも、隣接ドメインまたは隣接していないドメインに存在することもできます。BGPクラスフルトランスポートプレーンを使用して、単一ドメイン内または複数のドメインにわたって、特定のトラフィック制御特性を持つLSP上のサービスを解決できます。
BGPクラスフルトランスポートプレーンは、BGP-VPNテクノロジーを再利用することで、トンネリングドメインの疎結合と調整を維持します。
- ネットワーク層の到達可能性情報(NLRI)は、パスハイディングに使用される RD:TunnelEndpoint です。
- ルートターゲットはLSPのトランスポートクラスを示し、宛先デバイス上の対応するトランスポートRIBにルートをリークします。
- すべてのトランスポートトンネリングプロトコルは、transport-class.inet.3 ルーティングテーブルにイングレスルートをインストールし、トンネルトランスポートクラスをVPNルートターゲットとしてモデル化し、同じトランスポートクラスのLSPをtransport-class.inet.3 transport-ribルーティングテーブルに収集します。
-
このルーティングインスタンスのルートは、RFC-4364と同様の手順で、BGPクラスフルトランスポートプレーン(inet transport)AFI-SAFIにアドバタイズされます。
-
AS間リンクの境界を越える場合は、Option-bの手順に従って、これらの隣接するドメインにあるトランスポートトンネルをステッチする必要があります。
同様に、AS内領域を超える場合は、Option-bの手順に従って、異なるTEドメインにあるトランスポートトンネルをステッチする必要があります。
-
解決スキームを定義することで、様々なトランスポートクラスに対するインテントをフォールバック順に指定することができます。
- これらのトランスポートクラス上でマッピングコミュニティを送信することで、これらのトランスポートクラスを介してサービスルートやBGPクラスフルトランスポートルートを解決できます。
BGPクラスフルトランスポートファミリーは、BGP-LUトランスポート層ファミリーと並行して動作します。BGP-LUを実行するシームレスなMPLSネットワークでは、トンネルのトラフィック制御の特性が不明となるか、ドメイン境界を越えて保存されないため、5Gの厳格なSLA要件を満たすことが課題となります。BGPクラスフルトランスポートプレーンは、シームレスなMPLSアーキテクチャにおいて、トランスポートクラス情報とともにリモートループバック用の複数のパスをアドバタイズするための運用上容易でスケーラブルな手段を提供します。BGPクラスフルトランスファミリーのルートでは、トランスポートクラスカラーを伝送するトランスポートルートターゲット拡張コミュニティを使用して、異なるSLAパスを表現します。このトランスポートルートターゲットは、受信側のBGPルーターがBGPクラスフルトランスポートルートを適切なトランスポートクラスに関連付けるために使用されます。BGPクラスフルトランスポートルートを再アドバタイズすると、MPLSはルートを入れ替え、同じトランスポートクラスのAS内トンネルを相互接続することで、トランスポートクラスを保持したエンドツーエンドのトンネルを形成します。
BGPクラスフルトランスポートプレーンのAS内実装
図1 は、AS内ドメインにBGPクラスフルトランスポートプレーンを実装する前と後のネットワークトポロジーを示しています。デバイス PE11 と PE12 はトランスポートトンネルとして RSVP LSP を使用し、すべてのトランスポートトンネルルートは inet.3 RIB にインストールされています。BGPクラスフルトランスポートプレーンを実装することで、セグメントルーティングトンネルと同様に、RSVPトランスポートトンネルがカラーを認識できるようになります。
の前後のシナリオ
AS内設定でトランスポートトンネルをBGPトランスポートクラスに分類するには
- サービスノード(ingress PEデバイス)で、ゴールドやブロンズなどのトランスポートクラスを定義し、定義されたトランスポートクラスにカラーコミュニティ値を割り当てます。
構成例:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - トランスポートトンネルを、トンネルのingressノードで特定のトランスポートクラスに関連付けます。
構成例:
pe11# show protocols mpls label-switched-path toPE12-bronze { transport-class bronze; } label-switched-path toPE12-gold { transport-class gold; }
AS内BGPクラスフルトランスポートプレーンの機能:
- BGPクラスフルトランスポートは、名前付きトランスポートクラス(ゴールドおよびブロンズ)ごとに定義済みのトランスポートRIBを作成し、そのカラー値(100および200)からマッピングコミュニティを自動的に導き出します。
- トランスポートクラスと関連づけられたときに、トンネリングプロトコルによってトランスポートRIBにAS内トランスポートルートが入力されます。
この例では、トランスポートクラスゴールド(カラー100)とトランスポートクラスブロンズ(カラー200)に関連付けられたRSVP LSPルートが、それぞれトランスポート RIBjunos-rti-tc-<100>.inet.3 および junos-rti-tc-<200>.inet.3にインストールされています。
- サービスノード(ingress PE)は、サービスルートの拡張カラーコミュニティ(color:0:100とcolor:0:200)を定義済みの解決RIBのマッピングコミュニティと照合し、対応するトランスポートRIB(junos-rti-tc-<100>.inet.3、またはjunos-rti-tc-<200>.inet.3)のプロトコルネクストホップ(PNH)を解決します。
- BGPルートは、関連付けられたマッピングコミュニティを送信することで、解決スキームにバインドします。
- 各トランスポートクラスは、事前に定義済みの解決スキームを自動的に2つ作成し、マッピングコミュニティを自動的に導き出します。
解決スキームの1つは、 Color:0:<val> をマッピングコミュニティとして使用するサービスルートを解決するためのものです。
もう1つの解決スキームは、 Transport-Target:0:<val> をマッピングコミュニティとして使用するトランスポートルートを解決するためのものです。
- サービスルートPNHを、事前に定義済みの解決スキームにリストされているRIBを使用して解決できない場合は、inet.3ルーティングテーブルにフォールバックできます。
- また、[ edit routing-options resolution scheme] 設定階層にあるユーザー定義の解決スキームを使用することでも、異なる色のトランスポートRIB間のフォールバックを設定することができます。
BGPクラスフルトランスポートプレーンのAS間実装
AS間ネットワークでは、BGP-LUは、すべてのサービスノードまたはPEデバイスとボーダーノード(ABRおよびASBR)BGP最低でも2つのトランスポートクラス(ゴールドおよびブロンズ)を設定した後に、クラスフルトランスポートネットワークに変換されます。
トランスポートトンネルをBGPクラスフルトランスポートに変換するには:
- サービスノード(ingress PEデバイス)とボーダーノード(ABRおよびASBR)で、ゴールドやブロンドなどのトランスポートクラスを定義します。
構成例:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - トランスポートトンネルを、トンネルのingress ノード(ingress PE、ABR、ASBR)で特定のトランスポートクラスに関連付けます。
構成例:
RSVP LSPの場合
abr23# show protocols mpls label-switched-path toASBR21-bronze { transport-class bronze; } label-switched-path toASBR22-gold { transport-class gold;IS-ISフレキシブルアルゴリズムの場合
asbr13# show routing-options flex-algorithm 128 { … color 100; use-transport-class; } flex-algorithm 129 { … color 200; use-transport-class; } - ネットワーク内のBGPクラスフルトランスポート(inet transport)とBGP-LU(inet labeled-ユニキャスト)の新しいファミリを有効にします。
構成例:
abr23# show protocols bgp group toAs2-RR27 { family inet { labeled-unicast { … } transport { … } cluster 172.16.2.3; neighbor 172.16.2.7; } - エグレスPEデバイスからのサービスルートを、適切な拡張カラーコミュニティでアドバタイズします。
構成例:
pe11# show policy-options policy-statement red term 1 { from { route-filter 192.168.3.3/32 exact; } then { community add map2gold; next-hop self; accept; } } term 2 { from { route-filter 192.168.33.33/32 exact; } then { community add map2bronze; next-hop self; accept; } } community map2bronze members color:0:200; community map2gold members color:0:100;
AS間BGPクラスフルトランスポートプレーンの機能:
- BGPクラスフルトランスポートプレーンは、各々の名前付きトランスポートクラス(ゴールドおよびブロンズ)に対して事前に定義されたトランスポートRIBを作成し、そのカラー値からマッピングコミュニティを自動的に導き出します。
-
トランスポートクラスと関連づけられた場合、AS内トランスポートルートはトンネリングプロトコルによってトランスポートRIBに入力されます。
例えば、トランスポートクラスゴールドとブロンズに関連付けれられたトランスポートトンネルルートは、それぞれトランスポートRIBの junos-rti-tc-<100>.inet.3 と junos-rti-tc-<200>.inet.3にインストールされます。
- BGPクラスフルトランスポートプレーンは、各トランスポートRIBからbgp.transport.3ルーティングテーブルにトランスポートトンネルルートをコピーするときに、一意のルート識別素とルーティングテーブルを使用します。
- ボーダーノードは、BGPセッションでファミリーinetトランスポートがネゴシエートされている場合、bgp.transport.3からのルートを他のドメインのピアにルーティングテーブルアドバタイズします。
- 受信側のボーダーノードは、これらのbgp-ctルートをbgp.transport.3ルーティングテーブルにインストールし、トランスポートルートターゲットに基づいてこれらのルートを適切なトランスポートRIBにコピーします。
- サービスノードは、サービスルート内のカラーコミュニティと解決スキーム内のマッピングコミュニティを照合し、対応するトランスポートRIB( junos-rti-tc-<100>.inet.3または junos-rti-tc-<200>.inet.3)内のPNHを解決します。
- ボーダーノードは、トランスポートルートPNHを解決するために、事前に定義された解決スキームを使用します。
- 事前定義された解決スキームであれ、ユーザーが定義した解決スキームであれ、どちらの解決スキームもサービスルートPNH解決をサポートします。事前定義された解決スキームではフォールバックとしてinet.3を使用し、ユーザー定義の解決スキームでは、トランスポートRIBのリストをPNHを解決時に指定した順序で使用できます。
- ユーザー定義の解決スキームにリストされているRIBを使用してサービスルートPNHを解決できない場合、ルートは破棄されます。
例:クラスフルトランスポートプレーンの設定(ドメイン内)
- 始める前に
- 機能の概要
- トポロジーの概要
- トポロジー図
- PE1の設定手順
- クラスフルトランスポートプレーンの検証
- 付録1:トラブルシューティング
- 付録2:すべてのデバイスでコマンドを設定する
- 付録3:PE1での設定出力を表示する
始める前に
| ハードウェアとソフトウェアの要件 | Junos OSリリース21.1R1以降。
注:
プロバイダエッジルーター(PE1およびPE2)のみが、BGP-CT機能用のJunos OSリリースサポートを必要とします。 |
| 推定読書時間 |
45分 |
| 推定設定時間 |
1時間 |
| 何を期待しますか? |
多様にルーティングされたLSPパスにマッピングされる3つのサービスレベルを備えた稼働中のBGP-CTネットワーク。BGPカラー属性拡張コミュニティを使用して、特定のトラフィック(VPNカスタマールート)を目的のトランスポートクラスにマッピングするJunos設定。プロバイダネットワーク内の多様なパスにトラフィッククラスを強制する基本的なLSPトラフィックエンジニアリング |
| ビジネスへの影響 |
この設定例を使用して、単一の自律ネットワーク(イントラドメイン)内でBGPクラスフルトランスポート(BGP-CT)機能を設定および検証します。BGP-CTは、さまざまなレベルのパフォーマンスを提供するように設計できるネットワークパスにお客様のルートをマッピングします。ドメイン内 BGP-CT の一般的なユースケースは、サービスプロバイダが BGP-CT を導入して顧客に階層型 VPN サービスレベルを提供することです。 |
| 役立つリソース: |
|
| 詳細はこちら |
BGP-CTの詳細については、BGPクラスフルトランスポートプレーンの概要を参照してください |
| ジュニパーvLabs |
ジュニパー仮想ラボ(vLabs)にアクセスして、事前設定されたサンドボックスを予約してください。サンドボックスを使用して、BGP-CT機能を操作し、理解します。ルーティングセクションには 、「クラスフルトランスポートプレーン(ドメイン内シナリオ)」 のデモがあります。 |
| 詳細情報 |
Junosサービスクラス(JCOS)オンデマンド |
機能の概要
表1は、この例で展開された設定コンポーネントの概要を示しています。
| ルーティングおよびシグナリングプロトコル |
|
| OSPF |
すべてのルーターは OSPF を IGP として実行します。すべてのルーターは、エリア0(バックボーンエリアとも呼ばれます)に属しています。単一の OSPF ルーティング ドメインは、プロバイダ ネットワークでループバック接続を提供します。 |
| 内部および外部 BGP |
カスタマーエッジ(CE)デバイスは、レイヤー3 VPNサービスの一部として、EBGPピアリングを使用してプロバイダエッジデバイスとルートを交換します。 PE デバイスは、IBGP を使用して、リモート PE と IPv4 レイヤー 3 VPN ルートを交換します。これらのルートは、トラフィックを正しいデータプレーントンネルにマッピングするために使用されるカラーコミュニティも伝送します。この例では、ルートリフレクタを使用せず、直接PE-PEピアリングを選択しています。
注:
プロバイダルーター(Pルーター)はBGPを実行しません。スケーリングを促進するためのBGPフリーコアの一部です。Pデバイスは、MPLSラベルベースのスイッチングを使用して、PEデバイス間で顧客VPNトラフィックを転送します。 |
| 出欠確認 |
各PEデバイスは、リモートPEに3つのLSPをシグナリングします。これらのLSPは、対応するサービスクラスであるゴールド、ブロンズ、およびベストエフォート(BE)にマッピングされます。 RSVPは、プロバイダネットワーク内の目的のパスにトラフィックを強制する豊富なトラフィック制御をサポートします。これらのパスは、トランスポートクラスごとにSLAを適用するために、さまざまなサービスクラス(CoS)処理のニーズを提供するように設計できます。 当社の基本トポロジーは、PE デバイス間に 3 つのパスを提供します。ERO付きの名前付きパスを使用して、コアを介したLSPの多様なルーティングを確保します。Junosは、トラフィックエンジニアリングのための豊富な機能をサポートしています。
注:
クラスフルトランスポート機能は、セグメントルーティング-トラフィックエンジニアリング(SR-TE)およびIS-ISフレックスアルゴリズムトンネルを介して確立されたLSPでもサポートされています。 |
| MPLS |
プロバイダネットワークは、MPLSベースのラベルスイッチングデータプレーンを使用します。TE パスで MPLS を使用することで、各サービスクラスを、望ましいパフォーマンスレベルでディスジョイントパス上でルーティングできるようになります。前述のように、MPLS は BGP フリー コアのサポートも提供します。 |
| トランスポートトンネル | |
| PEデバイス間には、3つのMPLSトンネル(LSP)が確立されています。 |
各トンネルには、以下のトランスポートクラスが割り当てられます。
|
| サービスファミリー | |
| レイヤー 3 VPN( |
BGP-CTは、BGPラベル付きユニキャスト、Flowspec、レイヤー2 VPNなど、他のサービスファミリとも連携します。 |
| 一次検証タスク | |
|
IGP、RSVP、MPLS、BGP、L3VPNの動作を検証します。 |
|
トランスポートクラストンネル間のトラフィックステアリングを有効にするようにネットワークを変更し、サービストンネルの障害とその後のBEパス/クラスへのフェイルオーバーをシミュレートします。 |
トポロジーの概要
この設定例は、サービスプロバイダネットワークを介して通信する2台のカスタマーエッジ(CE)デバイスを備えたシンプルなMPLSベースのレイヤー3VPNに基づいています。ネットワークコアには、ラベルベースのスイッチングを使用してVPN顧客のトラフィックを転送する3つのプロバイダ(P)ルーターがあります。2台のプロバイダエッジ(PE)デバイスは、接続されたCEにレイヤー3 VPNサービスを提供します。PEは、RSVP信号化されたMPLS LSPを使用して、コアを介してVPNトラフィックを転送します。MPLSベースのL3VPNの運用と設定に関する背景情報については 、例:基本的なMPLSベースのレイヤー3VPNを設定するを参照してください 。
ここでは、CE1からCE2へのトラフィックの左から右へのフローと、PE1がPE2から学習したルートにアタッチされたBGPカラーコミュニティを使用して、目的のLSP転送ネクストホップを介してリモートCEに送信されたトラフィックをマッピングする方法に焦点を当てます。この例では、PE1 が明示的なルート オブジェクト(ERO)を使用して、これらの LSP を多様なパス上で強制的にルーティングします。PE2 ではこのステップを省略し、IGP ロードバランシングに基づいて LSP をルーティングできるようにします。トラフィックがCE1からCE2に流れるようにするには、CE1にCE2に到達するルートが必要です。CE2のルートは、CE1から引き寄せられるトラフィックとは反対方向に移動します。つまり、CE2のループバックへのルートは右から左に移動します。
この例では、ゴールドサービスクラスLSPはPE1-P1-PE2パスに制約されています。ブロンズサービスクラスは、PE1-P2-PE2パスを使用します。ベストエフォート LSP は、PE1-P3-PE2 パスに沿ってルーティングされます。トポロジー図では、色付きのリンクを使用して 3 つのパスを表しています。
この例では、 protocols mpls icmp-tunneling ステートメントを追加します。これは、レイヤー 3 VPN トラフィックのように、そのパスに MPLS スイッチングが含まれる場合でも、CE デバイスがプロバイダ ネットワークを介したパスをトレースできるようにするためです。このオプションは、トランスポートクラスの関数が使用されるときに予想される転送パスを確認するのに役立ちます。
表2は、このトポロジーのコンテキストにおける各デバイスの役割と機能を説明しています。任意のデバイス名をクリックすると、そのクイック設定が表示されます。
| デバイス名 | 役割 |
機能 |
| CE1 | ローカル CE デバイス(R1)。 | CEデバイスのループバックアドレスをアドバタイズして学習するためのPE1ルーターへのEBGPピア。CE2のループバックアドレスへのpingを使用してサービス接続をテストします。 |
| CE2 | リモート CE デバイス(R7) | CEデバイスのループバックアドレスをアドバタイズして学習するためのPE2ルーターへのEBGPピアリング。 カラーマッピングコミュニティを設定し、アタッチします。 |
| PE1(DUT) | ローカルPEデバイス(R2)。 | PE1 は、CE2 を起点とするカラータグ付きサービスルートを、共同スポンサーのトランスポートクラス(TC)にマッピングします。PE1は、IBGPセッションを介してPE2へのカラータグルートを受信します。 この例では、PE1 は ERO ベースの制約を使用して、プロバイダのコア上に 3 つの LSP の多様なルーティングを強制します。 |
| PE2 | リモート PE デバイス(R6)。 | PE2は、CE2が受信したカラータグ付きルートを、IBGPを使用してPE1に再アドバタイズします。これらのルートは、 inet-vpn ファミリーを使用して、カラーマップされたTCを備えたレイヤー3 VPNサービスをサポートします。 |
| P1、P2、P3 | プロバイダデバイスP1、P2、およびP3(R3、R4、およびR5)。 | P1-P3デバイスは、サービスプロバイダのコアネットワークを表します。これらは、L3 VPNを介して送信されたCEトラフィックを転送するためにMPLSラベルスイッチを実行する純粋なトランジットデバイスです。 |
トポロジー図
PE1の設定手順
CLIのナビゲーションについては、設定モードでのCLIエディターの使用を参照してください
このセクションでは、この例でPE1デバイスの設定に必要な主な設定タスクについて説明します。最初のステップは、基本的なレイヤー 3 VPN サービスを設定するのと共通です。以下の一連の手順は、レイヤー 3 VPN に BGP-CT 機能を追加する場合に固有のものです。どちらのPEデバイスも同様の構成を持っています。ここではPE1に焦点を当てます。
-
まず、一般的なレイヤー3VPNをプロビジョニングします。
-
IPv4用のループバックインターフェイス、コアフェーシングインターフェイス、およびCEインターフェイスを設定し、番号を付けます。MPLSスイッチングをサポートするために、Pデバイスに接続するコアに面するインターフェイスで
mplsファミリーを必ず有効にしてください。 -
自律システム番号を設定します。
-
ループバックインターフェイスとコアに面するインターフェイスでシングルエリアOSPFを設定します。
-
ループバックインターフェイスとコアに面するインターフェイスでRSVPを設定します。
-
リモートPEデバイスPE2へのIBGPピアリングセッションを設定します。IPv4レイヤー3VPNをサポートする
inet-vpnアドレスファミリーを含めます。 -
CE1デバイス用にVRFベースのルーティングインスタンスを設定します。EBGPをPE-CEルーティングプロトコルとして使用します。
[edit] set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE1 to P2" set interfaces ge-0/0/2 unit 0 family inet address 10.1.24.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE1 to P3" set interfaces ge-0/0/3 unit 0 family inet address 10.1.25.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32
[edit] set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 64510 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn interface ge-0/0/0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12
[edit] set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0
[edit] set routing-options route-distinguisher-id 192.168.0.1 set routing-options autonomous-system 65412
-
-
クラスフルトランスポートプレーンをレイヤー3 VPNに追加します。
ゴールドとブロンズのトランスポートクラスを設定します。
これは、クラスフルトランスポート機能を設定する上で重要な手順です。これらのトランスポートクラスは、プロバイダーコアを通過するRSVPシグナル(場合によってはトラフィックエンジニアリング)LSPにマッピングされます。CE2から学習したリモートルートには、これらのトランスポートクラスにマッピングされるカラーコミュニティがタグ付けされ、そうすることでPEデバイス間の目的のLSPにマッピングされます。
[edit] set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set routing-options resolution preserve-nexthop-hierarchy
注:グローバルまたはプロトコルレベルで
preserve-nexthop-hierarchyステートメントを有効または無効にすると、影響を受けるルートが指すネクストホップが再計算され、PFEとカーネルにダウンロードされます。これにより、より大規模な環境ではデバイスのCPUスパイクが高くなり、PFEでルートが再プログラムされるまでパケット損失が発生します。 -
PE1 から PE2 までの 3 つの LSP を、それぞれが異なる P ルーターを強制的に通過する制約付きルーティングで設定します。これらのLSPのうち2つは、 gold および bronze トランスポートクラスにマッピングされます。ゴールドLSPはP1を、ブロンズはP2を、ベストエフォートはP3デバイスを介してルーティングされます。
トランスポートクラスにマッピングされると、サービスプロバイダは、BGPカラーコミュニティで示される特定の顧客トラフィックを特定のLSPに配置できます。このカラーをLSPにマッピングすることで、サービスプロバイダは異なるSLAで階層型サービスを提供できます。
この例では、厳密な ERO を使用して、3 つの LSP がトポロジーで利用可能な 3 つのパス上で多様にルーティングされるようにしています。
[edit] set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path lsp_to_pe2 primary best-effort set protocols mpls label-switched-path gold_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path gold_lsp_to_pe2 preference 5 set protocols mpls label-switched-path gold_lsp_to_pe2 primary gold set protocols mpls label-switched-path gold_lsp_to_pe2 transport-class gold set protocols mpls label-switched-path bronze_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path bronze_lsp_to_pe2 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe2 primary bronze set protocols mpls label-switched-path bronze_lsp_to_pe2 transport-class bronze set protocols mpls path gold 10.1.23.2 strict set protocols mpls path bronze 10.1.24.2 strict set protocols mpls path best-effort 10.1.25.2 strict set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0
-
デフォルトのサービスクラス(ベストエフォート型)トンネルへのフォールバックを容易にするために、ゴールドおよびブロンズトランスポートクラストンネルを低いグローバルプリファレンスで設定します。この例では、プリファレンス値がデフォルトの7から5に変更されています。これにより、ゴールドまたはブロンズトンネルが使用できなくなった場合のフォールバックとして、ベストエフォート型トンネルを使用できます。ゴールドトンネルとブロンズトンネルの優先度を低い(より優先される)設定すると、サービスルートがベストエフォートトンネルに解決できる場合でも、転送対象に選択されます。
注:このセクションでは、PE1デバイスに必要な設定に焦点を当てました。クラスフルトランスポートのネクストホップ選択機能がPE1で機能するためには、リモートCE2デバイスのルートにカラーコミュニティのタグを付ける必要があることに注意してください。このタグ付けは、リモートPE2デバイスまたはリモートCE2デバイスで実行できます。ここでは、完全性のために後者のアプローチを示します。
-
リモートCE2で追加されたカラーコミュニティタグを、ブロンズおよびゴールドTCのトランスポートクラス定義に一致させます。
[edit] set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then community add map2bronze set policy-options policy-statement adv_direct term 1 then accept set policy-options community map2bronze members color:0:200 set policy-options community map2gold members color:0:100
クラスフルトランスポートプレーンの検証
このセクションでは、ワーキングクラスフルトランスポート機能を示すコマンドに焦点を当てます。クラスフルトランスポート機能に必要な基盤となる機能を検証するために使用されるコマンドについては、「 付録1:トラブルシューティング 」を参照してください。
これらのコマンドを使用して、BGPクラスフルトランスポートが正しく動作することを確認します。
| コマンド | 検証タスク |
| show route resolution scheme | サービスクラスルートがLSPネクストホップにどのように解決されるかを表示します。特定のルートの解決ルーティングテーブルを検証します。 |
| show route receiving-protocol bgp pe2-loopback-address | PE1が受信したVPNルートに、BGPカラーコミュニティが接続されていることを確認します。 |
| show routeおよびshow route forwarding-table VPNvpn | PE1でのルートのプロトコルネクストホップ(PNH)を表示して、トランスポートトンネルの選択を確認します。 |
| show mpls lsp statistics and show route forwarding-table | 特定のトランスポートクラスルートで使用されるトランスポートトンネルを確認します。 |
- トランスポートクラスとトランスポートトンネルの検証
- ネクストホップ解決スキームの検証
- CE2ルートのカラータグとネクストホップ選択の検証
- エンドツーエンドの接続性を検証する
- ベストエフォートへのフェイルオーバーを確認する
トランスポートクラスとトランスポートトンネルの検証
目的
PE1とPE2は、RSVP信号化されたMPLSトランスポートトンネルを使用して、差別化されたサービスレベルを提供できるレイヤー3 VPNサービスをサポートします。これらのサービスルートのネクストホップは、対応するサービスクラスに基づいて特定のMPLSトンネルに解決されます。サービスクラスは、VPNカスタマールートにBGPカラーコミュニティを付加することでシグナリングされます。
このパートでは、PE1 の 3 つの LSP がすべて動作していること、正しいトランスポートクラスにマッピングされていること、プロバイダのコア上で正しくルーティングされていることを確認します。
アクション
動作モードから、 show route 192.168.0.2 コマンドを入力します。
user@PE1 show route 192.168.0.2
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[OSPF/10] 00:27:20, metric 2
to 10.1.24.2 via ge-0/0/2.0
> to 10.1.25.2 via ge-0/0/3.0
to 10.1.23.2 via ge-0/0/1.0
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/7/1] 00:13:09, metric 2
> to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/5/1] 00:13:11, metric 2
> to 10.1.23.2 via ge-0/0/1.0, label-switched-path gold_lsp_to_pe2
junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/5/1] 00:13:08, metric 2
> to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2
意味
出力から、PE1がOSPFを介してPE2のループバックへの3つのパスを学習したことがわかります。これらのルートは、 inet.0 テーブルにあります。また、3つのLSPすべてが、PE2に到達するための有効なネクストホップとして表されていることにも注意してください。これらの各LSPは、異なるルーティングテーブルに収容されていることに注意してください。IPネクストホップの強調表示された部分(および対応するインターフェイス名)は、コアを介した目的の多様なLSPルーティングを確認します。ゴールドパスにマッピングされたトラフィックは10.1.23.2に送信され、ブロンズパスとBEのトラフィックはそれぞれ10.1.24.2および10.1.25.2に送信されます。
以下のトランスポートRIBとトランスポートトンネルが作成されます。
-
junos-rti-tc-100.inet.3gold_lsp_to_pe2向け -
junos-rti-tc-200.inet.3bronze_lsp_to_pe2向け -
lsp_to_pe2向け
inet.3
ネクストホップ解決スキームの検証
目的
サービスルート解決スキーム、関連するマッピングコミュニティ、および寄与するルーティングテーブル上でネクストホップがどのように解決されるかを確認します。
アクション
動作モードから、 show route resolution scheme all コマンドを入力します。
user@PE1> show route resolution scheme all Resolution scheme: junos-resol-schem-tc-100-v4-service References: 1 Mapping community: color:0:100 Resolution Tree index 1, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet.3 inet.3 Resolution scheme: junos-resol-schem-tc-100-v4-transport References: 1 Mapping community: transport-target:0:100 Resolution Tree index 3, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet.3 Resolution scheme: junos-resol-schem-tc-100-v6-service References: 1 Mapping community: color:0:100 Resolution Tree index 2, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet6.3 inet6.3 Resolution scheme: junos-resol-schem-tc-100-v6-transport References: 1 Mapping community: transport-target:0:100 Resolution Tree index 4, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet6.3 Resolution scheme: junos-resol-schem-tc-200-v4-service References: 1 Mapping community: color:0:200 Resolution Tree index 5, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet.3 inet.3 Resolution scheme: junos-resol-schem-tc-200-v4-transport References: 1 Mapping community: transport-target:0:200 Resolution Tree index 7, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet.3 Resolution scheme: junos-resol-schem-tc-200-v6-service References: 1 Mapping community: color:0:200 Resolution Tree index 6, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet6.3 inet6.3 Resolution scheme: junos-resol-schem-tc-200-v6-transport References: 1 Mapping community: transport-target:0:200 Resolution Tree index 8, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet6.3
意味
出力のIPv4部分に注目すると、junos-tc-100 (gold)トランスポートクラスには、それぞれサービスルートとトランスポートルートに使用される2つの解決スキーム( junos-resol-schem-tc-100-v4-serviceとjunos-resol-schem-tc-100-v4-transport )があることがわかります。
ゴールド サービス ルート( junos-resol-schem-tc-100-v4-service )の解決スキームは、junos-rti-tc-100.inet.3 と inet.3 の両方のルーティング テーブル(サンプル出力で強調表示されています)で解決します。サービステーブルとBE解決テーブルの両方を一覧表示すると、サービスクラスがダウンしたときにフォールバックがどのように行われるかがわかります。そのため、サービスLSPの優先値を変更(デフォルトの7ではなく5に設定)、サービスルートが常にBEフォールバックよりも優先されるようにしました。
CE2ルートのカラータグとネクストホップ選択の検証
目的
PE2が、ブロンズサービスクラス(カラー200)を選択するカラーコミュニティでCE2のループバックルートをアドバタイズしていることを確認します。
この例では、カラーコミュニティを接続するようにCE2デバイスを設定します。PE2は、PE1にルートを再アドバタイズする際に、このコミュニティをそのままにします。つまり、VPNのお客様は独自のサービスクラスマッピングを有効にすることができます。必要に応じて、PE ルーターは CE から受け取ったコミュニティを漂白または剥がすことができます。この場合、PE デバイスは、PE1 に再アドバタイズする前に、目的のカラーマッピングコミュニティを CE ルートにアタッチするように設定する必要があります。
アクション
動作モードから、 show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail コマンドを入力します。
user@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 192.168.0.2:12
VPN Label: 299808
Nexthop: 192.168.0.2
Localpref: 100
AS path: 64520 I
Communities: target:65412:12 color:0:200
PE1のVPNルーティングインスタンスでCE2ループバックの転送テーブルエントリーを表示します。転送ネクストホップが目的のトランスポートクラス(ブロンズ)と一致していることを確認します。 show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive コマンドを使用します。
user@PE1> show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive
Routing table: CE1_L3vpn.inet [Index 10]
Internet:
Destination: 172.16.255.2/32
Route type: user
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE, prefix load balance
Next-hop type: indirect Index: 1048574 Reference: 2
Nexthop:
Next-hop type: composite Index: 662 Reference: 2
Load Balance Label: Push 299808, None
Nexthop: 10.1.24.2
Next-hop type: Push 299872 Index: 653 Reference: 2
Load Balance Label: None
Next-hop interface: ge-0/0/2.0
意味
強調表示されたエントリーは、CE2ループバックルートに一致するトラフィックがge-0/0/2インターフェイスを使用して10.1.24.2に送信されていることを確認します。LSPに使用されたEROを思い出して、このインターフェイスとネクストホップはブロンズLSPとトランスポートクラスに関連付けられています。 299808 ラベルは、サービスVRFを識別するために使用されます。外側の RSVP トランスポートラベルは 299872です。
show rsvp session detail name bronze_lsp_to_pe2コマンドで、これがブロンズクラスの正しいRSVPトランスポートラベルであることをすばやく確認します
root@PE1> show rsvp session detail name bronze_lsp_to_pe2 Ingress RSVP: 3 sessions 192.168.0.2 From: 192.168.0.1, LSPstate: Up, ActiveRoute: 0 LSPname: bronze_lsp_to_pe2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 299872 Resv style: 1 FF, Label in: -, Label out: 299872 Time left: -, Since: Tue Aug 16 12:17:12 2022 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 23256 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.1.24.2 (ge-0/0/2.0) 1 pkts RESV rcvfrom: 10.1.24.2 (ge-0/0/2.0) 1 pkts, Entropy label: Yes Explct route: 10.1.24.2 10.1.46.2 Record route: <self> 10.1.24.2 10.1.46.2 Total 1 displayed, Up 1, Down 0
強調表示された部分は、ブロンズLSPがP2デバイスを介してルーティングされ、CE2 ループバックアドレスのVPN転送テーブルで以前に確認した示されたRSVPトランスポートラベル(299856)に関連付けられていることを示しています。
エンドツーエンドの接続性を検証する
目的
CE1 から CE2 の間で ping を実行することで、プロバイダのドメイン全体のエンドツーエンド接続を確認します。MPLSトラフィック統計を調べて、ブロンズトランスポートクラスが使用されていることをさらに確認します。
アクション
動作モードから、 ping コマンドを入力します。
user@CE1> ping 172.16.255.2 source 172.16.255.1 count 100 rapid PING 172.16.255.2 (172.16.255.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --- 172.16.255.2 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.647/3.589/30.264/2.695 ms
PE1での動作モードから、 show mpls lsp statistics コマンドを入力します。
user@PE1> show mpls lsp statistics
Ingress LSP: 3 sessions
To From State Packets Bytes LSPname
192.168.0.2 192.168.0.1 Up 100
8400 bronze_lsp_to_pe2
192.168.0.2 192.168.0.1 Up 0 0 gold_lsp_to_pe2
192.168.0.2 192.168.0.1 Up 0 0 lsp_to_pe2
Total 3 displayed, Up 3, Down 0
<output truncated for brevity>
アクション
CE1からCE2のループバックまでのルートをトレースします。当社の設定には、プロバイダコアでMPLSホップを持つICMPベースのトレースルートをサポートするための icmp-tunneling ステートメントが含まれています。
user@CE1> traceroute no-resolve 172.16.255.2
traceroute to 172.16.255.2 (172.16.255.2), 30 hops max, 52 byte packets
1 172.16.1.2 2.174 ms 1.775 ms 1.917 ms
2 10.1.24.2 5.171 ms 5.768 ms 4.900 ms
MPLS Label=299872 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 10.1.46.2 4.707 ms 4.347 ms 4.419 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.255.2 5.640 ms 5.851 ms 44.777 ms
意味
ping交換は成功し、統計からブロンズトランスポートトンネルの使用が確認されています。CE2へのルートに200色のコミュニティが付着していることを考えると、これは予想されることです。トレースルートの結果から、トラフィックがLSP上に転送され、このLSPが10.1.24.2を転送していることが確認されました。これは、P2デバイスに割り当てられたIPアドレスです。転送ネクストホップと外側ラベルの値から、このトラフィックがブロンズサービスクラスLSPで送信されていることを確認します。
ベストエフォートへのフェイルオーバーを確認する
目的
ブロンズトランスポートLSPをダウンして、CE2に送信されたトラフィックがBEパスにフェイルオーバーすることを確認します。
アクション
設定モードに入り、無効なネクストホップをブロンズトランスポートトンネルのEROとして指定します。ERO 要件を満たすことができない場合、関連する LSP がダウンします。
[edit] user@PE1# set protocols mpls path bronze 10.1.66.6 strict
変更がコミットされると、ブロンズ トンネルが表示されます。
root@PE1> show mpls lsp ingress Ingress LSP: 3 sessions To From State Rt P ActivePath LSPname 192.168.0.2 0.0.0.0 Dn 0 - bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * gold gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * best-effort lsp_to_pe2
CE1からCE2のループバックに ping とtraceルートコマンドを繰り返します。
root@CE1> ping 172.16.255.2 source 172.16.255.1 count 100 rapid
PING 172.16.255.2 (172.16.255.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.16.255.2 ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.164/5.345/12.348/1.240 ms
root@CE1> traceroute no-resolve 172.16.255.2
traceroute to 172.16.255.2 (172.16.255.2), 30 hops max, 52 byte packets
1 172.16.1.2 2.493 ms 1.766 ms 1.913 ms
2 10.1.25.2 5.211 ms 5.016 ms 5.514 ms
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 10.1.56.2 4.216 ms 4.467 ms 4.551 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.255.2 5.492 ms 5.543 ms 5.112 ms
PE1 の MPLS 統計情報を再度表示します。
user@PE1> show mpls lsp statistics root@PE1> show mpls lsp statistics Ingress LSP: 3 sessions To From State Packets Bytes LSPname 192.168.0.2 0.0.0.0 Dn NA NA bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 100 8400 lsp_to_pe2 Total 3 displayed, Up 2, Down 1 . . .
意味
ping交換は、現在ベストエフォートパスにありますが、まだ成功しています。PEでは、統計情報により、ベストエフォートトランスポートトンネルの使用が確認されています。トレースルートは、PE1がPE3を介して10.1.25.2ネクストホップに転送していることを示しています。これにより、トランスポートトンネルに障害が発生した場合に、色付きのトランスポートクラスからベストエフォートクラスへのフェイルオーバーが確認されます。
このセクションでは、ブロンズサービスクラスにマッピングされたLSPをダウンさせることで、BEクラスへのフェイルオーバーを実現しました。別の方法として、CE2デバイスのEBGPエクスポートポリシーを変更して、ゴールド(100)カラーコミュニティをアタッチすることを検討してください。このアプローチでは、CE1からCE2へのpingトラフィックがBEにフェイルオーバーするのではなく、ゴールドLSPを使用することが想定されます。このアプローチを好む場合、以下は CE2 でのトリックを実行します。必ずCE2で変更をコミットしてください。
[edit] root@CE2# delete policy-options policy-statement adv_direct term 1 then community add map2bronze root@CE2# set policy-options policy-statement adv_direct term 1 then community add map2gold
付録1:トラブルシューティング
検証セクションは、ネットワークが動作していることを前提としており、BGP-CT の動作確認に焦点を合わせることができます。BGP-CT機能は、MPLSベースのレイヤー3 VPNのコンテキストにおいて、有効なインターフェイス、IGP、RSVP、MPLS、BGPを備えたネットワークに依存しています。
表4は、BGP-CTソリューションが期待どおりに機能しない場合に注意すべき事項についてのガイダンスを示しています。テーブルは、基本的なインターフェイス接続から始まり、PE デバイス間の BGP ルート交換の成功で終わる、下から上へと構成されています。
この例の一部として、ループバックアドレスとルーターIDを設定します。デバイスの以前の RID が異なっていた場合、安定するまでに時間がかかることがあります。RIDの変更は非常に混乱を招くものであり、頻繁に起こることではありません。ラボ環境の場合、新しいRIDをコミットした直後に、すべてのデバイスで restart routing 動作モードコマンドを発行することをお勧めします。
| 機能層 | 検証アプローチ |
| インターフェイスとIPアドレッシング | トポロジー内のすべてのインターフェイスが動作していることを確認します。各リンクのローカルエンドとリモートエンドの両方にpingできることを確認します。ほとんどのネットワークと同様に、この例のプロトコルとサービスには、機能するIPv4インフラストラクチャが必要ですroot@PE1> show interfaces terse | match "(ge-0/0/0|ge-0/0/1|ge-0/0/2|ge-0/0/3)"
ge-0/0/0 up up
ge-0/0/0.0 up up inet 172.16.1.2/30
ge-0/0/1 up up
ge-0/0/1.0 up up inet 10.1.23.1/24
ge-0/0/2 up up
ge-0/0/2.0 up up inet 10.1.24.1/24
ge-0/0/3 up up
ge-0/0/3.0 up up inet 10.1.25.1/24
root@PE1> ping 10.1.23.2 count 1
PING 10.1.23.2 (10.1.23.2): 56 data bytes
64 bytes from 10.1.23.2: icmp_seq=0 ttl=64 time=2.951 ms
--- 10.1.23.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.951/2.951/2.951/0.000 ms
root@PE1> ping 172.16.1.1 routing-instance CE1_L3vpn count 1
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=64 time=2.755 ms
--- 172.16.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.755/2.755/2.755/0.000 ms
|
| OSPF(IGP)ルーティング | すべてのプロバイダデバイスに、予想されるすべての OSPF 隣接関係があることを確認します。 show ospf interfaces および show ospf neighbors 動作モードコマンドを使用します。プロバイダループバックアドレスのルートを表示し、すべてのリモートループバックアドレス(show route protocol ospf | match 192.168.0)の有効なOSPFパスを確認します。ローカルループバックからすべてのプロバイダルーターのリモートループバックアドレスにpingを実行します。この例では、CSPF ベースの LSP を使用しています。そのためには、 root@PE1> show ospf interface Interface State Area DR ID BDR ID Nbrs ge-0/0/1.0 BDR 0.0.0.0 192.168.0.11 192.168.0.1 1 ge-0/0/2.0 BDR 0.0.0.0 192.168.0.12 192.168.0.1 1 ge-0/0/3.0 DR 0.0.0.0 192.168.0.1 192.168.0.13 1 lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0 root@PE1> show ospf neighbor Address Interface State ID Pri Dead 10.1.23.2 ge-0/0/1.0 Full 192.168.0.11 128 34 10.1.24.2 ge-0/0/2.0 Full 192.168.0.12 128 32 10.1.25.2 ge-0/0/3.0 Full 192.168.0.13 128 37 root@PE1> show route protocol ospf| match 192.168.0 192.168.0.2/32 *[OSPF/10] 00:10:15, metric 2 192.168.0.11/32 *[OSPF/10] 00:18:40, metric 1 192.168.0.12/32 *[OSPF/10] 00:18:35, metric 1 192.168.0.13/32 *[OSPF/10] 00:10:15, metric 1 root@PE1> ping 192.168.0.2 source 192.168.0.1 count 1 PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=63 time=3.045 ms --- 192.168.0.2 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.045/3.045/3.045/0.000 ms |
| MPLS と RSVP | mplsファミリーですべてのコア インターフェイスが有効になっていることを確認します。 show interfaces terseコマンドを使用します。また、protocols mpls階層とprotocols RSVP階層下のすべてのプロバイダインターフェイスが有効になっていることも確認します。show mpls interfaces コマンドと show rsvp interfaces コマンドを使用します。
注:
MPLS ファミリーおよび各プロトコルに対して正しいインターフェイスユニット番号が記載されていることを確認してください。この例では、デフォルトのユニット番号であるユニット0をすべてのインターフェイスで使用しています。 root@PE1> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/1.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/2.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/3.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
lo0.0 Up 0 100% 0bps 0bps 0bps 0bps
root@PE1> show mpls interface
Interface State Administrative groups (x: extended)
ge-0/0/1.0 Up <none>
ge-0/0/2.0 Up <none>
ge-0/0/3.0 Up <none>
PEルーターでは、リモートPEデバイスのループバックアドレスで、エグレスするようにLSPが正しく定義されていることを確認します。ERO およびその他の TE 制約が有効であることを確認します。
注:この例では、CSPF ベースの LSP を使用しています。そのためには、IGPがTEデータベース(TED)をサポートしている必要があります。OSPFがIGPの場合は、必ず
traffic-engieering設定ステートメントを含めてください。あるいは、LSP定義で
no-cspfステートメントを使用して、方程式からCSPFを削除することを検討します。
root@PE1> show mpls lsp Ingress LSP: 3 sessions To From State Rt P ActivePath LSPname 192.168.0.2 192.168.0.1 Up 0 * bronze bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * gold gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * best-effort lsp_to_pe2 Total 3 displayed, Up 3, Down 0 Egress LSP: 3 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - bronze_lsp_to_pe1 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - gold_lsp_to_pe1 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - lsp_to_pe1 Total 3 displayed, Up 3, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 |
| BGP | PEデバイスで show bgp summaryコマンドを使用して、CEへのEBGPセッションとリモートPEへのIBGPセッションの両方が確立されていることを確認します。ping を実行できるにもかかわらず BGP がダウンしている場合は、ピア定義が正しくないか疑われます。ループバックピアリング(IBGPの場合)には local-addressステートメントが必要であることを思い出してください。EBGPの場合、直接接続されたネクストホップを指定し、 edit routing-options の下にあるローカルAS番号とEBGPピアグループの下のリモートAS番号が指定されていることを確認します。PE-PEセッションで root@PE1> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
bgp.l3vpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1 64510 55 55 0 0 23:13 Establ
CE1_L3vpn.inet.0: 1/2/2/0
192.168.0.2 65412 57 56 0 0 23:11 Establ
inet.0: 0/0/0/0
bgp.l3vpn.0: 2/2/2/0
CE1_L3vpn.inet.0: 2/2/2/0 show route advertisingおよびreceiving protocolコマンドは、特定のBGPスピーカーがそれぞれどのルートをアドバタイズまたは受信するかを確認する場合に便利です。 root@PE1> show route advertising-protocol bgp 192.168.0.2 CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.0/30 Self 100 I * 172.16.255.1/32 Self 100 64510 I root@PE1> show route receive-protocol bgp 192.168.0.2 inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.2.0/30 192.168.0.2 100 I * 172.16.255.2/32 192.168.0.2 100 64520 I junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 192.168.0.2:12:172.16.2.0/30 * 192.168.0.2 100 I 192.168.0.2:12:172.16.255.2/32 * 192.168.0.2 100 64520 I |
| レイヤー 3 VPN | IBGPセッションが family inet-vpn ルートをサポートしていることを確認します。リモートPEによってアドバタイズされたルートが、ルートターゲットに基づいて正しいインスタンスにインポートされていることを確認します。各PEのルーティングインスタンスで使用されるインポートおよびエクスポートポリシーが一致し、正しいルートをアドバタイズすることを確認します。BGP検証セクションの一部は、リモートCEルートの受信と、それらのルートのVRFインスタンスへのインポートを確認します。 root@PE1> show bgp neighbor 192.168.0.2 | match nlri
NLRI for restart configured on peer: inet-unicast inet-vpn-unicast
NLRI advertised by peer: inet-unicast inet-vpn-unicast
NLRI for this session: inet-unicast inet-vpn-unicast
root@PE1> show route table CE1_L3vpn.inet
root@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail
. . .
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 192.168.0.2:12
VPN Label: 299776
Nexthop: 192.168.0.2
Localpref: 100
AS path: 64520 I
Communities: target:65412:12 color:0:200
root@PE1> show route table CE1_L3vpn.inet
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.0/30 *[Direct/0] 00:30:11
> via ge-0/0/0.0
[BGP/170] 00:29:57, localpref 100
AS path: 64510 I, validation-state: unverified
> to 172.16.1.1 via ge-0/0/0.0
172.16.1.2/32 *[Local/0] 00:30:11
Local via ge-0/0/0.0
172.16.2.0/30 *[BGP/170] 00:21:26, localpref 100, from 192.168.0.2
AS path: I, validation-state: unverified
> to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
172.16.255.1/32 *[BGP/170] 00:29:57, localpref 100
AS path: 64510 I, validation-state: unverified
> to 172.16.1.1 via ge-0/0/0.0
172.16.255.2/32 *[BGP/170] 00:29:40, localpref 100, from 192.168.0.2
AS path: 64520 I, validation-state: unverified
> to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2 BGPのトラブルシューティングで説明した方法を使用して、CEデバイスが予想ルートを受信し、アドバタイズしていることを確認します。 |
付録2:すべてのデバイスでコマンドを設定する
この例をすばやく設定するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit]階層レベルのCLIにコマンドをコピー&ペーストします。
CE1
set interfaces ge-0/0/0 unit 0 description "Link from CE1 to PE1 for Layer 3 VPN" set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.1/32 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then accept set protocols bgp group ToPE1 type external set protocols bgp group ToPE1 export adv_direct set protocols bgp group ToPE1 peer-as 65412 set protocols bgp group ToPE1 neighbor 172.16.1.2 set routing-options router-id 172.16.255.1 set routing-options autonomous-system 64510 set system host-name CE1
CE2
set interfaces ge-0/0/0 unit 0 description "Link from CE2 to PE2 for Layer 3 VPN" set interfaces ge-0/0/0 unit 0 family inet address 172.16.2.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.2/32 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then community add map2bronze set policy-options policy-statement adv_direct term 1 then accept set policy-options community map2bronze members color:0:200 set policy-options community map2gold members color:0:100 set protocols bgp group PE2 type external set protocols bgp group PE2 export adv_direct set protocols bgp group PE2 peer-as 65412 set protocols bgp group PE2 neighbor 172.16.2.2 set routing-options router-id 172.16.255.2 set routing-options autonomous-system 64520 set system host-name CE2
PE1(DUT)
set interfaces ge-0/0/0 unit 0 description "Link from PE1 to CE1" set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.2/30 set interfaces ge-0/0/1 unit 0 description "Link from PE1 to P1" set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE1 to P2" set interfaces ge-0/0/2 unit 0 family inet address 10.1.24.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE1 to P3" set interfaces ge-0/0/3 unit 0 family inet address 10.1.25.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 64510 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn interface ge-0/0/0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols mpls icmp-tunneling set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path lsp_to_pe2 primary best-effort set protocols mpls label-switched-path gold_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path gold_lsp_to_pe2 preference 5 set protocols mpls label-switched-path gold_lsp_to_pe2 primary gold set protocols mpls label-switched-path gold_lsp_to_pe2 transport-class gold set protocols mpls label-switched-path bronze_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path bronze_lsp_to_pe2 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe2 primary bronze set protocols mpls label-switched-path bronze_lsp_to_pe2 transport-class bronze set protocols mpls path gold 10.1.23.2 strict set protocols mpls path bronze 10.1.24.2 strict set protocols mpls path best-effort 10.1.25.2 strict set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0 set routing-options route-distinguisher-id 192.168.0.1 set routing-options resolution preserve-nexthop-hierarchy set routing-options router-id 192.168.0.1 set routing-options autonomous-system 65412 set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set system host-name PE1
PE2
set interfaces ge-0/0/0 unit 0 description "Link from PE2 to P1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.36.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from PE2 to P2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.46.2/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE2 to P3" set interfaces ge-0/0/2 unit 0 family inet address 10.1.56.2/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE2 to CE2" set interfaces ge-0/0/3 unit 0 family inet address 172.16.2.2/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set routing-instances CE2_L3vpn instance-type vrf set routing-instances CE2_L3vpn protocols bgp group CE2 type external set routing-instances CE2_L3vpn protocols bgp group CE2 peer-as 64520 set routing-instances CE2_L3vpn protocols bgp group CE2 neighbor 172.16.2.1 set routing-instances CE2_L3vpn interface ge-0/0/3.0 set routing-instances CE2_L3vpn route-distinguisher 192.168.0.2:12 set routing-instances CE2_L3vpn vrf-target target:65412:12 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.2 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.1 set protocols mpls icmp-tunneling set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path gold_lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path gold_lsp_to_pe1 transport-class gold set protocols mpls label-switched-path gold_lsp_to_pe1 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path bronze_lsp_to_pe1 transport-class bronze set protocols mpls label-switched-path bronze_lsp_to_pe1 preference 5 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set routing-options route-distinguisher-id 192.168.0.2 set routing-options router-id 192.168.0.2 set routing-options autonomous-system 65412 set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set system host-name PE2
P1
set interfaces ge-0/0/0 unit 0 description "Link from P1 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.23.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P1 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.36.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.11/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.11 set system host-name P1
P2
set interfaces ge-0/0/0 unit 0 description "Link from P2 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.24.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P2 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.46.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.12/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.12 set system host-name P2
P3
set interfaces ge-0/0/0 unit 0 description "Link from P3 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.25.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P3 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.56.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.13/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.13 set system host-name P3
付録3:PE1での設定出力を表示する
中括弧形式での完全なPE1設定
user@PE1# show | no-more
system {
host-name PE1;
}
interfaces {
ge-0/0/0 {
unit 0 {
description "Link from PE1 to CE1";
family inet {
address 172.16.1.2/30;
}
}
}
ge-0/0/1 {
unit 0 {
description "Link from PE1 to P1";
family inet {
address 10.1.23.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
description "Link from PE1 to P2";
family inet {
address 10.1.24.1/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
description "Link from PE1 to P3";
family inet {
address 10.1.25.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-instances {
CE1_L3vpn {
instance-type vrf;
protocols {
bgp {
group CE1 {
type external;
peer-as 64510;
neighbor 172.16.1.1;
}
}
}
interface ge-0/0/0.0;
route-distinguisher 192.168.0.1:12;
vrf-target target:65412:12;
}
}
routing-options {
route-distinguisher-id 192.168.0.1;
resolution {
preserve-nexthop-hierarchy;
}
router-id 192.168.0.1;
autonomous-system 65412;
transport-class {
name gold {
color 100;
}
name bronze {
color 200;
}
}
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.0.1;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
neighbor 192.168.0.2;
}
}
mpls {
label-switched-path lsp_to_pe2 {
to 192.168.0.2;
primary best-effort;
}
label-switched-path gold_lsp_to_pe2 {
to 192.168.0.2;
preference 5;
primary gold;
transport-class gold;
}
label-switched-path bronze_lsp_to_pe2 {
to 192.168.0.2;
preference 5;
primary bronze;
transport-class bronze;
}
path gold {
10.1.23.2 strict;
}
path bronze {
10.1.24.2 strict;
10.1.66.6 strict;
}
path best-effort {
10.1.25.2 strict;
}
icmp-tunneling;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
}
rsvp {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
}
VPNサービスのカラーベースマッピングの概要
静的な色付きLSPおよびBGPセグメントルーティングトラフィックエンジニアリング(SR-TE)LSP上のトランスポートトンネルを解決するためのプロトコルネクストホップ制約として(IPv4またはIPv6アドレスに加えて)色を指定できます。これはカラーIPプロトコルのネクストホップ解決と呼ばれ、解決マップを設定してVPNサービスに適用する必要があります。この機能により、レイヤー2およびレイヤー3VPNサービスのカラーベースのトラフィックステアリングを有効にすることができます。
- VPNサービスのカラーリング
- VPNサービスマッピングモードの指定
- カラーIPプロトコルネクストホップ解決
- IPプロトコルネクストホップ解決へのフォールバック
- SR-TEおよびIS-ISアンダーレイ上のBGPラベル付きユニキャストカラーベースマッピング
- VPNサービスのカラーベースマッピングでサポートされている機能とサポートされていない機能
VPNサービスのカラーリング
一般に、VPN サービスには、VPN NLRI がアドバタイズされる egressルーター、または VPN NLRI が受信および処理される ingressルーターで色が割り当てられます。
さまざまなレベルでVPNサービスに色を割り当てることができます。
-
ルーティングインスタンスごと。
-
BGPグループごと。
-
BGPネイバーごと。
-
プレフィックスごと。
-
プレフィックスのセット。
カラーを割り当てると、そのカラーはBGPカラー拡張コミュニティの形でVPNサービスに添付されます。
マルチカラーVPNサービスと呼ばれる、VPNサービスに複数の色を割り当てることができます。この場合、最小のカラー値がVPNサービスのカラーと見なされ、それ以外のカラーはすべて無視されます。
複数のカラーは、以下の順序で複数のポリシーを介して、エグレスデバイスおよび/またはイングレスデバイスによって割り当てられます。
-
エグレスデバイス上のBGPエクスポートポリシー。
-
イングレスデバイス上のBGPインポートポリシー。
-
イングレスデバイス上のVRFインポートポリシー。
VPNサービスのカラーリングには、次の2つのモードがあります。
Egressカラーの割り当て
このモードでは、エグレスデバイス(つまりVPN NLRIのアドバタイザー)がVPNサービスのカラーリングを行います。このモードを有効にするには、ルーティングポリシーを定義し、[edit protocols bgp]階層レベルでVPNサービスのルーティングインスタンスvrf-export、グループエクスポート、またはグループネイバーエクスポートに適用します。VPN NLRIは、指定されたカラーの拡張コミュニティを持つBGPによってアドバタイズされます。
例えば：
[edit policy-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}
または
BGPグループまたはBGPネイバーのエクスポートポリシーとしてルーティングポリシーを適用する場合、ポリシーがVPN NLRIに適用されるようにするには、BGP、BGPグループ、またはBGPネイバーレベルで vpn-apply-export ステートメントを含める必要があります。
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}
ルーティングポリシーは、レイヤー3 VPNプレフィックスNLRI、レイヤー2 VPN NRLI、およびEVPN NLRIに適用されます。カラー拡張コミュニティは、すべてのVPNルートに継承され、インポートされ、1つまたは複数のingressデバイス上のターゲットVRFにインストールされます。
イングレスカラーの割り当て
このモードでは、イングレスデバイス(つまりVPN NLRIの受信側)がVPNサービスのカラーリングを行います。このモードを有効にするには、ルーティングポリシーを定義し、それを[edit protocols bgp]階層レベルでVPNサービスのルーティングインスタンス vrf-importグループインポート、またはグループネイバーインポートに適用します。ルーティングポリシーに一致するすべてのVPNルートは、指定されたカラーの拡張コミュニティにアタッチされます。
例えば：
[edit policy-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}
または
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}
VPNサービスマッピングモードの指定
柔軟なVPNサービスマッピングモードを指定するには、resolution-mapステートメントを使用してポリシーを定義し、[edit protocols bgp]階層レベルでVPNサービスのルーティングインスタンスvrf-import、グループインポート、またはグループネイバーインポートでポリシーを参照する必要があります。ルーティングポリシーに一致するすべてのVPNルートは、指定された解決マップでアタッチされます。
例えば：
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}
VPNサービスのルーティングインスタンスにインポートポリシーを適用できます。
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}
インポートポリシーは、BGPグループまたはBGPネイバーに適用することもできます。
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}
各VPNサービスマッピングモードには、解決マップで定義された一意の名前が必要です。解決マップでは、IPカラーの単一のエントリのみがサポートされており、VPNルートは、inetcolor.0およびinet6color.0ルーティングテーブル上でip-address:color形式のカラー付きIPプロトコルネクストホップを使用して解決されます。
カラーIPプロトコルネクストホップ解決
プロトコルネクストホップ解決プロセスが強化され、カラー付きIPプロトコルネクストホップ解決がサポートされます。カラー付きVPNサービスの場合、プロトコルネクストホップ解決プロセスは、カラーと解決マップを取り、 ip-address:color形式でカラー付きIPプロトコルネクストホップを構築し、inetcolor.0およびinet6color.0ルーティングテーブル内のプロトコルネクストホップを解決します。
色付きLSP上で色付きレイヤー2VPN、レイヤー3VPN、またはEVPNサービスのマルチパス解決をサポートするポリシーを設定する必要があります。その後、リゾルバーのインポートポリシーとして、関連するRIBテーブルにポリシーを適用する必要があります。
例えば：
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}
[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}
IPプロトコルネクストホップ解決へのフォールバック
色付きVPNサービスに解決マップが適用されていない場合、VPNサービスはその色を無視し、IPプロトコルのネクストホップ解決にフォールバックします。逆に、色なしVPNサービスに解決マップが適用されている場合、解決マップは無視され、VPNサービスはIPプロトコルのネクストホップ解決を使用します。
フォールバックは、LDP用のRIBグループを使用してinet{6}color.0ルーティングテーブルにルートをインストールすることで、色付きSR-TE LSPからLDP LSPへのシンプルなプロセスです。カラー付き IP プロトコルのネクストホップの最長プレフィックスマッチにより、カラー付き SR-TE LSP ルートが存在しない場合、一致する IP アドレスを持つ LDP ルートが返されます。
SR-TEおよびIS-ISアンダーレイ上のBGPラベル付きユニキャストカラーベースマッピング
BGPラベル付きユニキャスト(BGP-LU)は、IPv4とIPv6の両方のアドレスファミリーに対して、IS-ISアンダーレイを使用してセグメントルーティング-トラフィックエンジニアリング(TE)上でIPv4またはIPv6ルートを解決できます。BGP-LUは、BGPコミュニティカラーのマッピングとSR-TEの resolution map の定義をサポートします。色付きプロトコル ネクスト ホップが構築され、 inetcolor.0 テーブルまたは inet6color.0 テーブル内の色付き SR-TE トンネルで解決されます。したがって、BGP-LUは、パケットトランスポートのためにSR-TEトンネル上のプロトコルネクストホップを解決します。BGPでは、非カラーベースのマッピングに inet.3 テーブルと inet6.3 テーブルを使用します。
VPNサービスのカラーベースマッピングでサポートされている機能とサポートされていない機能
VPNサービスのカラーベースのマッピングでは、以下の機能がサポートされています。
-
BGPレイヤー3VPN
-
BGPレイヤー2VPN(Kompellaレイヤー2VPN)
-
BGP EVPN
-
単一のIPカラーオプションを備えた解像度マップ。
-
色付き IPv4 および IPv6 プロトコルのネクストホップ解決。
-
inetcolor.0またはinet6color.0ルーティングテーブル内のLDP LSPへのルーティング情報ベース(ルーティングテーブルとも呼ばれる)グループベースのフォールバック。
-
カラー付きSR-TE LSP。
-
仮想プラットフォーム。
-
64ビットJunos OS。
-
論理システム。
-
BGPラベル付きユニキャスト
以下の機能は、VPNサービスのカラーベースのマッピングではサポートされていません。
-
RSVP、LDP、BGP-LUなどの色付きMPLS LSP、静的。
-
レイヤー 2 回線
-
FEC-129 BGP自動検出およびLDPシグナルレイヤー2VPN。
-
VPLS
-
MVPN
-
解決マップを使用した IPv4 と IPv6