Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

LSP ルート

MPLS とルーティングテーブル

IGPs and BGP は、ルーティング情報を inet. 0 ルーティングテーブル (メイン IP ルーティングテーブル) に格納しています。このtraffic-engineering bgpコマンドが設定されている場合、転送トラフィックに MPLS パスを使用できるように BGP だけが MPLS のパス情報が別のルーティングテーブルの inet. 3 に格納されます。BGP だけが inet. 3 ルーティングテーブルにアクセスします。BGP は、inet .0 と inet の両方を使用して、次ホップアドレスを解決します。このtraffic-engineering bgp-igpコマンドが設定されていると、igps が転送トラフィックに MPLS パスを使用できるようになり、MPLS パス情報が inet. 0 ルーティングテーブルに格納されます。(図 1そして図 2 、2つのトラフィックエンジニアリング構成におけるルーティングテーブルの例を示しています)。

図 1: ルーティングと転送テーブル、トラフィックエンジニアリング bgpルーティングと転送テーブル、トラフィックエンジニアリング bgp

inet.3 ルーティング テーブルには、各 LSP のホスト アドレスがエグレス ルーター。このルーティングテーブルは受信ルーターで使用され、パケットを宛先の送信ルーターにルーティングします。BGP は、受信ルーター上で inet. 3 ルーティングテーブルを使用して、次ホップアドレスの解決をサポートします。

MPLS は MPLS パスルーティングテーブル (MPLS. 0) も維持します。そこには、各 LSP の次のラベルスイッチルーターのリストが含まれています。このルーティングテーブルは、送信ルーターで、LSP の次のルーターにパケットをルーティングするために使用されます。

通常、LSP の送信ルーターは mpls を参照しません。0ルーティングテーブル。(このルーターは、LSP の最下手のルーターが mpls.0 を参照する必要はありません。パケットのラベルを 0 の値に変更するか、ラベルをポップするかのいずれか)。どちらの場合も、パケットエグレス ルーター IPv4 パケットとして転送し、IP ルーティング テーブル(inet.0)を参照してパケットを転送する方法を決定します。

移行または送信ルーターが MPLS パケットを受信すると、MPLS 転送テーブルの情報を使用して、LSP 内の次の通過ルーターを決定したり、このルーターが送信ルーターであることを確認したりできます。

BGP がネクストホッププレフィックスを解決した場合、inet. 0 と inet. 3 ルーティングテーブルの両方を検証し、最小の優先度で次ホップを検索します。両方のルーティングテーブルで同じ優先度を持つ next-hop エントリが見つかると、BGP は inet. 3 ルーティングテーブル内のエントリを優先します。

図 2: ルーティングと転送テーブル, トラフィックエンジニアリング bgp-igpルーティングと転送テーブル, トラフィックエンジニアリング bgp-igp

通常、BGP では、inet. 3 ルーティングテーブル内の次ホップエントリが選択されます。これらの設定は常に OSPF よりも小さく、次ホップの設定 IS-IS します。Lsp を設定する場合、MPLS Lsp のデフォルトの設定を上書きして、次ホップの選択プロセスを変更することができます。

BGP が inet. 3 ルーティングテーブルからネクストホップエントリを選択すると、その LSP がパケット転送エンジンの転送テーブルにインストールされます。これにより、その次ホップ宛のパケットが LSP によって入力および移動される原因となります。LSP が削除されたり失敗したりすると、inet. 3 ルーティングテーブルと転送テーブルからパスが削除され、BGP は戻って inet. 0 ルーティングテーブルから次ホップを使用するように戻ります。

高速再ルーティングの概要

高速再ルーティングによって LSP パスに冗長性が提供されます。高速再ルーティングを有効にすると、detours は LSP に基づいて precomputed と事前に確立されます。現在の LSP パスでネットワーク障害が発生した場合、トラフィックは迂回経路の 1 つに迅速にルーティングされます。 図 3 は、確立された迂回を示す、ルーター A からルーター F への LSP を示しています。各 detour はアップストリームノードによって確立され、即時下流ノードと即時下流ノードへのリンクを回避します。各 detour は、図に示されていない1つ以上のラベルスイッチルーター (またはスイッチ) を通過する可能性があります。

