【大阪 / 横浜 / 徳島】インフラ / サーバーサイドエンジニア募集中！
【導入実績 500社以上】AWS 構築・運用保守・監視サービス
【CentOS 後継】AlmaLinux OS サーバー構築・移行サービス
【WordPress 専用】クラウドサーバー『ウェブスピード』
YAMAHA RTX830 で VRRP を組んでみた
目次 [非表示]
こんにちは。
好きな数字は4096
システムソリューション部のかわです🐹
もうすぐ春ですね。
先日 YAMAHA さんの RTX830 で VRRP検証することがあったので、備忘録がてらに世界に発信しようと思います。
VRRP ってなに？
※ 知ってる人は読み飛ばしてね
■ YAMAHAさん公式ドキュメント⇩
http://www.rtpro.yamaha.co.jp/RT/docs/vrrp/vrrp.html
説明しよう！
VRRP（Virtual Router Redundancy Protocol）とは、ルーターを冗長化し、ローカル側から2台のルーターを、あたかも1台であるかのように見せかける技術である。
いわゆる HA（High Availability）の一種ですね。VRRP には TCP や UDP は使用せず、プロトコル番号112が使用されます。
これによって障害等が発生した際に、片方がダウンしても、もう片方で引き続き疎通が可能になります。便利ですね。
検証環境
ルーターには YAMAHA RTX830 を2台使用しました。
■ 簡易構成図
ローカルPC（上図の女の子）では、デフォルトゲートウェイとして、VIP（仮想IPアドレス）である「192.168.100.1」のみが見えています（実際は物理IPである「マスタ：192.168.100.2」「バックアップ：192.168.100.3」にも直接接続可能）。
■ 注意点
- WAN側インターフェイスに割り当てるIPは、staticである必要があります！
- 上下にL2スイッチ等必要です！
config
VRRP まわりの基本設定はこれだけ！⇩
■ メイン側（RTX1）
1 2 3 | ip lan1 vrrp 1 192.168.100.1 priority=200 #仮想IPの設定。priorityは高い方が優先ip lan1 vrrp shutdown trigger 1 lan2 #ダウン判断のインターフェイス指定（lan2がWAN）ip lan1 address 192.168.100.2/24 #筐体側の実アドレス |
■ バックアップ側
1 2 3 | ip lan1 vrrp 1 192.168.100.1 priority=100ip lan1 vrrp shutdown trigger 1 lan2ip lan1 address 192.168.100.3/24 |
■ WAN側 死活監視用
1 | ip keepalive 10 icmp-echo 1 3 1.1.1.1 #IPは仮 |
検証の記録
簡易的に、ローカルPCからインターネット宛（192.168.10.1）のping送信を実施しました。
検証その1）ping をVIP:192.168.100.1、インターネット側IP:192.168.10.1宛に継続して、送信中にマスタ側電源OFF時
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | 192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63要求がタイムアウトしました。192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63192.168.10.1 の ping 統計: パケット数: 送信 = 42、受信 = 41、損失 = 1 (2% の損失)、ラウンド トリップの概算時間 (ミリ秒): 最小 = 1ms、最大 = 4ms、平均 = 1ms192.168.100.1 からの応答: バイト数 =32 時間 =1ms TTL=255192.168.100.1 からの応答: バイト数 =32 時間 =1ms TTL=255192.168.100.1 からの応答: バイト数 =32 時間 =1ms TTL=255要求がタイムアウトしました。192.168.100.1 からの応答: バイト数 =32 時間 =1ms TTL=255192.168.100.1 からの応答: バイト数 =32 時間 =1ms TTL=255192.168.100.1 の ping 統計: パケット数: 送信 = 78、受信 = 77、損失 = 1 (1% の損失)、ラウンド トリップの概算時間 (ミリ秒): 最小 = 0ms、最大 = 3ms、平均 = 0ms |
⇧7行目で ping がタイムアウト。その後約7秒で192.168.10.1宛の疎通が復旧。
同じタイミングで20行目、デフォルトゲートウェイである仮想IPの「192.168.100.1」が、バックアップ機側に切り替わり、ping応答が復旧。
lossもかなり少なく抑えられました。
検証その2）インターネット断発生時（マスタ側WANを物理的に切断）
1 2 3 | 192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63要求がタイムアウトしました。192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63 |
→ ほぼ瞬断レベルで復旧できること確認
→ マスタからバックアップの切り替わりもすぐに行われました。やったねたえちゃん！
いい感じですね。
万が一のときにもなかなかやってくれそうな気がします。
ステータス確認用コマンド
検証時、このへんを使って切り替わりのステータス確認を行いました。
■ VRRP
1 2 3 4 5 6 | show status vrrp# 出力例show status vrrp LAN1 ID:1 仮想IPアドレス: 192.168.100.1 現在のマスター: 192.168.100.2 優先度: 200 自分の状態: Master / 優先度: 200 Preempt 認証: NONE タイマ: 1 |
⇧メイン側がマスタとして稼働中ですね
■インターフェイスとkeepaliveの確認
1 2 | show status lan2show status ip keepalive |
～完～
12
読み込み中...12 
【2026.6.30 Amazon Linux 2 サポート終了】Amazon Linux サーバー移行ソリューション
この記事をかいた人
About the author
