VRRPで切り替わらない時の切り分け｜priorityとtrackの落とし穴

VRRPを組んだはずなのに、いざMasterルータを落としてみたら通信が切れたまま戻らない。あるいは、意図していないタイミングでBackup側にフェイルオーバーしてしまう。これ、ネットワーク屋なら一度は食らったことある話だと思う。で、こういう時に限って深夜のメンテ中だったりして、本当に焦る。

この記事では、Catalyst 9300 × 2台構成を想定して、VRRPが切り替わらない／勝手に切り替わるときに自分が現場で実際にやっている切り分けをまとめた。priority、preempt、トラッキング、そしてVRRPv2/v3の挙動差まで、ハマりやすい順に並べてある。コマンド例は手元のIOS-XE 17.6で打って動作確認したものを載せているので、そのまま使えるはず。

まずは状態確認、show vrrpから目grepで読む

切り替わらない、と言われて真っ先にやるのはこれ。

R1# show vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Vl10                10 120 3570      Y   Master  192.168.10.2    192.168.10.1
R2# show vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Vl10                10 100 3609      Y   Backup  192.168.10.2    192.168.10.1

両方がMasterになっていたら、それはAdvertisementが届いていないサイン。逆に両方がBackupなら、仮想MAC（0000.5e00.01xx）がARPテーブルに乗らずクライアントが通信できない状態になる。ここの見落としは、意外と多い。

show vrrpで最低限見るポイント

• State: Master / Backup / Init のどれか
• Priority: 設計値通りか（後述）
• Pre (Preempt): Y なら優先度が高い側が常に奪い返す
• Timer: Master 1秒 / Backup 3.6秒がデフォルト
• Master addr: 「誰が」Masterとして見えているか

ちなみに、VRRPv3だとshow vrrp の表示フォーマットが微妙に変わる。Groupごとのstate machine遷移を追いたいなら debug vrrp allより debug vrrp state のほうが読みやすい。all にするとアドバタイズ1本ごとにログが流れて、本番系だとログローテが追いつかない。

切り替わらない原因その1：priorityとpreemptの組み合わせミス

これ、最初めちゃくちゃ困ったやつ。preemptを切った状態で一度Backupに寄せてしまうと、priorityが高い方が復旧してもMasterに戻らない。設計書では「R1が現用」と書いてあるのに、いつの間にかR2が居座り続けている、みたいな。

! 現用側：priority 120、Preempt有効（デフォルト）
R1(config)# interface Vlan10
R1(config-if)# vrrp 10 address-family ipv4
R1(config-router)# address 192.168.10.1 primary
R1(config-router)# priority 120
R1(config-router)# ! preempt はデフォルト有効なので明示不要

! 待機側：priority 100
R2(config)# interface Vlan10
R2(config-if)# vrrp 10 address-family ipv4
R2(config-router)# address 192.168.10.1 primary
R2(config-router)# priority 100

preemptを意図的に外すケース（遅延収束させたい、ARP再学習を避けたい等）もあるにはあるけど、意図がないなら触らない。自分はpreempt delay minimumを30秒くらい入れておくのが好き。ルータ起動直後はルーティングテーブルがまだ収束してないのに、すぐMasterに戻ると一時的に通信断が起きることがある。

priority 255だけ特別扱いな件

priorityを255にすると、そのルータは「仮想IPを物理IPとして持っているオーナー」として扱われる。ownerはpreempt設定に関係なく必ずMasterになるので、仕様として押さえておく。個人的にはownerは使わない派。仮想IPをどれかの物理IPに一致させると、ルーティングやNAT設計で混乱のもとになるので。

切り替わらない原因その2：Advertisementが届いていない

次に疑うのがここ。Advertisementは宛先224.0.0.18のマルチキャストでInterval 1秒（VRRPv2デフォルト）。これが相手側に届いていないと、両方がMasterに昇格する「スプリットブレイン」状態になる。

届かない典型パターン:

• Vlan SVIが間にあるスイッチでマルチキャストがブロックされている
• アクセスポートになっていて別VLANに落ちている
• トランクポートのallowed vlanから対象VLANが抜けている
• MTU不一致で大きいパケットが落ちる（めったにないが検証機で遭遇した）
• ACLでVRRPパケットをdenyしている（HSRPでよくある話だけど、VRRPでも同じ）

切り分けコマンド：

R1# show ip igmp interface vlan 10
R1# show interfaces trunk | include Vlan
R1# debug vrrp packets
*Apr 20 03:12:44.123: VRRP: Grp 10 sending Advertisement checksum 0x5A3B
*Apr 20 03:12:44.230: VRRP: Grp 10 Advertisement from 192.168.10.3 received

自分が送っているログは出るのに、相手から受けているログが出ない、という時はL2経路が原因のことがほぼ100%。pingも届かなかったりする。まあここまでくればL2屋の領分なので、vlan showとspanning-tree blockingを見に行くフェーズに入る。

切り替わらない原因その3：トラッキング設定の落とし穴

正直、現場で一番悩ましいのがこれ。

「上流リンクが落ちたらBackupに寄せたい」という要件、よくあると思う。これをやるのがinterface trackingとIP SLA tracking。でも、設定ミスをやらかしやすい。

interface trackingの基本形

R1(config)# track 10 interface GigabitEthernet1/0/1 line-protocol
R1(config)# interface Vlan10
R1(config-if)# vrrp 10 address-family ipv4
R1(config-router)# track 10 decrement 30

