VRRP とは｜Master 選出と priority 設計の落とし穴

はじめに

ネットワークのデフォルトゲートウェイは、ホスト側に静的に設定されることが一般的です。設定も運用もシンプルな反面、そのルーターが停止した時点で配下のホストがすべて外部と通信できなくなる、単一障害点になります。

この課題を解決するのが VRRP（Virtual Router Redundancy Protocol）です。複数のルーターで 1 つの仮想 IP アドレスを共有し、障害時には待機側が自動的に転送責任を引き継ぎます。RFC で標準化されているため、Cisco・FortiGate・NEC IX・YAMAHA RTX といったメーカーが混在する環境でも構成できる点が、ベンダー独自プロトコルとの違いになります。

一方で、VRRP は「priority が大きいほうが Master になる」という理解だけで設計を進めると、設定した値どおりに動かない場面に遭遇します。priority 255 の扱いや切り替わりまでの待機時間の算出方法は、RFC の規定とベンダー実装で解釈が分かれる部分があるためです。

結論から述べます。VRRP の Master は、仮想 IP アドレスを実インターフェースアドレスとして持つ「IP アドレス所有者」が存在すればその機器が優先され、存在しない場合に priority の大小で決まります。切り替わりまでの時間は Advertisement 間隔と priority から算出される値で決まるため、priority は「どちらを Master にするか」だけでなく「どれだけ速く切り替わるか」にも影響します。この 2 点を押さえておくと、設定値と実挙動のずれを事前に避けられます。

VRRP とは（用語と動作の全体像）

VRRP は、LAN 上の複数のルーターの中から仮想ルーターの役割を担う 1 台を動的に選出するプロトコルです。ホスト側の設定は静的なデフォルトゲートウェイのままで、ルーター側だけで冗長化を実現できる点が特徴になります。

参考: RFC 5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
“VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router”
（VRRP は、仮想ルーターの役割をいずれかのルーターに動的に割り当てる選出プロトコルを規定しています）
https://www.rfc-editor.org/rfc/rfc5798.html

VRRP が解決する課題

ホストがデフォルトゲートウェイを知る方法には、RIP や OSPF などの動的ルーティングプロトコルを動作させる方法、ICMP ルーター探索を使う方法、静的なデフォルトルートを設定する方法があります。このうち実運用で広く使われているのは静的なデフォルトルートで、DHCP による配布と組み合わせて運用されます。

ホスト側の負荷が小さく、実装を選ばない方式ですが、経路が 1 本に固定されるため、ゲートウェイの停止がそのまま通信断につながります。ホスト側に代替経路を検知する仕組みがないためです。VRRP は、この構成を維持したままゲートウェイ側で冗長性を確保する設計になっています。

同じ目的を持つプロトコルには Cisco 独自の HSRP もあります。どちらを選ぶかの判断基準は、関連記事『HSRP と VRRP の違い｜FHRP の選定基準と判断の順序』で整理しています。

押さえておきたい用語

VRRP の解説では似た用語が並ぶため、最初に整理しておきます。RFC 5798 で定義されている用語は次のとおりです。

実務で混同しやすいのが VRID と仮想 IP アドレスの関係です。仮想ルーターは VRID とアドレスの組で定義されるため、同じ VRID を別の LAN で使い回すことに制約はありません。また、同一の VRID 番号を IPv4 用と IPv6 用の両方に使うこともできますが、その場合は別々の仮想ルーターとして扱われます。

もう 1 つ重要なのが IP アドレス所有者という考え方です。RFC の想定では、仮想 IP アドレスは Master 側ルーターの実インターフェースアドレスと同じ値にする構成が基本形として説明されています。ただし実際の製品では、どちらの機器も所有者にせず、仮想 IP アドレスを独立したアドレスとして割り当てる構成が広く使われています。この違いが priority の設計に直結するため、次のセクションで詳しく扱います。

ホストから見た VRRP の動作

ホスト側の視点では、VRRP を意識する要素はありません。動作は次の流れになります。

