VRRP を理解する
概要 VRRP(Virtual Router Redundancy Protocol)を使用すると、LAN上に仮想冗長ルーティングプラットフォームを構築し、単一のルーティングプラットフォームに頼らずにLAN上のトラフィックをルーティングすることができます。
VRRP を理解する
イーサネット、高速イーサネット、ギガビット イーサネット、10 ギガビット イーサネット、および論理インターフェイスに対して、IPv6 向けの仮想ルーター冗長プロトコル(VRRP)または VRRP を設定できます。VRRP を使用すると、LAN 上のホストは、ホスト上の単一のデフォルト ルートの静的な設定以上のものを必要とせずに、その LAN 上の冗長ルーティング プラットフォームを利用できます。VRRP ルーティング プラットフォームは、ホスト上で設定されたデフォルト ルートに対応する IP アドレスを共有します。常に、VRRP ルーティング プラットフォームの 1 つがプライマリ(アクティブ)で、他のプラットフォームがバックアップになります。プライマリ ルーティング プラットフォームに障害が発生した場合、バックアップ ルーティング プラットフォームの 1 つが新しいプライマリ ルーティング プラットフォームとなり、仮想デフォルト ルーティング プラットフォームが提供され、単一のルーティング プラットフォームに頼らずに LAN 上のトラフィックをルーティングできるようになります。VRRP を使用すると、バックアップ デバイスは障害が発生したデフォルト デバイスを数秒以内に引き継ぐことができます。これは、最小限の VRRP トラフィックで、ホストとの対話なしで行われます。仮想ルーター冗長プロトコルは、管理インターフェイスではサポートされていません。
VRRP を実行しているデバイスは、プライマリ デバイスとバックアップ デバイスを動的に選択します。また、1 から 255 までの優先順位を使用して、プライマリ デバイスとバックアップ デバイスを強制的に割り当てることもできます (255 が最優先)。VRRP 動作では、デフォルトのプライマリ デバイスが定期的にバックアップ デバイスにアドバタイズメントを送信します。デフォルトの間隔は 1 秒です。バックアップ デバイスが一定期間アドバタイズメントを受信しなかった場合、次に優先度の高いバックアップ デバイスがプライマリとして引き継ぎ、パケットの転送を開始します。
RVI(ルーテッドVLANインターフェイス)に優先度255を設定することはできません。
ネットワーク トラフィックを最小限に抑えるために、VRRP は、プライマリとして動作しているデバイスのみが任意の時点で VRRP アドバタイズメントを送信するように設計されています。バックアップ デバイスは、プライマリ ロールを引き継ぐまで、また引き継がない限り、アドバタイズメントを送信しません。
IPv6 向け VRRP は、IPv6 のネイバー探索手順よりも、代替デフォルト ルーターへのスイッチオーバーがはるかに高速です。一般的な導入では、1 つのバックアップ ルーターのみを使用します。
VRRPのプライマリおよびバックアップルーティングプラットフォームを、 バーチャルシャーシ 構成のプライマリおよびバックアップメンバースイッチと混同しないでください。バーチャルシャーシ構成のプライマリメンバーとバックアップメンバーは、単一のホストを構成します。VRRP トポロジーでは、 図 3 に示すように、1 つのホストがプライマリ ルーティング プラットフォームとして動作し、もう 1 つのホストがバックアップ ルーティング プラットフォームとして動作します。
VRRP は、RFC 3768、 Virtual Router Redundancy Protocolで定義されています。IPv6のVRRPは、 draft-ietf-vrrp-ipv6-spec-08.txt、IPv6の仮想ルーター冗長プロトコルで定義されています。draft-ietf-vrrp-unified-mib-06.txt「 IPv4およびIPv6を介したVRRPの管理オブジェクト定義」も参照してください。
RFC 3768で定義されているVRRPは認証をサポートしていませんが、VRRPのJunos OS実装は、RFC 2338で定義されている認証をサポートしています。このサポートは、RFC 3768 の後方互換性オプションによって実現されます。
EX2300 および EX3400 スイッチでは、ルーティング エンジンのスイッチオーバー、インターフェイス フラップ、パケット転送エンジンからの完全なデータ収集など、CPU を多用する操作イベントのフラップを防止するために、VRRP プロトコルを Hello 間隔を 2 秒以上、dead 間隔を 6 秒以上に設定する必要があります。
図 1 に、基本的な VRRP トポロジを示します。この例では、ルーター A、B、および C は VRRP を実行しており、一緒になって仮想ルーターを構成しています。この仮想ルーターの IP アドレスは 10.10.0.1(ルーター A の物理インターフェイスと同じアドレス)です。
仮想ルーターはルーター A の物理インターフェイスの IP アドレスを使用するため、ルーター A はプライマリ VRRP ルーターであり、ルーター B と C はバックアップ VRRP ルーターとして機能します。クライアント 1 から 3 は、デフォルト ゲートウェイ IP アドレス 10.10.0.1 で構成されます。ルーターAは、プライマリルーターとして、送信されたパケットをそのIPアドレスに転送します。プライマリ仮想ルーターに障害が発生した場合、優先度の高いルーターがプライマリ仮想ルーターとなり、LAN ホストに中断のないサービスを提供します。ルーター A が回復すると、再びプライマリ仮想ルーターになります。
場合によっては、継承セッション中に、2 台のルーターがプライマリ/プライマリ状態になる短い時間枠があります。このような場合、状態を継承する VRRP グループは 120 秒ごとに VRRP アドバタイズメントを送信します。そのため、ルーターがプライマリ-プライマリ状態からプライマリバックアップ状態に移行した後、回復するのに最大120秒かかります。
ACXシリーズルーターは、最大64のVRRPグループエントリーをサポートすることができます。これらは、IPv4 または IPv6 ファミリーの組み合わせにすることができます。いずれかのファミリ(IPv4 または IPv6)が VRRP 専用に設定されている場合、64 個の一意の VRRP グループ識別子がサポートされます。IPv4 ファミリと IPv6 ファミリの両方が同じ VRRP グループを共有する場合、32 個の一意の VRRP 識別子のみがサポートされます。
ACX シリーズ ルーターは、IPv6 アドレスの VRRP バージョン 3 をサポートしています。
ルーター ACX5448、RFC 3768 VRRP バージョン 2 および RFC 5798 VRRP バージョン 3 をサポートしています。また、ルーター ACX5448、集合型イーサネットおよびIRB(統合型ルーティングおよびブリッジング)インターフェイス上での VRRP の設定もサポートしています。
ルーターで VRRP を設定する際ACX5448以下の制限が適用されます。
最大 16 の VRRP グループを設定できます。
VRRP バージョン 2 と VRRP バージョン 3 のインターワーキングはサポートされていません。
VRRP デリゲート処理はサポートされていません。
VRRP バージョン 2 認証はサポートされていません。
図 1 は、EX シリーズ スイッチを使用した基本的な VRRP トポロジーを示しています。この例では、スイッチ A、B、C は VRRP を実行しており、これらが一体となって仮想ルーティング プラットフォームを構成しています。この仮想ルーティング プラットフォームの IP アドレスは(スイッチ A の物理インターフェイスと同じアドレス)です10.10.0.1。
の基本VRRP
図 3 は、バーチャル シャーシ構成を使用した基本的な VRRP トポロジーを示しています。スイッチA、スイッチB、スイッチCは、相互接続された複数のジュニパーネットワークスEX4200イーサネットスイッチで構成されています。各バーチャルシャーシ構成は、VRRPを実行する単一のスイッチとして動作し、これらを組み合わせることで仮想ルーティングプラットフォームを構成します。この仮想ルーティング プラットフォームの IP アドレスは(スイッチ A の物理インターフェイスと同じアドレス)です10.10.0.1。
上のVRRP
仮想ルーティング プラットフォームはスイッチ A の物理インターフェイスの IP アドレスを使用するため、スイッチ A がプライマリ VRRP ルーティング プラットフォームであり、スイッチ B とスイッチ C はバックアップ VRRP ルーティング プラットフォームとして機能します。クライアント1〜3は、プライマリルーターであるスイッチAが送信されたパケットをそのIPアドレスに転送するため、のデフォルトゲートウェイIPアドレス 10.10.0.1 で設定されています。プライマリ ルーティング プラットフォームに障害が発生した場合、優先度の高いスイッチがプライマリ仮想ルーティング プラットフォームとなり、LAN ホストに中断のないサービスを提供します。スイッチ A が回復すると、再びプライマリ仮想ルーティング プラットフォームになります。
関連項目
IPv6 向け VRRP および VRRP の概要
以下のインターフェイスに対して、IPv6 の仮想ルーター冗長プロトコル(VRRP)と VRRP を設定できます。
イーサネット
ファストイーサネット
トライレートイーサネット銅線
ギガビットイーサネット
10ギガビットイーサネットLAN/WAN PIC
イーサネット論理インターフェイス
IPv6 向け VRRP および VRRP を使用すると、LAN 上のホストは、ホスト上の 1 つのデフォルト ルートの静的な設定以上のものを必要とせずに、その LAN 上の冗長ルーターを利用できます。VRRP ルータは、ホストに設定されたデフォルト ルートに対応する IP アドレスを共有します。常に、VRRP ルータの 1 つがプライマリ(アクティブ)で、他はバックアップになります。プライマリに障害が発生すると、バックアップルーターの1つが新しいプライマリルーターになるため、常に仮想デフォルトルーターが提供され、単一のルーターに依存することなくLAN上のトラフィックをルーティングできます。
VRRP は、RFC 3768、 Virtual Router Redundancy Protocolで定義されています。
VRRP および IPv6 向け VRRP の概要情報、設定ガイドライン、ステートメントの概要については、 Junos OS 高可用性ユーザーガイドを参照してください。
関連項目
QFabric システム間の VRRP を理解する
ジュニパーネットワークスのQFabricシステムは、VRRP(Virtual Router Redundancy Protocol)をサポートしています。このトピックでは、次の内容について説明します。
QFabric システムでの VRRP の違い
デフォルト ゲートウェイへの静的ルートを使用してネットワーク上のサーバーを構成すると、構成の労力と複雑さが最小限に抑えられ、処理オーバーヘッドが削減されます。ただし、デフォルト ゲートウェイに障害が発生すると、通常は壊滅的なイベントが発生し、サーバーが分離されます。VRRP(仮想ルーター冗長プロトコル)を使用することで、プライマリゲートウェイに障害が発生した場合に、サーバーに代替ゲートウェイを動的に提供することができます。
VRRP で設定されたスイッチは、サーバのデフォルト ルートとして設定したアドレスである仮想 IP(VIP)アドレスを共有します。通常の VRRP 動作では、スイッチの 1 つが VRRP プライマリであり、VIP を所有し、アクティブなデフォルト ゲートウェイであることを意味します。その他のデバイスはバックアップです。スイッチは、設定した優先度に基づいて、プライマリ ロールとバックアップ ロールを動的に割り当てます。プライマリに障害が発生すると、プライオリティが最も高いバックアップ スイッチがプライマリになり、数秒以内に VIP の所有権を取得します。これは、サーバーとの対話なしで行われます。
2 つの QFabric システムを、あたかも 2 つのスタンドアロン スイッチであるかのように VRRP コンフィギュレーションに参加するように設定できます。ただし、通常の VRRP 動作では、特定の VRRP グループのプライマリにできるシステムは一度に 1 つだけであるため、グループに設定された VIP を使用してデフォルト ゲートウェイとして動作できるシステムは 1 つだけです。2 つの QFabric システムで VRRP を実行する場合、両方のシステムで同時に VIP を使用してゲートウェイとして動作させ、トラフィックを転送したい場合があります。これを実現するために、ファイアウォールフィルターを設定して、2つのネットワークノードグループ間のリンク上で、QFabricシステム間のVRRPアドバタイズパケットをブロックすることができます。これを行うと、両方のQFabricシステムが、VIPが受信するプライマリトラフィックおよび転送トラフィック(両方のQFabricシステムに接続されたサーバー上で設定するデフォルトゲートウェイアドレス)として機能します。VMware の vMotion を使用する場合、この構成により、仮想マシンはデフォルト ゲートウェイ情報を更新することなく、QFabric システムに接続されたサーバー間を移行できます。例えば、データ センター A の QFabric システムに接続されたサーバーで実行されている仮想マシンは、両方の QFabric システムが同じ VIP を使用するため、新しいゲートウェイ IP アドレスと MAC アドレスを解決することなく、データ センター B の QFabric システムに接続されたサーバーに移行できます。
ファイアウォール フィルターを使用して VRRP トラフィックをブロックするには、そのトラフィックの protocol vrrp トラフィックと一致し、そのトラフィックを破棄するファイアウォール条件を作成します。
構成の詳細
2 つの QFabric システムで VRRP グループを設定することは、2 台のスイッチで VRRP を設定することと同じです。主な違いは次のとおりです。
VRRP に参加する両方の QFabric システムのすべてのインターフェイスは、同じ VLAN のメンバーである必要があります。
両方の QFabric システムで、その VLAN 内に RVI(ルーテッド VLAN インターフェイス)を作成する必要があります。
両方の RVI に割り当てる IP アドレスは、同じサブネット内にある必要があります。
RVI で VRRP を設定する必要があります。
両方の RVI は、同じ VRRP グループのメンバーである必要があります。これにより、2つのQFabricシステムで仮想IPアドレスを共有できます。
以下の表は、2 つの QFabric システム(QFabric システム A と QFabric システム B)で実行されている VRRP 設定例の要素を示しています。この例では、両方の QFabric システムが VIP 10.1.1.50/24 の VRRP プライマリとして動作するように設定されており、ファイアウォール フィルターがシステム間の VRRP アドバタイズメントをブロックすることを前提としています。 表 1 に、設定例で RVI に必要な特性を示します。
次の表に示すコンフィギュレーション設定のほとんどは、従来の VRRP コンフィギュレーションにも適用されます。ただし、アドバタイズ間隔と優先度の設定は(前述のように)異なる必要があります。
| QFabric システム A での RVI | QFabric システム B での RVI |
vlan.100 |
VLAN.200 |
VLAN 100 のメンバー。(VLAN は両方の QFabric システムで同じであることに注意してください。) |
VLAN 100 のメンバー |
IP アドレス 10.1.1.100/24 |
IP アドレス 10.1.1.200/24 |
VRRPグループ500のメンバー |
VRRPグループ500のメンバー |
仮想 IP アドレス 10.1.1.50/24 |
仮想 IP アドレス 10.1.1.50/24 |
両方の QFabric システムの RVI で VRRP を設定する必要があります。表 2 に、各 RVI の VRRP 設定例の要素を示します。優先順位を除いて、パラメーターは両方のシステムで同じ でなければならない ことに注意してください。
| QFabric システム A 上の RVI 上の VRRP | QFabric システム B 上の RVI 上の VRRP |
VRRP グループ 500 |
VRRP グループ 500 |
仮想 IP アドレス 10.1.1.50/24 |
仮想 IP アドレス 10.1.1.50/24 |
アドバタイズ間隔は60秒です。(通常の VRRP 設定では、この間隔を 1 秒など、はるかに短く設定します。ただし、この構成では、これらのパケットは QFabric システム B に接続するインターフェイスのファイアウォール フィルターによってブロックされるため、頻繁に送信する必要はありません)。 |
アドバタイズ間隔 60 秒 |
認証タイプ md5 |
認証タイプ md5 |
認証キー $9$1.4ElMVb2aGi4aZjkqzFRhSeWx7-wY2aM8 |
認証キー $9$1.4ElMVb2aGi4aZjkqzFRhSeWx7-wY2aM8 |
優先度 254。(通常の VRRP 設定では、この値は 2 つのシステムで異なり、値が大きいシステムがプライマリになります。ただし、この設定では両方のシステムがプライマリとして機能するため、異なる値を設定する必要はありません)。 |
優先度 254 |
優先度 255 は RVI ではサポートされていません。
表 3 は、設定例の QFabric システム A のすべてのインターフェイスの一覧と、それらの接続先を示しています。
| QFabric システム A の VLAN 100 インターフェイス | 接続先 |
vlan.100 |
VLAN.200 |
ネットワークノードグループインターフェイスQFA-NNG:xe-0/0/0 |
QFB-NNG:xe-0/0/0 on QFabric システム B |
ネットワーク ノード グループ インターフェイス QFA-NNG:xe-0/0/1 |
冗長サーバー ノードグループインターフェイス QFA-RSNG:xe-0/0/0 |
冗長サーバー ノードグループインターフェイス QFA-RSNG:xe-0/0/0 |
ネットワーク ノード グループ インターフェイス QFA-NNG:xe-0/0/1 に接続します。 |
冗長サーバー ノードグループインターフェイス QFA-RSNG:xe-0/0/1 |
仮想マシンを実行しているサーバーを備えたLAN |
表 4 は、設定例の QFabric システム B のすべてのインターフェイスの一覧と、それらの接続先を示しています。
| QFabric システム B の VLAN 100 インターフェイス | 接続先 |
VLAN.200 |
vlan.100 |
ネットワークノードグループインターフェイスQFB-NNG:xe-0/0/0 |
QFA-NNG:xe-0/0/0 on QFabric システム A |
ネットワークノードグループインターフェイスQFB-NNG:xe-0/0/1 |
冗長サーバー ノードグループインターフェイス QFB-RSNG:xe-0/0/0 |
冗長サーバー ノードグループインターフェイス QFB-RSNG:xe-0/0/0 |
ネットワーク ノード グループ インターフェイス QFB-NNG:xe-0/0/1 に接続します。 |
冗長サーバー ノードグループインターフェイス QFB-RSNG:xe-0/0/1 |
仮想マシンを実行しているサーバーを備えたLAN |
関連項目
VRRPv3 用 Junos OS サポート
VRRPv3 を使用する利点は、VRRPv3 が IPv4 アドレス ファミリと IPv6 アドレス ファミリの両方をサポートするのに対し、VRRPv2 は IPv4 アドレスのみをサポートすることです。
次のトピックでは、VRRPv3 の Junos OS のサポートと相互運用性、および VRRPv3 とその前身の違いについて説明します。
Junos OS VRRP サポート
リリース12.2より前のリリースでは、Junos OSは、RFC 3768、 仮想ルーター冗長 プロトコル(VRRP )(IPv4用)およびインターネットドラフトdraft-ietf-vrrp-ipv6-spec-08、 IPv6向け仮想ルーター冗長プロトコルをサポートしていました。
VRRPv3は、Junos OSリリース12.2より前のリリースを使用するルーターではサポートされておらず、QFX10000スイッチ上のIPv6でもサポートされていません。
IPv6 向け VRRPv3 は、QFX10002-60C でサポートされています。
リリース12.2以降、Junos OSは以下をサポートします。
RFC 3768、 仮想ルーター冗長プロトコル(VRRP)
RFC 5798、 IPv4およびIPv6のVRRP(仮想ルーター冗長プロトコル)バージョン3
RFC 6527、 仮想ルーター冗長性プロトコル バージョン 3(VRRPv3)向け管理対象オブジェクトの定義
Junos OSリリース12.2以降のリリースを使用するルーター上のVRRP(IPv6用)は、VRRPチェックサムの計算方法が異なるため、Junos OS以前のリリースのルーター上のVRRP(IPv6用)と相互運用できません。 IPv6 VRRP チェックサムの動作の違いを参照してください。
IPv6 VRRP チェックサムの動作の違い
IPv6 VRRP ネットワークを有効にする場合は、次のチェックサムの違いを考慮する必要があります。
Junos OS リリース 12.2 より前のリリースで、IPv6 の VRRP が設定されている場合、VRRP チェックサムは RFC 3768、 VRRP(仮想ルーター冗長プロトコル)のセクション 5.3.8 に従って計算されます。
Junos OS リリース 12.2 以降、IPv6 の VRRP が設定されている場合、VRRPv3 が有効かどうかに関係なく、VRRP チェックサムは RFC 5798の IPv4 および IPv6 向け仮想ルーター冗長プロトコル(VRRP)バージョン 3 のセクション 5.2.8 に従って計算されます。
さらに、疑似ヘッダーは、IPv6 VRRP チェックサムを計算する場合にのみ含まれます。IPv4 VRRP チェックサムの計算時に疑似ヘッダーは含まれません。
Junos OSリリース12.2(またはそれ以降のJunos OSリリース)IPv6 VRRPを搭載したルーターを、リリース12.2より前のJunos OSリリースを実行しているルーターと相互運用できるようにするには、Junos OSリリース12.2以降を実行しているルーターの階層レベルに
[edit protocols vrrp]設定ステートメントを含めchecksum-without-pseudoheaderます。Junos OS リリース 12.2 以降のユーティリティは
tcpdump、RFC 5798、 IPv4 および IPv6 向け仮想ルーター冗長プロトコル(VRRP)バージョン 3 に従って、VRRP チェックサムを計算します。そのため、古いJunos OSリリース(Junos OS リリース 12.2より前)から受信したIPv6 VRRPパケットを解析するとtcpdump、次のようにbad vrrp cksum表示されます。23:20:32.657328 Out ... -----original packet----- 00:00:5e:00:02:03 > 33:33:00:00:00:12, ethertype IPv6 (0x86dd), length 94: (class 0xc0, hlim 255, next-header: VRRP (112), length: 40) fe80::224:dcff:fe47:57f > ff02::12: VRRPv3-advertisement 40: vrid=3 prio=100 intvl=100(centisec) (bad vrrp cksum b4e2!) addrs(2): fe80::200:5eff:fe00:3,2001:4818:f000:14::1 3333 0000 0012 0000 5e00 0203 86dd 6c00 0000 0028 70ff fe80 0000 0000 0000 0224 dcff fe47 057f ff02 0000 0000 0000 0000 0000 0000 0012 3103 6402 0064 b4e2 fe80 0000 0000 0000 0200 5eff fe00 0003 2001 4818 f000 0014 0000 0000 0000 0001このメッセージは VRRP の障害を示していないため、無視してかまいません。
VRRP 相互運用性
Junos OS リリース 12.2 より前のリリースでは、VRRP(IPv6)はインターネット ドラフト draft-ietf-vrrp-ipv6-spec-08 に従いましたが、チェックサムは RFC 3768 セクション 5.3.8 に基づいて計算されました。リリース 12.2 以降、VRRP(IPv6)は RFC 5798 に準拠し、チェックサムは RFC 5798 セクション 5.2.8 に基づいて計算されます。VRRP チェックサムの計算方法の違いにより、Junos OS リリース 12.2 以降のリリースを使用するルーターで設定された IPv6 VRRP は、Junos OS リリース 12.2 より前のリリースで設定された IPv6 VRRP と相互運用できません。
Junos OSリリース12.2(またはそれ以降のJunos OSリリース)を搭載したルーターIPv6 VRRPを、リリース12.2より前のJunos OSリリースを実行しているルーターと相互運用できるようにするには、Junos OSリリース12.2以降を搭載したルーターの階層レベルに [edit protocols vrrp] 設定ステートメントを含めchecksum-without-pseudoheaderます。
VRRP の相互運用性について知っておくべき一般的なポイントを次に示します。
Junos OSリリース12.2以降のリリースを使用するルーターでVRRPv3(IPv4またはIPv6)を設定した場合、Junos OSリリース12.1以前のリリースを使用するルーターでは動作しません。これは、Junos OS リリース 12.2 以降のリリースのみが VRRPv3 をサポートしているためです。
Junos OSリリース12.2以降のリリースを使用するルーターで設定されたVRRP(IPv4またはIPv6)は、Junos OSリリース12.2より前のリリースを使用するルーターで設定されたVRRP(IPv4またはIPv6)と相互運用できます。
IPv4 向け VRRPv3 は、以前のバージョンの VRRP とは相互運用できません。VRRPv3 が有効になっているルーターが VRRPv2 IPv4 アドバタイズパケットを受信すると、ルーターはバックアップ ステートに移行し、ネットワーク内に複数のプライマリが作成されないようにします。この動作のため、既存の VRRPv2 ネットワークで VRRPv3 を有効にする場合は注意が必要です。詳細については、 VRRPv2 から VRRPv3 へのアップグレード を参照してください。
メモ：VRRPv3 アドバタイズパケットは、以前のバージョンの VRRP が設定されているルーターでは無視されます。
VRRPv2 から VRRPv3 へのアップグレード
ネットワーク内のすべての VRRP ルータで VRRPv3 をイネーブルにできる場合にのみ、ネットワークで VRRPv3 を有効にします。
VRRPv2 から VRRPv3 にアップグレードする場合にのみ、VRRPv2 ネットワークで VRRPv3 を有効にします。 VRRP の 2 つのバージョンを混在させることは、永続的な解決策ではありません。
VRRP のバージョン変更は、壊滅的で破壊的であると見なされ、ヒットレスではない可能性があります。パケット損失の期間は、VRRP グループの数、関連するインターフェイスや FPC、ルーターで実行されている他のサービスやプロトコルの負荷など、多くの要因によって異なります。
VRRPv2 から VRRPv3 へのアップグレードは、次の考慮事項により、トラフィックの損失を避けるために非常に慎重に行う必要があります。
すべてのルータで同時に VRRPv3 を設定することはできません。
移行期間中は、VRRPv2 と VRRPv3 の両方がネットワークで動作します。
VRRP バージョンを変更すると、すべての VRRP グループのステート マシンが再起動します。
VRRPv3(IPv4 の場合)ルーターは、VRRPv2(IPv4 の場合)アドバタイズメント パケットを受信すると、デフォルトでバックアップ ステートになります。
VRRPv2(IPv4 の場合)パケットには、常に最高の優先度が与えられます。
VRRPv2 と VRRPv3 のチェックサムの相違点(IPv6 の場合)では、複数のプライマリ ルーターを作成できます。
複数のプライマリ ルーターが作成されないように、アップグレード中はバックアップ ルーターで VRRPv3(IPv6 用)を無効にします。
表 5 に、VRRPv2 から VRRPv3 への移行中に発生する手順とイベントを示します。 表 5 では、2 台の VRRPv2 ルータ R1 および R2 が G1 および G2 の 2 つのグループに設定されています。ルーターR1はG1のプライマリとして機能し、ルーターR2はG2のプライマリとして機能します。
|
|
For IPv4 |
For IPv6 |
|
|
VRRPv3(IPv4)は以前のバージョンのVRRPと相互運用できないため、VRRPv3 を有効にする場合は、ネットワーク内のすべての VRRP ルーターで VRRPv3 が有効になっていることを確認してください。たとえば、VRRPv3 が有効になっているルーターが VRRPv2 IPv4 アドバタイズパケットを受信した場合、ルーターはバックアップ ステートに移行し、ネットワーク内に複数のプライマリが作成されないようにします。
階層レベルで ステートメント[edit protocols vrrp]を設定するversion-3ことで、VRRPv3 を有効にできます(IPv4 または IPv6 ネットワークの場合)。LAN 上のすべての VRRP ルーターに同じプロトコル バージョンを設定します。
VRRPv3 の機能
VRRPv3 では、Junos OS の一部の機能が以前の VRRP バージョンと異なります。
VRRPv3認証
VRRPv3(IPv4用)が有効になっている場合、認証は許可されません。
および
authentication-keyステートメントはauthentication-type、どの VRRP グループにも設定できません。非 VRRP 認証を使用する必要があります。
VRRPv3 アドバタイズ間隔
VRRPv3(IPv4 および IPv6 用)のアドバタイズ間隔は、階層レベルの ステートメント[edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name]を使用してfast-interval 設定する必要があります。
ステートメントは使用
advertise-intervalしないでください(IPv4の場合)。(IPv6 の場合)ステートメント
inet6-advertise-intervalは使用しないでください。
VRRPv3 向け統合型 ISSU
Junos OS リリース 15.1 では、以下の機能を実現するために、VRRP 統合型稼動中ソフトウェア アップグレード(ISSU)の設計変更が行われました。
統合型 ISSU の間、ピアルーターとのプロトコル隣接関係を維持する。統合 ISSU を受けるルーターのピア ルーターで作成されたプロトコル隣接関係はフラップしない、つまりリモート ピア ルーターの VRRP はフラップしないことを意味します。
競合機器や補完機器との相互運用性を維持する。
他のJunos OSリリースや他のジュニパーネットワーク製品との相互運用性を維持します。
統合型 ISSU をサポートするには、 [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] 次の構成の値(階層レベルにあります)を最大値に保つ必要があります。
プライマリルーターでは、アドバタイズ間隔(
fast-intervalステートメント)を40950ミリ秒に保つ必要があります。バックアップ ルーターでは、プライマリ ダウン間隔(
advertisements-thresholdステートメント)を最大のしきい値に保つ必要があります。
この VRRP 統合 ISSU デザインは、VRRPv3 でのみ機能します。VRRPv1 または VRRPv2 ではサポートされていません。その他の制限は次のとおりです。
VRRP 統合 ISSU は VRRP のみを処理します。パケット転送は、パケット転送エンジンが行います。パケット転送エンジン統合ISSUは、中断のないトラフィックフローを確保する必要があります。
VRRP は、統合型 ISSU 中のいかなる変更イベント(プライマリ ルーティング エンジンのバックアップへの切り替えや、バックアップ ルーティング エンジンのプライマリへのスイッチオーバーなど)の影響を受けません。
VRRP は、統合型 ISSU に入る前に、実行中のタイマーを停止して破棄する場合があります。これは、タイマーの満了時に予想されるアクションが実行されないことを意味します。ただし、すべての実行タイマーの有効期限が切れるまで統合 ISSU を延期できます。
ローカルルーターとリモートルーターの両方でISSUを統合することは、同時に実行することはできません。
関連項目
VRRP フェイルオーバー遅延の概要
フェイルオーバーは、障害やスケジュールされたダウンタイムが原因でプライマリデバイスが使用できなくなったときに、ネットワークデバイスの機能をセカンダリデバイスに引き継ぐバックアップ運用モードです。フェイルオーバーは、通常、ネットワーク上で常に利用可能でなければならないミッションクリティカルなシステムにとって不可欠な部分です。
VRRP は、メンバー間のセッション同期をサポートしていません。プライマリ デバイスに障害が発生すると、優先度が最も高いバックアップ デバイスがプライマリとして引き継ぎ、パケットの転送を開始します。既存のセッションは、アウトオブステートとしてバックアップ デバイスにドロップされます。
高速フェールオーバーには短い遅延が必要です。したがって、フェイルオーバー遅延は、IPv6 操作の VRRP および VRRP のフェイルオーバー遅延時間をミリ秒単位で設定します。Junos OSは、フェイルオーバー時間の遅延について、50〜100000ミリ秒の範囲をサポートします。
ルーティング エンジン上で実行されている VRRP プロセス(vrrpd)は、VRRP セッションごとに VRRP プライマリ ロールの変更をパケット転送エンジンに伝えます。各 VRRP グループは、このような通信をトリガーして、パケット転送エンジンを独自の状態またはアクティブな VRRP グループから継承された状態に更新できます。このようなメッセージでパケット転送エンジンが過負荷になるのを避けるために、フェイルオーバー遅延を設定して、後続のルーティングエンジンからパケット転送エンジンへの通信間の遅延を指定できます。
ルーティング エンジンは、パケット転送エンジン ハードウェア フィルタや VRRP セッションの再プログラミングなど、パケット転送エンジンで必要な状態変更を容易にするために、VRRP プライマリ ロールの変更をパケット転送エンジンに伝えます。以下のセクションでは、ルーティング エンジンからパケット転送エンジンへの通信について、2 つのシナリオで詳しく説明します。
フェイルオーバー遅延が設定されていない場合
フェイルオーバー遅延が設定されていない場合、ルーティング エンジンから動作する VRRP セッションのイベントのシーケンスは次のようになります。
ルーティング エンジンによって検出された最初の VRRP グループの状態が変化し、新しい状態がプライマリである場合、ルーティング エンジンは適切な VRRP アナウンス メッセージを生成します。パケット転送エンジンには状態変化が通知されるため、そのグループのハードウェアフィルターは遅滞なく再プログラムされます。新しいプライマリは、VRRP グループに無償 ARP メッセージを送信します。
フェールオーバー タイマーの遅延が開始されます。デフォルトでは、フェイルオーバー遅延タイマーは次のとおりです。
500 ミリ秒:設定された VRRP アナウンス間隔が 1 秒未満の場合。
2 秒:設定された VRRP アナウンス間隔が 1 秒以上で、ルータ上の VRRP グループの総数が 255 の場合。
[10 秒(10 秒)]:設定された VRRP アナウンス間隔が 1 秒以上で、ルータ上の VRRP グループの数が 255 を超える場合。
ルーティング エンジンは、後続の VRRP グループの状態変更を 1 つずつ実行します。ステートが変化し、特定の VRRP グループの新しいステートがプライマリになるたびに、ルーティング エンジンは適切な VRRP アナウンス メッセージを生成します。ただし、パケット転送エンジンへの通信は、フェイルオーバー遅延タイマーが終了するまで抑制されます。
フェイルオーバー遅延タイマーが経過すると、ルーティング エンジンは、状態を変更できたすべての VRRP グループに関するメッセージをパケット転送エンジンに送信します。その結果、これらのグループのハードウェア フィルタが再プログラムされ、新しい状態がプライマリであるグループには、Gratuitous ARP メッセージが送信されます。
このプロセスは、すべての VRRP グループの状態遷移が完了するまで繰り返されます。
したがって、フェイルオーバー遅延を設定しない場合、設定されたVRRPアナウンスタイマーとVRRPグループの数に応じて、最初のVRRPグループの完全な状態遷移(ルーティングエンジンとパケット転送エンジンの状態を含む)が直ちに実行されますが、残りのVRRPグループに対するパケット転送エンジンの状態遷移は少なくとも0.5〜10秒遅れます。この中間状態では、ハードウェア フィルタの再設定が延期されたため、パケット転送エンジンでまだ完了していない状態変化の VRRP グループの受信トラフィックがパケット転送エンジン レベルでドロップされることがあります。
フェイルオーバー遅延が設定されている場合
フェイルオーバー遅延が設定されている場合、ルーティング エンジンから操作される VRRP セッションのイベントのシーケンスは以下のように変更されます。
ルーティング エンジンは、一部の VRRP グループに状態変更が必要であることを検知します。
フェイルオーバー遅延は、設定された期間開始されます。許容されるフェイルオーバー遅延タイマーの範囲は、50 から 100000 ミリ秒です。
ルーティング エンジンは、VRRP グループに対して 1 つずつの状態変更を実行します。ステートが変化し、特定の VRRP グループの新しいステートがプライマリになるたびに、ルーティング エンジンは適切な VRRP アナウンス メッセージを生成します。ただし、パケット転送エンジンへの通信は、フェイルオーバー遅延タイマーが終了するまで抑制されます。
フェイルオーバー遅延タイマーが経過すると、ルーティング エンジンは、状態を変更できたすべての VRRP グループに関するメッセージをパケット転送エンジンに送信します。その結果、これらのグループのハードウェア フィルタが再プログラムされ、新しい状態がプライマリであるグループには、Gratuitous ARP メッセージが送信されます。
このプロセスは、すべての VRRP グループの状態遷移が完了するまで繰り返されます。
そのため、フェイルオーバー遅延が設定されている場合、最初の VRRP グループのパケット転送エンジンの状態も延期されます。ただし、ネットワーク オペレータには、VRRP の状態変更時の停止を最小限に抑えるために、ネットワーク導入のニーズに最も適したフェイルオーバー遅延値を設定できるという利点があります。
フェイルオーバー遅延は、ルーティング エンジンで実行されている VRRP プロセス(vrrpd)が運用する VRRP セッションにのみ影響します。パケット転送エンジンに配信される VRRP セッションの場合、フェイルオーバー遅延設定は効果がありません。
関連項目
変更履歴テーブル
機能のサポートは、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がプラットフォームでサポートされているかどうかを判断します。