2-5 VTP
VLAN 定義をスイッチ間で自動同期する VTP の仕組み。Server / Client / Transparent 3 モードを iosvl2 実機で検証する。
1. VTP とは
VTP（VLAN Trunking Protocol）は、VLAN database を同一ドメイン内のスイッチ間で自動的に同期する Cisco 独自プロトコルである。前節 2-3 では 1 台のスイッチ上に vlan 10 vlan 20 といった定義を直接書いて VLAN を生やした。スイッチが 1 台、せいぜい 2 台であればこの運用で困らないが、十数台のアクセススイッチを抱えるキャンパス規模になると、同じ VLAN 定義を全機にコピーして回る作業は急速に破綻する。1 台で VLAN を作れば残りの switch には自動で行き渡る、という仕組みが必要になる。
VTP はこの「VLAN 定義を 1 か所で集中管理し、残りに配信する」役割を担う。VTP advertisement という制御フレームをトランクポート経由で交換し、ドメイン名・configuration revision・MD5 digest を突き合わせて差分を取り込む。トランクが前提になるのは、VTP advertisement そのものが VLAN 1（management VLAN）の上に乗ったマルチキャストフレームとして流れるからで、前節 2-4 で扱った Trunk が VTP の動作基盤となる。
2. 3 つの動作モード
VTP には 3 つの動作モードがあり、各スイッチはこのいずれか 1 つで動く。
| モード | VLAN 編集 | VTP advertisement 受信 | VTP advertisement 中継 | VLAN DB の同期 |
|---|---|---|---|---|
| Server | 可能（配信元） | する | する | する |
| Client | 不可 | する | する | する |
| Transparent | 自分独自に可能 | 中継のみ（自分では使わない） | する | しない |
Server は VLAN database の編集権を持ち、変更を VTP advertisement として配信する。Client は VLAN を自分で作れず、Server から流れてきた advertisement を受信して自身の VLAN DB を上書きする。この 2 モードがいわば「マスター・スレーブ」の関係である。
Transparent は性格がまったく違う。VTP advertisement はトランク経由で隣の switch へ中継するが、内容を自分の VLAN DB には反映しない。代わりに自前の VLAN を vlan コマンドで自由に作れる。VTP には参加するが、ドメインの集中管理には乗らないという、半独立の立ち位置である。
3 章以降で扱う構成では、コアスイッチを Server、アクセススイッチを Client にして VLAN を集中管理し、特殊用途のスイッチだけ Transparent にする、というのが典型パターンだった。あえて「だった」と書いたのは、後述のとおり現代の運用では VTP そのものを使わないケースが増えているためである。
3. Configuration Revision と同期判定
VTP の動作を理解するうえで最重要なのが Configuration Revision である。これは VLAN database のバージョン番号にあたる整数で、Server 上で VLAN を 1 回変更するたびに +1 されていく。受信側（Client や別の Server）は、advertisement 内の revision が 自分の revision より高ければ「新しい」とみなして上書きを受け入れる。同じか低ければ無視する。
この単純な比較ルールが、VTP の最大の落とし穴を生む。たとえば社内ラボで散々 VLAN を作っては消した古いスイッチ（revision = 200）が手元にあったとする。これをそのまま本番ネットワーク（revision = 30）に Server として接続すると、ラボ機の高い revision が「正」とみなされて本番のすべての Client に伝播し、本番の VLAN 定義が一気にラボの内容で上書きされる。本番側で運用していた VLAN 群はその瞬間に消える。VTP 事故の代表例として、CCNA のテキストにもセキュリティガイドにも繰り返し登場する有名な落とし穴である。
予防策は単純で、「他から持ち込んだスイッチは接続前に必ず vtp mode client または vtp mode transparent にして revision を 0 に戻す」ことに尽きる。あるいはドメイン名を変えてしまえば MD5 digest 比較ではじかれるが、いずれにせよ「revision を意識せず物理結線だけする」ことを許容してはいけないプロトコルである。
4. CML での検証
検証は CML（Cisco Modeling Labs）上の iosvl2 で行った。本節は STP を扱う 2-6 と地続きで複数のスイッチが必要になるが、host RAM 容量の都合で Cat9000v ではなく軽量な iosvl2 を採用している。VTP 関連の CLI とプロトコル挙動は IOS と IOS-XE で共通のため、結論はそのまま現行機種に転用できる。
トポロジは SW1 → SW2 → SW3 の直列チェーンで、SW1 を VTP server、SW2 を client、SW3 を transparent に置いた。SW1 Gi0/2 ↔ SW2 Gi0/1 と SW2 Gi0/2 ↔ SW3 Gi0/1 は全て dot1q トランクである。SW1 上で VLAN 10 / 20 / 30 を作成し、それがチェーン上をどう伝播するかを実機の show vtp status / show vlan brief で追う。
各スイッチの day0 config から VTP と VLAN に関わる部分だけ抜き出すと、次のようになる。
! SW1 (Server)
vtp domain STUDY
vtp version 2
vtp mode server
!
vlan 10
name USERS
vlan 20
name GUESTS
! SW2 (Client)
vtp domain STUDY
vtp version 2
vtp mode client
! SW3 (Transparent)
vtp domain STUDY
vtp version 2
vtp mode transparent
!
vlan 99
name LOCAL_TRANSPARENTドメイン名はいずれも STUDY で揃え、version は 2 で統一した。SW1 だけが VLAN 10 / 20 / 30 を持ち、SW3 だけが独自の VLAN 99 を持つ。残りの SW2 は VLAN を一切定義していない点に注目してほしい。VTP の効果はここで現れる。
5. SW1（Server）の状態
SW1 から見ると、自身が Server として VLAN database を編集し、advertisement を流す側になっている。
SW1#show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : STUDY
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 5254.00ad.8000
Configuration last modified by 0.0.0.0 at 5-15-26 15:18:05
Local updater ID is 0.0.0.0 (no valid interface found)
Feature VLAN:
--------------
VTP Operating Mode : Server
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
Configuration Revision : 6
MD5 digest : 0x19 0x47 0x84 0xC0 0xB7 0x09 0x63 0x57
0x02 0xF4 0x72 0xE4 0x72 0x16 0xAB 0xA2VTP Operating Mode が Server、VTP Domain Name が STUDY、Configuration Revision が 6 である。VLAN 10 / 20 / 30 の 3 つを順に作成し、トランク有効化の過程で追加の内部変更も拾った結果として revision は 6 まで進んでいる。MD5 digest は VLAN database のハッシュで、ドメイン内で同じ DB を持つスイッチ同士は同じ digest を返す。
VLAN database 自体は show vlan brief で見える。
SW1#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/0, Gi0/1
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsupVLAN 10 / 20 / 30 がいずれも active で並んでいる。なお実用上は問題ないが、本検証では day0 config の投入順序の都合で VLAN name（USERS、GUESTS）が反映されず、表示は IOS デフォルトの VLAN0010 等になっている。トランクポートの状態も合わせて確認しておく。
SW1#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/2 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi0/2 1-4094
Port Vlans allowed and active in management domain
Gi0/2 1,10,20,30SW2 へ向かう Gi0/2 が dot1q トランクとして up しており、VLAN 10 / 20 / 30 がトランク上で active と認識されている。VTP advertisement はこのトランクの上を流れていく。
6. SW2（Client）— 自動受信を確認
ここが本節の山場である。SW2 の day0 config は vtp mode client のみで、VLAN は 1 つも定義していない。それにもかかわらず、SW1 と接続した瞬間に SW2 の VLAN database は SW1 と完全に一致する。
SW2#show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : STUDY
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 5254.0054.8000
Configuration last modified by 0.0.0.0 at 5-15-26 15:18:05
Feature VLAN:
--------------
VTP Operating Mode : Client
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
Configuration Revision : 6
MD5 digest : 0x19 0x47 0x84 0xC0 0xB7 0x09 0x63 0x57
0x02 0xF4 0x72 0xE4 0x72 0x16 0xAB 0xA2注目すべきは 3 点ある。VTP Operating Mode が Client、Configuration Revision が 6（SW1 と同値）、そして MD5 digest も SW1 と完全に一致している。Number of existing VLANs も 8 で揃っており、SW2 の VLAN database が SW1 のものでまるごと上書きされたことが分かる。
VLAN リストを直接見ると、その上書きの結果がより直接的に確認できる。
SW2#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/0
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsupSW2 で vlan 10 も vlan 20 も vlan 30 も一切叩いていない。それでも show vlan brief には SW1 と同じ VLAN 10 / 20 / 30 が active で並ぶ。これが VTP の本懐である。Server 1 台で VLAN を作れば、ドメイン内のすべての Client が同じ VLAN を即座に持つ。スイッチが 100 台あろうが、追加の手作業はゼロで済む。
トランク側も確認しておく。
SW2#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 on 802.1q trunking 1
Gi0/2 on 802.1q trunking 1
Port Vlans allowed and active in management domain
Gi0/1 1,10,20,30
Gi0/2 1,10,20,30Gi0/1 が SW1 への上りトランク、Gi0/2 が SW3 への下りトランクで、両方とも 1 / 10 / 20 / 30 を運べる状態になっている。SW1 から流れてきた VTP advertisement はこの Gi0/2 を経由して SW3 へも中継される。
7. SW3（Transparent）— 中継のみ、反映しない
最後に SW3 を見る。SW3 は同じ STUDY ドメインのトランクに接続されており、SW2 から VTP advertisement を受信できる位置にいる。しかし vtp mode transparent のため、その内容は自身の VLAN DB には取り込まれない。
SW3#show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : STUDY
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 5254.005c.8000
Configuration last modified by 0.0.0.0 at 5-15-26 15:11:43
Feature VLAN:
--------------
VTP Operating Mode : Transparent
Maximum VLANs supported locally : 1005
Number of existing VLANs : 6
Configuration Revision : 0
MD5 digest : 0x78 0x8C 0x83 0x76 0xAC 0x59 0x54 0x23
0x74 0xD8 0x35 0xCE 0x17 0x84 0x65 0xC4VTP Operating Mode が Transparent、Configuration Revision が 0、Number of existing VLANs が 6 になっている点に注目する。Server / Client では revision が 6 まで進み VLAN が 8 個（1、10、20、30、1002〜1005）あったのに対し、Transparent では revision が動かず VLAN も 6 個（1、99、1002〜1005）にとどまる。MD5 digest も SW1 / SW2 と完全に違う値になっている。VTP の同期ロジックが SW3 上では「働いていない」ことがこれで裏付けられる。
VLAN database を直接見ると、その分離はさらにはっきりする。
SW3#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/0
99 LOCAL_TRANSPARENT active
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsupSW1 で作った VLAN 10 / 20 / 30 は SW3 には一切現れない。代わりに、SW3 が day0 config で自前定義した VLAN 99 LOCAL_TRANSPARENT だけが居る。Transparent はドメインの集中管理に乗らず、自分の VLAN を自分の判断で持つ独立採算スイッチとして振る舞う。
ただし「VTP に完全に無関係」ではない点に注意したい。トランク側を見ると、SW3 は SW2 からの advertisement を中継してはいる。
SW3#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 on 802.1q trunking 1
Port Vlans allowed and active in management domain
Gi0/1 1,99Gi0/1 のトランクは up しており、もし SW3 の先にさらに別の Client がいれば、SW3 はその Client に向けて SW1 由来の advertisement をそのまま中継する。Transparent の正確な役割は「自分のためには使わないが、他人のためには通す」中継ノードである。これが Client（受け取って自分も使う）と Transparent（受け取らず通すだけ）の決定的な違いになる。
8. 落とし穴・補足
- Revision リセット必須: 別環境の switch を本番ドメインに新規接続する際は、接続前に
vtp mode clientまたはvtp mode transparentを実行して configuration revision を 0 に戻す。これを怠ると、持ち込み機の revision が本番より高かった場合に本番側の VLAN database が一気に上書きされ、運用 VLAN が消える事故になる。VTP 関連で最も有名な事故パターンであり、テキストに必ず登場する。 - MD5 mismatch でドメインが事実上分断される: VTP advertisement は domain 名と MD5 digest で同一ドメイン判定される。domain 名が違えば advertisement は捨てられ、同じ場合でも MD5 digest が一致しなければ同期は走らない。SW1 の
show vtp countersでもNumber of config digest errors : 1が観測されており、digest 不一致は実機で日常的に発生する。 - 管理 VLAN（VLAN 1）が VTP のキャリア: VTP advertisement は VLAN 1 を介して流れる。VLAN 1 を運用上不要としてトランクから除外したい場合は、VTP の動作にも影響することを覚悟する必要がある。
- 現代の運用では VTP off / mode transparent が多数: VXLAN/EVPN の普及、構成管理ツール（Ansible / NSO 等）による全機一括 push の一般化、そして上述の事故リスクが重なり、「VTP に集中管理させる」設計は近年急速に減っている。新規設計では全 switch を
vtp mode transparent（または IOS-XE 17 以降のvtp mode off）にして、VLAN 定義は構成管理側で配るのが事実上の標準である。VTP は仕組みとしては美しいが、現場では「自動同期の便利さ < 事故リスク + 自動化との衝突」と判断されつつあるプロトコルでもある。
9. 次節
ここまでで、VLAN database をスイッチ間で自動同期する VTP の動作を 3 モードに分けて実機で確認した。Server で作った VLAN が Client に瞬時に反映され、Transparent には反映されない。configuration revision の比較が同期判定の中核であり、revision を意識せず物理結線するだけの運用が事故を呼ぶ。これが VTP の核心である。
しかし、ここまで構築してきた「複数のスイッチを Trunk で相互接続する構成」には別の問題がついて回る。スイッチを 3 台以上輪状や網状に結ぶと、ブロードキャストフレームが永久に回り続ける L2 ループ が発生する。CAM テーブルが書き換え合戦を起こし、リンクが帯域上限まで埋まり、ネットワーク全体が停止する。続く 2-6「STP と RSTP」では、この L2 ループを自動検出・自動切断する Spanning Tree Protocol の仕組みを、再び CML 実機の出力で追っていく。