1. ホストはデフォルトゲートウェイとして仮想 IP アドレスを設定します
2. ホストが仮想 IP アドレスに対して ARP 要求を送信します
3. Master が ARP 応答を返します。このとき返すのは物理 MAC アドレスではなく、仮想ルーターに割り当てられた仮想 MAC アドレスです
4. ホストは仮想 MAC アドレス宛にフレームを送信し、Master がそれを転送します
5. Master に障害が発生すると、Backup が Master へ遷移し、同じ仮想 MAC アドレスでの転送を引き継ぎます

切り替わってもホスト側の ARP テーブルの内容は変わりません。仮想 MAC アドレスが機器をまたいで引き継がれるためです。ホスト側での再設定や ARP テーブルのクリアが不要という利点は、ここから生まれています。

なお、Backup 側は仮想 IP アドレス宛の ARP 要求に応答せず、仮想 MAC アドレス宛のフレームも破棄する動作が規定されています。同一セグメントに 2 台が存在しても応答が重複しないのは、この規定によるものです。

VRRP ルーターがとる 3 つの状態

VRRP ルーターは、参加している仮想ルーターごとに状態を持ちます。RFC 5798 で定義されている状態は次の 3 つです。

• Initialize: 起動待ちの状態。設定完了後の開始イベントを待機します
• Backup: Master の死活を監視する状態。Advertisement を受信できなくなると Master へ遷移します
• Master: 仮想 IP アドレス宛のパケットを転送し、ARP 要求に応答する状態

状態遷移は Initialize を起点に、Master と Backup の間を相互に行き来する構造になっています。起動時の分岐は priority の値で決まり、priority が 255 の機器（IP アドレス所有者）は Backup を経由せず、直接 Master へ遷移します。所有者でない機器は、いったん Backup 状態に入ってから Master 選出の結果を待ちます。

状態名称のベンダー差

RFC 上の名称は Master と Backup ですが、実際の機器の表示は統一されていません。設計書と実機出力を突き合わせる場面で戸惑いやすい部分です。

FortiGate では Master が PRIMARY と表示されるため、「Master になっているか確認したいがそれらしい文字列が見当たらない」という状況が起こります。FortiGate 側の確認コマンドと出力の読み方は、関連記事『FortiGate VRRP の設定手順』にまとめています。

また、他社文書では「マスター / スレーブ」という表現が使われることもありますが、RFC 5798 にスレーブという用語の定義はありません。待機側の正式な名称は Backup です。

Master 選出と priority の設計

VRRP の Master は priority の大小で決まりますが、その手前に「IP アドレス所有者かどうか」という判定が入ります。また priority は Master の決定だけでなく、Backup が障害を検知するまでの待機時間にも影響します。この 2 点が、設定値と実挙動がずれる主な原因になります。

priority の既定値と設定可能範囲

RFC 5798 では、priority を 8 ビットの符号なし整数として次のように規定しています。

注意したいのは、この規定が「設定可能な範囲」としてどう実装されるかはベンダーによって異なる点です。

Cisco の構成ガイドでは、Backup 側の priority を 1〜254 の範囲で設定するものとして案内されています。所有者でない機器に 255 を設定する余地がないため、RFC の意図がそのまま構文に反映されています。一方 FortiOS の config vrrp では priority の範囲が 1〜255 で定義されており、仮想 IP アドレスを所有しない機器にも 255 を設定できます。

FortiGate の設定例で priority 255 が使われるのは、この実装差によるものです。設定として成立する以上は誤りではありませんが、Cisco 機器と対向させる構成では、Cisco 側が 255 を設定できないという非対称性が生まれます。マルチベンダー構成では、双方が設定できる 1〜254 の範囲で設計を揃えておくと、後からの機器追加や置き換えに対応しやすくなります。

IP アドレス所有者と priority 255 の関係

RFC の想定する基本構成では、仮想 IP アドレスは Master 側ルーターの実インターフェースアドレスと同じ値に設定します。この機器を IP アドレス所有者と呼び、priority は 255 に固定されます。所有者は起動と同時に Master として動作を開始し、Backup を経由しません。

しかし実務では、仮想 IP アドレスをどちらの機器も所有しない構成が広く使われています。

所有者が存在しない構成では、priority の大小だけで Master が決まります。ここで押さえておきたいのが、RFC 5798 の受信処理では「受信したインターフェースに VRID が設定されていること」に加えて「自身が IP アドレス所有者（priority 255）でないこと」を検証し、条件を満たさない場合はパケットを破棄すると規定されている点です。1 つのリンク上に priority 255 の機器を複数配置しない設計が前提になります。

