【実務・中級編】 VTP(VLAN Trunking Protocol)バージョン1および2の動作仕様 – インフラ・物理&L2/L3ネットワーク基礎実践ガイド

はじめに:VTPという「諸刃の剣」と、いま私たちが向き合うべき理由

ネットワークエンジニアとして現場を渡り歩いていると、VTP(VLAN Trunking Protocol)ほど、その便利さと引き換えに絶望的な障害を引き起こすプロトコルもないと感じます。新しいスイッチをラックにマウントし、トランクポートを結線した瞬間、既存のプロダクション環境のVLANデータベースがごっそり吹き飛ぶ――。いわゆる「VTPリビジョン番号の罠」にハマり、冷や汗を流した夜を過ごしたエンジニアも少なくないでしょう。

Web APIの設計やクラウドネイティブなインフラ構築が主流になった現在でも、オンスプレミスやデータセンターの基盤、あるいはハイブリッド環境の足回りにはシスコシステムズのCatalystスイッチが鎮座しています。L2/L3ネットワークの基礎として、VTPバージョン1およびバージョン2が内部でどのようにMACアドレスやVLAN情報を同期し、どのようなパケットを流しているのか。その深淵を覗くことは、インフラエンジニアとしての確かな生存戦略になります。

今回は、VTPv1/v2の動作仕様、サーバー・クライアント・トランスペアレントの各モードの挙動、そして実務で必ず直面する「コンフィグレーションリビジョン番号」の同期メカニズムについて、現場の泥臭い知見を交えて徹底解説します。

—

1. VTPの基本概念と3つの動作モード

VTPは、シスコ独自のL2プロトコルであり、複数のスイッチ間でVLANの追加・削除・名前変更などのデータベースを自動同期させるために開発されました。何十台、何百台とあるスイッチに、1台ずつ手動でVLANを作っていく苦行から私たちを解放してくれた偉大な仕組みです。

しかし、その制御は全自動であるがゆえに、モード設計を誤るとネットワーク全体を巻き込む大惨事につながります。VTPには以下の3つのモードが存在します。

サーバーモード(Server)

  • 役割: VTPドメインにおける「親」であり、VLANの作成、変更、削除の全権を握ります。
  • 挙動: 自身が行ったVLANの変更をNVRAM(非易失性RAM)に保存し、トランクポートを通じて定期的なアドバタイズメント(通知)を周囲のスイッチへブロードキャスト/マルチキャスト送信します。他のスイッチから受け取ったより新しい情報も、自身のデータベースに反映します。

クライアントモード(Client)

  • 役割: サーバーモードの指示に従う「従属」の存在です。
  • 挙動: 自身でVLANの作成・変更・削除を行うことはできません(コマンドを受け付けません)。サーバーから送られてくるVTPメッセージを受信し、自身のVLANデータベースとNVRAMを上書き更新します。

トランスペアレントモード(Transparent)

  • 役割: 孤高の「傍観者(透過)」です。
  • 挙動: 自身のVLANデータベースは完全にローカルで管理します(独自にVLANを追加・削除可能)。他のスイッチから送られてきたVTPメッセージを受信しても、自身のデータベースには一切反映しません。ただし、「俺は関係ない顔」をしながら、トランクポート経由でそのVTPパケットをそのまま他のスイッチへ転送(中継)する点がポイントです。

—

2. コンフィグレーションリビジョン番号の同期メカニズム

VTPの挙動を語る上で絶対に外せないのが、「コンフィグレーションリビジョン番号(Configuration Revision Number)」という32ビットの整数値です。この番号こそが、VTP同期の生死を分ける心臓部です。

リビジョン番号のインクリメントルール

1. スイッチがサーバーモードの状態で、VLANの追加・削除・変更などの設定変更を行うと、リビジョン番号が必ず 「+1」 されます。
2. リビジョン番号は、VTPドメイン名が同じである場合にのみ比較・同期の対象となります。
3. トランスペアレントモードのスイッチは、常にリビジョン番号 0 を保持し、インクリメントしません。

同期と上書きの恐ろしいアルゴリズム

スイッチは、自分よりも「リビジョン番号が大きい」VTPメッセージを受信した場合、たとえその内容が古いVLAN構成であっても、自身のVLANデータベースを強制的に上書きします。

ここでよくある現場の悲劇を思い出してください。
「オフィスのレイアウト変更で、昔どこかのラボで使っていた中古のCatalystスイッチ(VLANがたくさん登録されており、リビジョン番号が『50』になっている)を、現在の本番ネットワーク(リビジョン番号『5』)にトランク接続した。その際、うっかりモードをサーバーのままにしてしまった……」

結果はどうなるでしょうか?
中古スイッチから発信されたリビジョン 50 のVTPパケットを受信した本番環境のサーバー群は、「おっ、こっちの方が新しい情報だ!」と勘違いし、自身のデータベースをリビジョン 50 の内容に書き換えてしまいます。その結果、本番で稼働していた重要なVLANがごっそり消滅し、通信が完全断するというインシデントが発生します。これが「VTPリビジョン爆弾」の正体です。

