Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

レイヤー3VPNでのプロバイダエッジリンク保護

このトピックでは、CE ルーターと代替 PE ルーター間のリンク保護とバックアップ パスを提供する、事前計算された保護パスの設定例を紹介します。

ホスト高速再ルートの理解

ホスト高速再ルート(HFRR)は、事前に計算された保護パスをパケット転送エンジン(PFE)に追加するため、プロバイダーエッジデバイスとサーバーファーム間のリンクが転送に使用できなくなった場合、PFEはルーターまたはプロトコルが更新された転送情報を提供するのを待つことなく、別のパスを使用できます。この事前計算された保護パスは、多くの場合、修復パスまたはバックアップ パスと呼ばれます。

HFRRは、イーサネットなどのマルチポイントインターフェイス上のIPエンドポイントを保護するテクノロジーです。このテクノロジは、サーバー エンドポイントの高速サービス復元が重要なデータセンターで重要です。インターフェイスまたはリンクがダウンした後、HFRR を使用すると、ローカル修復時間を約 50 ミリ秒にすることができます。

図 3 に示すネットワーク トポロジーについて考えてみます。

図3:ホスト高速再ルート Network topology with MPLS L3VPN cloud, PE1 and PE2 routers connecting customer networks.

ルーティングデバイスは、アドレス解決プロトコル(ARP)とIPv6近隣探索プロトコル(NDP)によってトリガーされるホストルート転送エントリーを作成します。HFRRは、ルーティングプロトコルによって供給されるバックアップネクストホップでホストルートを増強します。これらのバックアップネクストホップにより、ネットワークが再コンバージェンスする間も、到着するトラフィックの流れを維持できます。

トラフィックは、プロバイダー エッジ デバイスである PE1 と PE2 に接続されたネットワークから、ホスト A とホスト B に流れます。このトラフィックはHFRRで保護されています。デバイスPE2とホストサーバー間のリンクがダウンした場合、トラフィックはデバイスPE1を介してホストサーバーに再ルーティングされます。トポロジでは、ホスト A とホスト B は LAN PC を表し、総称してサーバー ファームと呼ばれます。PE デバイスは、その間にレイヤー 3 VPN が設定されたルーターです。デバイス PE1 は、ARP または IPv6 NDP を介して、直接接続されたホストについて学習します。

また、デバイス PE2 は、サーバー ファーム ネットワークに関する情報を持っており、この情報をデバイス PE1 にアドバタイズします。このアドバタイズは、内部BGP(IBGP)を使用してレイヤー3 VPNを介して送信されます。デバイス PE1 および PE2 では、このルートはサーバー ファーム サブネットへの直接ルートと見なされます。

デバイス PE1 は、ARP および NDP で学習したホスト ルートを使用して、サーバー ファーム内のホスト マシンにトラフィックを送信します。デバイスPE1とサーバーファーム間のリンクが中断され、HFRRが設定されていない場合、ルーティングデバイスは次に良いルート、つまりIBGPルートを見つけます。この実装では、更新が行われてネットワークが再コンバージェンスするまでの一定期間、トラフィックが失われます。デバイス PE1 に設定された HFRR は、トラフィックが中断することなく転送され続けることができるように、バックアップ パスで ARP および NDP ルートを増強することで、この問題を解決します。

この特定のトポロジーのバックアップ パスは、IBGP レイヤー 3 VPN ルートです。実際の導入では、デバイス PE2 は直接接続されたサーバー ファーム ネットワークのリンク保護を設定することもでき、デバイス PE1 はデバイス PE2 へのレイヤー 3 VPN ルートを使用して自身を介してサーバー ファームへの到達可能性をアドバタイズできます。したがって、HFRRは、デバイスPE1とデバイスPE2の両方で有効にする必要があります。また、デバイス PE1 とデバイス PE2 はどちらも、BGP を介してサーバー ファームへの到達可能性をアドバタイズする必要があります。

たとえば、デバイス PE1 からサーバー ファームへのリンクと、デバイス PE2 からサーバー ファームへのリンクの両方が同時にダウンした場合、PE デバイス間で一時的なルーティング ループが発生する可能性があります。このループは、両端の BGP がサーバー ファーム サブネットがダウンしていることを学習して BGP ルートを取り消すまで継続できます。

ARP プレフィックス制限とブラックアウト補足タイムアウト

HFRR プロファイルを設定する場合、オプションの ARP プレフィックス制限により、ARP ルートの数の最大値が設定されるため、ルーティングテーブル内の各 HFRR プロファイルに対して作成される FRR ルートも設定されます。この制限は、ARP 攻撃がルーティング デバイスの仮想メモリを使い果たすのを防ぎます。ARP プレフィックス制限は、転送テーブル内の ARP ルートを制限しません。ただし、Junos OSがプロファイルに対して読み取るARPルートの数は制限されるため、ルーティングプロセス(rpd)がルーティングテーブルと転送テーブルに作成するHFRRルートの数も制限されます。