これでR1のGi1/0/1が落ちると、priorityが120 – 30 = 90に下がり、R2の100 を下回ってR2がMasterに昇格する。設計的にはキレイ。

で、よくやらかすのが decrement値の設定ミス。例えば decrement 10 にすると、120 – 10 = 110 で、依然としてR2の100より高い。つまり切り替わらない。「trackは効いているのに切り替わらない」と言われたら、まずここを疑う。

IP SLAトラッキングと合わせ技

リンクは生きているけど、上流のISPが死んでいる、みたいなパターンにはIP SLAが効く。

R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 8.8.8.8 source-interface GigabitEthernet1/0/1
R1(config-ip-sla-echo)# frequency 5
R1(config)# ip sla schedule 1 life forever start-time now
R1(config)# track 20 ip sla 1 reachability
R1(config)# interface Vlan10
R1(config-if)# vrrp 10 address-family ipv4
R1(config-router)# track 20 decrement 30

ただ、8.8.8.8への到達性をトラッキング対象にするのは、個人的にあまりおすすめしない。Google側の事情で一時的にICMPがドロップされると、こっちのVRRPが無駄に切り替わる。SLAはできれば自社内の確実に応答してくれる機器（上流キャリアのCE側IPなど）を指定したい。

切り替わるタイミングの話：メンテ中に意図せずフリップする

以前、客先で夜間メンテ中にこのエラーに遭遇した。R1側でshutdownしていないのに、何故か数分おきにMaster/Backupがトグルしていた。ログを見ると、advertisementがタイミング的に衝突しているようだった。

原因はVRRPv2とv3の混在。R1はv3、R2はv2のままという悲しい状態。

R1# show vrrp vlan 10
Vlan10 - Group 10 - Address-Family IPv4
  Description is "v3 unified"
  ...
R2# show vrrp
Vlan10 - Group 10
  State is Backup
  Virtual IP address is 192.168.10.1
  Virtual MAC address is 0000.5e00.010a
  ! v2モード（fvrrp互換なし）

v2とv3はパケットフォーマットが違うので、完全に相互運用はできない。片方だけでfvrrp設定やaddress-family ipv4を使っていると、サイレントにうまくいかない。設定ファイルはdiff取って、両機が同じバージョンで動くよう統一するのが鉄則。

切り分けフロー：自分がいつもやってる順番

長年やってると「これを順番にやれば9割解決する」という手順が固まってくる。参考までに晒しておく。

1. 両機でshow vrrp briefを叩いて、State/Priorityを見る
2. priority × track decrement の計算をして、設計通りか確認
3. debug vrrp packetsで自機送信・相手受信の両方向を確認
4. 片方向だけ欠けていたらL2経路（trunk/allowed vlan/blocking port）を見に行く
5. 両方見えているのにトグルするなら、v2/v3混在と認証（MD5）設定差分を疑う
6. trackingを使っていればshow trackで状態、show ip sla statisticsで到達性を確認

ぶっちゃけ、5分で切り分け終わるケースがほとんど。沼るのは認証パスワードのtypoと、VLAN設計が現行と食い違っているとき。これは夜中だと頭が回らなくなるので、設計書の構成図を手元に置いておくのが結局一番速い。

HSRPとの比較：どっちを選ぶか

弊社内はHSRP派が多数だけど、マルチベンダー環境ではVRRPの方が安心。RFC 5798準拠なのでFortiGateやJuniperともIPレベルで相互運用できる。HSRPはCisco独自なので、NEXUSとCatalystの組み合わせしか使えない。余談だけど、VRRPはIPv6もRFCに含まれていて、この辺りの仕様はCisco公式のFHRP Configuration Guideが一番まとまっている。

選定基準ざっくりまとめ

認証についてはVRRPv3では仕様上廃止されていて、実質的にはIPsecなど別レイヤーで守る考え方になっている。個人的にはこっちの方が好き。VRRP内でMD5を持ち回るのは管理が面倒だった。

現場Tips：障害演習で必ずやっているテスト

設定が入ったら、本番投入前に以下3つは必ずテストする。

まず1つ目は物理リンクdown。Masterルータの上流ケーブルを物理的に抜いて、フェイルオーバーの時間を測る。ping -t 192.168.10.1 で何秒ロスしたかを計る。VRRP v2デフォルト3.6秒、v3ならsub-secondまで追い込める。2つ目はルータ電源断。OSが停止するケースの復旧確認。3つ目はpreempt動作。復旧後にMasterに戻るか、戻らないかの挙動確認。

この3つをやっておかないと、本番で「いざ」というときに想定外の挙動に慌てる。自分はこの検証を手抜きして痛い目に遭ったことが過去2回ある。この部分は検証が足りていないので、追って機会があれば時間計測の実測値も記事にしたい。

まとめ

要点はシンプル。priority × decrement の計算が合っているか、Advertisementが両方向に届いているか、v2/v3や認証が一致しているか。この3点を順番に確認すれば、VRRPの切り替わり問題はだいたい片付く。

関連記事として、HSRPのACLマルチキャストdenyハマりの話もHSRPが組めなくなる前に知っておきたい｜ACLでマルチキャストをdenyしてしまう落とし穴にまとめている。併せて読むとFHRP系の切り分けが一気に楽になるはず。