VTPv1/v2の深淵：コンフィグレーションリビジョン番号が引き起こすネットワーク崩壊と、そのパケットレベルの真実
ネットワークエンジニアのキャリアにおいて、最も冷や汗をかく瞬間の一つが「VLAN情報が一瞬にして全スイッチから消失し、数千台の端末が孤立した瞬間」ではないだろうか。
シスコシステムズが独自に開発した VTP (VLAN Trunking Protocol) は、大規模なスイッチングファブリックにおいて、VLANの追加・変更・削除を全スイッチ間で同期させるための強力なプロトコルである。しかし、このプロトコルは利便性の裏に、ひとたび設計思想を誤ればネットワーク全体を壊滅させるだけの破壊力を秘めている。
今回は、あえてレガシー領域に分類されつつある VTP Version 1 および Version 2 の動作仕様に深くメスを入れ、パケットレベルの挙動からコンフィグレーションリビジョンの罠、そして現場で絶対に踏んではいけない地雷の回避策まで、インフラアーキテクトの視点から徹底的に紐解いていこう。
—
1. VTPの動作モードとアーキテクチャの基本
VTPは、Catalystスイッチ間でVLANデータベース（vlan.dat）を自動同期するためのプロトコルだ。その役割は以下の3つのモードによって厳密に定義されている。
+------------------+ VTP Advertisement +--------------------+
| VTP Server | ------------------------> | VTP Client |
| (VLAN作成/変更可) | | (読み取り専用/同期) |
+------------------+ +--------------------+
^
| VTP Advertisement
+-------------------------------------+
|
+--------------------+
| VTP Transparent |
| (ローカルのみ保持/ |
| 中継のみ実施) |
+--------------------+Server（サーバーモード）
デフォルトのモードである。このモードのスイッチでは、VLANの作成、変更、削除を自由に行うことができ、その変更履歴はフレームとしてトランクポート経由でネイバー（隣接スイッチ）へブロードキャスト/マルチキャスト送信される。また、受信したVLAN情報を自身のデータベースに反映し、さらに下流へ伝播させる。
Client（クライアントモード）
VLANの追加・変更・削除が一切禁止されているモードだ。自身のローカルメモリ上でVLAN設定を変更しようとしても、CLI上で拒否される。サーバーから送られてくるVTPアドバタイズメントを受信し、自身の vlan.dat を強制的に上書き同期することだけに特化している。
Transparent（トランスペアレントモード）
VTPの同期の輪から完全に外れた「孤高の存在」である。トランスペアレントモードのスイッチでVLANを作成・変更しても、それはローカルの vlan.dat に保存されるだけで、他のスイッチへは一切同期されない。
ただし、非常に重要な挙動として、ネイバーから受信したVTPアドバタイズメントを自身のCPUで処理しつつ、そのまま他のトランクポートへ転送（リレー）する機能を持っている。
—
2. パケットレベルで見るVTPフレーム構造と同期のメカニズム
VTPはトランクリンクを通じて動作するため、IEEE 802.1Qのタグが付与されたフレーム内でやり取りされる。実は、VTPのトラフィックはL2のマルチキャストアドレスである 01-00-0c-cc-cc-cc（Ciscoルータ/スイッチのプロトコル用マルチキャスト）宛てに送信される。EtherTypeは 0x2004（Cisco Discovery Protocolと同様のプライベート領域）を使用している。
VTPアドバタイズメントには主に以下の3種類が存在する。
1. Summary Advertisement（サマリーアドバタイズメント）
- 5秒毎、またはVLAN構成変更時に定期送信される。
- 現在のVMD（VLAN Management Domain）名、コンフィグレーションリビジョン番号（Configuration Revision Number）、タイムスタンプ、MD5ダイジェストなどが含まれる。
2. Subset Advertisement（サブセットアドバタイズメント）
- サマリーアドバタイズメントの直後、またはVLANの詳細な追加・削除が行われた際に送信される。
- 具体的なVLAN ID、VLAN名、MTUなどの詳細データが格納される。
3. Advertisement Request（アドバタイズメントリクエスト）
- クライアントやサーバーが、自身が持つリビジョンよりも新しいサマリーを受信した際、あるいはリセット直後に詳細データを要求するために送信する。
コンフィグレーションリビジョン番号の魔力
VTPの同期ロジックにおいて、絶対的な正当性を決めるのは「コンフィグレーションリビジョン番号の高さ」のみである。
- スイッチA（リビジョン: 10）
- スイッチB（リビジョン: 15）
この状態で両者をトランクで接続した場合、リビジョン「15」を持つスイッチBのVLANデータベースが正とみなされ、リビジョン「10」のスイッチAは、Bからのアドバタイズメントを受信した瞬間、自身のVLANデータベースをBのそれに完全上書き（消去＆置換）される。
これが、現場で恐れられている「VTPインシデント」のメカニズムである。
—
3. 現場を崩壊させる典型的なアンチパターン：中古スイッチの罠
実務において、VTPv1/v2が引き起こす最悪の障害といえば「ラボや別案件で使っていた中古スイッチ（または適当に設定したスイッチ）を、既存のプロダクションネットワークに接続した瞬間、全VLANが吹き飛ぶ現象」だ。
障害発生のシナリオ
1. あるエンジニアが、VTPドメイン名が一致する（あるいはデフォルトの空白ドメインのまま）テスト用スイッチ（Serverモード、リビジョン: 50）を持ち込んだ。
2. このスイッチは、過去の検証で無数のVLANが作成・削除されたため、リビジョン番号が 50 までカウントアップしていた。
3. 本番ネットワークのコアスイッチ（Serverモード、リビジョン: 10）が稼働しているトランクポートに、このテスト用スイッチを接続した。
4. テスト用スイッチは「俺の方がリビジョンが新しい（50 > 10）」と判断し、本番コアスイッチに対してサマリーアドバタイズメントを送信。
5. コアスイッチはそれを信じ込み、自身のVLANデータベースをテスト用のスカスカな状態に書き換えた。
6. 結果、全VLANが消失し、トランク上の全通信がブラックホール化する。
この悲劇を防ぐためには、ネットワークに新しいスイッチを投入する前の「儀式」が不可欠となる。
—
4. 実務における堅牢な対策とVTP設定のベストプラクティス
VTPv1/v2の仕様上のリスクを回避するため、インフラアーキテクトが実務で必ず実装すべき鉄則をコードと設定例を交えて解説する。
対策1：VTPモードを「Transparent」に固定する
現代の大規模ネットワーク、あるいはVLANの設計が厳密に管理されている環境において、動的なVTPサーバー/クライアント同期を利用するメリットはほぼ存在しない。ヒューマンエラーによる全滅を防ぐため、アクセス層を含めたすべてのスイッチでVTPモードを transparent に設定するのが業界標準のベストプラクティスである。
以下のCisco IOSコマンドをテンプレートとして適用せよ。
! すべてのスイッチでVTPモードをトランスペアレントに変更する
conf t
vtp mode transparent
! VTPドメイン名は意図しない同期を防ぐためにダミーでも構わないので一意な文字列にする
vtp domain PROD-DATA-CORE-202X
! パスワードを設定して不正なアドバタイズメントのインジェクションを防ぐ（v2でも有効）
vtp password SuperSecretVtpPassWord!
end対策2：リビジョン番号のリセット手順（安全な初期化）
もし、手元にあるスイッチのVTPリビジョン番号が上がってしまい、初期化したい場合は以下の手順を踏む必要がある。単純に vlan.dat を削除するだけでは不十分なケースがあるため、以下の手順が確実である。
! 1. 一時的にVTPモードをトランスペアレントに変更する
! （トランスペアレントモードではリビジョン番号が0にリセットされ、アドバタイズメントに影響を与えなくなる）
conf t
vtp mode transparent
end
! 2. 状態を確認し、リビジョンが「0」になったことを確認する
show vtp status
! 3. 必要に応じて元のサーバーモードに戻す（必要がなければトランスペアレントのままで推奨）
conf t
vtp mode server
end
! 4. フラッシュメモリ上のvlan.datを完全に削除してリフレッシュする場合
delete flash:vlan.dat
! （プロンプトが表示されたらEnterで確定）
reload—
5. まとめ：プロトコルの裏側を知る者だけが防げる障害
VTPv1およびv2は、設定の簡略化という甘い蜜を提供してくれる一方で、その同期メカニズムのプリミティブさゆえに、一歩間違えればネットワーク全体を灰燼に帰すリスクを孕んでいる。
パケットレベルで「誰が一番高いリビジョンを持っているか」という単純なマジョリティ（正確にはマジョリティではなく単なる数字の大小）で正当性が決まる仕様を理解していれば、新規スイッチ接続時の恐怖をコントロールすることができる。
最新のネットワーク環境では、VTP自体を完全に無効化するか、あるいはより安全に設計された VTP Version 3（プライマリーサーバーの概念や、隠しドメイン、明示的な認証機構が導入されている）への移行、あるいはSDNによる一元管理が主流だ。しかし、足元の基盤を支えるレガシープロトコルの挙動を血肉として理解しているか否かが、一流のインフラエンジニアと単なるオペレーターを分ける境界線となるのだ。
コメント