高速再ルーティングは、入口ルーター (またはスイッチ) 間の障害発生地点を問わず、トラフィックを保護します。スケールされたすばやい再ルーティングのシナリオで障害が発生した場合、デバイスは、障害が発生したリンクを経由して接続していたすべてのピアへの到達可能性を失います。このため、デバイス間の BGP セッションがダウンすると、トラフィックが中断してしまいます。LSP において複数の障害が発生した場合、高速再ルーティングが失敗する可能性があります。また、高速再ルーティングによって、受信ルーターやアウトルータの障害から保護することはできません。

図 3: Detours は、高速再ルーティングを使用して LSP に設定されています。Detours は、高速再ルーティングを使用して LSP に設定されています。

ノードがダウンストリーム リンクに障害が発生している(リンク レイヤー固有のライブネス検出メカニズムを使用して)、またはダウンストリーム ノードに障害が発生している(RSVP ネイバー hello プロトコルを使用して)、ノードが迅速にトラフィックを迂回に切り替えた場合、同時に、リンクやノードの障害についてイングレス ルーターに信号を送信します。は、ルーター B とルーター C の間のリンクに障害が発生 図 4 した場合の迂回を示しています。

図 4: ルーター B からルーター C へのリンクに障害が発生した後の Detourルーター B からルーター C へのリンクに障害が発生した後の Detour

ネットワークトポロジが十分ではない場合、他のルーターへの十分なリンクを備えたルーターが不足していると、detours の一部が成功しない可能性があります。たとえば、ルーター A からルーター C への detour は、 図 3リンク a-b とルーター b をスキャンできません。このようなパスを使用できない場合、detour は発生しません。

ノードが detour へのトラフィックを切り替えると、その後すぐに新たに計算された detour にトラフィックを切り替えることができる場合があることに注意してください。これは、最初の detour ルートが最適なルートではないためです。再ルーティングを可能な限り速くするために、ノードは最初に detour が有効であることを確認せずに、トラフィックを初期 detour に切り替えます。スイッチが作成されると、ノードは detour を再度計算します。ノードが、初期 detour がまだ有効であると判断すると、トラフィックはこの detour を通過し続けることになります。ノードが初期 detour が無効になったと判断した場合は、再び、トラフィックを新たに計算された detour に切り替えます。

注:

ノードが最初showの detour にトラフィックを切り替えた後でコマンドを発行すると、ノードは、そのトラフィックが元の LSP 上でフローしていることを示している場合があります。この状況は一時的なものであり、即座に修正する必要があります。

高速再ルーティングの detour にかかる時間は、以下の2つの独立した時間間隔によって異なります。

  • リンク障害やノード障害の検出に必要な時間は、使用しているリンク レイヤーと障害の性質によって大きく異なります。たとえば、SONET/SDH リンクの障害検知は、通常、ギガビットイーサネットリンクよりもはるかに高速で、ルーター障害の検知よりもはるかに高速です。

  • detour にトラフィックをスプライスするために必要な時間の長さ — この操作は パケット転送エンジン によって実行されます。detour にトラフィックをスプライスする時間は少しです。必要な時間は、detours に切り替えられる Lsp の数によって異なる可能性があります。

高速再ルーティングは、パケットロスを削減するための短期的なパッチです。Detour の計算によって適切な帯域幅が予約されない場合があるため、detours は代替リンクの輻輳を招く可能性があります。受信ルーターは、LSP ポリシー制約を完全に認識している唯一のルーターであり、そのため、十分な長期の代替パスを提供できるのは唯一のルーターです。

Detours は RSVP を使用して作成されており、すべての RSVP セッションと同様に、ネットワークの追加の状態とオーバーヘッドが必要になります。このため、各ノードでは、高速再ルーティングが有効になっている LSP ごとに、1つの detour が確立されます。各 LSP に対して複数の detour を作成すると、オーバーヘッドが増加しますが、実用的な目的はありません。

ネットワークのオーバーヘッドをさらに削減するために、各 detour は、障害が発生したノードまたはリンクの後、できるだけ早く LSP にマージを試みます。ルーター ノードを移動する LSP を検討できる場合、迂回 nn – 1 作成できます。たとえば、detour はルーター E またはルーター F ではなく、ルーター D の LSP にマージして試みようとします。 LSP にマージすると、迂回拡張性の問題をより容易にします。 図 5トポロジーの制約により、detour が LSP に迅速にマージされない場合、detours は他の detours と自動的にマージされます。

