I have a fair amount of VTP questions that I’ll leave here. Thank you in advance.
When you issue commands like show vtp devices, VTP appears to use some messages to discover who is available in the VTP domain that appears as **unknown ** in Wireshark. What’s going on here? Can Wireshark not decode them?
Is it possible to have redundant VTP servers? If the primary server in VTPv3 goes down, it loses its VTP primary status so there would temporarily be no server until we fixed the issue.
Where is the VTP password included in the VTP message?
There is an MD5 digest regardless of whether any password is configured or not. If I configure a VTP password, is it included in the calculation of this digest?
I’ve created about 500 VLANs on the VTPv3 server and all it did was send a summary advertisement message
All the other switches have VLANs despite not receiving a subset message. This works normally with VTPv1-2. Is this a CML bug?
Why can’t extended VLANs be pruned, even in VTPv3? These protocols always have some little rule that makes no sense to me.
The code field within the header tells the device what kind of message it is. For VTPv2, you have:
0x01 for summary advertisement
0x02 for subset advertisement
0x03 for an advertisement request
0x04: for a join message, used for pruning
After doing some research, I have been unable to find what code 0x05 is. I believe it is a code that is specific to VTP version 3, which is the version in the specific packet you shared, but I am not sure. What I have found however is that others have similar results in Wireshark whenever they use version 3, and it is likely an issue with the Wireshark version you are using.
In VTP versions 1 and 2, you can configure multiple VTP servers in the network for redundancy but only in a stateless manner (i.e. servers don’t detect the failure of other servers). They can coexist and independently make changes to the VLAN database. If one server fails, the others continue to function normally. Since any switch in server mode can make and propagate changes, redundancy is thus inherently supported in a distributed manner. However, this also introduces the risk of inconsistent VLAN information if multiple servers are configured incorrectly or out of sync.
In VTP version 3, you have the concept of a primary server. Only one server can hold the “primary server” role at any given time, and this server is the only one allowed to make changes to the VLAN database. Other servers can be configured in the VTP domain to operate as secondary servers, which can distribute VLAN information but cannot make changes. In the event of a failure of the primary server, the topology remains stable due to the secondary servers. However, you must manually promote one of the secondary servers to a primary server in order to be able to make any changes to the VLANs.
The VTP password is not explicitly included in the VTP message. Instead, it’s used to generate the MD5 digest that you see in the packet. The MD5 digest is a cryptographic hash of the VTP message and the password. If the password is configured, it will be included in the calculation of this digest. If it is not, the hash is simply applied to the VTP message alone.
Hmm that’s interesting. Even with VTPv3, the VLANs themselves are propagated using subset messages. Could it be that version 3 VTP subset messages are simply not recognized and filtered correctly by Wireshark due to its inability to recognize them? (See your question 1).
The reason extended VLANs cannot be pruned, even in VTPv3, boils down to a combination of historical design choices, backward compatibility, and the technical complexity of managing such a large VLAN range. While it might seem like an odd restriction, it’s rooted in practical considerations about how VTP was developed and the environments in which it is used.
So yes, while it can be a bit frustrating, it’s one of those quirks that arise from the evolution of networking protocols. The good news is that understanding these details can help you navigate the complexities of network management with a bit more clarity—even if some of the rules still seem arbitrary!
Thank you for sharing this. I am in an environment where we are hoping to migrate to VTP version 3. The plan is to initially stand up a new switch as a replacement for a switch that is EOL, and configure it as the Primary VTP3 Server. Then we will work to either replace or reconfigure/upgrade downstream switches to sync with the new switch. Trying to gain some insight into what the scenario is with a mixed environment of VTP version 3 and 2 devices. Will a VTP version 2 switch be able to interact with a version 3 switch in any fashion (whether as a client or operating transparently to forward VTP3 information)? Grateful for any thoughts in this regard.
VTPv2 and VTPv3 can coexist in a mixed environment, but with significant limitations that you must be aware of.
VTPv3 switches can interact with VTPv2 switches for VLANs in the standard range (1–1005) because backward compatibility exists. However, extended VLANs (1006–4094), private VLANs, RSPAN VLANs, and MST configurations synchronized via VTPv3 will not propagate to VTPv2 devices. VTPv2 switches will ignore VTPv3-specific data, operating as “transparent” for any unsupported features. Authentication between the versions is also incompatible, potentially causing synchronization failures.
When migrating, you will unavoidably have a temporary mixed environment (unless you are replacing everything in one go). IN a mixed environment, it’s a good idea to avoid using VPTv3 exclusive features until all switches are upgraded. Ensure identical VTP domain names and passwords across all devices. If temporary coexistence is unavoidable, closely monitor VLAN changes and restrict VLAN IDs to the 1–1005 range during the transition.
These protocols always have some little rule that makes no sense to me.
