During my test, I also found the VTP Client keeps the Vlans that were obtained from the VTP server.
All that information is tied together in the vlan.dat file so indeed - a VTP Client can bring a network down in some situations such as 'higher revision number'.
Best Practice is to delete the vlan.dat file on any new switch being inserted into a production network.
Keep hitting those books, you are bringing up very useful topics into these forums :)
Here is some output from an isolated switch:
S4#sh vtp status
VTP Version : 2
Configuration Revision : 14
Maximum VLANs supported locally : 1005
Number of existing VLANs : 14
VTP Operating Mode : Client
VTP Domain Name : NET34
Trying to create a Vlan:
S4(config)#vlan 33
VTP VLAN configuration not allowed when device is in CLIENT mode.
No other switch connected:
S4#sh int trunk
S4#
Vlans obtained from a VTP Server before rebooting:
S4#sh vlan | e unsup
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Fa0/24
Gi0/1, Gi0/2
4 VLAN0004 active
10 VLAN_10 active
40 VLAN0040 active
45 VLAN0045 active
49 VLAN0049 active
50 VLAN0050 active
59 VLAN0059 active
100 VLAN0100 active
363 VLAN0363 active
BTW, I deleted NVRAM: "startup-config" and "private-config" files and it deleted my original configuration but the Vlan information was kept intact since they are kept in Vlan.dat as I previously stated.
__
Edison.
