あどもんネットワーク

フルスタック志向の現役ネットワークエンジニアが、手を動かして確かめた備忘録。


VRRPのグループ番号(VRID)が既存と被って大変だった話


ルータ2台をVRRPで冗長化する案件で、既存のVRRPとグループ番号(VRID)が被っていて、大変な目にあいました。

先に結論を書いておくと、VRRPを入れるときは、同じセグメントですでに使われているVRIDがないか必ず確認しましょう、という話です。

何が起きたか

構成はざっくりこんな感じでした。

  • 既存:既存機器がVRRPを使っている(VRID 1)
  • 今回:ルータ2台をVRRPで追加(こちらもVRID 1で設定)

同じセグメントに、VIPの違う2つのVRRPグループが同じVRID 1で並んでしまったわけです。既存機器はこちらの管轄ではなかったので、事前に気づけませんでした。

その結果、こんな症状が出ました。

  • Master/Backupが想定どおりに決まらず、よくわからないタイミングでBackupに切り替わる
  • ルータを接続したタイミングで、既存のLAN端末がオフラインになる
  • 別セグメントのNTPサーバへの時刻同期が、Backup側だけ失敗する

自分たちのルータ同士でシンプルにMaster/Backupが決まる想定だったので、最初は何が起きているのかさっぱりでした。

VRIDが被るとなぜまずいのか

VRRPのアドバタイズ(Masterが自分の生存を知らせるパケット)は、マルチキャストアドレス224.0.0.18(IPv4の場合)宛てにセグメント全体へ流れます。受け取った側は、パケットに入っているVRIDを見て、自分のグループのものかを判断します。

ここがポイントで、RFCではVIPが一致しているかの確認は「してもよい(MAY)」という任意の扱いです。VRRPv3(RFC 9568)では、確認して不一致が見つかってもログを残すだけで、パケット自体はそのまま処理されます。つまり、VIPが違う別の冗長ペアのアドバタイズでも、VRIDが同じなら自分のグループのものとして扱われてしまうことがあるんです。

そもそもRFCは、同じLAN上のVRRPルータ間でVRIDとアドレスの対応を揃えておくことを前提にしています。同じLANでVRIDを使い回すこと自体が想定外の構成なんですよね。

今回のケースでは、既存側と今回のルータの計4台が、ひとつのグループとして選出し合っていたと考えられます。自分たちで決めたはずの状態が既存側のアドバタイズで覆されるので、状態が安定しないのも納得です。

もう一つ気をつけたいのが仮想MACアドレスです。VRRPの仮想MACは、IPv4の場合 00-00-5E-00-01-{VRID} という形で、VRIDから決まります。つまりVRIDが同じなら、2つのグループの仮想MACもまったく同じになります。するとスイッチのMACアドレステーブルが行ったり来たりして、端末からGWへの通信が別のルータに届いてしまいます。

なお、機器によっては仮想MACではなく実MACを使う設定もあります。仮想MACまで被るかどうかは、既存側の設定次第です。

参考:RFC 9568(VRRPv3)/RFC 3768(VRRPv2)(どちらも受信時のチェックは7.1節、仮想MACは7.3節)

Backupだけ同期できなかったのはなぜ?

ここは正直、まだ断定できていません。

状態が頻繁に入れ替わっていたことや、別セグメントへの通信がどのGWを経由していたかが関係していそうです。ただ、既存側の設定がわからないので、実環境では確かめきれませんでした。

そのため、検証環境で再現して原因を突き止める予定です。結果は別記事で詳しく書きます。

VRIDの重複を確認する方法

お客さんのネットワークに自分のPCをつないでパケットを見る、というのは現実的にはなかなかできません。確認は次の2つが中心になります。

1. 設計段階で既存のVRIDを確認する

既存ベンダーやお客さんに、同じセグメントで使っているVRIDをヒアリングします。設計書があればそちらでも確認します。ヒアリングシートに項目として入れておくと漏れにくいです。

RFC上、VRIDにデフォルト値はありません。それでも1は選ばれやすい番号なので、何も考えずに1を使うのは避けたほうが安全です。

2. 接続後、想定外のMasterがいないか確認する

ルータを接続したら、自分たちのペア以外のルータがMasterになっていないかを確認します。Ciscoなら次のコマンドです。

show vrrp brief
  • show vrrp:VRRPの状態を表示する
  • brief:インターフェースごと・グループごとに1行で簡潔に表示する

出力では、次の列を見ます。

  • Grp:グループ番号(VRID)
  • Pri:自分の優先度
  • State:自分の状態(Master/Backup)
  • Master addr:現在Masterになっているルータの実IP
  • Group addr:VIP

Master addr に、自分たちのペア以外のIPが出ていたら要注意です。同じVRIDのルータが別にいるサインです。ただし、機器によってはVIPが違うアドバタイズを破棄するため、ここに出てこないこともあります。VIPの不一致を知らせるログや、状態遷移のログが頻繁に出ていないかもあわせて確認しましょう。

まとめ

  • VRRPを入れるときは、同じセグメントのVRIDの重複を必ず確認する
  • 重複すると、別のペア同士で選出が混ざり、状態が不安定になることがある
  • VRIDが同じなら仮想MACも同じになり、既存端末の通信にまで影響が出ることがある
  • 確認は設計段階のヒアリングと、接続後の Master addr・ログのチェックで

「なぜBackupだけNTP同期に失敗したのか」は、検証環境で再現してから詳しく書く予定です。公開したらここにリンクを貼ります。

\ 最新情報をチェック /


コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

トップへ戻る