3.8FHRPとマルチキャスト

端末は通常デフォルトゲートウェイを1つしか持てないため、そのルータが落ちればセグメント全体が外部と通信できなくなります。FHRP（First Hop Redundancy Protocol）は、複数のルータで1つの仮想IPと仮想MACを共有し、端末から見て「ゲートウェイは常に生きている」状態を作る仕組みです。一方マルチキャストは、1つの送信を多数の受信者へ効率よく届ける技術ですが、ユニキャストと同じ感覚で診断すると必ず行き詰まります——鍵は「経路は受信者から送信元へ向かって作られる」という逆向きの発想です。この節では両者を、既定値の違いと診断手順という実務の観点から扱います。

3.8.1HSRPとVRRPの既定値の違い

• HSRPはCisco独自で、Active（実際に転送する）とStandby（待機）の役割を持つ。端末に配る仮想IPに対応する仮想MACはHSRPv1で 0000.0c07.acXX（XXはグループ番号の16進）、HSRPv2では 0000.0c9f.fXXX。優先度の既定は100で、大きいほうがActiveになる。ただしpreempt（プリエンプション）は既定で無効である点が最重要。
• VRRPはIETF標準（RFC）で、役割はMasterとBackup。仮想MACは 0000.5e00.01XX。優先度の既定は同じく100だが、preemptが既定で有効という決定的な違いがある。マルチベンダ環境ではVRRPが選択肢になる。関連してGLBP（Cisco独自）は複数ルータで同時に負荷分散しながら冗長化できる点が両者と異なる。
• preemptの既定値の違いが実務で最も事故を生む。HSRPで高優先度ルータをActiveに設計しても、そのルータが再起動すると復帰後もStandbyのまま居座り、意図した経路（例えば広帯域リンク側）が使われない。設計どおりに戻すにはstandby <group> preempt を明示する必要がある。逆にVRRPは既定で戻るため、意図せず切り戻りが起きる可能性を織り込む。
• インタフェーストラッキング（standby 1 track <if> <decrement>）を併用すると、上流リンクの障害時に自ルータの優先度を下げて役割を譲ることができる。トラッキングだけ設定してpreemptを入れ忘れると、優先度が下がっても切り替わらない（あるいは復旧しても戻らない）ため、両者はセットで設計する。

3.8.2マルチキャストの配送とRPF

• RPFチェック（Reverse Path Forwarding）はマルチキャストのループ防止の要。受信したマルチキャストパケットについて、そのパケットが到着したインタフェースが、ユニキャストルーティングテーブル上で送信元へ戻るために使うインタフェースと一致するかを検証し、一致しなければ破棄する。したがってユニキャスト経路が非対称だとマルチキャストだけ届かないという現象が起こる。
• PIM SM（Sparse Mode）は「受信要求があった枝だけに配る」明示的join方式。受信者側のルータはRP（ランデブーポイント）へ向けて (*,G) のjoinを送り、まずは共有ツリー（RPT）で受信を開始する。トラフィックが流れ始めると、より効率の良いSPT（最短パスツリー・(S,G)）へ切り替える（SPTスイッチオーバー）。RPの設定不整合や到達不可はSM全体の不通に直結するため、show ip pim rp mapping で全ルータのRP認識が揃っているかを確認する。
• IGMPはホストとその直近ルータの間で「このグループを受信したい」を伝えるプロトコル（ルータ間の配送はPIMが担う）。v2はグループ単位のjoin/leaveとクエリア選出を行う。v3は送信元を指定できるのが決定的な違いで、これによりSSM（Source-Specific Multicast・232.0.0.0/8）が成立する。SSMはRPを必要とせず、受信者が (S,G) を直接指定するため設計が単純で、不要な送信元からの受信も防げる。
• bidir-PIM（双方向PIM）は多対多（全員が送信者にも受信者にもなる）用途に最適化され、SPTへ切り替えず共有ツリーのみを使い、送信元ごとの (S,G) 状態を持たないためルータの状態量を大幅に削減する。MSDP（Multicast Source Discovery Protocol）は異なるドメインのRP同士が SA（Source Active）メッセージで送信元情報を交換する仕組みで、ドメイン間マルチキャストやAnycast RP（同一アドレスの複数RPで冗長化・負荷分散）の実現に使われる。

