Lesson Contents
Most people think that only a VTP server can change the VLAN database in a VTP domain. A VTP client can’t create, change, or delete VLANs, so how could it ever cause any harm?
VTP doesn’t care about the mode of the switch that sends an advertisement. It only looks at the configuration revision number. When a switch receives an advertisement for its own VTP domain with a higher revision number, it replaces its VLAN database with the one it received. This is true for VTP clients and VTP servers.
If you connect a switch with a higher revision number to your network, it can overwrite the VLAN database of every VTP server and VTP client in the domain, even when that switch is a VTP client. Only switches in VTP transparent mode keep their own VLANs. This is sometimes called a “VTP bomb”. In this lesson, I’ll show you how this works.
Configuration
We’ll use three switches, all running IOSvL2 with VTP version 2.
Topology
SW1 and SW2 are our “production” network. SW3 is a switch that someone used in a lab and now wants to add to the network. We’ll configure SW3 on its own first, and connect it later.
Configure the VTP server (SW1)
First, let’s shut the interface that connects to SW3. This way, SW3 isn’t part of the network yet:
SW1(config)#interface GigabitEthernet0/1
SW1(config-if)#shutdown
SW1(config-if)#exitNow we configure the VTP domain, version, and mode, and turn the interface to SW2 into a trunk. VTP advertisements are only sent on trunk links:
SW1(config)#vtp domain NWL
Changing VTP domain name from NULL to NWL
SW1(config)#vtp version 2
SW1(config)#vtp mode server
Device mode already VTP Server for VLANS.
SW1(config)#interface GigabitEthernet0/0
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunkConfigure the VTP client (SW2)
SW2(config)#vtp domain NWL
Domain name already set to NWL.
SW2(config)#vtp version 2
SW2(config)#vtp mode client
Setting device to VTP Client mode for VLANS.
SW2(config)#interface GigabitEthernet0/0
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunkNotice the “Domain name already set to NWL” message. A switch without a VTP domain name takes the domain name from the first VTP advertisement it receives, so SW2 already learned it from SW1. But how, if VTP advertisements are only sent on trunk links? The interface of SW2 uses the default switchport mode dynamic auto. Once we configured SW1 as a trunk, DTP negotiated a trunk between the two switches before we configured anything on SW2.
Create VLANs on the VTP server
Let’s create some VLANs on SW1:
SW1(config)#vlan 10
SW1(config-vlan)#name SALES
SW1(config-vlan)#exit
SW1(config)#vlan 20
SW1(config-vlan)#name ENGINEERING
SW1(config-vlan)#exit
SW1(config)#vlan 30
SW1(config-vlan)#name MANAGEMENT
SW1(config-vlan)#exitLet’s look at the output of show vtp status on SW1:
SW1#show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : NWL
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 5254.00c0.8000
Configuration last modified by 0.0.0.0 at 10-26-26 16:58:13
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 : 4
MD5 digest : 0xE4 0x1D 0xA4 0xA0 0x1C 0x73 0x35 0x3F
0x81 0x25 0x41 0x0D 0xC4 0x1A 0x8E 0x84SW1 has configuration revision 4. Every change to the VLAN database increases the revision number by one. We only created three VLANs, so where does the fourth change come from? The vtp version 2 command also counts as a change. Let’s check SW2:
SW2#show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : NWL
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 5254.0017.8000
Configuration last modified by 0.0.0.0 at 10-26-26 16:58:13
Feature VLAN:
--------------
VTP Operating Mode : Client
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
Configuration Revision : 4
MD5 digest : 0xE4 0x1D 0xA4 0xA0 0x1C 0x73 0x35 0x3F
0x81 0x25 0x41 0x0D 0xC4 0x1A 0x8E 0x84SW2#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active
10 SALES active
20 ENGINEERING active
30 MANAGEMENT active
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsupSW2 has the same revision number (4) and the same MD5 digest, and it learned VLANs 10, 20, and 30. Our production network is in sync.
Prepare the “lab” switch (SW3)
Now let’s configure SW3. Imagine that someone used this switch in a lab with the same VTP domain name. We’ll make it a VTP server, create some VLANs, and configure the trunk:
SW3(config)#vtp domain NWL
Changing VTP domain name from NULL to NWL
SW3(config)#vtp version 2
SW3(config)#vtp mode server
Device mode already VTP Server for VLANS.
SW3(config)#vlan 100
SW3(config-vlan)#name LAB100
SW3(config-vlan)#exit
SW3(config)#vlan 200
SW3(config-vlan)#name LAB200
SW3(config-vlan)#exit
SW3(config)#vlan 300
SW3(config-vlan)#name LAB300
SW3(config-vlan)#exit
SW3(config)#vlan 400
SW3(config-vlan)#name LAB400
SW3(config-vlan)#exit
SW3(config)#vlan 500
SW3(config-vlan)#name LAB500
SW3(config-vlan)#exit
SW3(config)#interface GigabitEthernet0/0
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
SW3(config-if)#exitBefore we connect this switch to the network, we change it to VTP client mode with vtp mode client. Many people think this makes it “safe”:
SW3(config)#vtp mode client
Setting device to VTP Client mode for VLANS.Let’s look at SW3:
SW3#show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : NWL
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 5254.0025.8000
Configuration last modified by 0.0.0.0 at 10-26-26 16:58:28
Feature VLAN:
--------------
VTP Operating Mode : Client
Maximum VLANs supported locally : 1005
Number of existing VLANs : 10
Configuration Revision : 6
MD5 digest : 0xF2 0x1E 0xD5 0x66 0x80 0x33 0x83 0x35
0xFF 0x65 0x1D 0x55 0x94 0x02 0xC4 0x0ESW3#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active
100 LAB100 active
200 LAB200 active
300 LAB300 active
400 LAB400 active
500 LAB500 active
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsupSW3 is a VTP client, but it still has configuration revision 6. Changing the mode from server to client doesn’t reset the revision number. SW3’s revision number is higher than the revision number of our production network (4).
Enable debugging on the VTP server
Before we connect SW3, let’s enable a debug on SW1 so we can see what happens when the VTP advertisement from SW3 arrives:
SW1#debug sw-vlan vtp events
vtp events debugging is onThere are a couple of VTP debug commands. Here is why we use this one:
debug sw-vlan vtp eventsshows each VTP advertisement that the switch receives and sends, the revision number in it, and the result of the revision number comparison. This is exactly what we want to see.debug sw-vlan vtp packetsshows a hex dump of every VTP packet that the switch sends and receives. A single advertisement produces dozens of lines of hex, and it doesn’t show the revision number comparison. You don’t need it for this lab.debug sw-vlan vtp xmitonly shows the advertisements that the switch transmits, so you won’t see the incoming advertisement from SW3.
Connect SW3 to the network
Let’s connect SW3 by running no shutdown on the interface of SW1:
SW1(config)#interface GigabitEthernet0/1
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
SW1(config-if)#no shutdownOnce the trunk is up, SW3 sends its VTP advertisement to SW1. Let’s see what happens.
Verification
Here is the debug output on SW1:
SW1#
VTP LOG RUNTIME: switchport trunk mode on Gi0/1 has changed
VTP LOG RUNTIME: delaying first flood on new trunk
VTP LOG RUNTIME: Transmit vtp summary, domain NWL, rev 4, followers 0, tlv blk size 8 (inc #tlv field),
MD5 digest calculated = E4 1D A4 A0 1C 73 35 3F 81 25 41 0D C4 1A 8E 84
VTP LOG RUNTIME: Summary packet received, domain = NWL, rev = 6, followers = 0, length 80, trunk Gi0/1
VTP LOG RUNTIME: Validate TLVs : #tlvs 1, max blk size 4
VTP LOG RUNTIME: Validate TLVs : #00, val 6, len 4
VTP LOG RUNTIME: Summary packet rev 6 greater than domain NWL rev 4
VTP LOG RUNTIME: Domain NWL currently not in updating state
VTP LOG RUNTIME: Summary packet with followers field zero
VTP LOG RUNTIME: Transmit vtp request, domain NWL, start value 0
VTP LOG RUNTIME: Summary packet received, domain = NWL, rev = 6, followers = 1, length 80, trunk Gi0/1
VTP LOG RUNTIME: Validate TLVs : #tlvs 1, max blk size 4
VTP LOG RUNTIME: Validate TLVs : #00, val 6, len 4
VTP LOG RUNTIME: Summary packet rev 6 greater than domain NWL rev 4
VTP LOG RUNTIME: Domain NWL currently not in updating state
VTP LOG RUNTIME: pdu len 80, #tlvs 1
VTP LOG RUNTIME: Subset packet received, domain = NWL, rev = 6, seq = 1, length = 300
VTP LOG RUNTIME: Transmit vtp summary, domain NWL, rev 6, followers 1, tlv blk size 8 (inc #tlv field),
MD5 digest calculated = F2 1E D5 66 80 33 83 35 FF 65 1D 55 94 02 C4 0E
VTP LOG RUNTIME: Transmit vtp summary, domain NWL, rev 6, followers 1, tlv blk size 8 (inc #tlv field),
MD5 digest calculated = F2 1E D5 66 80 33 83 35 FF 65 1D 55 94 02 C4 0E
VTP LOG RUNTIME: Summary packet received, domain = NWL, rev = 6, followers = 1, length 80, trunk Gi0/0
VTP LOG RUNTIME: Validate TLVs : #tlvs 1, max blk size 4
VTP LOG RUNTIME: Validate TLVs : #00, val 6, len 4
VTP LOG RUNTIME: Summary packet rev 6 equal to domain NWL rev 6
VTP LOG RUNTIME: Subset packet received, domain = NWL, rev = 6, seq = 1, length = 300I removed the timestamps to make it easier to read. Let’s walk through it:
- The trunk on Gi0/1 comes up, and SW1 sends a summary advertisement with its own revision number (4).
- SW1 receives a summary advertisement from SW3 on Gi0/1 with revision 6. The followers field is 0, which means no subset advertisement (with the actual VLAN information) follows.
- SW1 compares the revision numbers: “Summary packet rev 6 greater than domain NWL rev 4”. This is the key line. SW1 doesn’t check whether SW3 is a server or a client, only the revision number.
- SW1 wants the VLAN information, so it sends an advertisement request to SW3 (“Transmit vtp request”). Our VTP server asks a VTP client for its VLAN database!
- SW3 answers with a summary advertisement (followers = 1) and a subset advertisement that contains its VLANs. SW1 accepts it.
- SW1 now has revision 6 and sends a summary advertisement on both trunks with the new MD5 digest.
- SW2 sends an advertisement on Gi0/0 with revision 6. SW1 reports “equal to domain NWL rev 6”, so SW2 has synchronized with the new database as well.
Here are some other messages that you might see with this debug:
Summary packet rev 3 lower than domain NWL rev 14: the advertisement has a lower revision number, so the switch ignores it.Summary packet rev 14 equal to domain NWL rev 14: the revision numbers are the same, so nothing changes.%SW_VLAN-4-VTP_USER_NOTIFICATION: VTP protocol user notification: MD5 digest checksum mismatch on receipt of equal revision summary on trunk: Gi0/1: the revision numbers are the same, but the VLAN databases are different. The switch doesn’t overwrite anything, but your switches are out of sync.
Let’s check the result with some show commands. First, the trunks on SW1 with show interfaces trunk:
SW1#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/0 on 802.1q trunking 1
Gi0/1 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi0/0 1-4094
Gi0/1 1-4094
Port Vlans allowed and active in management domain
Gi0/0 1,100,200,300,400,500
Gi0/1 1,100,200,300,400,500
Port Vlans in spanning tree forwarding state and not pruned
Gi0/0 1
Gi0/1 1VLANs 10, 20, and 30 are gone from the list of active VLANs, and VLANs 100–500 have taken their place. Let’s look at the VTP status of SW1:
SW1#show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : NWL
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 5254.00c0.8000
Configuration last modified by 0.0.0.0 at 10-26-26 16:58:28
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 : 10
Configuration Revision : 6
MD5 digest : 0xF2 0x1E 0xD5 0x66 0x80 0x33 0x83 0x35
0xFF 0x65 0x1D 0x55 0x94 0x02 0xC4 0x0EOur VTP server now has configuration revision 6 and the same MD5 digest as SW3. The “last modified” timestamp is the moment we created the last VLAN on SW3. Here are the VLANs:
SW1#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active
100 LAB100 active
200 LAB200 active
300 LAB300 active
400 LAB400 active
500 LAB500 active
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsupOur VLANs SALES, ENGINEERING, and MANAGEMENT are gone. SW1 accepted the VLAN database of a VTP client. SW1 then advertised this database to SW2:
SW2#show vtp status | include Operating|Revision|modified
Configuration last modified by 0.0.0.0 at 10-26-26 16:58:28
VTP Operating Mode : Client
Configuration Revision : 6SW2#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active
100 LAB100 active
200 LAB200 active
300 LAB300 active
400 LAB400 active
500 LAB500 active
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsupThe entire VTP domain now runs the VLAN database from our lab switch. In a real network, any access interface assigned to VLAN 10, 20, or 30 would now be inactive, and those users would lose connectivity.
Don’t forget to disable the debug when you are done:
SW1#undebug all
All possible debugging has been turned offHow to prevent this
Always reset the configuration revision number to 0 before you connect a switch to a production network. You can do this by changing the VTP mode to transparent with vtp mode transparent:
SW3(config)#vtp mode transparent
Setting device to VTP Transparent mode for VLANS.SW3#show vtp status | include Operating|Revision
VTP Operating Mode : Transparent
Configuration Revision : 0The revision number stays 0 when you change the switch back to VTP client mode:
SW3(config)#vtp mode client
Setting device to VTP Client mode for VLANS.SW3#show vtp status | include Operating|Revision
VTP Operating Mode : Client
Configuration Revision : 0Another method, and the one that Cisco documents, is to change the VTP domain name to something else and back. This also resets the revision number to 0. Once the revision number is 0, you can connect the switch. It will then learn the VLAN database from the network instead of overwriting it.
A switch only accepts an advertisement with a higher revision number when:
- The VTP domain name matches (it’s case-sensitive).
- The VTP password matches (it’s part of the MD5 digest).
- The link between the switches is a trunk.
- The receiving switch is in VTP server or client mode. A switch in transparent mode ignores the VLAN information in the advertisement.
The VTP version doesn’t have to match. The version is part of the advertisement, and a switch that supports both versions adopts the version it receives. In a lab test, a VTP version 1 client with a higher revision number overwrote a VTP version 2 server, and the server changed to version 1.
If you try this in your own lab and nothing happens, check these items first. Also check the revision number on the “new” switch right before you connect it, because any domain name change or a switch to transparent mode resets it to 0. The debug sw-vlan vtp events command is helpful here too: if you don’t see any “Summary packet received” messages, the advertisements aren’t arriving at all.
VTP version 3 largely prevents this problem. Only the primary server can change the VLAN database, so a client or secondary server with a higher revision number can’t overwrite the domain, unless someone promotes that switch to primary server with the vtp primary command.
Conclusion
You have now learned that a VTP client can overwrite the VLAN database of a VTP server:
- VTP switches accept the VLAN database with the highest configuration revision number, regardless of whether the sender is a VTP server or VTP client.
- Changing a switch from server to client mode does not reset the configuration revision number.
- A switch with a higher revision number in the same VTP domain (same domain name and password) overwrites the VLAN database of all VTP servers and clients in the domain. Transparent switches are not affected.
- Use
debug sw-vlan vtp eventsto see the revision number comparison in action. Look for the “greater than” message. - Reset the revision number to 0 with
vtp mode transparent(or by changing the domain name) before you connect a switch to a production network. - VTP version 3 largely prevents this because only the primary server can make changes.
I hope you enjoyed this lesson. If you have any questions, feel free to leave a comment!