3.5FHRP（HSRP）による第1ホップ冗長化

PCやサーバは基本的にルーティングプロトコルを話さず、設定された1つのデフォルトゲートウェイIPにしか出口を頼れません。もしそのゲートウェイのルータが1台きりで落ちると、セグメント内の全端末が外に出られなくなります。FHRP（第1ホップ冗長化プロトコル）は、複数のルータで仮想IPを共有し、1台が落ちても別の1台が同じ仮想IP宛を肩代わりすることで、この単一障害点を消す仕組みです。この節ではその代表であるCisco独自のHSRPの動作と、実務で最も間違えやすいプリエンプトの設計判断を扱います。

3.5.1FHRPが解決する問題

• FHRP＝デフォルトゲートウェイを冗長化するプロトコル群の総称。ホストには仮想IPを1つデフォルトゲートウェイとして設定し、その仮想IPを複数の実ルータが共有する。ホスト側は設定を一切変えずに、裏でルータが冗長化される。代表にCisco独自のHSRP／GLBPと標準のVRRPがある。
• 冗長化の要は仮想MACにもある。ホストは仮想IP宛にARPを打ち、返ってくる仮想MACをゲートウェイのMACとしてキャッシュする。Activeルータが落ちてStandbyが引き継いでも、仮想IPと仮想MACは変わらないため、ホストのARPキャッシュを更新せずに転送先だけが差し替わる（切替がホストから見えない）。

3.5.2HSRPの動作：Active／Standbyと優先度・プリエンプト

• HSRP（Cisco独自）ではグループ内の1台がActiveとなって仮想IP／仮想MAC宛のトラフィックを実際に転送し、1台がStandbyとして待機、残りはリッスン状態。ActiveとStandbyはHelloで互いを監視し、Activeが応答しなくなるとStandbyが即座にActiveへ昇格する。
• どのルータがActiveになるかは優先度（既定100・範囲0〜255）で決まり、優先度が高いルータがActive（同値ならインタフェースIPが高い方）。仮想MACはHSRPv1で0000.0c07.acXX（XXはグループ番号）という決まった形を取る。
• プリエンプト（standby <group> preempt）＝既定では無効。無効のままだと、いったんActiveが決まった後により高い優先度のルータが（復旧などで）現れても、現Activeが居座ってフェールバックしない。復旧した本来の主ルータへ自動で戻したいなら、そのルータでプリエンプトを明示的に有効化する必要がある。

あなたはあるフロアのデフォルトゲートウェイを、主ルータR1（優先度110）とバックアップR2（優先度100）の2台でHSRP冗長化し、仮想IP10.0.0.1をホストのデフォルトゲートウェイに設定しました。設計意図は「普段はR1が転送し、R1が落ちたらR2が肩代わり、R1が復旧したらR1に戻す」です。まずR1のメンテナンスでR1を落とすと、StandbyのR2が即座にActiveへ昇格し、仮想IP10.0.0.1と仮想MACは変わらないので、ホストはARPキャッシュを更新することなく通信を続けられます——ここまでは狙いどおりです。ところがR1のメンテナンスが終わって復旧させても、トラフィックがR2に流れ続けてR1に戻らないという現象が起きました。R1の優先度110はR2の100より高いのに、なぜ戻らないのか。原因はHSRPのプリエンプトが既定で無効だからです。プリエンプトが無効だと、R2がすでにActiveになった後にR1が高優先度で復旧しても、R2は現状のActiveを譲りません。設計意図どおり「復旧したR1に自動で戻す」には、R1側でstandby 1 preemptを明示的に有効化しておく必要があります。ここはOSPFのDR選出が非プリエンプティブなのと同じ落とし穴に見えますが、HSRPはプリエンプトを設定すればプリエンプティブにできる点が異なります。さらに実務では、R1のインタフェース優先度をstandby 1 trackで上流リンクの状態に連動させ、上流が切れたら自動で優先度を下げてR2へ譲る、という設計も定番です。「優先度を高くしただけでは自動フェールバックしない、プリエンプトが要る」——これがHSRP設計で最も多い取りこぼしです。

3.5.3この節のまとめ

• FHRPは複数ルータで仮想IP／仮想MACを共有し、デフォルトゲートウェイの単一障害点を消す（ホストは無変更）
• HSRPは優先度（既定100・高い方がActive）でActive／Standbyを決め、Active障害時にStandbyが即昇格する
• プリエンプトは既定で無効＝有効化しない限り復旧した高優先度ルータへ自動フェールバックしない（OSPFのDR選出とは異なり設定で変えられる）