図 5: Detours を他の Detours に統合Detours を他の Detours に統合

すばやい再ルーティングの構成

高速再ルーティングは、lsp のノードまたはリンクに障害が発生した場合に LSP のトラフィックを自動的に再ルーティングするメカニズムを提供します。これにより、LSP を通過するパケットの損失を減らすことができます。

LSP で高速再ルーティングを構成するにはfast-reroute 、受信したルーター (またはスイッチ) にステートメントを追加します。

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

LSP のトランジット/エグレス 高速再ルート(またはスイッチ)で設定する必要があります。高速再ルーティングが有効になると、受信したルーター (またはスイッチ) は、LSP で高速再ルーティングが有効になっているすべてのダウンストリームルーター (またはスイッチ) に通知します。各ダウンストリームルーターは、LSP に detours を設定するための最適な機能を備えています。ダウンストリームルーターが高速再ルーティングをサポートしていない場合、detours のセットアップ要求を無視し、LSP をサポートし続けることができます。高速再ルーティングをサポートしないルーターでは、一部の detours が失敗することがありますが、それ以外の場合は LSP には影響しません。

注:

PFE の高速再ルーティングを有効にするには、トラフィックload-balance per-packetのルーティングが[edit policy-options policy-statement policy-name then]可能な各ルーターで、階層レベルのステートメントを使用してルートポリシーステートメントを構成します。「 RSVP Lsp でロードバランシングを設定する」も参照してください。

デフォルトでは、経路が再ルーティングされたパスに対して帯域幅を予約していません。経路を再ルーティングするパスに帯域幅を割り当てるbandwidthには、 bandwidth-percentステートメントまたはステートメントのいずれかを含めます。一度に1つのステートメントのみを含めることができます。bandwidthステートメントまたはbandwidth-percentステートメントが指定されていない場合は、デフォルトの設定では detour のパスに帯域幅が予約されません。

bandwidth明細書を含めると、detour パス用に予約する帯域幅の特定の量 (bps 単位) を指定できます。この帯域幅は LSP に割り当てられているものと同じである必要はありません。

bandwidth-percentステートメントを使用して帯域幅の割合を指定すると、detour のパス帯域幅は、メイントラフィックエンジニアリングに設定された帯域幅の割合を乗算して計算されます。トラフィックエンジニアリング LSP の帯域幅を構成する方法の詳細については、「トラフィックエンジニアリング lsp の構成」を参照してください。

ホップリミット制約は、detour が LSP 自体と比較して走査できるルーターの数を定義します。デフォルトでは、ホップ制限は 6 に設定されています。たとえば、LSP が 4 台のルーターを通過する場合、LSP の迂回は最大 10(つまり、4 + 6)のルーター ホップ(受信/送信ルーターを含む)にできます。

デフォルトでは、CSPF が代替パスを決定する際に、detour は親 LSP と同じ管理 (カラーリング) グループの制約を継承しています。管理グループは、リンクカラーリングまたはリソース クラスとも呼ばれる、手動で割り当てられた属性です。リンクの「色」を記述します。つまり、同じ色を持つリンクは概念的に同じクラスに属します。親 LSP を設定include-anyするときにステートメントを指定した場合、代替セッションで走査するすべてのリンクには、グループのリストに少なくとも1つの色が含まれている必要があります。親 LSP の設定include-all時にステートメントを指定した場合、代替セッションによって走査されるすべてのリンクには、グループのリストに含まれるすべての色が含まれている必要があります。親 LSP を設定excludeするときにステートメントを指定した場合、どのリンクにも、グループのリストに含まれている色が存在する必要があります。管理グループの制約の詳細については、 lsp の管理グループの設定を参照してください。

Detour のマージプロセス

このセクションでは、ルーターが選択する LSP を決定するプロセスについて説明します。このプロセスでは、同一のセッションおよび送信者テンプレート のオブジェクトを使用して、ルーターが異なるインターフェイスからパス メッセージを受信するときに選択します。この問題が発生した場合、ルーターはパスの状態をマージする必要があります。

