Introduction to VTP (VLAN Trunking Protocol)

Hi Laz,

Actually i am having one doubt here is that in topology we r using 3 switches and these all are in server mode initially and when configure a domain name over any one of them rest will synchronize themselves but if suppose we use other switches as client( having domain name null) initially rather than server mode then we start do changes on server like domain name, shall they synchronize themselves or not either we have to configure manually initially?

Hello Pradyumna

When a switch is initially turned on, the VTP domain given is NULL. Whenever you have a topology where a switch has NULL as the VTP domain, by default, it will adopt the first domain name it receives from a VTP server on the network.

This is true of all switches, whether they are configured as clients or as servers.

I have just tested this in a lab. I created three switches (SW1, SW2, SW3), and before connecting them with trunks, I configured SW1 as the VTP server, and SW2 and SW3 as VTP clients. I didn’t change any of the domains. I then connected the three switches together with trunks. I changed the domain on SW1 to Cisco and the domain automatically changed on the clients SW2 and SW3 as well.

I hope this has been helpful!


Thanks Laz explanation


I have few questions:

  1. If the switch used to synced the domain name from a vtp domain server, or manually configured a vtp domain name, then it won’t be override by any other switches that’s configured with a different vtp domain name, regardless of how high the revision # is, correct?

  2. Let’s say i configured two VTP domain A and B within the switching network. A is with revision# 10, B is with revision# 20. I have a switch SW that’s synced to A. If I force delete a switch’s vlan.dat and reboot, it will sync with B after the reboot since it has higher revision# correct? I labbed this thing up, it proves this statement, but just want to double confirm.

  3. Still, if i have two VTP domain A and B. The communicate between the different VTP domain should consider as layer 3 now, correct? I did a test. On switch SW1 joined vtp domain A and has vlan 10,20. SW2 joined vtp domian B and has vlan 10,30.If I configure inter vlan 10 on both SW1 and SW2 with IP address & I’m able to ping each other. Since the vlan database won’t sync between different vtp domains, what is the logic behind this scenario? Would you please shed lights on this problem?

  4. Is there any concerns if there’s vlan overlap between different vtp domains?

Thank you very much,

Hello Helen

If a switch has a domain name already configured, that domain name can only be changed manually. The only time a switch will adopt a new domain name is if it is in the “no-management-domain state”, such as is the case when the switch is new, right out of the box, or if a switch is reverted to its default config. Only then will a switch automatically adopt the domain name of the VTP server on the network (if one exists). Revision numbers have no effect on the VTP domain names.

Like I mentioned before, the revision number plays no part in the adoption of a domain name. The switch will adopt the domain name of the first VTP advertisement it receives from a VTP server over a trunk link. It then ignores any additional advertisements with a different domain name, regardless of the revision number. In a sense, the adoption of a VTP domain is “sticky”.
Otherwise, the switch would be able to change VTP domains continuously based on revision numbers. In your experiment, it was just by chance that the switch synced with the VTP server with the higher revision number. Whichever advertisement reaches the switch first, that is what is adopted.

VTP domains should not be confused with broadcast domains or network segments. The implementation of a VTP domain does not necessarily correspond to the creation of multiple subnets. The fact that you are able to ping from one IP address to another has nothing to do with VTP, and has everything to do with how you have configured your network topology.

It is generally best practice to have only a single VTP domain to configure in a particular network segment. Also, it is a good idea to keep VLANs administered by a single VTP server, or at least by multiple VTP servers in the same domain. If you need to implement multiple VTP domains, make sure that each domain is administrating different VLANs. By implementing multiple domains that administrate the same VLANs, you can have unwanted and unpredictable results on particular VLANs, especially if you delete them.

I hope this has been helpful!


Hi There, great explanation.

However surly the topology provided creates a loop, I couldn’t get my switches to advertise the VLAN to each other, all have the same domain name configured, any idea why this did not work ?


Hi Laz,