—

3. VTPv1とv2の差異:実務で知るべきポイント

バージョン1とバージョン2の最大の違いは、「未対応VLAN(Token Ringなど)の扱い」と「バージョンの下位互換性・一貫性の強制」にあります。

  • VTP v1: トランスペアレントモードのスイッチは、受け取ったVTPメッセージを転送する際、ドメイン名が一致しているか厳密にチェックしていました。
  • VTP v2: トランスペアレントモードでのドメイン名チェックが緩和され、さらにトークンリング(Token Ring)VLANのサポートや、VTPパケットのフォーマット拡張が行われました。

しかし、実務的な観点から言うと、「今どきv1を使う理由はなく、基本はv2、あるいはセキュアな運用のためにはVTP自体をオフ(あるいはトランスペアレント)にするのが定石」です。

—

4. 実機設定サンプルと検証コマンド

それでは、実際にCisco IOS環境でVTPを設定する際の設定ファイル(コンフィグ)と、トラブルシューティングで必ず叩くべき確認コマンドを見ていきましょう。

設定例:スイッチA(VTPサーバー)の構築

!
vtp domain Corporate-NW      ! VTPドメイン名を「Corporate-NW」に設定
vtp version 2                ! VTPバージョンを2に指定
vtp mode server              ! 自身をサーバーモードに設定
!
vlan 10                      ! 開発用VLANの作成
 name Development
vlan 20                      ! 本番用VLANの作成
 name Production
!

設定例:スイッチB(VTPクライアント)の構築

!
vtp domain Corporate-NW      ! サーバーと同じドメイン名を指定
vtp version 2
vtp mode client              ! 自身をクライアントモードに設定
!

> 💡 現場のTips: クライアントモードに変更すると、手動で vlan 30 などを作成しようとしても VTP Client mode cant add VLAN. と怒られます。これが正常な動作です。

運用の命綱:show vtp status による状態確認

ネットワークに異常を感じたら、あるいは新しいスイッチを接続する直前には、必ず以下のコマンドを実行してリビジョン番号を確認してください。

Switch# show vtp status
VTP Version                     : 2
Configuration Revision          : 5         <--- ★ここを必ず確認!
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 12
VTP Operating Mode              : Server    <--- ★モードの確認
VTP Domain Name                 : Corporate-NW
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled
VTP Traps Generation            : Disabled
MD5 Digest                      : 0x4A 0x8B 0x11 0x2C ...
Configuration last modified by 192.168.1.10 at 3-10-25 10:00:00

この出力結果の中で、Configuration Revision が意図しない大きな数値になっていないか、そして VTP Operating Mode が想定通り(クライアントならClient、独立させたいならTransparent)になっているかを入念にチェックします。

—

5. 安全なインフラ運用のためのベストプラクティス

VTPは強力なプロトコルですが、ヒューマンエラーによる全社障害のリスクと常に隣り合わせです。現代の堅牢なネットワーク設計では、以下のプラクティスが事実上の標準(デファクトスタンダード)となっています。

1. VTPオフ(またはトランスペアレント)の徹底
近年の大規模・高信頼ネットワークでは、VTPによる自動同期を行わず、すべてのスイッチを vtp mode transparent に設定するか、そもそもVTPを使用せずに各スイッチで個別に(あるいはNetBoxやAnsibleなどのIaCツールを使って)VLANを管理する手法が好まれます。トランスペアレントにしておけば、万が一古いリビジョンのスイッチが混入しても、VLANデータベースが勝手に破壊されるリスクをゼロに抑えられます。

2. ドメイン名の複雑化とパスワードの設定(やむを得ず使う場合)
どうしてもVTPサーバー/クライアント環境を維持する必要がある場合は、vtp domain に推測されにくい複雑な文字列を指定し、さらに vtp password [secret-key] を設定して暗号化(MD5ダイジェストによる認証)をかけ、不正なスイッチからのパケットを受け付けないように防衛線を張ることが鉄則です。

3. ラボ機材の初期化を怠らない
検証環境(ラボ)で散々いじり倒したスイッチを本番へ投入する際は、必ず erase startup-config を行い、フラッシュに残っている vlan.dat ファイルを削除(delete vlan.dat)してから再起動し、リビジョン番号を 0 にリセットする習慣を徹底しましょう。

—

おわりに

今回は、VTPv1/v2の動作仕様と、インフラエンジニアの肝を冷やすリビジョン番号の仕組みについて解説しました。

ネットワークの裏側で黙々とパケットを処理し、状態を同期し続けるプロトコルの挙動を理解していると、障害が発生した際にもパケットの流れ(シーケンス)やスイッチの状態から瞬時に原因を特定できるようになります。「なぜこの設計になっているのか」「この設定を入れるとどんなパケットが飛び交うのか」という背景に思いを馳せながら、日々のインフラ運用・設計に向き合っていきましょう。

コメント

タイトルとURLをコピーしました