Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLSトラフィックエンジニアリング設定

MPLS とトラフィック制御

トラフィック制御により、ルーティング テーブルを使用する標準ルーティング モデルをバイパスして、データ パケットがたどるパスを制御できます。トラフィック制御は輻輳したリンクから、自動計算された宛先ベースの最短パスによって選択されない代替リンクにフローを移動します。トラフィックエンジニアリングにより、以下のことが可能になります。

  • 高価な長距離ファイバーの効率を高める。

  • 単一または複数の障害に直面した場合のトラフィックの再ルーティング方法を制御します。

  • 重要なトラフィックと通常のトラフィックをパス単位で分類します。

トラフィック制御設計のコアは、ルーター間のLSP(ラベルスイッチ パス)の構築に基づいています。LSP は、フレーム リレーまたは ATM の仮想回線のようなコネクション指向です。 LSP は信頼性がありません: LSP に入るパケットには、優遇措置は可能ですが、配信保証はありません。また、LSP は、パスに入るパケットがエンベロープにカプセル化され、中間ノードに触れられることなくパス全体で切り替えられるという単一方向トンネルと同様です。LSP は、ネットワーク内でのパケットの転送方法を細かく制御します。信頼性を確保するために、LSP は一連のプライマリ パスとセカンダリ パスを使用できます。

LSPは、BGPトラフィック(宛先が自律システム[AS]の外部にあるトラフィック)にのみ設定できます。この場合、AS内のトラフィックはLSPの存在による影響を受けません。LSPは、BGPトラフィックと内部ゲートウェイプロトコル(IGP)トラフィックの両方に対して設定することもできます。そのため、AS内トラフィックとAS間トラフィックの両方がLSPの影響を受けます。

MPLSトラフィックエンジニアリングとシグナリングプロトコルの概要

トラフィックエンジニアリングは、効率的で信頼性の高いネットワーク運用を促進すると同時に、ネットワークリソースとトラフィックパフォーマンスを最適化します。トラフィックエンジニアリングは、トラフィックフローを内部ゲートウェイプロトコル(IGP)によって選択された最短経路から、ネットワーク上で混雑していない可能性のある物理経路に移動させる機能を提供します。トラフィックエンジニアリングをサポートするためには、ソースルーティングの他に、ネットワークは次のことを行う必要があります。

  • 帯域幅や管理要件など、すべての制約を考慮して送信元でのパスを計算します。

  • パスが計算されると、ネットワークトポロジーとリンク属性に関する情報をネットワーク全体に配布します。

  • ネットワークリソースを予約し、リンクの属性を変更する。

トランジットトラフィックをIPネットワーク経由でルーティングする場合、MPLSはその通過をエンジニアリングするためによく使用されます。トランジットネットワークを正確に通過する経路は、トラフィックの送信者にも受信者にもあまり重要ではありませんが、ネットワーク管理者は、特定の送信元アドレスと宛先アドレスのペア間でトラフィックをより効率的にルーティングしたいと思うことがよくあります。MPLSは、各パケットに特定のルーティング命令を含む短いラベルを追加することで、ネクストホップ検索に基づいてパケットを転送するのではなく、ネットワークを介してルーターからルーターにパケットを切り替えます。その結果得られる経路を ラベルスイッチドパス(LSP)と呼びます。LSPは、ネットワーク上のトラフィックの通過を制御し、トラフィックの転送を高速化します。

LSPは、手動で作成することも、シグナリングプロトコルを使用して作成することもできます。シグナリングプロトコルは、トランジットネットワークを通過するトラフィックのLSPを確立するために、MPLS環境内で使用されます。Junos OSは、LDPとRSVP(Resource Reservation Protocol)の2つのシグナリングプロトコルをサポートしています。

MPLSトラフィックエンジニアリングでは、以下のコンポーネントを使用します。

  • パケット転送用のMPLS LSP

  • ネットワークトポロジーとリンク属性に関する情報を配信するためのIGP拡張

  • 経路計算と経路選択のためのCSPF(Constrained Shortest Path First)

  • パスに沿った転送状態を確立し、パスに沿ったリソースを予約するためのRSVP拡張機能

Junos OSは、異なるOSPFリージョン間のトラフィックエンジニアリングもサポートしています。

トラフィックエンジニアリング機能

トラフィックフローを既存の物理トポロジーにマッピングする作業は、 トラフィックエンジニアリングと呼ばれています。トラフィックエンジニアリングは、トラフィックフローを内部ゲートウェイプロトコル(IGP)が選択する最短経路から、ネットワーク上で混雑していない可能性のある物理経路に移動させる機能を提供します。

トラフィックエンジニアリングは、以下のような機能を提供します。

  • ネットワーク内のボトルネックや輻輳するポイントを回避するプライマリパスをルーティングします。

  • プライマリパスが単一または複数の障害に直面した場合に、トラフィックをどのように再ルーティングするかを正確に制御します。

  • ネットワークのサブセットが過剰利用され、潜在的な代替パスに沿った他のサブセットが過小利用されることがないようにすることで、利用可能な集約帯域幅と長距離ファイバーをより効率的に使用できるようにします。

  • 運用効率を最大化します。

  • パケットロスの最小化、長時間の輻輳の最小化、スループットの最大化により、ネットワークのトラフィック指向の性能特性を強化します。

  • マルチサービス・インターネットをサポートするために必要なネットワークの性能特性(損失率、遅延変動、転送遅延など)を統計的に束縛することを強化します。