Would you please elaborate more on the topic in regards to vtp domain should not be confused with broadcast domain(question3)? I don’t think I fully understand the answer.
For my last question “Is there any concerns if vlan overlaps between different vtp domains”. I did a lab to create two vtp domain among three switches. SW3 has a vtp domain name ccnp while the rest 2 switches has a vtp domain name ccie. both vtp domains has vlan 10, and if i delete vlan 10 from SW3, it didn’t affect the vlan on the rest of the switches. What kind of the unpredictable results you think it can happen if different vtp domain are administrating the same vlans?
Thank you very much for your help Laz.

Hello Ziran

The topology does indeed create a loop, however, this is not a problem because the switches run spanning tree protocol (STP) by default, and such looks are dealt with. This of course is a different topic than VTP, but you can find out more about it here:

Now there may be many reasons for your VLANs not being shared between devices. Some of the most common that you should check include:

  1. Verify that the switches are not configured as transparent, because they will ignore VTP updates
  2. Ensure that you have at least one VTP server in the topology
  3. make sure you are using the same domain-name in all devices, otherwise VTP advertisements will not be shared
  4. VTP will only send packets over a trunk link, make sure the links between the switches are trunk links.

Take a look at these and see if they help you in your troubleshooting process… If you have further questions let us know!

I hope this has been helpful!


Hello Helen

The reason I mentioned broadcast domains here is because in your previous post you said:

The communicate between the different VTP domain should consider as layer 3 now, correct?

Unless I misunderstood, you also seemed to indicate that communication between VTP domains would require routing, thus each VTP domain would correspond to a broadcast domain or a network segment.

I may have misunderstood your initial comments, but in any case, the point I was trying to make is that VTP will only communicate between switches at Layer 2, and only via trunks. There are no IP addresses involved with VTP, regardless of whether you are using the same or different VTP domain names, and regardless of the subnets assigned to each VLAN. VTP packets will be sent out of all trunk ports, regardless of the domain being used. VTP is always sent untagged and uses VLAN1 as stated in this post.

The topology you have created will function correctly, and the experiment you did by deleting the VLAN in SW3 resulting in the expected behaviour. Functionally, this will work, however, the question remains, why would you do this? What is the purpose behind having multiple VTP domains administrating the same set of VLANs? As far as I can see, there is no benefit.

The primary problem with this is the complexity of administration this adds, which also increases the potential for mistakes. By doing it this way, you need to make changes to the specific VLAN in both domains separately. Because the primary purpose of VTP is to be able to sync VTP creation deletion and management, introducing two VTP domains to administer the same VLANs simply reverts back to having to apply the same thing multiple times. You can do it, but I can see no reason to do so.

I hope this has been helpful!


Hi Laz,

Thank you very much for the detailed explanation.

I was kinda confused before about the correlation between vtp domain and broadcast domain, since different vtp domain sperates vlan info from each other. For instance, if I have VLAN 10 on two switches, but two switches are in the different vtp domain, then the VLAN 10 on the two switches won’t be considered to be in the same vlan 10 broadcast domain. But what you explained is vtp domain’s job is to sync vlan database inside of the vtp domain, and keep a separate vlan database between different vtp domain. In regards to the data transmission between two different vtp domain, VTP has nothing to do with the data transmission. The layer2 data transfer is based on MAC address, if client 1 in vlan 10 that connects to vtp domain 1 try to talk to client 2 that’s in also in vlan 10 that connects to vtp domain 2. When the frame from client1 transfer through trunk, the switch will still tag the frame as vlan 10 and then send it client2. Am I understand that correctly now?


Hello Helen

Yes, that’s it exactly!

I’m glad it was helpful!


Hi René
Just starting this ccnp course but is the first part all refresh ? It looks to me that vlan, vtp,dtp is ccna material

Hello Marco