ARPプレフィックス制限は、各HFRRプロファイルに適用されます。ルーティングテーブル内のすべてのARP/HFRRルートの合計数を制限するものではありません。各HFRRプロファイルのARP/HFRRルート数を制限するだけです。

ARP プレフィックス制限を設定する設定ステートメントは 2 つ( global-arp-prefix-limit arp-prefix-limit )あり、1 つはグローバル [edit routing-options host-fast-reroute] 階層レベル、もう 1 つは [edit routing-instances instance-name routing-options interface interface-name] 階層レベルです。グローバル global-arp-prefix-limit ステートメントは、ルーティングデバイスに設定されたすべてのHFRRプロファイルに対して、デフォルトのARPプレフィックス制限を設定します。 arp-prefix-limit ステートメントは、保護されたインターフェイスのHFRRプロファイルの global-arp-prefix-limit を上書きします。

HFRR プロファイル内の ARP ルートの数が、設定された ARP プレフィックス制限の 80% に達すると、システム ログに警告メッセージが送信されます。この警告メッセージは、ARP プレフィックスが設定値の 80% を超えた場合、その HFRR プロファイルに追加された後続の ARP ルートに対して表示されます。

HFRR プロファイル内の ARP ルートの数が、HFRR プロファイル用に設定された ARP プレフィックス制限の 100% に達すると、別の警告メッセージがシステムログに送信されます。数値が100%の閾値を超えると、HFRRプロファイルは無効化されます。この場合、すべてのARP/FRRルートがルーティングテーブルから削除されます。FRR ルートは、転送テーブルからも削除されます。

HFRR プロファイルが非活動化された後、ブラックアウト・タイマーが開始されます。このタイマーのタイムアウト値は、ARP キャッシュのタイムアウト (カーネルのタイムアウト) + 補助ブラックアウトタイマーです。

グローバルCLIステートメントとHFRRごとのCLIステートメント( global-supplementary-blackout-timer および supplementary-blackout-timer )があります。グローバル値は [edit routing-options host-fast-reroute] 階層レベルにあり、ルーティングデバイス上のすべてのHFRRプロファイルに適用されます。 [edit routing-instances instance-name routing-options interface interface-name] 階層レベルでルーティングインスタンスインターフェイスに設定された補足ブラックアウトタイマーは、そのHFRRプロファイルのグローバル値のみを上書きします。

ブラックアウト タイマーが終了すると、HFRR プロファイルが再有効化され、Junos OS は ARP ルートを再度学習して HFRR ルートを再作成します。ARP プレフィックス制限を再び超えなければ、HFRR ルートはアップします。

HFRR プロファイルがブロックリストに登録されていて、非アクティブ化状態にある場合、ARP 状態の再評価は、コミット操作のたびに、または restart routing コマンドでルーティング プロセス(rpd)が再起動されるたびに実行されます。

一次ルートとバックアップルートの候補

HFRRネクストホップの主要ルートは、ARPおよびIPv6 NDPルートによって提供されます。これらは /32 または /128 ルートです。バックアップルートは、ローカルインターフェイスで設定されたアドレスとプレフィックスが完全に一致します。例えば、ローカルアドレスが10.0.0.5/24として設定されている場合、ルーティング・デバイスは、バックアップ・ルートを選択するために、プレフィックス長24のプレフィックス10.0.0.0と完全に一致するものを探します。

バックアップ ルート選択の制約事項は、以下のとおりです。

  • プレフィックスは、ルーティングデバイスのHFRR対応インターフェイスで設定されたものと同じサブネットアドレスに一致する必要があります。

  • リモートエンドには、ルートアグリゲーション(集約とも呼ばれる)が設定されていない必要があります。例えば、リモートエンドが2つ以上の/24サブネットを組み合わせて、プレフィックス長が/24未満のサブネットをアドバタイズする場合、Junos OSはこの要約されたルートをバックアップルートとして選択しません。

  • /32 または /128(ARP または NDP)ルートに最も長いプレフィックス一致を持つ別のプロトコルによって学習された別のルートがルーティングテーブルにある場合、そのルートはバックアップ候補として選択されません。例えば、ローカルインターフェイスアドレスが10.0.0.5/24であるとします。また、ルーティングテーブルに、プレフィックスが 10.0.0.0/24 の IBGP ルートと、プレフィックスが 10.0.0.0/28 の OSPF ルートが含まれているとします。サブネット内の特定のプレフィックスに対しては/28ルートがより良いルートですが、Junos OSは10.0.0.0/28をバックアップ候補とは見なしません。IBGPルートは、すべてのホストルートのバックアップ候補になります。ただし、グローバル修復後は、OSPFルートが転送に使用されます。

要するに、バックアップ候補は、HFRR で保護しているサブネット ローカル インターフェイスと同じプレフィックスを持つルートでなければなりません。

バックアップ・パス選択ポリシー

