One thing that I noticed while studying for the SWITCH exam is that VTP sections always skip a very important note about how VTP can cause a lot of trouble. A lot of folks including me don't use VTP unless we've been told we have to. But the fact still remains it's on our Cisco exams, it has to be explored and that exploration can lead to some of us deploying it. That's why we go and learn about this stuff, to roll it out into production if it makes sense. So from what we all read and experience, choose VTP servers closest to the points of network management, make your VTP clients all the rest and VTP transparent switches for the one-offs. This is more or less how I've done it in the real world also. But a VTP client can actually wipe out everything on your VTP server if it's revision number is higher than your VTP server. It does take a very unique situation, but it's not impossible. I put together a simple lab to illustrate it. Let's take the following..
Here is the east side of the network, and SW1 is acting the core switch and VTP server for your access layer.
SW1(config)#do sh vtp staVTP Version : 2Configuration Revision : 10Maximum VLANs supported locally : 1005Number of existing VLANs : 11VTP Operating Mode : ServerVTP Domain Name : CISCOVTP Pruning Mode : DisabledVTP V2 Mode : EnabledVTP Traps Generation : DisabledMD5 digest : 0×30 0xC8 0xBE 0xD2 0×02 0x4C 0x4B 0xB3
SW1(config)#do sh vlan briVLAN Name Status Ports—- ——————————– ——— ——————————-1 default active F0/1, F0/2, Fa0/3, Fa0/4, Fa0/5, Fa0/6Fa0/23, Fa0/2440 VLAN0040 Fa0/11, Fa0/12, Fa0/13, Fa0/1450 VLAN0050 active60 VLAN0060 Fa0/7, Fa0/8, Fa0/9, Fa0/1070 VLAN0070 Fa0/15, Fa0/16, Fa0/17, Fa0/1880 VLAN0080 Gi0/290 VLAN0090 Fa0/19, Fa0/20, Fa0/21, Fa0/221002 fddi-default act/unsup1003 trcrf-default act/unsup1004 fddinet-default act/unsup1005 trbrf-default act/unsup
An urgent call comes in with a request to replace a downed switch ASAP! As you leave a co-worker mentions there is a switch you can use as the replacement on the shelf in the storage room. You grab the switch, run to the west side of the building to replace it. You didn't check the switch at all, but your buddy said this switch is good to go!
Unknowingly, you grabbed the wrong switch. You grabbed another switch that was put on top of the one you're buddy was talking about.
Because you know all about VTP and you've been told the switch to use is OK, you just go ahead and set the VTP mode to CLIENT.
SW2(config-vlan)#vtp mode client
Your trunks to the core switch of the access layer/VTP server are all plugged up and so you open them up.
SW2(config)#int Gi0/1SW2(config-if)#no shut
SW1, the core switch/VTP server sees the following:
SW1#2d21h: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up2d21h: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up2d21h: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up2d21h: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
As you're walking away, you here a bunch of sighs and comments that the network is slow and you begin hearing people asking each other if they can get their corporate portal, email, google and even youtube and so on.
Slightly nervous, when you get back to the east side, you decide to check out SW1, the core switch/VTP server and you see:
SW1(config)#do sh vlan briVLAN Name Status Ports—- ——————————– ——— ——————————-1 default active F0/1, F0/2, Fa0/3, Fa0/4, Fa0/5, Fa0/6Fa0/19, Fa0/20, Fa0/21, Fa0/22Fa0/23, Fa0/24100 VLAN0100 active101 VLAN0101 active102 VLAN0102 active103 VLAN0103 active104 VLAN0104 active105 VLAN0105 active1002 fddi-default act/unsup1003 trcrf-default act/unsup1004 fddinet-default act/unsup1005 trbrf-default act/unsup
Panic begins to set in immediately as you realize exactly what's happened! You run back over to the west side, console into SW2 and then you know exactly what happened!
SW2(config)#do sh vtp staVTP Version : 2Configuration Revision : 21Maximum VLANs supported locally : 1005Number of existing VLANs : 12VTP Operating Mode : ClientVTP Domain Name : CISCOVTP Pruning Mode : DisabledVTP V2 Mode : EnabledVTP Traps Generation : Disabled
SW2#sh vlan briVLAN Name Status Ports—- ——————————– ——— ——————————-1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4Fa0/23, Fa0/24100 VLAN0100 active101 VLAN0101 Fa0/15, Fa0/16, Fa0/17, Fa0/18102 VLAN0102 Fa0/19, Fa0/20, Fa0/21, Fa0/22103 VLAN0103 Fa0/9, Fa0/10, Fa0/13, Fa0/14104 VLAN0104 Gi0/2105 VLAN0105 active106 VLAN0103 Fa0/5, Fa0/6, Fa0/7, Fa0/81002 fddi-default act/unsup1003 trcrf-default act/unsup1004 fddinet-default act/unsup1005 trbrf-default act/unsup
Now, I'm not making this stuff up! This stuff happens all the time! The rule of thumb is that you should always reset the revision number to 0 on any switch before putting it into production. Whether it's going to be a VTP Server, Client or in Transparent mode, it's best to start fresh. If we follow this best practice we would never end up in the very unintentional situation like above.
Even though it's a switch that may have come from another part of your network, always treat it as a new, rogue and unknown switch. Don't ever assume anything!
So what are the steps you should do to reset the Configuration Revision to 0 and remove all VLANS?
- Be sure that the switch is OFF net and you are consoled in to the CLI.
- Perform a write erase
- Delete the vlan.dat file
- Set the VTP mode to Transparent or change the VTP Domain name
- Personally I'd set it to Transparent mode.
- Reload the switch
- Check the VTP status
- Review the Configuration Revision number
- Review the number of VLANs
- Review the VTP Domain Name
SW2#write eraseErasing the nvram filesystem will remove all configuration files! Continue? [confirm][OK]Erase of nvram: complete00:02:20: %SYS-7-NV_BLOCK_INIT: Initalized the geometry of nvrameleSW2#delete flash:vlan.datDelete filename [vlan.dat]?Delete flash:vlan.dat? [confirm]SW2(config)#vtp mode transparentSetting device to VTP TRANSPARENT mode
SW1#reloadSystem configuration has been modified. Save? [yes/no]: noProceed with reload? [confirm]3d22h: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.
The results:
Switch#sh vtp statusVTP Version : 2Configuration Revision : 0 << Revision # set to 0Maximum VLANs supported locally : 1005Number of existing VLANs : 5 << These are the default VLANSVTP Operating Mode : ServerVTP Domain Name :VTP Pruning Mode : DisabledVTP V2 Mode : DisabledVTP Traps Generation : DisabledMD5 digest : 0×57 0xCD 0×40 0×65 0×63 0×59 0×47 0xBDConfiguration last modified by 0.0.0.0 at 0-0-00 00:00:00Local updater ID is 0.0.0.0 (no valid interface found)
Switch#sh vlan briVLAN Name Status Ports—- ——————————– ——— ——————————-1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4Fa0/5, Fa0/6, Fa0/7, Fa0/8Fa0/9, Fa0/10, Fa0/11, Fa0/12Fa0/13, Fa0/14, Fa0/15, Fa0/16Fa0/17, Fa0/18, Fa0/19, Fa0/20Fa0/21, Fa0/22, Fa0/23, Fa0/24Gi0/1, Gi0/21002 fddi-default act/unsup1003 token-ring-default act/unsup1004 fddinet-default act/unsup1005 trnet-default act/unsup
This may seem like a lot of steps, but it's better than dealing with the results of a simple mistake or misunderstanding which could cripple your network in an instant. If you're network change, outage, swap, etc won't save a life – you should always approach it with thought, caution, pre-steps and a back out plan. Think about the changes you're about to make before you pull the trigger.
Fixing this isn't as difficult as breaking it believe it or not. When the original VLANS are removed, the port configurations are not. Unless you make configuration changes the ports just go into limbo. They won't even show up in the "show vlan brief" output. Once you add the VLANS back to your VTP server and that propagates, you will see the ports assigned to their respective VLANS come back online
References:
Wendell Odom: VTP Clients Updating Servers (Thanks Alexandros Tsourakis via G+)
As always, pointing out anything that you see here that is incorrect or inaccurate is greatly appreciated! Be sure to rate this post to bring useful material to new and browsing readers!
Cheers!
@LBSources
Loading ...
[...] VTP Client Mode – It Can Still Wipe Out Your VTP Server! | Echo .. Reply Packets!!!!! – Detailed blog post on the perils of VTP and why you need to careful. With great power comes risk – excellent summary of entry level information. Now, I’m not making this stuff up! This stuff happens all the time! The rule of thumb is that you should always reset the revision number to 0 on any switch before putting it into production. Whether it’s going to be a VTP Server, Client or in Transparent mode, it’s best to start fresh. If we follow this best practice we would never end up in the very unintentional situation like above. [...]