前回（第1回）はVRRPの基本動作と、標準設定でもあるpreempt（自動切り戻し）が有効な状態でのフェイルオーバーの動きを実機ログつきで解説しました。
今回はその 第2回（応用編） です！
実際の現場（特に拠点間接続や商用環境）で重要になる
「Keepaliveを使った静的ルート死活監視との連動」
と、
「あえてpreempt=off（自動切り戻し無効）にして回線のバタつきを防ぐ設計」
について、ご紹介したいと思います。
1. 今回の検証構成と目的
システム構成図
現場でよくあるのが、「ルーターのポート自体はLink Upしているのに、その先のONUやメディアコンバータ（MC）、あるいはキャリア網内で障害が起きていて通信が通らない」という障害です。
物理リンクが落ちないため、単純なVRRPだけでは切り替わってくれません。そこで、ICMP EchoによるkeepaliveでRT等の対向装置死活監視を行います。
監視のpingが通らなくなったら静的ルート（ip route）を削除。それをトリガーにしてvrrp shutdown triggerを発動させ、安全に予備機へ切り替える構成を組みます。(詳細後述)
正常時（主回線経由で通信）
主回線側のKeepalive（ICMP Echo）が正常に通っており、RTX1300-1（Priority: 200）がMasterとして通信を搬送します。
障害発生時（主回線の途中障害をKeepaliveで検知）
途中経路の断線等でKeepaliveが落ちると、RTX1300-1の静的ルートが消滅。VRRPトリガーによってRTX1300-2（Priority: 100）がMasterへと昇格します。
2. 主な設定ポイント（Config解説）
両ルーターの主要Config抜粋です。
RTX1300-1（主系 / Priority: 200）
ip route 10.20.20.0/24 gateway 10.30.30.21 keepalive 1
ip keepalive 1 icmp-echo 3 3 10.30.30.21 local-address=10.30.30.11
ip lan1 address 10.10.10.11/24
ip lan1 vrrp 110 10.10.10.254 priority=200 preempt=off
ip lan1 vrrp shutdown trigger 110 lan2
ip lan1 vrrp shutdown trigger 110 route 10.20.20.0/24
RTX1300-2（副系 / Priority: 100）
ip route 10.20.20.0/24 gateway 10.40.40.22 keepalive 1
ip keepalive 1 icmp-echo 3 3 10.40.40.22 local-address=10.40.40.12
ip lan1 address 10.10.10.12/24
ip lan1 vrrp 110 10.10.10.254 priority=100 preempt=off
ip lan1 vrrp shutdown trigger 110 lan2
ip lan1 vrrp shutdown trigger 110 route 10.20.20.0/24
config中のここがポイント！
-
ip keepalive 1 icmp-echo ...
対向（10.30.30.21）へ3秒間隔でPingを打ち、3回連続で返ってこなければ（計9秒）「障害発生」と判断します。 -
ip route ... keepalive 1
Keepalive ID 1の死活とルート情報を連動させます。通信不可になればルーティングテーブルからこの経路が消えます。 -
ip lan1 vrrp shutdown trigger 110 route 10.20.20.0/24
指定したルートが消えた瞬間、VRRPプロセス自体をシャットダウンして自らBackupへ降格します。 -
preempt=off
優先度（Priority）が高い主系（RTX1300-1）が復旧しても、勝手にMasterへ戻らない（Non-Preempt）設定にしておきます。
💡 メモ：なぜYAMAHAはCiscoみたいにPriority減算（Tracking）をやらないのか？
CiscoのHSRPやVRRPに慣れていると「アップリンクが落ちたらPriorityの値を▲xxx 減算して副機に逆転させる」というトラッキング設計をよく使いますが、YAMAHAの仕様にはPriorityを動的に減算させる機能はありません。 (luaスクリプトで作りこまない限りは)
YAMAHAの場合は、Priorityを操作するのではなく
vrrp shutdown triggerでVRRPプロセスそのものをシャットダウン（停止）させる という割り切った設計になっています。公式仕様（YAMAHAドキュメント: マスタールーター動作時のシャットダウントリガを設定する）で指定できるトリガーは以下の通りです：
LAN形式: LANポートの物理リンクダウンpp形式: 回線切断や LCP/PP Keepalive による対向ダウン検知tunnel形式: IPsec / L2TP / PPTP / IPIP などのトンネルKeepaliveによるダウン検知route形式: 対象の経路（Static/Dynamic）がルーティングテーブルから消滅、または指定GWに向かなくなった場合今回は
route形式を使って「Keepalive不可 ➔ ルート消滅 ➔ VRRPシャットダウン」というコンボを組んでいます。
3. 実機コマンドによる動作検証
試験用RTX1300のコンソールから採取したログです。
Phase 1：初期状態（正常時）
RTX1300-1（Priority: 200）がMaster、RTX1300-2（Priority: 100）がBackupとして問題なく稼働している状態です。
- RTX1300-1 (主系)
RTX1300-1# show status ip keepalive
ID STATE TARGET REACH TIMER COUNT
------------------------------------------------------------------------
1 up 10.30.30.21 yes 3 3
RTX1300-1# show status vrrp
LAN1 ID:110 仮想IPアドレス: 10.10.10.254
現在のマスター: 10.10.10.11 優先度: 200
自分の状態: Master / 優先度: 200 Non-Preempt 認証: NONE タイマ: 1
- RTX1300-2 (副系)
RTX1300-2# show status vrrp
LAN1 ID:110 仮想IPアドレス: 10.10.10.254
現在のマスター: 10.10.10.11 優先度: 200
自分の状態: Backup / 優先度: 100 Non-Preempt 認証: NONE タイマ: 1
Phase 2：途中経路断線（障害発生）
RTX1300-1のLAN2先にある途中経路(直結となるONUやMCの先にある何かを想定)を落としてみます。
1. Keepaliveが落ちていくリアルな推移
show status ip keepalive を叩き続けると、カウントダウンしながらダウン確定へ向かうのが分かります。
1. STATE: up (REACH: yes / COUNT: 3)
2. STATE: up (REACH: yes / COUNT: 1) ← 応答なし！カウント開始
3. STATE: down? (REACH: no / COUNT: -) ← 仮Down（応答なし継続）
4. STATE: down (REACH: no / COUNT: -) ← 確定Down！
2. VRRP切り替えとSyslog
Keepaliveがdownになった瞬間、静的ルートが消えてVRRPシャットダウンがトリガーされます。
- RTX1300-1のSyslog (
show log)
2026/08/02 15:01:14: [KEEPALIVE 1] STATUS LED is OFF
2026/08/02 15:01:14: [VRRP LAN1:110] (version 2) MASTER -> INITIALIZE
主系（RTX1300-1）がINITIALIZE状態（停止）になったため、VRRPアドバタイズメントが途絶え、副系（RTX1300-2）が即座にMasterへ昇格しました。切り替え成功です！
Phase 3：途中経路戻し（障害復旧時の挙動）
ではここからは今回変えた preempt=off の挙動です。障害回線を復旧させてみます。
1. Keepaliveの復旧
物理線を戻すとKeepaliveがupに復帰し、静的ルートもルーティングテーブルに書き戻されます。
RTX1300-1# show status ip keepalive
ID STATE TARGET REACH TIMER COUNT
------------------------------------------------------------------------
1 up 10.30.30.21 yes 3 3
- RTX1300-1のSyslog (
show log)
2026/08/02 15:05:34: [KEEPALIVE 1] STATUS LED is ON
2026/08/02 15:05:34: [VRRP LAN1:110] (version 2) INITIALIZE -> BACKUP
2. VRRPステータスの確認（切り戻しが起きない！）
復旧後のステータスを両方確認します。
- RTX1300-1 (主系：Priority 200)
RTX1300-1# show status vrrp
LAN1 ID:110 仮想IPアドレス: 10.10.10.254
現在のマスター: 10.10.10.12 優先度: 100
自分の状態: Backup / 優先度: 200 Non-Preempt 認証: NONE タイマ: 1
- RTX1300-2 (副系：Priority 100)
RTX1300-2# show status vrrp
LAN1 ID:110 仮想IPアドレス: 10.10.10.254
現在のマスター: 10.10.10.12 優先度: 100
自分の状態: Master / 優先度: 100 Non-Preempt 認証: NONE タイマ: 1
なぜPriority 200の主系がMasterに戻らないのか？
これが preempt=off（Non-Preempt）の狙い通りだからです！
主系
が息を吹き返しても、現在Masterを務めている副系（RTX1300-2）が元気に動いている限り、 後から割り込んでMaster権限を奪い返さない（切り戻さない） という動作になります。
まとめポイント
1. Keepaliveはサイレント障害の命綱
回線業者側の障害や途中のL2スイッチ障害は、ポートのLink Upだけ見ていても絶対に検知できません。ICMP EchoによるKeepaliveとvrrp shutdown trigger routeの組み合わせは、YAMAHAでHA構成を組むなら有用なテクニックかと思います。
2. なぜ実務では preempt=off が好まれるのか？
デフォルトのpreempt=onだと、主回線が「切れかかっている状態（断続的なバタつき」の時に、通信が主系と副系を行ったり来たりしてネットワークが大混乱します。
preempt=off にしておけば：
- 障害時に一度副系へ倒れたら、主系が復旧しても勝手に切り戻らない。
- 業務時間中の不要なセッション切断を防止できる。
- 夜間やメンテナンス時間など、作業者が手動で安全に主系へ戻す運用ができる。
というメリットがあります。