VRRP を理解する

QFabricシステムにおけるVRRPの違い

デフォルトゲートウェイへの静的ルートを使用してネットワーク上のサーバーを構成すると、構成の労力と複雑さが最小限に抑えられ、処理のオーバーヘッドが削減されます。ただし、通常、デフォルトゲートウェイに障害が発生すると、サーバーが分離する壊滅的なイベントが発生します。VRRP(Virtual Router Redundancy Protocol)を使用すると、プライマリゲートウェイに障害が発生した場合に、サーバーの代替ゲートウェイを動的に提供できます。

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 システムに接続されたサーバーに移行できます。

構成の詳細

2台のQFabricシステム間でVRRPグループを設定する方法は、2台のスイッチ上でVRRPを設定する方法と似ています。主な違いは次のとおりです。

• VRRP に参加する両方の QFabric システムのすべてのインターフェイスは、同じ VLAN のメンバーである必要があります。

• 両方のQFabricシステムで、そのVLANにRVI(Routed VLAN Interface)を作成する必要があります。

• 両方の 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 に必要な特性を示しています。

両方の QFabric システムの RVI で VRRP を設定する必要があります。表 2 は、各 RVI の VRRP 設定例の要素を示しています。優先度を除き、パラメータは両方のシステムで同じ でなければならない ことに注意してください。

表 3 は、構成例の QFabric システム A 上のすべてのインターフェイスを示し、その接続先を示しています。

表 4 は、構成例の QFabric システム B 上のすべてのインターフェイスを示し、それらの接続先を示しています。

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 でもサポートされていません。

リリース12.2以降、Junos OSは以下をサポートします。

• RFC 3768、 仮想ルーター冗長プロトコル(VRRP)

• RFC 5798、 IPv4およびIPv6向け仮想ルーター冗長プロトコル(VRRP)バージョン3

• RFC 6527、 仮想ルーター冗長性プロトコル バージョン 3(VRRPv3)向け管理対象オブジェクトの定義

IPv6 VRRP チェックサムの動作の違い

IPv6 VRRP ネットワークを有効にする場合は、以下のチェックサムの違いを考慮する必要があります。

• Junos OS リリース 12.2 より前のリリースでは、IPv6 向け VRRP が設定されている場合、RFC 3768、 仮想ルーター冗長プロトコル(VRRP)のセクション 5.3.8 に従って VRRP チェックサムが計算されます。

• 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 チェックサムを計算します。そのため、 tcpdump が古い Junos OS リリース(Junos OS リリース 12.2 より前)から受信した IPv6 VRRP パケットを解析すると、次の bad vrrp cksum メッセージが表示されます。

  content_copy zoom_out_map

  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リリース)のルーターに、リリース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 つのバージョンを混在させることは、恒久的な解決策ではありません。

VRRPv2 から VRRPv3 へのアップグレードは、次の点を考慮するため、トラフィックの損失を避けるために慎重に行う必要があります。

• すべてのルーターで同時にVRRPv3を設定することはできません。

• 移行期間中は、VRRPv2とVRRPv3の両方がネットワーク内で動作します。

• VRRP のバージョンを変更すると、すべての VRRP グループのステート マシンが再起動されます。

• VRRPv3(IPv4用)ルーターは、VRRPv2(IPv4用)アドバタイズパケットを受信すると、デフォルトでバックアップ状態になります。

• VRRPv2(IPv4用)パケットには、常に最高の優先度が与えられます。

• VRRPv2 と VRRPv3(IPv6 用)のチェックサムの違いにより、複数のプライマリ ルーターを作成できます。

  アップグレード中にバックアップルーターでVRRPv3(IPv6用)を無効にして、複数のプライマリルーターを作成しないようにします。

表 5 は、VRRPv2 から VRRPv3 への移行時に発生する手順とイベントを示しています。 表 5 では、R1 と R2 の 2 つの VRRPv2 ルーターが、G1 と G2 の 2 つのグループで設定されています。ルーターR1はG1のプライマリとして機能し、ルーターR2はG2のプライマリとして機能します。

VRRPv3(IPv4)は以前のバージョンのVRRPと相互運用できないため、VRRPv3を有効にする場合は、ネットワーク内のすべてのVRRPルーターでVRRPv3が有効になっていることを確認してください。例えば、VRRPv3が有効になっているルーターがVRRPv2 IPv4アドバタイズパケットを受信した場合、ルーターはバックアップ状態に移行し、ネットワーク内に複数のプライマリが作成されないようにします。

[edit protocols vrrp] 階層レベルで version-3 ステートメントを設定することで、VRRPv3 を有効にできます(IPv4 または IPv6 ネットワーク用)。LAN上のすべてのVRRPルーターで同じプロトコルバージョンを設定します。