ルーターは、以下のプロセスを実行して、パスの状態をマージするタイミングと方法を決定します。

  • すべてのパス メッセージに高速再ルート迂回オブジェクトが含されていない場合、またはルーターが LSP のエグレスである場合、マージは必要ありません。このメッセージは RSVP トラフィックエンジニアリングに従って処理されます。

  • それ以外の場合、ルーターは着信インターフェイスに加えて、パスの状態を記録する必要があります。Path メッセージが同じアウトゴーイングインターフェイスとネクストホップルーターを共有していない場合、ルーターは、それらを独立した Lsp と見なし、それらをマージしません。

  • 同じアウトゴーイングインターフェイスと次ホップルーターを共有するすべての path メッセージについて、ルーターは次のプロセスを使用して最終 LSP を選択します。

    • このノードから発生する LSP が1つのみの場合は、それを最終 LSP として選択します。

    • 1 つのアプリケーション オブジェクトが含高速再ルートの LSP は、最後の LSP として選択します。

    • 複数の Lsp が存在し、その一部が detour オブジェクトを保有している場合は、最終的な LSP 選択プロセスで detour オブジェクトを含むものを除外します。

    • 複数の最後の LSP 受験者が残っている(つまり、迂回と保護された LSP の両方がある)場合は、複数のオブジェクトを含む LSP 高速再ルートします。

    • すべての LSP に他のオブジェクト高速再ルート、迂回しないオブジェクトを選択します。すべての Lsp が detour オブジェクトを保有している場合は、それらをすべて選択します。

    • 残りの LSP の応募者は、他の Lsp が回避するノードをスキャンすることを考慮してください。

    • 複数の候補 Lsp がまだ残っている場合は、明示的ルートオブジェクト (ERO) パスの長さが最も短いものを選択します。複数の LSP が同じパス長を持つ場合は、1つをランダムに選択します。

  • 最終的な LSP が特定されたら、ルーターはこの LSP に対応する path メッセージのみを送信する必要があります。その他すべての Lsp は、このノードでマージされたものと見なされる。

Detour の計算

Detours のコンピューティングとセットアップは、各ノードで独立して実行されます。ノード上で、LSP に高速再ルーティングが有効になっていて、ダウンストリームのリンクまたはノードを識別できる場合、ルーターはローカルトラフィックエンジニアリングデータベースの情報を使用して、制約された最短パスの最初 (CSPF) 計算を実行します。このため、detours は、トラフィックエンジニアリング拡張機能をサポートする IGP に依存しています。トラフィックエンジニアリングデータベースがなければ、detours を確立することはできません。

CSPF は最初に、次の下流ノードをスキップするパスの検索を試みます。このパスを検索しようとすると、いずれかのノードまたはリンクでダウンストリームの障害から保護されます。ノードをスキップするパスが使用できない場合、CSPF は次の下流ノードへの代替リンク上のパスを検索しようとします。代替リンクを見つけようとすると、リンク内のダウンストリームの障害から保護されます。Detour の計算が初めて成功するとは限りません。計算が失敗した場合、ルーターは計算が成功するまで、更新間隔の約1回に detours の時間を算定します。各 detour の RSVP メトリックは、1万 ~ 19999 の範囲の値に設定されています。

迅速なルート変更のパス最適化

高速再ルーティング保護パスは非決定的です。特定のノードの実際の保護パスは、fast 再ルーティングパスが計算されたときに LSP の履歴とネットワークトポロジによって異なります。ネットワークに複数のリンクフラップがあると、確実な動作ができないため、運用上の問題が生じ、最適化されたパスが不十分になる可能性があります。小規模なネットワークでも、リンクフラップを2、3個にすることで、非常に多くのノードを通過し、その状態を無期限に維持できます。これは効率的ではなく、ネットワークの予測可能性が低くなります。

高速再ルーティングの最適化により、この不具合に対処します。グローバルパス最適化タイマーを提供し、高速再ルーティングが有効になっているすべての Lsp を最適化し、detour のパスを実行して運用することができます。タイマーの値は、予想される RE 処理負荷に応じて変化することができます。

高速再ルーティング最適化アルゴリズムは、IGP メトリックのみをベースとしています。新しいパスの IGP メトリックが古いパスよりも低い限り、新しいパスが混雑している(帯域幅の使用率が高い)場合や、ホップ数が多い場合でも、CSPF の結果が受け入れられます。

RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnelsに準拠して、新しいパスを計算して 高速再ルート 最適化用に受け入れる場合、既存の迂回は最初に破棄され、新しい迂回が確立されます。トラフィックロスを防止するために、detours がアクティブに保護しているトラフィックは最適化されていません。

