【大阪 / 横浜】インフラ / サーバーサイドエンジニア募集中!

【大阪 / 横浜】インフラ / サーバーサイドエンジニア募集中!

【導入実績 500社以上】AWS 構築・運用保守・監視サービス

【導入実績 500社以上】AWS 構築・運用保守・監視サービス

【CentOS 後継】AlmaLinux OS サーバー構築・移行サービス

【CentOS 後継】AlmaLinux OS サーバー構築・移行サービス

【WordPress 専用】クラウドサーバー『ウェブスピード』

【WordPress 専用】クラウドサーバー『ウェブスピード』

【格安】Webサイト セキュリティ自動診断「クイックスキャナー」

【格安】Webサイト セキュリティ自動診断「クイックスキャナー」

【予約システム開発】EDISONE カスタマイズ開発サービス

【予約システム開発】EDISONE カスタマイズ開発サービス

【100URLの登録が0円】Webサイト監視サービス『Appmill』

【100URLの登録が0円】Webサイト監視サービス『Appmill』

【200ヶ国以上に対応】グローバル eSIM「ビヨンドSIM」

【200ヶ国以上に対応】グローバル eSIM「ビヨンドSIM」

【中国法人に対応】中国クラウド / サーバー構築・運用保守

【中国法人に対応】中国クラウド / サーバー構築・運用保守

【YouTube】ビヨンド公式チャンネル「びよまるチャンネル」

【YouTube】ビヨンド公式チャンネル「びよまるチャンネル」

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)

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    #筐体側の実アドレス

■ バックアップ側

ip lan1 vrrp 1 192.168.100.1 priority=100
ip lan1 vrrp shutdown trigger 1 lan2
ip lan1 address 192.168.100.3/24

■ WAN側 死活監視用

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時

192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63
192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63
192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63
192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63
192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63
192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63
要求がタイムアウトしました。
192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63
192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63
192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63

192.168.10.1 の ping 統計:
    パケット数: 送信 = 42、受信 = 41、損失 = 1 (2% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 1ms、最大 = 4ms、平均 = 1ms

192.168.100.1 からの応答: バイト数 =32 時間 =1ms TTL=255
192.168.100.1 からの応答: バイト数 =32 時間 =1ms TTL=255
192.168.100.1 からの応答: バイト数 =32 時間 =1ms TTL=255
要求がタイムアウトしました。
192.168.100.1 からの応答: バイト数 =32 時間 =1ms TTL=255
192.168.100.1 からの応答: バイト数 =32 時間 =1ms TTL=255

192.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を物理的に切断)

192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63
要求がタイムアウトしました。
192.168.10.1 からの応答: バイト数 =32 時間 =1ms TTL=63 

→ ほぼ瞬断レベルで復旧できること確認
→ マスタからバックアップの切り替わりもすぐに行われました。やったねたえちゃん!

いい感じですね。
万が一のときにもなかなかやってくれそうな気がします。

ステータス確認用コマンド

検証時、このへんを使って切り替わりのステータス確認を行いました。

■ VRRP

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の確認

show status lan2
show status ip keepalive 

~完~

この記事がお役に立てば【 いいね 】のご協力をお願いいたします!
9
読み込み中...
9 票, 平均: 1.00 / 19
479
X facebook はてなブックマーク pocket
【2024.6.30 CentOS サポート終了】CentOS サーバー移行ソリューション

【2024.6.30 CentOS サポート終了】CentOS サーバー移行ソリューション

【2025.6.30 Amazon Linux 2 サポート終了】Amazon Linux サーバー移行ソリューション

【2025.6.30 Amazon Linux 2 サポート終了】Amazon Linux サーバー移行ソリューション

【大阪 / 横浜】インフラエンジニア・サーバーサイドエンジニア 積極採用中!

【大阪 / 横浜】インフラエンジニア・サーバーサイドエンジニア 積極採用中!

この記事をかいた人

About the author

かわ けん

システムソリューション部所属
好奇心旺盛ポケ○ン