RFC の運用上の推奨事項としても、priority 255 のルーターは起動と同時に低優先度のルーターをすべて置き換えるため、1 リンクにつき 1 台までにとどめるよう案内されています。所有者でない機器に 255 を設定できる実装では、この点が設計者の責任になります。

priority 0 が持つ特別な意味

priority 0 は設定値ではなく、Master が仮想ルーターの責任を手放すことを通知するための予約値です。Master が Shutdown イベントを受け取ると、priority 0 の Advertisement を送信してから Initialize 状態へ遷移します。

これを受信した Backup は、通常の Master_Down_Interval ではなく後述の Skew Time だけ待機して Master へ昇格します。計画的なメンテナンスで Master 側の VRRP を停止する際、切り替わりが通常の障害時より速いのはこの規定によるものです。

逆に言えば、電源断やケーブル断のようにこの通知が送れない障害では、Backup はタイマー満了まで待つことになります。メンテナンス時の切り替わり時間を実測して「この程度で切り替わる」と判断すると、実際の障害時には想定より長い通信断が発生します。切り替わり時間の見積もりは、通知なしのケースを基準にすることをおすすめします。

切り替わり時間を決める Skew Time と Master_Down_Interval

Backup が「Master がダウンした」と判定するまでの時間は、次の 2 つの式で決まります。

Skew_Time = ((256 - priority) × Master_Adver_Interval) ÷ 256   [センチ秒]

Master_Down_Interval = (3 × Master_Adver_Interval) + Skew_Time  [センチ秒]

Master_Adver_Intervalは Master から受信した Advertisement に含まれる間隔で、既定値は 100 センチ秒（1 秒）です。Skew Time は priority が高いほど小さくなるため、優先度の高い Backup ほど早く Master へ昇格します。複数の Backup が同時に昇格して一時的に Master が重複する状態を避けるための仕組みです。

既定の Advertisement 間隔（1 秒）で priority を変えた場合の計算例です。

ベンダーの資料では「Advertisement 間隔の 3 倍」と簡略に説明されることが多く、実際には Skew Time の分だけ長くなります。既定値どうしの構成では 3 秒ではなく 3.6 秒前後が目安になり、priority の設定次第で 0.5 秒程度の差が生じます。要件として通信断時間を提示する場面では、この差を織り込んでおくと実測値との乖離を避けられます。

なお、Skew Time の算出式は VRRPv2 と VRRPv3 で異なります。VRRPv2 は Advertisement 間隔が秒単位のため式に間隔が含まれず、VRRPv3 では間隔が乗算されます。Advertisement 間隔を既定の 1 秒から変更する場合、この違いが計算結果に効いてきます。バージョンごとの差は後のセクションで整理します。

preempt の既定値と 1 つの例外

preempt は、復旧した高優先度のルーターが現在の Master を置き換えるかどうかを制御するパラメータです。RFC 5798 における既定値は有効（True）です。復旧時に自動で切り戻る動作が標準になります。

ここに 1 つ例外があります。仮想 IP アドレスを所有するルーターは、preempt の設定値にかかわらず常に置き換えを行います。所有者を持つ構成で preempt disable を設定しても、所有者が復旧すれば Master に戻ります。切り戻しを抑止したい要件がある場合、所有者を作らない構成にする必要があります。

もう 1 点、Master 状態にあるルーターは preempt の値を参照しません。preempt が影響するのは Backup 状態で Advertisement を受信したときの判定のみです。

回線が不安定な環境では、切り戻しのたびに通信断が発生するため preempt を無効にする設計も選択肢になります。ただし、所有者でない機器に priority 255 を設定できる実装で preempt disable がどう動作するかは公式ドキュメントで明示されていないため、該当構成を採用する場合は事前の検証をおすすめします。

priority 値の設計指針

以上を踏まえた設計上の指針を整理します。