トラフィック制御のコンポーネント

Junos®オペレーティングシステム(OS)では、トラフィックエンジニアリングはMPLSとRSVPで実装されています。トラフィックエンジニアリングは、4つの機能コンポーネントで構成されています。

LSPのトラフィック制御を設定する

LSPを設定すると、ホストルート(32ビットマスク)がingressルーターにインストールされ、egressルーターに向かってインストールされます。ホストルートのアドレスがLSPの宛先アドレスであること。[edit protocols mpls]階層レベルでtraffic engineeringステートメントのbgpオプションはデフォルトで有効になっており(bgpオプションを明示的に設定することも可能)、ルート計算でLSPを使用することを許可BGPのみになります。もう一方のtraffic-engineeringステートメントオプションでは、マスタールーティングインスタンスでこの動作を変更することができます。この機能は、特定のルーティングインスタンスでは利用できません。また、traffic-engineeringステートメントオプション(bgpbgp-igpbgp-igp-both-ribs、またはmpls-forwarding)は一度に1つだけ有効にすることができます。

注:

traffic-engineeringステートメントオプションのいずれかを有効または無効にすると、すべてのMPLSルートが削除され、その後ルーティングテーブルに再度挿入されます。

概要 LSAにおけるLSPメトリックのアドバタイズのセクションで説明されているように、OSPFおよびトラフィック制御は、サマリーリンクステートアドバタイズ(LSA)でLSPメトリックをアドバタイズするように設定することができます。

次のセクションでは、LSPのトラフィックエンジニアリングを設定する方法について説明します。

BGP と IGP の両方のトラフィック転送に LSP を使用する

traffic-engineeringステートメントのbgp-igpオプションを含めることで、BGPとIGPがエグレスルーターに送信されるトラフィックの転送にLSPを使用するように設定できます。bgp-igpオプションを選択すると、すべてのinet.3ルートがinet.0ルーティングテーブルに移動されます。

ingressルーターに、traffic-engineeringステートメントのbgp-igpオプションを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

    注:

    traffic-engineeringステートメントのbgp-igpオプションは、VPN用に設定できません)。VPNでは、inet.3ルーティングテーブル内にルートが必要です。

仮想プライベートネットワークでの転送にLSPを使用する

VPNが正常に機能するためには、ルートがinet.3ルーティングテーブルに残っている必要があります。VPN の場合は、traffic-engineering ステートメントの bgp-igp-both-ribs オプションを設定して、BGP と IGP がエグレスルーター宛ての転送トラフィックに LSP を使用するようにします。bgp-igp-both-ribsオプションは、inet.0 ルーティングテーブル(IPv4 ユニキャストルート用)と inet.3 ルーティングテーブル(MPLSパス情報用)の両方にイングレスルートをインストールします。

ingressルーターには、 traffic-engineering bgp-igp-both-ribs ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

bgp-igp-both-ribsステートメントを使用すると、inet.3テーブルからのルートがinet.0テーブルにコピーされます。コピーされたルートはLDPシグナル化ルートまたはRSVPシグナル化ルートであり、inet.0の他のルートよりも優先度が低くなる可能性があります。優先度の低いルートは、アクティブなルートとして選択される可能性が高くなります。ルーティングポリシーはアクティブなルートに対してのみ動作するため、これが問題となることがあります。この問題を回避するには、代わりにmpls-forwardingオプションを使用します。

注:

数値が最も小さい優先値を持つLSPが優先ルートとして選択されます。

次に例を示します。

優先値1000のLSPはより優れているため、優先値1001のLSPよりも優先されます。

ルート選択ではなく、転送にRSVPおよびLDPルートを使用する

traffic-engineeringステートメントにbgp-igpまたはbgp-igp-both-ribsオプションを設定すると、優先度の高いLSPをinet.0ルーティングテーブル内のIGPルートよりも優先できます。IGPルートはもはやアクティブなルートではないため、再配布されない可能性があります。

traffic-engineeringステートメントにmpls-forwardingオプションを設定した場合、LSPは転送に使用されますが、ルート選択からは除外されます。これらのルートは、inet.0とinet.3の両方のルーティングテーブルに追加されます。inet.0 ルーティングテーブル内の LSP は、アクティブなルートが選択されると優先度が低くなります。ただし、inet.3 ルーティングテーブル内の LSP には通常の優先度が与えられるため、転送ネクストホップの選択に使用されます。

mpls-forwardingオプションを有効にすると、状態がForwardingOnlyのルートが、現在アクティブなルートよりも優先度が低い場合でも、優先的に転送されます。ルートの状態を調べるには、show route detailコマンドを実行します。

LSPを転送に使用しながら、ルート選択から除外するには、traffic-engineeringステートメントにmpls-forwardingオプションを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

mpls-forwardingオプションを設定すると、IGPショートカットルートがinet.0ルーティングテーブルにのみコピーされます。