高速再ルーティングパスの最適化間隔の設定

高速再ルーティングの最適化タイマーを構成することで、高速再ルーティングでパスの最適化を有効にできます。最適化タイマーは、ネットワークリソースをより効率的に使用するために、高速再ルーティング detour Lsp を再計算する定期的な最適化プロセスをトリガーします。

高速再ルートを有効にするには、ステートメントに optimize-timer オプションを使用して秒数を指定 fast-reroute します。

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

  • [edit protocols rsvp]

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

Inet. 3 または inet 6.3 ルーティングテーブルに LSP 関連ルートを追加します。

デフォルトでは、送信ルーターへのホストルートは inet. 3 または inet 6.3 ルーティングテーブルにインストールされています。(ホストルートアドレスは、 toステートメントで設定したものです)。ホストルートをインストールすると、BGP が次ホップの解決を実行できるようになります。また、ホストルートは、動的ルーティングプロトコルから学習されたプレフィックスを妨害し、inet/inet 6.0 ルーティングテーブルに格納することもできなくなります。

Inet .0 または inet 6.0 の表のルートとは異なり、inet. 3 または inet 6.3 テーブルのルートは、パケット転送エンジンにコピーされないため、システム転送テーブルに直接変更が加えられることはありません。これらのpingルートで or tracerouteコマンドを使用することはできません。Inet にのみ使用されます。3または inet 6.3 は、BGP が次ホップの解決を実行することを許可することです。Inet. 3 または inet 6.3 テーブルを調べるにshow route table inet.3は、or show route table inet6.3コマンドを使用します。

Inet. 3 または inet 6.3 ルーティングテーブルに追加のルートを挿入するにinstallは、以下のステートメントを含めます。

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

指定されたルートは、LSP が確立されるときに、エイリアスとしてルーティングテーブルにインストールされます。ルートを追加すると、指定したプレフィックス内の次のホップを解決したり、その次ホップの特定の LSP に追加のトラフィックを送信したり BGP できます。

このactiveオプションをinstall文に含めると、指定したプリフィックスが inet. 0 または inet 6.0 ルーティングテーブル (プライマリ転送テーブル) にインストールされます。その結果、LSP が確立されるたびに転送テーブルにインストールされるルートが作成されます。これは、ルートを ping またはトレースできることを意味します。このオプションは、このタイプの接頭辞が静的ルートによく似ているため、注意して使用してください。

エイリアスルートを使用するのは、ルーターに複数のアドレスが使用されていて、BGP 次ホップや MPLS に対応していないルーターの場合です。どちらの場合も、LSP はローカル ドメイン内の別の MPLS 対応システムに設定し、「境界」ルーターとして機能するように設定できます。LSP は境界ルーターで終了し、そのルーターからレイヤー 3 の転送がパケットを真のネクスト ホップ ルーターに転送します。

相互接続の場合、ドメインの境界ルーターはプロキシルーターとして機能し、境界ルーターがそれ自体にBGPネクスト ホップを設定していない場合、相互接続のプレフィックスをアドバタイズできます。

MPLS をサポートしていないルーターを持つプレゼンス (POP) の場合、MPLS をサポートするルーター (コアルーターなど) は、POP 全体のプロキシとして機能し、POP をカバーする一連のプレフィックスを挿入できます。したがって、POP 内のすべてのルーターは、内部 BGP (IBGP) のネクストホップとしてアドバタイズでき、トラフィックは LSP に従ってコアルーターに到達できます。つまり、POP 内で通常の IGP ルーティングが優先されるようになります。

Inet. 3 またpingtraceroute inet 6.3 ルーティングテーブルのルートに対して or コマンドを使用することはできません。

BGP 次ホップの解決のために、ルートが inet に存在するか、inet 6.0 または inet に含まれているかにかかわらず、違いはありません。 3/inet 6.3;最適な一致を持つルート (最大マスク) が選択されます。複数のベストマッチルートの中で、優先度の値が高いものが選択されています。

注:

このinstall destination-prefix activeステートメントは静的 lsp ではサポートされていません。静的 LSP install destination-prefix activeに対してステートメントが設定されている場合、MPLS ルートは inet. 0 ルーティングテーブルにインストールされません。