• priority 255 は所有者専用と考える。所有者を作らない構成では、Master 側を 200 前後、Backup 側を既定の 100 のままにすると、マルチベンダー構成でも値を揃えられます
• Backup が複数ある場合は値を均等に分散させる。RFC の推奨事項でも、100 の次に追加する機器は 99 ではなく 50 程度が望ましいとされています。値が近いと Skew Time の差が小さくなり、収束が遅くなるためです
• priority が同値の場合は実 IP アドレスの大小で決まる。設計上は同値を避けることをおすすめします

参考: Cisco IP Addressing Services Configuration Guide / VRRPv3 Protocol Support
“the virtual device backup with the higher IP address is elected”
（実 IP アドレスが大きいほうの Backup が Master に選出されます）
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-7/configuration_guide/ip/b_177_ip_9300_cg/vrrpv3_protocol___support.html

上位回線の障害を検知して priority を下げる機能（インターフェーストラッキングや宛先監視）は RFC の規定外で、各社が独自に実装しています。この扱いは後のセクションで整理します。

VRRP の通信仕様と仮想 MAC

VRRP の制約の多くは、パケットの送り方に関する規定から導かれます。「なぜルーターを跨げないのか」「なぜ中間スイッチの設定が問題になるのか」は、仕様を押さえると理由が明確になります。

Advertisement の宛先とプロトコル番号

VRRP が送信するパケットは Advertisement の 1 種類のみで、次の宛先に送られます。

宛先はいずれもリンクローカルスコープのマルチキャストアドレスで、ルーターは TTL や Hop Limit の値にかかわらずこの宛先のデータグラムを転送してはならないと規定されています。VRRP がセグメントを越えられない一次的な理由がここにあります。

中間にレイヤー 2 スイッチを挟む構成では、IGMP snooping の動作によってこのマルチキャストが意図せず遮断されることがあります。ネゴシエーションが成立しない場合の切り分けポイントとして、プロトコル番号 112 のパケットが双方向に届いているかを確認する方法が有効です。

TTL 255 の検証が持つ 2 つの意味

RFC 5798 では、送信時に TTL を 255 に設定し、受信側は TTL が 255 でないパケットを破棄しなければならないと規定しています。この規定には 2 つの意味があります。

1 つは L2 隣接の担保です。ルーターを 1 台でも経由すると TTL が減算されるため、受信側で必ず破棄されます。リンクローカルマルチキャストによる制限と合わせて、二重に経路越えを防ぐ構造になっています。

もう 1 つはセキュリティです。RFC のセキュリティ考慮事項では、この TTL 検証が外部ネットワークからの VRRP パケット注入に対する保護として機能すると説明されています。VRRPv3 に認証機能がないにもかかわらず一定の安全性が保たれているのは、攻撃対象が同一セグメント上のノードに限定されるためです。

裏を返すと、同一セグメントに接続できる相手からの攻撃は防げません。アクセスポートに端末が接続される環境では、スイッチ側で VRRP パケットをフィルタする対策が検討対象になります。RFC でも、信頼できないホストが接続される環境では、スイッチポート単位で VRRP メッセージをフィルタする仕組みを考慮できると触れられています。

仮想 MAC アドレスの構造と役割

仮想ルーターには、VRID から一意に決まる MAC アドレスが割り当てられます。

先頭 3 オクテットは IANA の OUI に由来し、続く 2 オクテットが IPv4 用と IPv6 用のアドレスブロックを示します。最後の 1 オクテットが VRID そのものです。VRID を 16 進数に変換するだけで期待される仮想 MAC が求められるため、パケットキャプチャの結果と設定値の突き合わせは計算で確認できます。VRID が 100 であれば 00-00-5E-00-01-64 になります。この対応関係により、1 つのネットワーク上で最大 255 の仮想ルーターを識別できます。

もう 1 つ押さえておきたいのが、Advertisement の送信元 MAC アドレスに仮想 MAC が使われる点です。これは学習ブリッジ対策の規定で、仮想 MAC が送信元として一度も現れないと、スイッチが仮想 MAC の学習を行えず、仮想ルーター宛のフレームがすべてフラッディングされます。定期的な Advertisement には、この学習エントリを維持する役割もあります。

なお、仮想 MAC の使用は RFC で規定された動作ですが、実装では有効化の設定が必要な製品もあります。FortiGate では set vrrp-virtual-mac enable を明示的に設定する構成例が公式ドキュメントで案内されています。この設定を省いた場合の挙動やメーカー別の扱いは、各メーカーの設定記事で扱います。