bgp-igp-both-ribsオプションとは異なり、mpls-forwardingオプションではLDPシグナル化ルートとRSVPシグナル化ルートを転送に使用することができ、ルーティング目的でBGPルートとIGPルートをアクティブな状態に維持してルーティングポリシーを適用することができます。

例えば、ルーターがBGP実行されていて、別のBGPスピーカーに送信する必要がある10.10.10.1/32のBGPルートがあるとします。bgp-igp-both-ribsオプションを使用し、ルーターに10.10.10.1へのラベルスイッチパス(LSP)がある場合、10.10.10.1へのMPLSルートがinet.0ルーティングテーブルでアクティブになります。これにより、ルーターが他の BGP ルーターに 10.10.10.1 ルートをアドバタイズしないように防止できます。一方、bgp-igp-both-ribsオプションではなくmpls-forwardingオプションを使用すると、10.10.10.1/32 BGPルートが他のBGPスピーカーにアドバタイズされ、LSP は引き続き 10.10.10.1 宛先へのトラフィックの転送に使用されます。

サマリーLSAでのLSPメトリックのアドバタイズ

LSPをリンクとして扱うように、MPLSとOSPFを設定することができます。この設定では、ネットワーク内の他のルーターがこのLSPを使用できるようになります。この目標を達成するためには、LSPメトリックをサマリーLSAでアドバタイズするように、MPLSおよびOSPFトラフィックエンジニアリングを設定する必要があります。

MPLSには、 traffic-engineering bgp-igp および label-switched-path ステートメントを含めます。

以下の階層レベルでこれらのステートメントを含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

