VTP Version 3

Hello, everyone.

I have a fair amount of VTP questions that I’ll leave here. Thank you in advance.

  1. 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?
    obrázok

  2. 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.

  3. 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?

  4. 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?

  5. Why can’t extended VLANs be pruned, even in VTPv3? :smiley: These protocols always have some little rule that makes no sense to me.

That’s all, thanks guys :slight_smile:

David

Hello David

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! :smile:

I hope this has been helpful!

Laz

Thank you yet again Laz!

1 Like