Master 遷移時の GARP と ARP 応答のルール

ARP の扱いには、状態ごとに明確な規定があります。

• Master: 仮想 IP アドレス宛の ARP 要求に応答します。このとき返すのは仮想 MAC アドレスであり、物理 MAC アドレスを返してはならないと規定されています
• Backup: 仮想 IP アドレス宛の ARP 要求に応答してはならず、仮想 MAC 宛のフレームも破棄します
• Master へ遷移した時点: 仮想 MAC アドレスを含む Gratuitous ARP をブロードキャストします

フェイルオーバー時にホスト側の ARP テーブルを更新する必要がないのは、仮想 MAC が引き継がれるためです。一方でスイッチ側の MAC アドレステーブルは、仮想 MAC の学習ポートを新しい Master 側へ更新する必要があり、この更新を促すのが Gratuitous ARP の役割になります。

Proxy ARP を併用する場合は、Proxy ARP の応答にも仮想 MAC アドレスを含める必要があります。物理 MAC を広告してしまうと、ホストが実機の MAC アドレスを学習し、フェイルオーバー時に通信が復旧しなくなるためです。

また、所有者でない機器が Master になっている場合、その機器は仮想 IP アドレス宛のパケットを転送すべきではないとされています。転送すると不要なトラフィックが発生し、環境によっては TTL が尽きるまで転送ループが継続する可能性があるためです。実装によっては、Master 遷移時に該当アドレス宛の reject ルートを追加する方式が採られています。

VRRPv2 と VRRPv3 の違い

VRRPv2 は RFC 3768 で規定され、VRRPv3（RFC 5798）がこれを置き換える形になっています。現行機器の多くは両方に対応していますが、既定バージョンが製品によって異なるため、対向機器との整合が必要です。

主な差分

実務で影響が大きいのは Advertisement 間隔の単位です。VRRPv3 では最大 Advertisement 間隔が 12 ビットのセンチ秒フィールドとして定義されているため、1 秒未満の設定が可能になります。切り替わり時間を 1 秒未満に短縮したい要件では、VRRPv3 の採用が前提になります。

認証フィールドの廃止と設計への影響

VRRPv2 にはパスワード認証のフィールドがありましたが、VRRPv3 では仕様から削除されています。RFC 5798 のセキュリティ考慮事項では、その理由が説明されています。認証を行っても、悪意のあるノードが Master として振る舞うことは防げず、複数の Master が存在する状態は全機器が Backup になる状態と同程度の影響をもたらすためです。加えて、VRRP を保護しても ARP を妨害すれば同じ結果を引き起こせる点も挙げられています。

セキュリティ要件として「冗長化プロトコルの認証」が求められる案件では、VRRPv3 を選ぶ限り認証は構成できません。この場合は、L2 側のポートセキュリティやフィルタリングで代替する設計になります。要件定義の段階で確認しておきたい項目です。

v2 と v3 を混在させる場合の注意点

RFC 5798 では、v2 と v3 の相互運用はオプション扱いで、v2 から v3 への移行期にのみ用いるべきであり、恒久的な構成とみなすべきではないとされています。実装によっては、両方の Advertisement を送受信する設定フラグが用意されています。

参考: Allied Telesis VRRP Feature Overview and Configuration Guide
“allows a VRRPv3 virtual router to send both VRRPv2 and VRRPv3 advertisements”
（VRRPv3 の仮想ルーターが VRRPv2 と VRRPv3 の両方の Advertisement を送信できるようになります）
https://www.alliedtelesis.com/sites/default/files/vrrp_feature_overview_guide_revb.pdf

混在構成では、RFC が 2 つの注意点を挙げています。

1 つは、遅い間隔で動作する高優先度の Master が不安定になる点です。サブセカンド設定の VRRPv3 機器と、秒単位の VRRPv2 機器を組み合わせる場合、VRRPv2 側に高い priority を与えない設計が推奨されています。