OSPFには、 lsp-metric-into-summary ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols ospf traffic-engineering shortcuts]

  • [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

OSPFトラフィックエンジニアリングの詳細については、 ルーティングデバイス用Junos OSルーティングプロトコルライブラリを参照してください。

エリア間トラフィックエンジニアリングの実現

Junos OS は、複数の OSPF エリアにまたがって、連続したトラフィック制御された LSP をシグナリングできます。LSP シグナリングは、RFC 4206 一般 化マルチプロトコルラベルスイッチ (GMPLS) トラフィック制御 (TE) によるラベルスイッチパス (LSP) 階層に記載されているように、ネストシグナリングまたは連続シグナリングのいずれかを使用して行う必要があります。ただし、連続シグナリングのサポートは、基本的なシグナリングに限定されます。再最適化は、連続シグナリングではサポートされていません。

以下に、エリア間トラフィックエンジニアリング機能の一部を示します。

  • OSPFエリア内で明示的なルートオブジェクト(ERO)の計算にCSPFを使用して、ルーズホップのエリアボーダールーター(ABR)がingressルーターに設定されている場合、エリア間のトラフィックエンジニアリングを有効にすることができます。ABR で ERO 拡張が完了します。

  • CSPF を有効にすると、エリア間のトラフィック制御は有効にできますが、ingressルーターの LSP 設定で ABR を指定しなくても可能です (ABR は自動的に指定できます)。

  • 差別化されたサービス(DiffServ)トラフィックエンジニアリングは、クラスタイプのマッピングが複数のエリアで統一されていればサポートされます。

エリア間のトラフィックエンジニアリングを有効にするには、各LSPトランジットルーターの設定に expand-loose-hop ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

LSPのAS間トラフィックエンジニアリングの実現

一般に、トラフィックエンジニアリングは、次の条件を満たすLSPに対して可能です。

  • LSP の両端が同じ OSPF エリアまたは同じ IS-IS レベルにある。

  • LSPの両端は、同じ自律システム(AS)内の異なるOSPFエリアにあります。異なる IS-IS レベルで終了する LSP はサポートされていません。

  • 明示的パスLSPの両端が異なるOSPF ASにあり、自律システム境界ルータ(ASBR)が明示的パスLSPでサポートされるルースホップとして静的に設定されています。詳細については、「 明示的なパスLSPの設定」を参照してください

LSP上に静的に定義されたASBRがなければ、あるルーティングドメイン(AS)と別のルーティングドメインとの間でトラフィックエンジニアリングは不可能です。しかし、AS が単一のサービスプロバイダの管理下にある場合、トラフィックエンジニアリングされた LSP が AS をまたぎ、それらをリンクしている OSPF ASBR を動的に検出できる場合があります(この機能では IS-IS はサポートされません)。

AS間トラフィックエンジニアリングLSPは、特定のネットワーク要件を満たし、制限条件に該当せず、OSPFパッシブモードがEBGPで設定されていれば可能です。詳細は次項で説明します。

AS間トラフィックエンジニアリング要件

AS間トラフィックエンジニアリングLSPの適切な確立と機能は、以下のネットワーク要件に依存し、これらはすべて満たされなければならない。

  • すべてのASは、単一のサービスプロバイダの管理下にあります。

  • 各AS内のルーティングプロトコルはOSPFを使用し、AS間のルーティングプロトコルはEBGPが使用されます。

  • ASBR情報は、各AS内部で確認できます。

  • EBGPの経路情報はOSPFで配信され、各AS内ではIBGPフルメッシュが実現されています。

  • トランジットLSPはAS間リンクには設定 されず 、各ASの入口点ASBRと出口点ASBRの間に設定 されます

  • 異なるASのASBR間のEBGPリンクはダイレクトリンクであり、OSPFの下でパッシブトラフィックエンジニアリングリンクとして設定する必要があります。このパッシブリンクのリモートノード識別子には、ループバックや他のリンクアドレスではなく、リモートリンクアドレスそのものが使用されます。OSPFパッシブトラフィックエンジニアリングモードの設定の詳細については、 OSPFパッシブTEモードの設定を参照してください。

また、OSPFパッシブトラフィックエンジニアリングリンクのリモートノードに使用するアドレスは、EBGPリンクに使用するアドレスと同じである必要があります。OSPFとBGP全般については、 ルーティングデバイス用Junos OSルーティングプロトコルライブラリを参照してください。

AS間トラフィックエンジニアリングの制限

LSP階層化(ネスト化)シグナリングのみが、AS間トラフィックエンジニアリングLSPでサポートされています。ポイントツーポイントのLSPのみサポートされます(ポイントツーマルチポイントはサポートされません)。

また、以下の制限があります。これらの条件のうち一つでもあれば、上記の要件を満たしていても、AS間トラフィックエンジニアリングLSPは不可能になります。

  • マルチホップ BGP の使用はサポートされていません。

  • AS内部でBGP経路を知られないようにするポリサーやトポロジーの使用はサポートされていません。

  • EBGPピア間のLAN上の複数のASBRはサポートされていません。EBGPピア間のLAN上のASBRは1つだけサポートされます(他のASBRがLAN上に存在することはできますが、アドバタイズすることはできません)。

  • ASBR情報を隠蔽するルートリフレクタやポリシー、ASBR情報のAS内部への配布を防止するポリシーはサポートされていません。

  • 双方向LSPはサポートされていません(トラフィックエンジニアリングの観点からはLSPは単方向です)。

  • 同じ宛先へのAS間パスとAS内パスの両方を持つトポロジーはサポートされていません。

さらに、すべてのLSPでルーチン化されているいくつかの機能は、AS間トラフィックエンジニアリングではサポートされていません。

  • 管理者グループのリンクカラーには対応していません。

  • セカンダリスタンバイはサポートされていません。

  • 再最適化には対応していません。

  • トランジットルーターでのクランクバックはサポートされていません。

  • 多様なパス計算には対応していません。

  • グレースフル リスタートはサポートされていません。

AS間トラフィックエンジニアリングLSPの制限またはサポートされていない機能の一覧は、すべてを網羅しているわけではありません。

OSPF パッシブ TE モードの設定

通常、OSPFなどの内部ルーティングプロトコルは、AS間のリンクでは実行されません。ただし、AS間トラフィックエンジニアリングが適切に機能するためには、AS間リンクに関する情報、特にリモートインターフェイスのアドレスがAS内部で利用できるようにする必要があります。この情報は通常、EBGP 到達可能性メッセージにも OSPF ルーティング アドバタイズにも含まれません。

このリンクアドレス情報をAS内でフラッディングし、トラフィックエンジニアリングの計算に利用できるようにするには、各AS間インターフェイスでトラフィックエンジニアリング用のOSPFパッシブモードを設定する必要があります。また、OSPFが配信し、トラフィックエンジニアリングデータベースに含めるためのリモートアドレスも指定する必要があります。

AS間インタフェースOSPFトラフィックエンジニアリングにパッシブモードを設定するには、[edit protocols ospf area area-id interface interface-name]階層レベルでリンクのpassiveステートメントを含めます。

ルーターに OSPF が正しく設定されている必要があります。次の例では、AS間リンク so-1/1/0 を設定し、AS内のOSPFでトラフィックエンジニアリング情報を配布します。リモートIPアドレスは 192.168.207.2です。

パケット転送コンポーネント

Junosトラフィックエンジニアリングアーキテクチャのパケット転送コンポーネントはMPLSであり、ネットワーク上の所定のパスに沿ってIPパケットの流れを誘導する役割を担っています。このパスは、 LSP(ラベルスイッチ パス)と呼ばれます。LSP は単方式です。つまり、トラフィックは、ヘッドエンド(イングレス)ルーターからテールエンド(エグレス)ルーターに向かって一方向に流れます。二重トラフィックには 2 つの LSP が必要です。各方向にトラフィックを伝送するには 1 つの LSP。LSPは、1つ以上のラベルスイッチホップを連結して作成され、パケットをMPLSドメイン内のあるルーターから別のに転送できるようにします。

ingressルーターがIPパケットを受信すると、MPLSヘッダーをパケットに追加し、LSPの次のルーターに転送します。ラベル付きパケットは、LSPのテールエンドであるegressルーターに到達するまで、各ルーターによってLSPに沿って転送されます。この時点で、MPLSヘッダーが削除され、パケットはIP宛先アドレスなどのレイヤー3 情報に基づいて転送されます。この方式の価値は、LSP の物理パスが、IGP が宛先 IP アドレスに到達する最短パスとして選択するものに限定されないということです。

ラベル スワップに基づくパケット転送

各ルーターでのパケット転送プロセスは、ラベル スワップの概念に基づいています。この概念は、PVC(恒久仮想回線)の各 ATM(非同期転送モード)で発生するものと似ています。各 MPLS パケットは、20 ビットの固定長ラベル フィールドを含む 4 バイト カプセル化ヘッダーを伝送します。ラベルを含むパケットがルーターに到着すると、ルーターはラベルを調べ、インデックスとしてMPLS転送テーブルにコピーします。転送テーブルの各エントリには、同じインバウンドラベルを持つ特定のインタフェースに到着するすべてのパケットに適用される一連の転送情報にマッピングされたインタフェースインバウンドラベルペアが含まれています。

パケットが MPLS バックボーンをどのように通過するか

このセクションでは、IP パケットが MPLS バックボーンネットワークを通過する際にどのように処理されるかについて説明します。

MPLSバックボーンのエントリエッジでは、IPヘッダーがingressルーターによって調べられます。この分析に基づいて、パケットは分類され、ラベルが割り当てられ、MPLSヘッダーにカプセル化され、LSPのネクストホップに向けて転送されます。MPLS は、IP パケットを LSP に割り当てできるように、高い柔軟性を提供します。例えば、Junosトラフィック制御の実装では、同じegressルーターでMPLSドメインを出るはずのingressルーターに到着したすべてのパケットが、同じ LSPに沿って転送されます。

パケットが LSP を通過し始めると、各ルーターはラベルを使用して転送を決定します。MPLS転送の決定は、元のIPヘッダーとは独立して行われます。受信インターフェイスとラベルは、MPLS転送テーブルへの検索キーとして使用されます。古いラベルは新しいラベルに置き換えられ、パケットは LSP に沿ってネクスト ホップに転送されます。このプロセスは、パケットがegressルーターに到達するまでLSPの各ルーターで繰り返されます。

パケットがegressルーターに到着すると、ラベルが削除され、パケットはMPLSドメインを出ます。その後、パケットは、パケットの元のIPヘッダーに含まれる宛先IPアドレスに基づいて、IPルーティングプロトコルによって計算された従来の最短パスに従って転送されます。

情報配信コンポーネント

トラフィックエンジニアリングには、ネットワークトポロジーに関する詳細な知識だけでなく、ネットワーク負荷に関する動的情報も必要です。情報配布コンポーネントを実装するために、IGP のシンプルな拡張が定義されます。リンク属性は、各ルーターのリンク状態アドバタイズの一部として含まれています。IS-IS拡張には新しいTLV(type length value)の定義が含まれ、OSPF拡張は不透明なLSA(リンク状態アドバタイズ)で実装されます。リンク状態 IGP が使用する標準フラッティング アルゴリズムは、リンク属性がルーティング ドメイン内のすべてのルーターに分散されるようにします。IGPリンク状態アドバタイズに追加されるトラフィック エンジニアリング拡張には、最大リンク帯域幅、最大予約済みリンク帯域幅、現在の帯域幅予約、リンクカラーリングなどがあります。

各ルーターは、ネットワーク リンク属性とトポロジー情報を専用のトラフィック制御データベースで管理しています。トラフィック制御データベースは、物理トポロジーを横断する LSP の配置のための明示的なパスの計算にのみ使用されます。その後のトラフィック制御計算は、IGP および IGP のリンク状態データベースから独立するように、別のデータベースが維持されます。一方、IGP は変更なく動作を継続し、ルーターのリンク状態データベースに含まれる情報に基づいて従来の最短パス計算を実行します。

パス選択コンポーネント

ネットワークリンク属性とトポロジー情報がIGPによってフラッディングされ、トラフィック制御データベースに保存された後、各ingressルーターはトラフィック制御データベースを使用して、ルーティングドメイン全体の独自のLSPセットのパスを計算します。各LSPのパスは、ストリクトまたはルーズ明示的なルートで表すことができます。明示的なルートは、LSP の物理パスの一部であるべき事前に設定されたルーターのシーケンスです。ingressルーターがLSP内のすべてのルーターを指定した場合、LSPは明示的ストリクトルートによって識別されると言われます。ingressルーターがLSP内の一部のルーターのみを指定した場合、LSPは明示的なルーズルートとして記述されます。明示的なストリクトおよびルーズルートのサポートにより、パス選択プロセスには可能な限り広い自由度が与えられますが、必要に応じて制限されます。

ingressルーターは、トラフィック制御データベース内の情報に制限付き最短パスファースト(CSPF)アルゴリズムを適用して、各LSPの物理パスを決定します。CSPF は、ネットワーク全体の最短パスが計算されるときに、特定の制限を考慮するために変更された最短パスファースト アルゴリズムです。CSPF アルゴリズムへの入力には以下が含まれます。

  • IGPから学習し、トラフィック制御データベースで保守されるトポロジーリンク状態情報

  • IGP拡張によって伝送され、トラフィック制御データベースに保存される、ネットワークリソースの状態に関連する属性(総リンク帯域幅、予約済みリンク帯域幅、利用可能なリンク帯域幅、リンクカラーなど)

  • 提案されたLSPを通過するトラフィックをサポートするために必要であり、ユーザー設定から取得される管理属性(帯域幅要件、最大ホップ数、管理ポリシー要件など)

CSPF は、新しい LSP の各候補ノードとリンクを検討する際、リソースの可用性や、コンポーネントの選択がユーザー ポリシー制約に違反するかどうかに基づいて、特定のパス コンポーネントを受け入れるか拒否するかを決定します。CSPF 計算の出力は、制約を満たすネットワークを通る最短パスを提供する一連のルーター アドレスで構成される明示的なルートです。この明示的なルートは、シグナリング コンポーネントに渡され、LSP に沿ってルーターで転送状態を確立します。

シグナリング コンポーネント

LSP は、シグナリング コンポーネントによって実際に確立されるまで、実行可能であることは認識されません。LSP 状態の確立とラベルの配布を担当するシグナリング コンポーネントは、RSVP の多くの拡張に依存しています。

  • 明示的なルート オブジェクトにより、RSVP パス メッセージは、従来の最短パス IP ルーティングとは独立した明示的なルーターのシーケンスを通過できます。明示的なルートは、ストリクトまたはルーズのいずれかです。

  • ラベル リクエスト オブジェクトは、中間ルーターが確立する LSP のラベル バインディングを提供することを要求する RSVP パス メッセージを許可します。

  • ラベル オブジェクトにより、RSVP は既存のメカニズムを変更することなく、ラベルの配布をサポートできます。RSVP Resv メッセージは RSVP パス メッセージのリバース パスに従うため、ラベル オブジェクトはダウンストリーム ノードからアップストリーム ノードへのラベルの配布をサポートします。

オフライン パス計画と分析

オンライン パス計算によって管理の手間は軽減されますが、グローバルにトラフィック制御を最適化するには、オフライン計画と分析ツールが必要です。オンライン計算では、リソースの制約を考慮して、1 つずつ LSP を計算します。このアプローチの課題は決定論的ではないことです。LSP が計算される順序は、ネットワーク全体に及ぶ各 LSP の物理パスを決定する上で極めて重要な役割を果たします。プロセスの早い段階で計算された LSP は、先に計算された LSP ほどネットワーク リソースを消費するため、プロセスの後の段階で計算された LSP よりも多くのリソースを利用できます。LSP の計算順序が変更された場合、結果として得られる一連の LSP の物理パスも変わる可能性があります。

オフライン計画と分析ツールは、各リンクのリソースの制約と各 LSP の要件を同時に検討します。オフライン アプローチは完了までに数 時間かかる可能性がありますが、グローバル計算を実行し、各計算の結果を比較してから、ネットワーク全体に最適なソリューションを選択します。オフライン計算の出力は、ネットワーク リソースの使用を最適化する一連の LSP です。オフライン計算が完了した後は、グローバルに最適化されたソリューションのルールに従って、それぞれがインストールされるため、LSP を任意の順序で確立できます。

柔軟なLSP計算と設定

トラフィック制御では、トラフィックフローを物理的なトポロジーにマッピングします。制約ベースルーティングを使用して、オンラインでパスを決定できます。物理パスの計算方法に関係なく、RSVP を介してネットワーク全体に転送状態がインストールされます。

Junos OSでは、LSPをルーティングして設定する方法として、以下の方法をサポートしています。

  • オフラインで LSP のフルパスを計算し、必要な静的転送状態を LSP 内の各ルーターに個別に設定できます。これは、一部のインターネットサービスプロバイダ(ISP)がIP-over-ATMコアを設定する方法と類似しています。

  • オフラインで LSP のフルパスを計算し、そのフルパスを使ってingressルーターを静的に設定できます。その後、ingressルーターは、動的なシグナリングプロトコルとしてRSVPを使用し、LSPに沿って各ルーターに転送状態をインストールします。

  • 制約ベースのルーティングを利用して、動的なオンライン LSP 計算を行うことができます。各 LSP の制約を設定します。そして、ネットワーク自体が、それらの制約を満たす最適なパスを決定します。具体的には、ingressルーターは、制約条件に基づいてLSP全体を計算し、ネットワーク上でシグナリングを開始します。

  • オフラインで LSP の部分的なパスを計算し、パス内のルーターのサブセットでingressルーターを静的に設定できます。その後、オンライン計算を許可して完全なパスを決定できます。

    たとえば、米国を横断する 2 つの東西のパス (北はシカゴ、南はダラスを経由する) を含むトポロジーがあるとします。ニューヨークのルーターとサンフランシスコのの間にLSPを確立したい場合、LSPの一部パスに、ダラスのルーターの1つのルースルートホップを含めるように設定できます。その結果、南のパスに沿ってルーティングされた LSP が生成されます。ingressルーターは、CSPFを使用して完全なパスを計算し、RSVPを使用してLSPに沿って転送状態をインストールします。

  • ingressルーターは、いかなる制約もなく設定できます。この場合、LSP のパス決定には、通常の IGP 最短経路ルーティングが使用されます。この設定は、トラフィック制御に関しては役に立ちません。しかし、これは簡単なので、仮想プライベートネットワーク(VPN)などのサービスが必要な場面では役に立つかもしれません。

これらの場合、プライマリLSPのバックアップとして任意の数のLSPを指定することができるため、複数の設定方法を組み合わせることができます。例えば、プライマリパスをオフラインで明示的に計算し、セカンダリパスを制約ベースに設定し、第 3 のパスを制約なしにすることができます。プライマリLSPがルーティングされている回線に障害が発生した場合、ingressルーターは、ダウンストリームルーターから受信したエラー通知やRSVPソフトステート情報の失効によって障害を認識します。その後、ルーターはトラフィックを動的にホットスタンバイ LSP に転送するか、RSVP を呼び出して新しいバックアップ LSP の転送状態を作成します。

BGPクラスフルトランスポートプレーンの概要

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内実装

図4 は、AS内ドメインにBGPクラスフルトランスポートプレーンを実装する前と後のシナリオを含むネットワークトポロジーを示しています。デバイス PE11 と PE12 はトランスポートトンネルとして RSVP LSP を使用し、すべてのトランスポートトンネルルートは inet.3 RIB にインストールされています。BGPクラスフルトランスポートプレーンを実装することで、セグメントルーティングトンネルと同様に、RSVPトランスポートトンネルがカラーを認識できるようになります。

図4:ASドメイン内:BGPクラスフルトランスポートプレーン実装Intra-AS Domain: Before-and-After Scenarios For BGP Classful Transport Planes Implementationの前後のシナリオ Intra-AS Domain: Before-and-After Scenarios For BGP Classful Transport Planes Implementation

AS内設定でトランスポートトンネルをBGPトランスポートクラスに分類するには

  1. サービスノード(ingress PEデバイス)で、ゴールドやブロンズなどのトランスポートクラスを定義し、定義されたトランスポートクラスにカラーコミュニティ値を割り当てます。

    構成例:

  2. トランスポートトンネルを、トンネルのingressノードで特定のトランスポートクラスに関連付けます。

    構成例:

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クラスフルトランスポートに変換するには:

  1. サービスノード(ingress PEデバイス)とボーダーノード(ABRおよびASBR)で、ゴールドやブロンドなどのトランスポートクラスを定義します。

    構成例:

  2. トランスポートトンネルを、トンネルのingress ノード(ingress PE、ABR、ASBR)で特定のトランスポートクラスに関連付けます。

    構成例:

    RSVP LSPの場合

    IS-ISフレキシブルアルゴリズムの場合

  3. ネットワーク内のBGPクラスフルトランスポート(inet transport)とBGP-LU(inet labeled-ユニキャスト)の新しいファミリを有効にします。

    構成例:

  4. エグレスPEデバイスからのサービスルートを、適切な拡張カラーコミュニティでアドバタイズします。

    構成例:

AS間BGPクラスフルトランスポートプレーンの機能:

  1. BGPクラスフルトランスポートプレーンは、各々の名前付きトランスポートクラス(ゴールドおよびブロンズ)に対して事前に定義されたトランスポートRIBを作成し、そのカラー値からマッピングコミュニティを自動的に導き出します。
  2. トランスポートクラスと関連づけられた場合、AS内トランスポートルートはトンネリングプロトコルによってトランスポートRIBに入力されます。

    例えば、トランスポートクラスゴールドとブロンズに関連付けれられたトランスポートトンネルルートは、それぞれトランスポートRIBの junos-rti-tc-<100>.inet.3junos-rti-tc-<200>.inet.3にインストールされます。

  3. BGPクラスフルトランスポートプレーンは、各トランスポートRIBからbgp.transport.3ルーティングテーブルにトランスポートトンネルルートをコピーするときに、一意のルート識別素とルーティングテーブルを使用します。
  4. ボーダーノードは、BGPセッションでファミリーinetトランスポートがネゴシエートされている場合、bgp.transport.3からのルートを他のドメインのピアにルーティングテーブルアドバタイズします。
  5. 受信側のボーダーノードは、これらのbgp-ctルートをbgp.transport.3ルーティングテーブルにインストールし、トランスポートルートターゲットに基づいてこれらのルートを適切なトランスポートRIBにコピーします。
  6. サービスノードは、サービスルート内のカラーコミュニティと解決スキーム内のマッピングコミュニティを照合し、対応するトランスポートRIB( junos-rti-tc-<100>.inet.3または junos-rti-tc-<200>.inet.3)内のPNHを解決します。
  7. ボーダーノードは、トランスポートルートPNHを解決するために、事前に定義された解決スキームを使用します。
  8. 事前定義された解決スキームであれ、ユーザーが定義した解決スキームであれ、どちらの解決スキームもサービスルートPNH解決をサポートします。事前定義された解決スキームではフォールバックとしてinet.3を使用し、ユーザー定義の解決スキームでは、トランスポートRIBのリストをPNHを解決時に指定した順序で使用できます。
  9. ユーザー定義の解決スキームにリストされているRIBを使用してサービスルートPNHを解決できない場合、ルートは破棄されます。

RSVP PathErr メッセージによるトラフィック制御データベースの精度向上

RSVPベースのトラフィック制御に欠かせないのが、トラフィック制御データベースです。トラフィック制御データベースには、トラフィック制御に参加しているすべてのネットワークノードとリンクの完全なリストと、それらのリンクのそれぞれが保持できる属性のセットが含まれています。(トラフィック制御データベースの詳細については、 Constrained-Path LSP Computationを参照してください)。最も重要なリンク属性の1つは帯域幅です。

RSVP LSP の確立と終了に伴い、リンクの帯域幅が急速に変化します。トラフィック制御データベースには、実際のネットワークとの間に不一致が生じる可能性があります。このような不一致は、IGPの更新レートを上げても修正できません。

リンクの可用性は、同じ不一致の問題を共有することができます。リンクが利用できなくなった場合、既存の RSVP LSP はすべて壊れます。しかし、その可用性はネットワークでも容易に知ることがないかもしれません。

rsvp-error-hold-timeステートメントを設定すると、ソース ノード(RSVP LSP のイングレス)は、ダウンストリーム ノードから送信される PathErr メッセージを監視することで、その LSP の障害を学習します。PathErr メッセージからの情報は、後続の LSP 計算に組み込まれ、LSP 設定の精度と速度を向上させることができます。一部の PathErr メッセージは、トラフィック制御データベースの帯域幅情報を更新するためにも使用され、トラフィック制御データベースとネットワーク間の不一致を軽減します。

update-thresholdステートメントを使用して、IGP更新の頻度を制御できます。インターフェイスでのRSVP更新しきい値の設定を参照してください。

このセクションでは、以下のトピックについて説明します。

PathErrメッセージ

PathErr メッセージは、異なるコード番号やサブコード番号によってさまざまな問題を報告します。これらの PathErr メッセージの完全なリストは、RFC 2205 の RSVP(Resource Reservation Protocol)、Version 1、Functional Specification および RFC 3209、 RSVP-TE: Extensions to RSVP for LSP Tunnels に記載されています。

rsvp-error-hold-time ステートメントを設定すると、特にリンク障害を表す PathErr メッセージの 2 つのカテゴリーが調べられます。

  • この LSP のリンク帯域幅は低いです。 要求された帯域幅は利用できません。コード 1、サブコード 2

    このタイプの PathErr メッセージは、リンクを送信するすべての LSP に影響を与えるグローバルな問題を表しています。これらの情報は、実際のリンク帯域幅が LSP で必要とされる帯域幅よりも低く、トラフィック制御データベースの帯域幅情報が過大評価されている可能性があることを示しています。

    このタイプのエラーを受信すると、ローカル トラフィック制御データベースで利用可能なリンク帯域幅が減少し、今後のすべての LSP 計算に影響を与えます。

  • この LSP ではリンクは利用できません。

    • アドミッション コントロール障害。コード 1、2 以外のサブコード

    • ポリシー コントロールの障害。コード 2

    • サービス プリエンプション。コード 12

    • ルーティングの問題。宛先へのルートは利用できません。コード 24、サブコード 5

    これらのタイプの PathErr メッセージは、通常、指定された LSP に関連しています。この LSP の障害は、必ずしも他の LSP も障害が発生する可能性があることを意味するものではありません。これらのエラーは、最大転送単位(MTU)の問題、サービス プリエンプション(運用担当者が手動で開始したものや、より高い優先度を持つ別の LSP によるもの)、ネクストホップ リンクのダウン、ネクストホップ ネイバーのダウン、ポリシー上の理由によるサービスの拒否などを示します。この特定のLSPをリンクから離してルーティングするのが最適です。

問題のリンクの特定

各 PathErr メッセージには、送信者の IP アドレスが含まれています。この情報は、ingressルーターに向けて変更されずに伝送されます。トラフィック制御データベース内の検索により、PathErr メッセージを発信したノードを特定できます。

各 PathErr メッセージには、メッセージをトリガーした RSVP セッションを特定するのに十分な情報が含まれています。これがトランジット ルーターの場合は、メッセージを転送するだけです。このルーターが(この RSVP セッションの)ingressルーターの場合、セッションが通過すべきすべてのノードとリンクの完全なリストを持っています。発信元のノード情報と組み合わせることで、リンクを一意に識別することができます。

トラフィック制御データベースの精度を向上させるルーターの設定

トラフィック制御データベースの精度を向上するには、 rsvp-error-hold-time ステートメントを設定します。このステートメントを設定すると、ソース ノード(RSVP LSP のイングレス)は、ダウンストリーム ノードから送信される PathErr メッセージを監視することで、その LSP の障害を学習します。PathErr メッセージからの情報は、後続の LSP 計算に組み込まれ、LSP 設定の精度と速度を向上させることができます。一部の PathErr メッセージは、トラフィック制御データベースの帯域幅情報を更新するためにも使用され、トラフィック制御データベースとネットワーク間の不一致を軽減します。

RSVP PathErr メッセージを記憶する期間を設定し、CSPF 計算でそのMPLSを考慮するには、 rsvp-error-hold-time ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

時間は 1 秒から 240 秒までの値を指定できます。デフォルトは25 秒です。値 0 を設定すると、PathErr メッセージの監視を無効にします。

変更履歴テーブル

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。

リリース
説明
23.1R1
Junos OSリリース23.1R1以降、Junos OSコンフェデレーションが有効になっている場合、BGPリンクステートBGP-LS NLRIでTLV 512にコンフェデレーションID BGP伝送できるようになりました。NLRIは、RFC9086で定義されているように、TLV 517でメンバーAS番号とともにコンフェデレーションIDを転送します。
22.1R1
Junos OSリリース22.1 R1以降、トラフィック制御データベース(TED)とBGPリンクステート(LS)でIPv6プレフィックスとIPv6隣接SID MPLSサポートを追加しました。
17.1R1
BGP を使用したリンク状態配信は、QFX10000 スイッチでサポートされています。