レイヤー 3 VPN ルートのみがバックアップの選択対象として考慮されます。HFRR は、通常の BGP パス選択アルゴリズムを使用して、1 つの最適なバックアップ ルートを選択します。バックアップ パスは 1 つだけ選択されます。バックアップ・パスの候補が複数ある場合は、選択アルゴリズムが最適なバックアップ・パスを選択します。HFRR は、どの時点でも、プライマリとバックアップの 2 つのパスのみを提供します。選択したバックアップ パス自体に 2 つのパスが含まれている場合、そのバックアップ ネクスト ホップの最初のパスが HFRR ルートのバックアップ ネクスト ホップとして使用されます。

プライマリパスは、重みが 1 のものがインストールされます。バックアップ パスは、0x4000 の重みでインストールされます。バックアップパスは、明らかに、プライマリインターフェイスと同じではないインターフェイスを経由するパスでなければなりません。

バックアップルートは、インターフェイスが属するルーティングテーブルでのみ検索されます。IPv4 の場合、Junos OSは routing-instance-name.inet.0 を使用します。IPv6 の場合、Junos OSは routing-instance-name.inet6.0 を検索します。

HFRRルートの特徴

HFRR ルートは転送専用ルートであり、ルート解決には使用されません。HFRRルートにはホストアドレスがあるため、プレフィックス長は/32または/128です。デュアルルーティングエンジンを搭載したプラットフォームの場合、バックアップルーティングプロセス(rpd)もHFRRルートを作成します。しかし、バックアップ外出プロセス(rpd)は、ルーティングエンジンのスイッチオーバー後にバックアップがプライマリになるまで、ルーティングテーブルにHFRRルートをインストールしません。

また、ルーティングテーブルにHFRRルートが存在する場合、そのHFRRルートがユニキャストのリバースパスフォワーディング(uRPF)計算に使用されることにも注意してください。

HFRR ルートの削除

HFRR ルートが削除されるのは、保護されたインターフェイスが設定で削除または無効化された場合、HFRR がルーティング インスタンスで設定され、ルーティング インスタンスが無効化または削除された場合、または HFRR( link-protection (Host Fast Reroute) )を有効にする ステートメントが削除または無効化された場合です。HFRRルートは、ルーティングプロセスの再起動時など、インスタンスのルーティングに致命的な操作が発生した場合に削除され、再度追加されます。すべてのバックアップ ルートが削除されると、HFRR ルートも削除されます。例えば、BGPがルートを取り消したときや、BGPが非アクティブ化または削除されたときなどです。

保護されたインターフェイスがダウンした後、HFRR が削除または非アクティブ化されると、タイマーは 20 秒のタイムアウトで開始されます。HFRR ルートの削除は、タイマーが切れた後に行われます。これは、インターフェイスがフラッピングしている(急速にアップダウンしている)場合に、Junos OSがトラフィックロスの原因となるルートの削除や追加を不必要に行わないようにするためです。このタイマーは、インターフェイスがダウンしている場合、または HFRR ルートが削除または非活動化された場合にのみ使用されます。

HFRRルートは、以下の場合、即時にパージされます。

  • バックアップ ルートがダウンし、他にバックアップ パスの候補がなくなります。

  • ARP 削除メッセージを受信します。

  • ルーティングプロセス(rpd)が終了します。

HFRRをサポートするインターフェイス

HFRRは、イーサネットインターフェイスでのみ許可されています。ポイントツーポイントインターフェイスでHFRRを設定すると、コミット操作は失敗します。

VPNルーティングおよび転送(VRF)タイプのルーティング インスタンスで設定されたインターフェイスのみが受け入れられます。他のタイプのルーティングインスタンスでHFRRを設定すると、コミット操作は失敗します。

以下の要件が満たされていない場合、コミット操作は失敗しません。ただし、インターフェイスは HFRR によって保護されておらず、 show hfrr profiles コマンド出力でインターフェイスは非アクティブとマークされます。

  • HFRR は番号付きインターフェイスでのみ許可されるため、インターフェイスにアドレスを割り当てる必要があります。例えば、アドレスのあるインターフェイスで IPv4 を設定し、アドレスなしで IPv6 を設定することはできません。

  • HFRR 保護用に設定されたインターフェイスは、 [edit interfaces] 階層レベルで設定する必要があり、さらに ルーティング インスタンスに接続する必要があります。

  • ルーティング インスタンスには、VT(仮想トンネル)インターフェイスまたは vrf-table-label ステートメントが含まれている必要があります。

show hfrr profilesコマンドの出力でインターフェイスが非アクティブとマークされるもう一つの理由は、インターフェイスがインスタンス間で移行中で、HFRR設定が前のルーティング インスタンスにある場合です。

次に示すように、同一ルーティング インスタンスに属する重複する論理ユニットでは HFRR はサポートされません。

ここに示すように重複するサブネットを設定し、重複する両方のサブネットで HFRR を有効にすると、ルーティング プロトコル プロセス(rpd)でRPD_ASSERTエラーが生成されます。