もう 1 つは、センチ秒単位で送信する VRRPv3 の Master が、VRRPv2 の Backup を処理しきれなくする可能性です。移行期には VRRPv3 側の間隔を 100 センチ秒（1 秒）程度に抑え、すべての機器を v3 に移行してからサブセカンド設定へ切り替える手順が案内されています。

段階的な機器更改でバージョンが混在する期間が発生する場合は、この 2 点を移行計画に織り込んでおくと、想定外のフラッピングを避けられます。

RFC 仕様とベンダー実装のずれ

VRRP は標準規格ですが、実装レベルでは各社の判断が入る領域があります。とくに「仮想 IP アドレス宛の通信をどう扱うか」と「上位回線の障害をどう検知するか」の 2 点は、マルチベンダー構成で挙動が食い違いやすい部分です。

仮想 IP アドレスへの ping が通らない理由

構築直後に「仮想 IP アドレスに ping が返らない」という状況に遭遇することがあります。これは障害ではなく、RFC 5798 の Accept_Mode という規定に沿った動作です。

Accept_Mode は、Master 状態の仮想ルーターが、自身が所有していない仮想 IP アドレス宛のパケットを自分宛として受け入れるかどうかを制御するパラメータで、RFC 上の既定値は False（受け入れない）です。IP アドレス所有者が存在しない構成では、Master であっても仮想 IP アドレス宛の ICMP や TCP 接続に応答しない動作が標準になります。

RFC でも、アドレス所有者の IP アドレスへの ping に依存する運用では Accept_Mode を True に設定することが考えられる、と補足されています。監視システムからゲートウェイの死活を仮想 IP アドレス宛の ping で確認する設計では、この設定が前提になります。

各社の実装は次のように分かれています。

NEC IX の公式ガイドラインでは、IPv4 と IPv6 で扱いが異なる点が明記されています。

参考: NEC UNIVERGE IX シリーズ 障害切り分けガイドライン
「VRRPv3(IPv6)の場合は常にVRRPの仮想IPアドレス宛のパケットを受信できるため、VRRPの仮想IPアドレス宛のパケットを受信する設定(virtual-host)は不要です」
https://jpn.nec.com/univerge/ix/Support/Troubleshooting/netmon-vrrp-3.html

設計上の注意点は、疎通確認の方法をベンダーごとに変える必要が生じる点です。Cisco と NEC IX が混在する構成で、仮想 IP アドレス宛の ping を共通の死活監視手段にしようとすると、片側だけ応答しない状況が起こります。監視設計では、仮想 IP アドレスではなく各機器の実 IP アドレスを対象にする方法も選択肢になります。

なお、Accept_Mode が False の場合でも、IPv6 の近隣要請と近隣通知は破棄してはならないと規定されています。IPv6 環境で近隣探索が成立しない場合、Accept_Mode 以外の原因を疑う必要があります。

上位回線の監視は RFC の規定外

VRRP が標準で判定するのは、Advertisement を受信できるかどうかだけです。上位回線の障害や上流ルーターの停止は、VRRP 自身では検知できません。VRRP を設定したインターフェースがリンクアップしている限り、Master はそのまま Master であり続けます。

この結果、上流への通信だけが届かないまま Master が維持される状態が発生します。対策として各社が独自に用意しているのが監視機能ですが、実装方式は大きく 2 系統に分かれます。

priority 減算型で見落とされやすいのが、減算値と priority 差の関係です。 Cisco のインターフェーストラッキングでは減算値の既定が 10 です。Master 側 priority 110、Backup 側 100 という構成では、障害検知後の Master の priority は 100 となり、Backup と同値になります。VRRP は Backup の priority が Master を上回った場合に昇格する仕様のため、同値では切り替わりません。

減算型を採用する場合は、減算後の値が Backup の priority を確実に下回るよう、priority 差と減算値をセットで設計することをおすすめします。前述の RFC 推奨（Backup の priority を均等に分散させる）と併せて検討すると、値の決め方が整理しやすくなります。

VRRP 停止型は、監視条件の成立時に Master 自身が VRRP から離脱する方式です。priority の大小関係を計算する必要がない反面、監視対象が復旧したときの切り戻し挙動が preempt の設定とは別に決まるため、動作の確認が必要になります。

