VRRP について
仮想ルーター冗長プロトコル(VRRP)を使用して、LAN上に仮想冗長ルーティングプラットフォームを作成し、単一のルーティングプラットフォームに依存せずにLAN上のトラフィックをルーティングできます。
VRRP について
イーサネット、ファスト イーサネット、ギガビット イーサネット、10ギガビット イーサネット、および論理インターフェイスでは、IPv6用VRRP(仮想ルーター冗長プロトコル)を設定できます。VRRP を使用すると、LAN 上のホストは、ホスト上の単一のデフォルト ルートの静的設定以上のものを必要とすることなく、その LAN 上の冗長ルーティング プラットフォームを使用できます。VRRP ルーティング プラットフォームは、ホストに設定されたデフォルト ルートに対応する IP アドレスを共有します。常に、VRRPルーティングプラットフォームの1つがプライマリ(アクティブ)で、残りがバックアップです。プライマリルーティングプラットフォームに障害が発生した場合、バックアップルーティングプラットフォームの1つが新しいプライマリルーティングプラットフォームとなり、仮想的なデフォルトルーティングプラットフォームが提供され、単一のルーティングプラットフォームに依存せずにLAN上のトラフィックをルーティングできるようになります。VRRP を使用すると、バックアップ デバイスが障害が発生したデフォルト デバイスを数秒以内に引き継ぐことができます。これは、最小限のVRRPトラフィックで、ホストとのやり取りなしで行われます。仮想ルーター冗長プロトコルは、管理インターフェイスではサポートされていません。
VRRP を実行しているデバイスは、プライマリ デバイスとバックアップ デバイスを動的に選択します。また、1から255までの優先度(255が最も高い優先度)を使用して、プライマリデバイスとバックアップデバイスの割り当てを強制することもできます。VRRP 動作では、デフォルトのプライマリデバイスが定期的にバックアップデバイスにアドバタイズを送信します。デフォルトの間隔は1秒です。バックアップデバイスが一定期間アドバタイズメントを受信しない場合、次に優先度の高いバックアップデバイスがプライマリとして引き継ぎ、パケットの転送を開始します。
ルーテッドVLANインターフェイス(RVI)には優先度255を設定できません。
VRRP は、ネットワーク トラフィックを最小限に抑えるために、プライマリとして動作しているデバイスのみが任意の時点で VRRP アドバタイズメントを送信するように設計されています。バックアップデバイスは、プライマリロールを引き継ぐまで、また引き継がらない限り、アドバタイズメントを送信しません。
IPv6 向け VRRP は、IPv6 のネイバー検出手順よりもはるかに高速な代替デフォルト ルーターへのスイッチオーバーを提供します。一般的な導入では、バックアップルーターは1台のみを使用します。
VRRP のプライマリおよびバックアップ ルーティング プラットフォームと、 バーチャルシャーシ 構成のプライマリおよびバックアップ メンバー スイッチを混同しないでください。バーチャルシャーシ構成のプライマリメンバーとバックアップメンバーは、単一のホストを構成します。VRRP トポロジーでは、 図 3 に示すように、1 つのホストがプライマリ ルーティング プラットフォームとして動作し、もう 1 つのホストがバックアップ ルーティング プラットフォームとして動作します。
VRRP は、RFC 3768、 仮想ルーター冗長プロトコルで定義されています。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プロトコルを2秒以上のHello間隔、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の設定もサポートしています。
ACX5448 ルーターで VRRP を設定する際には、以下の制限が適用されます。
-
最大16個のVRRPグループを設定します。
-
VRRP バージョン 2 と VRRP バージョン 3 の連携はサポートされていません。
-
VRRP デリゲート処理はサポートされていません。
-
VRRP バージョン 2 認証はサポートされていません。
図1は、EXシリーズスイッチを使用した基本的なVRRPトポロジーを示しています。この例では、スイッチ A、B、C は VRRP を実行しており、これらが組み合わされて仮想ルーティング プラットフォームを構成しています。この仮想ルーティングプラットフォームのIPアドレスは10.10.0.1です(スイッチAの物理インターフェイスと同じアドレス)。
の基本的なVRRP
図3は、バーチャルシャーシ構成を使用した基本的なVRRPトポロジーを示しています。スイッチA、スイッチB、スイッチCはそれぞれ、相互接続された複数のジュニパーネットワークスEX4200イーサネットスイッチで構成されています。各バーチャルシャーシ構成は、VRRPを実行している単一のスイッチとして動作し、組み合わせて仮想ルーティングプラットフォームを構成します。この仮想ルーティングプラットフォームのIPアドレスは10.10.0.1です(スイッチAの物理インターフェイスと同じアドレス)。
上のVRRP
仮想ルーティングプラットフォームはスイッチAの物理インターフェイスのIPアドレスを使用するため、スイッチAがプライマリVRRPルーティングプラットフォームとなり、スイッチBとスイッチCはバックアップVRRPルーティングプラットフォームとして機能します。クライアント1〜3は、プライマリルーターであるスイッチAが、そのIPアドレスに送信されたパケットを転送する 10.10.0.1 のデフォルトゲートウェイIPアドレスで設定されます。プライマリルーティングプラットフォームに障害が発生した場合、優先度の高いスイッチがプライマリ仮想ルーティングプラットフォームとなり、LANホストに中断のないサービスを提供します。スイッチAが回復すると、再びプライマリ仮想ルーティングプラットフォームになります。
VRRP と IPv6 向け VRRP の概要
以下のインターフェイスに対して、VRRP(Virtual Router Redundancy Protocol)と VRRP for IPv6 を設定できます。
イーサネット
ファストイーサネット
トライレートイーサネット銅線
ギガビットイーサネット
10ギガビットイーサネットLAN/WAN PIC
イーサネット論理インターフェイス
VRRP および IPv6 向け VRRP を使用すると、LAN 上のホストは、ホスト上の単一のデフォルト ルートの静的構成以上のものを必要とすることなく、その LAN 上の冗長ルーターを使用できます。VRRP ルーターは、ホストに設定されたデフォルト ルートに対応する IP アドレスを共有します。常に、VRRP ルーターの 1 つがプライマリ(アクティブ)で、残りがバックアップです。プライマリに障害が発生した場合、バックアップルーターの1つが新しいプライマリルーターとなるため、常に仮想デフォルトルーターが提供され、単一のルーターに依存せずにLAN上のトラフィックをルーティングできます。
VRRP は、RFC 3768、 仮想ルーター冗長プロトコルで定義されています。
VRRP と VRRP for IPv6 の概要情報、設定ガイドライン、ステートメントの概要については、 Junos OS 高可用性ユーザーガイドを参照してください。
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(Virtual Router Redundancy Protocol)バージョン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 のセクション 5.2.8、 IPv4 および IPv6 用の仮想ルーター冗長プロトコル(VRRP)バージョン 3 に従って計算されます。
さらに、擬似ヘッダーは、IPv6 VRRP チェックサムを計算する場合にのみ含まれます。IPv4 VRRP チェックサムの計算時には、疑似ヘッダーは含まれません。
リリース12.2(またはそれ以降のJunos OSリリース)Junos OS IPv6 VRRPを、リリース12.2より前のJunos OSリリースを実行しているルーターと相互運用できるようにするルーターには、リリース12.2以降を実行しているルーターの
[edit protocols vrrp]階層レベルでchecksum-without-pseudoheader設定ステートメントJunos OS含めます。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で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 を有効にしてください。 2 つのバージョンの VRRP を混在させることは、永続的な解決策ではありません。
VRRP のバージョン変更は壊滅的で破壊的であると考えられており、ヒットレスではない可能性があります。パケット損失の期間は、VRRP グループの数、関係するインターフェイスと FPC、ルーター上で実行されている他のサービスやプロトコルの負荷など、多くの要因によって異なります。
VRRPv2 から VRRPv3 へのアップグレードは、以下の点を考慮するため、トラフィックの損失を避けるために細心の注意を払って行う必要があります。
すべてのルーターで同時にVRRPv3を設定することはできません。
移行期間中は、VRRPv2とVRRPv3の両方がネットワーク内で動作します。
VRRP のバージョンを変更すると、すべての VRRP グループのステート マシンが再起動します。
VRRPv3(IPv4 の場合)ルーターは、VRRPv2(IPv4 の場合)アドバタイズ パケットを受信すると、デフォルトでバックアップ状態になります。
VRRPv2(IPv4用)パケットには常に最高の優先度が与えられます。
VRRPv2とVRRPv3(IPv6の場合)のチェックサムの違いにより、複数のプライマリルーターを作成できます。
複数のプライマリルーターが作成されないように、アップグレード中にバックアップルーターでVRRPv3(IPv6用)を無効にしてください。
表 1 は 、VRRPv2 から VRRPv3 への移行中に実行される手順とイベントを示しています。 表1では、R1とR2の2つのVRRPv2ルーターがG1とG2の2つのグループに設定されています。ルーター R1 は G1 のプライマリとして機能し、ルーター R2 は G2 のプライマリとして機能します。
|
|
For IPv4 |
For IPv6 |
|
|
VRRPv3(IPv4)は以前のバージョンのVRRPと相互運用できないため、VRRPv3を有効にする場合は、ネットワーク内のすべてのVRRPルーターでVRRPv3が有効になっていることを確認してください。例えば、VRRPv3が有効になっているルーターがVRRPv2 IPv4アドバタイズパケットを受信した場合、ルーターはネットワークに複数のプライマリが作成されないように、自身をバックアップ状態に移行します。
VRRPv3を有効にするには、[edit protocols vrrp]階層レベルでversion-3ステートメントを設定します(IPv4またはIPv6ネットワークの場合)。LAN 上のすべての VRRP ルーターで同じプロトコル バージョンを設定します。
VRRPv3 機能の機能
VRRPv3の一部のJunos OS機能は、以前のVRRPバージョンとは異なります。
VRRPv3認証
VRRPv3(IPv4用)が有効になっている場合、認証は許可されません。
authentication-typeおよびauthentication-keyステートメントは、どのVRRPグループにも設定できません。非VRRP 認証を使用する必要があります。
VRRPv3 アドバタイズ間隔
VRRPv3(IPv4およびIPv6用)のアドバタイズ間隔は、[edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name]階層レベルのfast-interval ステートメントで設定する必要があります。
(IPv4の場合)
advertise-intervalステートメントは使用しないでください。inet6-advertise-intervalステートメントを使用しないでください(IPv6の場合)。
VRRPv3用の統合型ISSU
以下の機能を実現するために、VRRP 統合型稼動中ソフトウェア アップグレード(ISSU)の設計変更が Junos OS リリース 15.1 で行われました。
統合型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 グループに gratuitous ARP メッセージを送信します。
フェイルオーバータイマーの遅延が開始されます。デフォルトでは、フェイルオーバー遅延タイマーは次のとおりです。
500ミリ秒—設定されたVRRPアナウンス間隔が1秒未満の場合。
2秒—設定されたVRRPアナウンス間隔が1秒以上で、ルーター上のVRRPグループの総数が255の場合。
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セッションの場合、フェイルオーバー遅延設定は効果がありません。
変更履歴テーブル
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。