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 (デフォルト VLAN) 上の制御トラフィックとして流れる点にあり、前節 2-4 で扱った Trunk が VTP の動作基盤となります。

2. 3 つの動作モード
VTP(ここで扱う v1 / v2)には主要な 3 つの動作モードがあり、各スイッチはこのいずれか 1 つで動作します(IOS-XE 17 以降では VTP を完全に無効化する vtp mode off も選べますが、本節では基本の 3 モードに絞ります)。
| モード | 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 に参加しつつ、ドメインの集中管理には乗らない半独立の立ち位置です。
典型的な構成パターンは、コアスイッチを 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 のテキストにもセキュリティガイドにも繰り返し登場する有名な落とし穴です。
予防策の要は「他から持ち込んだスイッチは接続前に必ず configuration revision を 0 に戻す」ことです。ここで注意したいのは、vtp mode client や vtp mode transparent へ切り替えるだけでは revision は確実には 0 に戻らない点です。Cisco が案内する確実なリセット手順は、いったん VTP ドメイン名を別の名前に変更し(この時点で revision が 0 にリセットされる)、元のドメイン名に戻すというものです(vtp mode transparent を経由する手順も併用されます)。リセット後に show vtp status で revision が 0 になったことを確認してから本番ドメインへ接続します。いずれにせよ「revision を意識せず物理結線だけする」運用を許容してはいけないプロトコルです。
4. CML での検証
検証は CML (Cisco Modeling Labs) 上の iosvl2 で行いました。本節は STP を扱う 2-6 と地続きで複数のスイッチが必要となりますが、host RAM 容量の都合で Cat9000v ではなく軽量な iosvl2 を採用しています。本節で扱う VTP v1 / v2 の基本動作(3 モードの役割・configuration revision による同期・transparent の中継)と通常範囲 VLAN (1〜1005) の挙動は IOS と IOS-XE で共通のため、結論はそのまま現行機種に転用できます。なお VTP v3・extended-range VLAN・vtp mode off などには機種やソフトウェアによる差分があり、本節の範囲外とします。
トポロジは SW1 → SW2 → SW3 → SW4 の直列チェーンで、SW1 を VTP server、SW2 と SW4 を client、SW3 を transparent に置きました。SW1 Gi0/2 ↔ SW2 Gi0/1、SW2 Gi0/2 ↔ SW3 Gi0/1、SW3 Gi0/2 ↔ SW4 Gi0/1 はいずれも dot1q トランクです。SW1 上で VLAN 10 / 20 / 30 を作成し、チェーン上をどう伝播するかを実機の show vtp status / show vlan brief で追います。とくに末端の SW4 は transparent な SW3 を越えた先に置いた client であり、ここに SW1 由来の VLAN が届くかどうかが「transparent は本当に中継するのか」を確かめる肝になります。
各スイッチの day0 config から VTP と VLAN に関わる部分だけ抜き出すと、以下のとおりです。
! SW1 (Server)
vtp domain STUDY
vtp version 2
vtp mode server
!
vlan 10
name USERS
vlan 20
name GUESTS
vlan 30
name SERVERS
! 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
! SW4 (Client)
vtp domain STUDY
vtp version 2
vtp mode clientドメイン名はいずれも STUDY で揃え、version は 2 で統一しています。SW1 だけが VLAN 10 / 20 / 30 を持ち、SW3 だけが独自の VLAN 99 を持ちます。残りの SW2 と SW4 は VLAN を一切定義していない点が注目ポイントです。VTP の効果はここで現れます。
なお検証の過程で 1 点補足しておくべき挙動がありました。スイッチを一斉に起動した直後は、VTP advertisement の伝播タイミングがかみ合わず、client 側が一時的に未同期 (configuration revision が低いまま *** MD5 digest checksum mismatch on trunk *** を表示する) になることがあります。VTP の summary advertisement は既定で 300 秒周期のため、起動直後のタイミングがずれると次の周期まで再同期しない窓が生じるためです。これは Server 側で VLAN database を一度変更すれば即座に triggered advertisement が発行されて解消します。本検証でも SW1 で VLAN を一度追加・削除して triggered advertisement を流し、全スイッチが同期した状態を確認してから以下の出力を取得しています。以降の show vtp status では、同期に参加する Server / Client (SW1 / SW2 / SW4) の configuration revision がいずれも 3 で揃います。一方 Transparent の SW3 は同期に参加しないため revision は 0 のまま動きません。
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.00f0.8000
Configuration last modified by 0.0.0.0 at 6-11-26 01:43:06
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 : 3
MD5 digest : 0xB4 0x79 0x12 0x91 0xAB 0x25 0x4B 0x45
0x9F 0x83 0x5D 0xB7 0x5A 0x8D 0x77 0xF2VTP Operating Mode は Server、VTP Domain Name は STUDY、Configuration Revision は 3 です。configuration revision は VLAN database への変更(VLAN の作成・削除・名前変更など)が起きるたびに +1 され、ここでは VLAN 10 / 20 / 30 を作成した一連の変更を経て 3 に達しています(トランク設定そのものは VLAN database の変更ではないため revision は増やしません)。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 USERS active
20 GUESTS active
30 SERVERS active
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsupVLAN 10 USERS / 20 GUESTS / 30 SERVERS がいずれも active で並んでいます。トランクポートの状態も合わせて確認します。
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,30
Port Vlans in spanning tree forwarding state and not pruned
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.00f3.8000
Configuration last modified by 0.0.0.0 at 6-11-26 01:43:06
Feature VLAN:
--------------
VTP Operating Mode : Client
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
Configuration Revision : 3
MD5 digest : 0xB4 0x79 0x12 0x91 0xAB 0x25 0x4B 0x45
0x9F 0x83 0x5D 0xB7 0x5A 0x8D 0x77 0xF2注目点は 3 つあります。VTP Operating Mode が Client、Configuration Revision が 3 (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 USERS active
20 GUESTS active
30 SERVERS 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 が、名前 (USERS / GUESTS / SERVERS) ごと 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 on trunk
Gi0/1 1-4094
Gi0/2 1-4094
Port Vlans allowed and active in management domain
Gi0/1 1,10,20,30
Gi0/2 1,10,20,30
Port Vlans in spanning tree forwarding state and not pruned
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.0088.8000
Configuration last modified by 0.0.0.0 at 6-11-26 01:32:49
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 が 3 まで進み 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 は左右両方のトランク (Gi0/1 が SW2 側、Gi0/2 が SW4 側) を up させています。
SW3#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 on trunk
Gi0/1 1-4094
Gi0/2 1-4094
Port Vlans allowed and active in management domain
Gi0/1 1,99
Gi0/2 1,99
Port Vlans in spanning tree forwarding state and not pruned
Gi0/1 1,99
Gi0/2 1,99ここで一見すると不思議な点があります。SW3 のトランクの “Vlans allowed and active in management domain” は 両ポートとも 1,99 だけで、SW1 由来の VLAN 10 / 20 / 30 はリストに出てきません。SW3 自身の VLAN database に 10 / 20 / 30 が存在しないので当然です。それでも、後述するとおり SW3 の先にいる SW4 は VLAN 10 / 20 / 30 を受信します。VTP advertisement は SW3 が「自分の管理する VLAN」として扱う対象ではなく、VLAN 1 上を流れる L2 フレームとしてそのまま転送されるためです。
中継の動きをもう一段はっきり見るために、SW3 の VTP カウンタを確認します。
SW3#show vtp counters
VTP statistics:
Summary advertisements received : 0
Subset advertisements received : 0
Request advertisements received : 0
Summary advertisements transmitted : 0
Subset advertisements transmitted : 0
Request advertisements transmitted : 0
Number of config revision errors : 0
Number of config digest errors : 0
Number of V1 summary errors : 0
VTP pruning statistics:
Trunk Join Transmitted Join Received Summary advts received from
non-pruning-capable device
---------------- ---------------- ---------------- ---------------------------
Gi0/1 0 0 0
Gi0/2 0 0 0すべてのカウンタが 0 です。received も transmitted も 0 で、SW3 は VTP advertisement を「自分が受信・送信する VTP プロトコルパケット」としては 1 つも数えていません。それにもかかわらず、次節で見るとおり SW3 の先の SW4 には advertisement が確かに届きます。これは transparent の動作メカニズムを示すものです。transparent は VTP advertisement を VTP プロトコルとして処理するのではなく、VLAN 1 上を流れる L2 マルチキャストフレームとして素通しで転送します。そのため自分のカウンタには 1 件も計上されず、自分の VLAN DB にも反映されない一方で、隣の switch には届きます。「自分のためには使わない (カウンタにも DB にも出ない) が、他人のためには通す (先の client に届く)」という transparent の役割が、このカウンタ 0 に表れています。
8. SW4 (Client) — transparent を越えた中継の実証
ここまでで、SW3 (transparent) が VLAN を自分には反映しないこと、そしてカウンタ上は VTP advertisement を一切処理していないことを確認しました。SW3 が本当に advertisement を中継しているかを検証するため、SW3 のさらに先 (Gi0/2 トランクの向こう) に client の SW4 を 1 台置きました。SW4 は SW1 から見て transparent な SW3 を 1 つはさんだ先に位置します。transparent が advertisement を素通しするのであれば、SW4 は SW1 由来の VLAN を受信するはずです。
SW4 の day0 config は vtp mode client のみで、VLAN は 1 つも定義していません。その SW4 の状態を見ます。
SW4#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.007f.8000
Configuration last modified by 0.0.0.0 at 6-11-26 01:43:06
Feature VLAN:
--------------
VTP Operating Mode : Client
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
Configuration Revision : 3
MD5 digest : 0xB4 0x79 0x12 0x91 0xAB 0x25 0x4B 0x45
0x9F 0x83 0x5D 0xB7 0x5A 0x8D 0x77 0xF2決定的な結果です。SW4 の Configuration Revision は 3、MD5 digest は 0xB4 0x79 0x12 0x91 ... で、いずれも SW1 / SW2 と完全に一致しています。Number of existing VLANs も 8 で揃っています。configuration revision と MD5 digest が一致するということは、SW4 が SW1 とまったく同じ VLAN database を受け取ったことを意味します。VLAN リストも見てみます。
SW4#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/0
10 USERS active
20 GUESTS active
30 SERVERS active
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsupSW4 でも vlan 10 vlan 20 vlan 30 は一切叩いていません。それでも SW1 で作った VLAN 10 USERS / 20 GUESTS / 30 SERVERS が名前ごと active で並んでいます。transparent な SW3 を越えて、SW1 の VLAN 定義が SW4 まで届いたわけです。トランク側も確認します。
SW4#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi0/1 1-4094
Port Vlans allowed and active in management domain
Gi0/1 1,10,20,30
Port Vlans in spanning tree forwarding state and not pruned
Gi0/1 1,10,20,30SW4 の Gi0/1 (SW3 への上りトランク) は 1 / 10 / 20 / 30 を運べる状態です。これが「SW3 自身は 1 / 99 しか持たないのに、その先の SW4 は 1 / 10 / 20 / 30 を持つ」という、transparent 中継のもっとも分かりやすい対比になります。
整理すると、SW3 (transparent) は次の 3 つを同時に満たしていました。
- 自分の VLAN DB には反映しない —
show vlan briefに 10 / 20 / 30 は現れず、自前の VLAN 99 だけ。revision も 0 のまま。 - VTP のカウンタには計上されない —
show vtp countersが received / transmitted ともすべて 0。 - それでも先の client には届く — SW4 が SW1 と revision / MD5 完全一致で VLAN 10 / 20 / 30 を受信。
このうち中継が成立したことの主証跡は 3 の「SW4 の同期」です。2 のカウンタ 0 はそれを補強する観察で、transparent が VTP advertisement を VTP プロトコルとして処理せず L2 フレームとしてブリッジ転送している様子を示します(カウンタの数え方は実装に依存し得るため、あくまで補助的な裏付けと位置付けます)。
Transparent の正確な役割は「自分のためには使わないが、他人のためには通す」中継ノードです。これが Client (受け取って自分も使う) と Transparent (受け取らず・数えず通すだけ) の決定的な違いとなります。
なお 1 点、混同しやすい区別を補足します。ここで実証したのは VTP advertisement (VLAN database の定義情報) が transparent な SW3 を越えて SW4 まで届くことであって、VLAN 10 / 20 / 30 のユーザ通信そのものが SW3 を通過することとは別の話です。SW4 が VLAN 10 を「持つ」ことと、VLAN 10 のフレームが SW1〜SW4 間でエンドツーエンドに流れることは、トランクの allowed VLAN や各リンクの状態など別の条件にも左右されます。本節で確認したのはあくまで「定義の伝播」である点に注意してください。
9. 落とし穴・補足
- Revision リセット必須: 別環境の switch を本番ドメインに新規接続する際は、接続前に configuration revision を 0 に戻します。
vtp mode client/vtp mode transparentへの切り替えだけでは revision は確実には 0 に戻りません。確実な手順は VTP ドメイン名を別名へ変更して revision を 0 にリセットし、元のドメイン名へ戻すことです(show vtp statusで 0 を確認してから接続)。これを怠ると、持ち込み機の revision が本番より高かった場合に本番側の VLAN database が一気に上書きされ、運用 VLAN が消える事故になります。VTP 関連で最も有名な事故パターンで、テキストに必ず登場します。 - MD5 mismatch でドメインが事実上分断される: 同一ドメインかどうかは domain 名(および設定時は password)で判定されます。domain 名が違えば advertisement は捨てられます。MD5 digest は advertisement の整合性検証に使われ、digest が一致しない advertisement は取り込まれません(password 不一致などが原因)。SW1 の
show vtp countersでもNumber of config digest errors : 1が観測されており、digest 不一致は実機で日常的に発生します。 - デフォルト VLAN (VLAN 1) が VTP のキャリア: VTP advertisement は VLAN 1 上の制御トラフィックとして流れます(VLAN 1 はデフォルト VLAN であり、任意に設定する「管理 VLAN」とは別概念です)。なお Catalyst では、トランクの allowed VLAN リストから VLAN 1 を外しても、CDP・VTP・DTP・PAgP といった VLAN 1 上の管理トラフィックは送受信が継続します。LACP も allowed VLAN から VLAN 1 を外しても流れ続けますが、これは VLAN 1 の管理トラフィックだからではなく、LACP が EtherType 0x8809 の Slow Protocols を使うリンクローカルの集約制御フレーム (IEEE 802.1AX) で、そもそも特定 VLAN のデータ面に乗らないためです。いずれにせよ、VTP を止めたい場合は allowed VLAN の操作ではなく、
vtp mode transparent/vtp mode offやポート単位の無効化で行います。 - 現代の運用では VTP off / mode transparent が多数: VXLAN/EVPN の普及、構成管理ツール (Ansible / NSO 等) による全機一括 push の一般化、上述の事故リスクが重なり、「VTP に集中管理させる」設計は近年急速に減っています。新規設計では全 switch を
vtp mode transparent(または IOS-XE 17 以降のvtp mode off) にして、VLAN 定義は構成管理側で配るのが事実上の標準です。VTP は仕組みとしては美しいものの、現場では「自動同期の便利さ < 事故リスク + 自動化との衝突」と判断されつつあるプロトコルでもあります。
10. 次節
ここまでで、VLAN database をスイッチ間で自動同期する VTP の動作を 3 モードに分けて実機で確認しました。Server で作った VLAN が Client に瞬時に反映され、Transparent には反映されない一方で、その Transparent を越えた先の Client にはちゃんと中継されることまで実機で追いました。configuration revision の比較が同期判定の中核となり、revision を意識せず物理結線するだけの運用が事故を呼びます。これが VTP の核心です。
しかし、ここまで構築してきた「複数のスイッチを Trunk で相互接続する構成」には別の問題がついて回ります。スイッチを 3 台以上輪状や網状に結ぶと、ブロードキャストフレームが永久に回り続ける L2 ループ が発生します。CAM テーブルが書き換え合戦を起こし、リンクが帯域上限まで埋まり、ネットワーク全体が停止します。続く 2-6 STP と RSTP では、この L2 ループを自動検出・自動切断する Spanning Tree Protocol の仕組みを、再び CML 実機の出力で追っていきましょう。
vlan 10 と打てば、100 台の Client がいても全部に行き渡る。手作業ゼロでね。| モード | VLAN 編集 | advertisement 受信 | 中継 | VLAN DB の同期 |
|---|---|---|---|---|
| Server | 可能(配信元) | する | する | する |
| Client | 不可 | する | する | する |
| Transparent | 自分独自に可能 | 中継のみ(自分では使わない) | する | しない |
vtp mode client や vtp mode transparent に切り替えるだけでは、revision は確実には 0 に戻らないんだ。Cisco が案内する確実な手順は、いったん VTP ドメイン名を別の名前に変えて(この時点で revision が 0 にリセットされる)、元のドメイン名に戻すというもの。リセット後に show vtp status で revision が 0 になったのを確認してから、本番ドメインへ接続する。「revision を気にせず物理結線だけする」運用は、絶対に許しちゃいけないプロトコルなんだ。SW1#show vtp status
VTP Operating Mode : Server
Configuration Revision : 3
MD5 digest : 0xB4 0x79 0x12 0x91 ...Server、revision は 3 だ。VLAN 10 / 20 / 30 を作った一連の変更で 3 まで上がっている。トランク設定そのものは VLAN database の変更じゃないから revision は増やさない、というのも覚えておくといい。MD5 digest は VLAN database のハッシュで、同じ DB を持つスイッチ同士は同じ digest を返すんだ。vtp mode client だけで、VLAN は 1 つも定義していない。それなのに ──SW2#show vtp status
VTP Operating Mode : Client
Configuration Revision : 3
MD5 digest : 0xB4 0x79 0x12 0x91 ...
SW2#show vlan brief
10 USERS active
20 GUESTS active
30 SERVERS activeshow vlan brief には、SW2 で一度も叩いていない VLAN 10 / 20 / 30 が、名前ごと active で並んでいる。これが VTP の本懐だよ。Server 1 台で作れば、ドメイン内の全 Client が同じ VLAN を即座に持つ。スイッチが 100 台あっても追加の手作業はゼロだ。transparent だから、内容は自分の DB に取り込まない。SW3#show vtp status
VTP Operating Mode : Transparent
Configuration Revision : 0
SW3#show vlan brief
99 LOCAL_TRANSPARENT activeshow vlan brief に SW1 の VLAN 10 / 20 / 30 は一切現れず、代わりに SW3 が自前で定義した VLAN 99 だけがいる。ドメインの集中管理に乗らず、自分の VLAN は自分の判断で持つ「独立採算スイッチ」として振る舞っているんだ。SW4#show vtp status
VTP Operating Mode : Client
Configuration Revision : 3
MD5 digest : 0xB4 0x79 0x12 0x91 ...
SW4#show vlan brief
10 USERS active
20 GUESTS active
30 SERVERS activeSW3#show vtp counters
Summary advertisements received : 0
Subset advertisements received : 0
Summary advertisements transmitted : 0vtp mode off)にして、VLAN は構成管理側で配るのが事実上の標準になりつつあるんだ。仕組みとしては美しいけど、現場では「自動同期の便利さ < 事故リスク」と判断されつつあるプロトコル、と覚えておこう。さて、ここまでスイッチを Trunk で相互接続してきたけど、輪っか状につなぐと別の問題が出る。次は 2-6 STP と RSTP で、その「L2 ループ」を自動で断ち切る仕組みを見ていくよ。