VRRPv3の機能

Junos OS の一部の機能は、VRRPv3 と以前の VRRP バージョンとは異なります。

• VRRPv3認証
• VRRPv3 アドバタイズ間隔
• VRRPv3 向け統合型 ISSU

フェイルオーバー遅延が設定されていない場合

フェイルオーバー遅延を設定していない場合、ルーティングエンジンから操作されるVRRPセッションのイベントの順序は次のとおりです。

1. ルーティングエンジンが検出した最初のVRRPグループの状態が変化し、新しい状態がプライマリである場合、ルーティングエンジンは適切なVRRPアナウンスメッセージを生成します。パケット転送エンジンには状態の変化が通知されるため、そのグループのハードウェアフィルターが遅延なく再プログラムされます。次に、新しいプライマリは Gratuitous ARP メッセージを VRRP グループに送信します。

2. フェイルオーバー タイマーの遅延が開始します。デフォルトでは、フェイルオーバー遅延タイマーは次のとおりです。

   • 500 ミリ秒—設定された VRRP アナウンス間隔が 1 秒未満の場合。

   • 2 秒—設定された VRRP アナウンス間隔が 1 秒以上で、ルーター上の VRRP グループの総数が 255 の場合。

   • 10 秒—設定された VRRP アナウンス間隔が 1 秒以上で、ルータ上の VRRP グループ数が 255 を超える場合。

3. ルーティングエンジンは、後続の VRRP グループに対して 1 つずつ状態変更を実行します。状態が変更され、特定の VRRP グループの新しい状態がプライマリになるたびに、ルーティングエンジンは適切な VRRP アナウンス メッセージを生成します。ただし、パケット転送エンジンへの通信は、フェイルオーバー遅延タイマーが終了するまで抑制されます。

4. フェイルオーバー遅延タイマーが終了すると、ルーティングエンジンは、状態を変更できたすべての VRRP グループに関するメッセージをパケット転送エンジンに送信します。その結果、これらのグループのハードウェア フィルターが再プログラムされ、新しい状態がプライマリであるグループに対しては、Gratuitous ARP メッセージが送信されます。

このプロセスは、すべてのVRRPグループの状態遷移が完了するまで繰り返されます。

したがって、failover-delay を設定しない場合、最初の VRRP グループの完全な状態遷移(ルーティングエンジンと パケット転送エンジンの状態を含む)が直ちに実行されますが、残りの VRRP グループのパケット転送エンジンの状態遷移は、設定された VRRP アナウンスタイマーと VRRP グループの数に応じて、少なくとも 0.5 〜 10 秒遅れます。この中間状態の間、パケット転送エンジンでまだ完了していない状態変更のための VRRP グループのトラフィックの受信は、ハードウェア フィルターの遅延再設定により、パケット転送エンジンレベルでドロップされる場合があります。

フェイルオーバー遅延が設定されている場合

フェイルオーバー遅延が設定されている場合、ルーティングエンジンから操作されるVRRPセッションのイベントの順序は以下のように変更されます:

1. ルーティングエンジンは、一部の VRRP グループが状態の変更を必要としていることを検知します。

2. フェイルオーバーの遅延は、設定された期間に開始されます。許容されるフェイルオーバー遅延タイマーの範囲は、50〜100000ミリ秒です。

3. ルーティングエンジンは、VRRP グループに対して 1 つずつ状態変更を実行します。状態が変更され、特定の VRRP グループの新しい状態がプライマリになるたびに、ルーティングエンジンは適切な VRRP アナウンス メッセージを生成します。ただし、パケット転送エンジンへの通信は、フェイルオーバー遅延タイマーが終了するまで抑制されます。

4. フェイルオーバー遅延タイマーが終了すると、ルーティングエンジンは、状態を変更できたすべての VRRP グループに関するメッセージをパケット転送エンジンに送信します。その結果、これらのグループのハードウェア フィルターが再プログラムされ、新しい状態がプライマリであるグループに対しては、Gratuitous ARP メッセージが送信されます。

このプロセスは、すべてのVRRPグループの状態遷移が完了するまで繰り返されます。

したがって、フェイルオーバー遅延が設定されている場合、最初のVRRPグループのパケット転送エンジンの状態も延期されます。ただし、ネットワーク オペレータには、VRRP 状態変更時の停止を最小限に抑えるために、ネットワーク展開のニーズに最適なフェイルオーバー遅延値を設定できるという利点があります。

フェイルオーバー遅延は、ルーティングエンジン上で動作するVRRPプロセス(vrrpd)によって運用されるVRRPセッションのみに影響します。パケット転送エンジンに分散されたVRRPセッションの場合、フェイルオーバー遅延設定は無効です。