The content of the CCNP course includes much of the CCNA material as well. They are included in order to give a review of all the technologies needed to be able to pass the CCNP exam. Remember that all content in the CCNA exam may be found on the CCNP exam as well, so you must be prepared. If you find that you are already OK with those topics, then you can skim over them for review, and focus on the topics you are not as familiar with.

I hope this has been helpful!


Hi Rene and staff.
Thanks for great explanation of every detail.
Lets suppose we have STP network that consists of at least 50 L2 or L3 switch.
My question1: What is real implementation of VPT Transparent mode in production network ?
My question2: Why do we need switch with VTP transparent mode between VTP server and VTP client ?

Hello Fazail

Transparent mode for VTP is useful when you want one or more switches within your network to have an independent and manually configured VLAN configuration. One reason you may want to disable VTP is if you are using private VLANs. VTP versions 1 and 2 don’t support the synchronization of private VLANs so if you’re using v1 or v2, you must put the participating switches into transparent mode. However, VTPv3 does support the synchronization of private VLANs.

Another reason is that v1 or v2 and don’t support extended VLAN IDs (VLAN IDs between 1006 and 4094). Such IDs will not syncrhonize. Again, v3 supports these IDs.

A third reason you would disable VTP could be if one of your switches supports the configuration of fewer VLANs. If for example you configure 400 VLANs in your network, but there is a switch that only supports 256 configured VLANs, any additional VLANs created will not be synchronized with that switch. In such a situation you would configure the switch as transparent and manage its VLANs manually.

You don’t need to have a transparent mode switch between a server and a client, but if you do have one between a server and client, it will forward any VTP messages it receives to other switches connected via trunk ports. More info on this at the following Cisco documentation.

I hope this has been helpful!


I just built a very simple topology with two switches and I wanted to “see” the VTP packets exchange in wiresharck when I add a vlan to the server config, but it seems like all the exchanges are always with revision 0 and no mention of the added vlan although the client receives the update.
Is there a tip I’m missing to see that in wiresharck ?
Thank you in advance

Hello Frederic

As VTP packets are being exchanged, you should see revision numbers increasing, and you should at some point see VLAN information included as additional sections of the VLAN Trunking Protocol section in Wireshark like so:

You can take a look at this example of an exchange of VTP packets for more details:

Now I don’t know why your capture resulting in what you described. How are you capturing, using SPAN or RSPAN? In order to correctly capture control packets like VTP, you must use the encapsulation replicate keywords at the end of the destination port command. You can find out more information at this Cisco documentation:

Let us know how you get on with your troubleshooting, and if you have further questions, you know where to find us!

I hope this has been helpful!


Hi Laz and thanks for answering,

I’m using only 2 switches connected with a single link and SW1 as server, SW2 as client.
What I discovered this morning is that everything looks correct in wiresharck as long as I use VTP version 2 (or 1, I guess), Indeed I can retrieve all the vlans informations BUT as long as I use VTP V3, I only obtain a revision number 0 with no real informations.

I guess this might be a bug due to either GNS3 implementation, or IOS “virtual” images…
Anyway I was able to “see” the packets, so I suppose even in VTPv3, it works the same in “real life”, if someone can confirm that part, it would be helpful.

Thanks a lot.

Hello Frederic

Hmm, that’s interesting. It got me thinking and I went into CML and tried the same thing. I found the VTP version 3 only appears to send summary advertisements with configuration revision number 0 and no VLAN information, just like you said in your case. I created and named various VLANs and found that no such information was contained within the VTP messages.

I’m starting to think that VTP may use other protocols to exchange its information such as CDP? Or STP? I was unable to find any such packets carrying any related information beyond CDP carrying the VTP domain name. So either the information is exchanged outside of VTP packets, or for some reason packet captures don’t capture this info for some reason.

I’ll talk to Rene about this one and see if he has any insights…

I hope this has been helpful!


Hi Laz,
Indeed, that’s weird, I looked at the cdp packets as well as you did…
Let me know if you discover something for my personal knowledge.