YAMAHA RTX では、シャットダウントリガの条件としてインターフェースのダウンだけでなく、経路の消失や keepalive による ICMP 監視の結果も指定できます。NEC IX のネットワークモニタも、経路監視・ホスト監視のイベントに対して VRRP の停止や優先度減算を割り当てる構造です。いずれも、監視部分と VRRP を分離して組み合わせる設計思想になっています。

主要ベンダーの対応比較

ここまでの内容を、メーカー別に整理します。設定手順そのものは各メーカーの記事で扱います。

対応バージョンと基本パラメータ

Cisco では、VRRPv3 の構文を使用するためにグローバル設定で fhrp version vrrp v3 を投入する必要があります。既定のままでは VRRPv2 の構文で動作するため、他社機器と VRRPv3 で合わせる要件がある場合、この 1 行の投入漏れが接続不可の原因になります。

NEC IX は IPv4 と IPv6 で準拠する RFC が異なる点が特徴です。IPv4 側は VRRPv2 を前提とした実装になっているため、IPv4 で VRRPv3 を要件とする構成では対応可否の確認が必要になります。

YAMAHA RTX は ip lan1 vrrp コマンドの 1 行に VRID・仮想 IP アドレス・priority・preempt・認証・Advertisement 間隔をまとめて指定する構文で、他社のブロック構造とは書式が大きく異なります。認証（auth=）のオプションが用意されている点も、VRRPv3 で認証が廃止された経緯を踏まえると押さえておきたい差分です。

監視機能と確認コマンドの呼称

NEC IX の show vrrp detail は、状態遷移の履歴と Advertisement・priority 0 の送受信カウンタ、TTL エラー数まで表示されます。フラッピングの原因を切り分ける際、履歴から遷移の頻度とタイミングを追える点が実務では有用です。

Palo Alto Networks の位置づけ

「Palo Alto で VRRP を設定したい」という要件を受けることがありますが、PAN-OS の公式ドキュメントでは、VRRP に相当する機能として Floating IP アドレスと仮想 MAC アドレスの組み合わせが案内されています。

参考: Palo Alto Networks / Floating IP Address and Virtual MAC Address
“recommended when you need functionality such as Virtual Router Redundancy Protocol”
（Virtual Router Redundancy Protocol のような機能が必要な場合に推奨されます）
https://docs.paloaltonetworks.com/ngfw/administration/high-availability/floating-ip-address-and-virtual-mac-address

Floating IP アドレスはアクティブ・アクティブ HA の構成要素で、各機器が持つインターフェース IP アドレスとは別に、機器間を移動するアドレスとして設定します。ホストはこの Floating IP アドレスをデフォルトゲートウェイに指定し、リンク障害や機器障害、パスモニタリングによるフェイルオーバーが発生すると、Floating IP アドレスと仮想 MAC アドレスが正常側へ移動します。

注意したいのは、これが VRRP プロトコルそのものではない点です。 HA ペアを構成する PAN-OS 機器どうしで完結する仕組みのため、他社機器と VRRP でピアリングする用途には使えません。Palo Alto と他社ルーターを VRRP で冗長化する構成を検討している場合は、要件の見直しが必要になります。現行バージョンでの対応状況は、導入前に公式ドキュメントで確認することをおすすめします。

まとめ

VRRP は、同一セグメント上の複数のルーターで仮想 IP アドレスを共有し、ホスト側の設定を変えずにゲートウェイを冗長化する標準規格です。設計の要点は priority の決め方に集約されますが、その値がそのまま実挙動になるとは限りません。RFC の規定と各ベンダーの実装差を押さえておくことが、想定どおりに動く構成への近道になります。

• VRRP は同一 L2 セグメント内で仮想 IP アドレスを共有する標準規格
• Master は IP アドレス所有者の有無を先に判定し、次に priority で決定
• priority 255 は所有者に予約された値で、設定可否はベンダーごとに異なる
• 切り替わり時間は Advertisement 間隔の 3 倍に Skew Time を加えた値
• preempt の既定は有効で、所有者は設定値にかかわらず常に切り戻る
• 仮想 IP アドレスへの ping は Accept_Mode の既定値により応答しない
• 上位回線の監視は RFC の規定外で、減算型と停止型の 2 系統に分かれる

以上、最後までお読みいただきありがとうございました。