あなたはキャンパスのディストリビューション2台（DSW1・DSW2）でHSRPを構成し、広帯域アップリンクを持つDSW1を優先度150でActive、DSW2を既定の100でStandbyとする設計にしました。ある夜、DSW1をメンテナンスで再起動したところ、想定どおりDSW2がActiveへ昇格して通信は継続しました。ところがDSW1が復帰した後もDSW2がActiveのままで、狭帯域側のアップリンクにトラフィックが流れ続けています。ここで「優先度150のほうが大きいのだから、いずれ自動的に戻るはずだ」と考えるのはHSRPの既定値を取り違えた判断です。HSRPのpreemptは既定で無効なので、優先度が高くても現Activeが健在な限り役割を奪い返しません。対処は DSW1 に standby 1 preempt を設定することで、これにより優先度の高い側が復帰時に確実にActiveへ戻ります。もし同じ設計をVRRPで組んでいたなら、preemptは既定で有効なので何もしなくても戻っていたはずで、この既定値の差こそが両プロトコルを見分ける最重要ポイントです。さらにこの環境では、DSW1の上流リンクが落ちたときにDSW1がActiveのままだと、ゲートウェイは生きているのに外部へ出られないという最悪の状態になります。これを防ぐには standby 1 track <上流IF> 60 のようなインタフェーストラッキングを併用し、上流障害時に優先度を150から90へ下げてDSW2（100）に譲ります。ただしトラッキングだけ入れてpreemptを忘れると、DSW2側が奪い返せず切り替わらないため、両者は必ずセットで設計します。話は変わって、同じキャンパスで社内向けの映像配信（マルチキャスト）を始めたところ、一部のフロアだけ映像が届かないという報告が来ました。ユニキャストの疎通は正常でpingも通ります。ここで「ユニキャストが通るのだから経路は問題ない」と結論づけるのは誤りで、マルチキャストにはRPFチェックという追加の関門があります。RPFは「そのパケットが到着したインタフェースが、ユニキャストルーティングテーブル上で送信元へ戻るときに使うインタフェースと一致するか」を検証し、一致しなければ破棄します。実際に show ip rpf <送信元IP> を実行すると、映像が届かないフロアの上流ルータではパケットの到着IFとRPFのIFが食い違っていました。原因は、経路変更の際に往路と復路が別リンクを通る非対称経路が生まれたことで、ユニキャストは問題なく通るためこれまで顕在化していなかったのです。加えてPIM SM環境では、show ip pim rp mapping で全ルータが同じRPを認識しているか、show ip mroute で (*,G) と (S,G) のエントリが期待どおり作られているかを確認します。もし配信元が固定で受信者が送信元を指定できる設計なら、IGMPv3によるSSM（232.0.0.0/8）へ寄せることでRPそのものを不要にでき、RP起因の障害クラスを設計から消せます。

3.8.3この節のまとめ

• HSRP（Cisco・Active/Standby・仮想MAC 0000.0c07.acXX・優先度既定100）はpreempt既定無効、VRRP（標準・Master/Backup）はpreempt既定有効。トラッキングとpreemptはセットで設計する
• RPFチェックはユニキャスト経路に依存し、非対称経路ではマルチキャストだけ破棄される。show ip rpf で到着IFとRPF IFを突き合わせる
• PIM SMはRPの共有ツリーで開始しSPTへ切替、IGMPv3の送信元指定でSSM（RP不要）、bidirは状態量削減、MSDPはRP間でSA交換