「HSRPとVRRP、どっちを使えばいいんですか」
CCNAの学習中にこの疑問にぶつかる人は多いと思います。参考書にも比較表が載っていますし、ネット上にも「VRRPのほうが標準規格で優れている」という解説がたくさんあります。
ただ、現役のネットワークエンジニアとして10年やってきた立場で正直に言うと、私はこの2つで迷ったことが一度もありません。
選ばなかったのではなく、選ぶ場面が発生しなかったからです。
VRRPのほうが標準規格で洗練されているって、いろんなサイトに書いてありますけど。
仕様としてはそのとおりです。ただ、優れているから選ぶという場面が現場ではほとんど来ないんですよ。
この記事では、まず試験で問われる仕様の違いをきちんと整理します。そのうえで、現場ではその違いがどう扱われているのか、そして実際にHSRPで困るのはどこなのかを書きます。
結論：違いは覚えるべきだが、現場では選ばない
先に結論を書きます。
HSRPとVRRPの仕様差は試験で問われるので覚える必要があります。ただし実務では、機器のベンダが決まった時点でどちらを使うかも自動的に決まります。比較検討というプロセスがそもそも挟まりません。
Cisco機器で構成するならHSRP。マルチベンダ、あるいはCisco以外が混ざるならVRRP。それだけです。
そして、実際に手を動かす段階で問題になるのは「どちらを選ぶか」ではなく、「設定したのに期待どおり切り替わらない」「切り替わりに時間がかかる」「対向が見えていない」といった話です。記事の後半はそこに時間を割きます。
HSRPとVRRPの違いを表で整理する
まずは試験で問われる部分です。
| 項目 | HSRP | VRRP |
|---|---|---|
| 策定元 | Cisco独自 | IETF標準（RFC 5798） |
| 対応機器 | Cisco機器のみ | ベンダを問わない |
| 動作 | UDP 1985番 | IPプロトコル 112番 |
| 宛先 | マルチキャスト 224.0.0.2（v1） | マルチキャスト 224.0.0.18 |
| 役割の呼び方 | Active / Standby | Master / Backup |
| 仮想MAC | 0000.0c07.acXX | 0000.5e00.01XX |
| デフォルトの送信間隔 | Hello 3秒 | Advertisement 1秒 |
| 障害と判定するまでの時間 | Hold 10秒 | Master Down Interval＝(3×Advertisement間隔)＋Skew Time。優先度100・Advertisement 1秒なら約3.6秒 |
| 実IPと仮想IPが同一の場合 | 特別扱いなし | IPアドレスオーナーとなり優先度255で必ずMaster |
障害判定までの時間だけ書き方が違うのは、VRRPが単純な3倍ではなくSkew Timeという補正を加えるためです。全バックアップが同時にMasterへ昇格するのを避ける目的で、優先度が低いほど待ち時間が長くなります。RFC 5798では Master_Down_Interval＝(3×Advertisement間隔)＋Skew_Time、Skew_Time＝((256−優先度)×Advertisement間隔)÷256 と定義されています。バックアップのデフォルト優先度は100なので、実機の show vrrp では3.6秒前後の値が表示されます。
試験対策としては、「HSRPはCisco独自」「VRRPは標準規格」という軸をまず押さえてください。ここが分かっていれば、対応機器・呼び方・仮想MACの違いはすべてそこから派生した話として理解できます。
仮想MACアドレスの形式は覚えておくと実務でも効きます。スイッチのMACアドレステーブルに 0000.0c07.ac で始まるアドレスが出ていれば、それはHSRPの仮想MACです。末尾の2桁はグループ番号を16進数にしたもので、たとえばグループ1なら 0000.0c07.ac01 になります。
なぜ現場では「選ばない」のか
私が関わってきた案件は、ほとんどがCisco機器で構成されていました。
この状態で「VRRPのほうが標準規格だからVRRPにしましょう」と提案する理由がありません。HSRPを使ったところで困らないですし、むしろ社内のドキュメントも過去のコンフィグもHSRP前提で揃っています。あえて崩すメリットがない。
逆に、Cisco以外の機器が入る構成であれば、悩む余地なくVRRPになります。HSRPはCisco独自なので、そもそも他ベンダの機器と組めません。
つまりどちらの場合も、決定は「比較」ではなく「前提」で終わります。ネット上で見かける「VRRPのほうが洗練されている」という評価は仕様としては正しいのですが、その正しさが選定に反映される場面は、実務ではあまり訪れません。
この記事の残りをHSRP中心で書くのも同じ理由です。日本のエンタープライズ現場では、遭遇する確率が高いのは圧倒的にHSRPのほうです。
CCNA v2.0では「動作状態の解釈」が問われる
ここは受験を検討している人向けの話です。
Ciscoは2026年5月20日にCCNA 200-301のブループリント Version 2.0 を公開しました。現行のv1.1は2027年2月2日まで受験可能で、v2.0は2027年2月3日から提供されます。
FHRPの扱いは、この改定ではっきり変わります。
| バージョン | 出題項目 |
|---|---|
| v1.1（3.5） | ファーストホップ冗長化プロトコルの目的・機能・概念を説明する |
| v2.0（3.4） | ファーストホップ冗長化プロトコル（HSRPとVRRP）の動作状態を解釈する |
変更点は2つあります。
- プロトコル名が「HSRPとVRRP」と明示された。v1.1では総称の「FHRP」だった
- 求められる行動が「説明する（Describe）」から「解釈する（Interpret）」に上がった
「解釈する」というのは、実機の出力を見て状態を判断できるかということです。概念を言葉で説明できるだけでは足りません。
これは実務の感覚とよく合っています。現場でFHRPの説明を求められることはまずありませんが、show standby を叩いて状態を読む場面は日常的にあるからです。次の見出しからは、まさにその読み方に入ります。
show standby の読み方
HSRPの状態を確認する基本コマンドは show standby です。実際の出力はこうなります。
Vlan10 - Group 110
State is Active
2 state changes, last state change 00:01:34
Virtual IP address is 192.168.10.100
Active virtual MAC address is 0000.0c07.ac6e (MAC In Use)
Hello time 3 sec, hold time 10 sec
Preemption enabled
Active router is local
Standby router is 192.168.10.2, priority 109 (expires in 10.784 sec)
Priority 110 (configured 110)
見る場所は決まっています。
- State：この機器が今どの状態か
- Standby router：対向が見えているか。ここが
unknownなら異常 - Hello time / hold time：タイマーがデフォルトか、調整済みか
- Preemption：優先度の高い機器が復旧したときに切り戻すかどうか
- state changes：回数と直近の変化時刻。ここが増え続けていたら不安定
私が最初に見るのは Standby router と state changes です。前者で対向が見えているかを、後者で安定しているかを一目で判断できます。
HSRPの状態は6つある
ActiveとStandbyだけではありません。Ciscoのドキュメントでは6つの状態が定義されています。
| 状態 | 意味 |
|---|---|
| Initial | 開始状態。HSRPが動いていない。設定変更直後やインタフェースが上がった直後 |
| Learn | 仮想IPをまだ把握しておらず、Activeルータからのhelloも受け取っていない |
| Listen | 仮想IPは分かっているが、ActiveでもStandbyでもない。helloを聞いている |
| Speak | 定期的にhelloを送り、Active/Standbyの選出に参加している |
| Standby | 次にActiveになる候補 |
| Active | 仮想MAC宛のパケットを実際に転送している |
実務で意味を持つのは Init と Speak です。
State is Init (interface down) と出ていたら、HSRP以前にインタフェースが上がっていません。show ip interface brief で確認する段階の話です。
Speak が頻繁に見えるなら、Active/Standbyの選出が何度もやり直されているということです。安定していれば通常は見えない状態なので、これが目に入る時点で何かが起きています。
切り替わりが遅いときに見る順番
実際に一番相談を受けるのがこれです。「冗長化しているはずなのに、切り替わるまでの通信断が長い」。
ここで多くの人が最初にタイマーへ手を伸ばすのですが、私は順番が逆だと思っています。
先に見るのはトラッキングの有無
HSRPのデフォルトタイマーは、Ciscoのドキュメントで hello 3秒 / hold 10秒 と定められています。Activeからのhelloが10秒間届かなければ、StandbyがActiveに昇格するという動きです。
逆に言えば、Activeルータそのものが落ちた場合は最大10秒かかります。これがデフォルトの素の性能です。
ただ、実際の障害はActiveルータの停止だけではありません。むしろ多いのは、Activeルータは生きているのにその先の上位リンクが落ちるケースです。この場合、HSRP的にはActiveが正常にhelloを送り続けているので切り替わりません。通信だけが止まります。
これを解決するのがインタフェーストラッキングです。指定したインタフェースがダウンしたときに自分の優先度を下げ、対向に切り替えさせる仕組みです。
そしてここが重要なのですが、Ciscoのドキュメントには、トラッキング機構を使っていて追跡対象リンクがダウンした場合、hello/holdタイマーの設定に関係なくフェイルオーバーまたはプリエンプションが即座に発生する、と明記されています。
つまり、上位リンク障害への追従を速くしたいなら、タイマーを削るのではなくトラッキングを入れるのが正解です。タイマーを削っても、この種の障害には効きません。
私が現場でトラッキング対象にしていたのは、データセンター方向やCPE方向のインタフェースです。要するに「そこが死んだらこのルータをActiveにしておく意味がなくなる」という向きを追跡させます。
タイマー調整は「ほどほど」で止める
そのうえで、タイマー調整もやります。デフォルトの10秒が許容できない要件は普通にあるからです。
ただし、削りすぎると状態がパタつきます。ほんの一瞬の輻輳やCPU負荷でhelloを取りこぼしただけで、切り替わりと切り戻しが繰り返されるようになります。冗長化のための設定が、逆に不安定さの原因になるという本末転倒が起きます。
数値までは覚えていませんが、削りすぎるとパタつくので、ほどほどのところで止めていました。
この感覚はCiscoも公式に注意喚起しています。フェイルオーバーやプリエンプションを速くするためにタイマーを下げることはできるが、CPU使用率の上昇と不要なスタンバイ状態のフラッピングを避けるため、helloタイマーを1秒未満、holdタイマーを4秒未満にしてはならない、という記述です。
実務での考え方はシンプルです。まず要件として何秒までの断が許容されるのかを確認し、その範囲に収まる中で、公式の下限より余裕のある値を選ぶ。設計としてはそれで十分です。ミリ秒まで削るような設定は、それが本当に必要な要件でない限り触らないほうがいい。
なお、hold時間はhello間隔の3倍以上にするのが定石です。helloを2回取りこぼしても切り替わらない余裕を作るためで、デフォルトの3秒と10秒もこの関係になっています。
対向が見えていないとき
show standby を叩いて、こう出ることがあります。
Vlan8 - Group 8 Local state is Active, priority 110, may preempt Hellotime 3 holdtime 10 Hot standby IP address is 10.1.2.2 configured Active router is local Standby router is unknown expired
Standby router is unknown。対向のHSRPが見えていない状態です。
この状態が両方の機器で起きていると、両方がActiveになります。仮想IPを2台が同時に名乗るので、通信は不安定になります。
原因はいくつかのパターンに分かれます。
パターン1：設定の不一致
構築時に一番よくあるのがこれです。分かりやすく、確認も早い。
- スタンバイグループ番号が両機で違う
- 仮想IPアドレスが両機で違う
- 両機の実IPアドレスが別サブネットになっている
- インタフェースがdown、またはadministratively down
両機で show standby を並べて見比べれば、たいていその場で分かります。
パターン2：ACLでHSRPが落とされている
見落としやすいのがこれです。
HSRPはピア間のhello送信にマルチキャストアドレス 224.0.0.2 のUDPポート1985を使います。インタフェースに適用したACLがこれを落としていると、設定はすべて正しいのに対向が見えません。
Ciscoのトラブルシューティング手順にも、HSRPピアのインタフェースに設定されたACLがHSRPのアドレスをフィルタしていないか確認せよ、と明記されています。設定を何度見返しても原因が分からないときは、ACLを疑ってください。
パターン3：HSRPの問題ではない
これが本題です。
稼働中に突然HSRPが不安定になった場合、原因がHSRPの外にあることがかなりあります。
直近であったのはループでした。ブロードキャストが増えてパタついていたんです。HSRPは被害者側でした。
Ciscoのドキュメントも同じことを言っています。STPのループや不安定な状態はHSRPピア間の通信を妨げ、その結果それぞれがActiveになる。HSRPのエラーメッセージがSTP問題の最初の兆候になることがある、という記述です。
ループが起きるとブロードキャストが増えます。ブロードキャストが増えると機器のCPUが上がり、helloが取りこぼされます。取りこぼしが3回続けばHSRPは対向が死んだと判断して状態を変える。これがパタつきの正体です。
この構造を知らないと、HSRPのログばかり見て時間を溶かします。
切り分けの順番としては、こうなります。
- 両機で
show standbyを並べ、設定不一致がないか確認する - インタフェースの状態とエラーカウンタを見る（
show interfaces、show interfaces status） - ACLでHSRPが落とされていないか確認する
- STPのトポロジと
Number of topology changesを確認する - ブロードキャスト・マルチキャストがユニキャストを超えていないか確認する
4と5でループが疑われたら、そこから先はHSRPの話ではなくSTPの話になります。
おまけ：ポートセキュリティとの相性
もう一つ、Ciscoが公式に挙げているハマりどころがあります。
HSRPを動かしているルータの接続先スイッチポートにポートセキュリティが設定されていると、MAC違反が発生します。同じセキュアMACアドレスを複数のインタフェースに持てないためです。デフォルトでは違反したポートがerr-disableになって即座にシャットダウンし、HSRPの状態メッセージがブロックされます。
回避策として、ルータ側で standby use-bia を使って仮想MACではなくバーンインアドレスを使わせるか、該当ポートのポートセキュリティを外す方法が示されています。
まとめ
- HSRPはCisco独自、VRRPはIETF標準。試験ではここを軸に整理する
- 実務では機器ベンダで自動的に決まるため、比較検討は発生しにくい
- CCNA v2.0（2027年2月3日開始）では「HSRPとVRRPの動作状態を解釈する」に格上げされる。実機出力の読み取りが要る
- 切り替わりが遅いときは、タイマーより先にトラッキングの有無を見る
- タイマーは削りすぎるとパタつく。Cisco公式の下限目安は hello 1秒 / hold 4秒
- 対向が見えないときは、設定不一致 → ACL → 物理層・STPの順で疑う
- HSRPの状態変化が頻発する場合、原因はHSRPの外にあることが多い
覚えることと、現場で効くこと。この2つは重なる部分もあれば、そうでない部分もあります。試験のために比較表を覚えるのは必要ですが、それを覚えたあとに何を見るのかまで知っておくと、現場に出たときの立ち上がりが違ってきます。
HSRPそのものの仕組みはHSRPとは？現役が教える仕組みと「コマンドは暗記しなくていい」理由で詳しく解説しています。あわせて読んでみてください。
コメント