Rene did some work on this and it seems that Wireshark is unable to parse VTPv3 information. This could be due to the fact that the protocol itself is proprietary. In any case, you can see the VLAN information for VTPv2 but not for VTPv3. The interesting thing however is you can see some of the VLAN information in the packet contents. The following is a link to a VTPv3 message that Rene captured on real devices (3850 switches) using SPAN: https://www.cloudshark.org/captures/31c5016ea6e5
It’s the same results as you with a revision number of 0, but if you scroll down in the packet contents on the right pane, you can see the names of three VLANs: DESKTOPS, SERVERS, MANAGEMENT as seen here:
So the information is there, but Wireshark doesn’t process it in such a way as to display it on the left pane.
Indeed, I reproduced the same thing this morning.
I can’t figure out where the revision number is stored but as there’s a MD5 digest, I guess this is encrypted somewhere, but it’s not really important for my understanding.
The V2 was more “understandable and readable” through wiresharck but the important thing is to be aware of what’s going on!!
Thanks to the both of you for your research, I’m also glad having pointed that out and understood that !!
This was a very good lesson! Maybe it’s good to mention in the lesson more about VLAN pruning. VTP pruning does not prune traffic from VLANs that are pruning-ineligible. VLAN 1 and VLANs 1002 to 1005 are always pruning-ineligible; traffic from these VLANs cannot be pruned. Extended-range VLANs (VLAN IDs higher than 1005) are also pruning-ineligible.
Also if you turn off pruning globally on the switch with: set vtp pruning enable, it cannot prune VLAN IDs higher than 1005
And what about the passwords? It’s good to set a password. And with VTP version 3 you can set the password secret. (so it’s not in plain text)
Q-1=What is the best way to bring a new switch as VTP client into the network where already we have our VTP server running .???
Q-2=Lets say we have 4 Switches, out of these 4 , 2 of them are server and both are configured the different domain name ,So we have 2 client , lets say 1 client switch is using the domain 1 and when i bring other switch into the network ,that switch is configured as the client . but which domain name it will accept to join ??..Domain 1 or domain 2 and how will it decide ??.
Q-3=Lets i have my vtp server and client in production and lets say i brought a new switch into the network and my goal is to make that switch as vtp client .So what should be rule of thumbs to attach that switch in the network so that there will be no impact my production and also that switch will sync itself with existing server ??
The most important thing to keep in mind is, before connecting the new switch to the network, configure it as transparent. If you do so, then you have no possibility of accidentally reconfiguring all of the VLANs of your network. Once that’s done, you can safely connect the switch. You can then configure the switch with the appropriate VTP configuration based on what you need.
By initially changing the mode to transparent, any revision number that may have existed on the switch is reset to 0, so you are sure that there is no way that you can have a larger revision number on the new switch you are adding.
In such a case, the new switch will receive the domain name of the first VTP server that is able to respond. Both servers will respond, but whichever VTP update reaches the new switch first, that’s the domain name that will be assigned.
As mentioned before, begin with transparent mode. Connect the switch, and then manually configure the mode, domain, and password. The switch should sync up with the VLAN information from the VTP server without impacting the network.
First of all, you mention that you have a native VLAN mismatch error. That is an error that you should correct by ensuring that the configured native VLAN on both ends of the link is the same. Now having said that, I tried to lab this up in Packet Tracer to replicate your results. I also included a VLAN mismatch on the trunk. I found that switches were able to synchronize their VLANs successfully. The VLAN mismatch will not hinder the operation of VTP. This makes sense because VTP uses VLAN 1 and not the native VLAN for communication (even if VLAN 1 is not allowed on a trunk, it makes an exception).
In order to ensure that VTP will function, you must:
Make sure the correct switches are configured as servers and client
Make sure that the domain is the same
Make sure that the VTP version being used is the same
Make sure that the password being used is correct on all devices
hi i am doing this same lab from 3 days now i came to solution . interfaces were set to auto negotiation mode
i set it to switchport mode trunk and thigs got better now switches are syncing with each other .
One thing is i connected one more new transparent switch with the SW2 hoping that it 2 transparent switches will share and exchange info but . transparent mode don’t update its data base . it will forward it .
Just i want to know that in the real world where we use transparent mode ?
Thanks for sharing your solution. Yes, VTP will only share VLAN information across trunks. If the connected ports were set to auto-negotiation mode, then they would default to access ports, and thus VTP would not sync across such connections.
Switches in transparent mode will always forward VTP messages but will never update their databases to the information found within them. This is why you don’t see any changes taking place in the VLAN database of these switches.
Transparent mode is used in real-world scenarios. Most often, if you simply don’t want VTP to function at all, and you want to administrate the VLANs of your network manually, you would essentially disable any VTP operation by making all your switches transparent.
In other scenarios, you may be adding a switch to a network that uses VTP, but the switch is only serving a single VLAN. There is no reason to have that switch be informed of dozens or even hundreds of VLANs on your network when you won’t be using them.
In addition, some switches can only handle a specific number of VLANs. I’ve had a situation where I had a 2960 switch that could only support up to 64 configured VLANs but we had 80 VLANs being shared on the network using VTP. This switch couldn’t learn any new VLANs configured, so we made it transparent, and configured it manually only with the necessary local VLANs needed.
The VTP revision number is a 32-bit field within the VTP header. That allows for over 4.2 billion revisions. Because the VTP revision number always starts at 0 and is always incremented by 1, it will rarely reach this limit within the lifetime of a particular network. There is no way to set the revision number to a particular value, say close to the upper limit, so in order to reach the maximum, it must be reached with legitimate changes to the network.
Now having said that, of course, there is the possibility of a network reaching that maximum value, either due to a malfunction of the VTP protocol, or an attack where VTP packets are spoofed with false revision numbers. Although I have not found any proof to support this, my suspicion is that the timestamp field found within the VTP header is also used to allow the revision number value to “roll over” from 4.2 billion to 0 and to continue.
By using the timestamp, a revision number of 4,294,967,296 and a timestamp of, say, 10/10/2020 14:57:00 will be a smaller revision number than 0 with a timestamp of 10/10/2020 15:00:00 simply because the timestamp is later.
Such a situation is extremely rare, and this is why I believe that there is no information (at least that I can find) about what happens when this maximum is reached. However, the timestamp resolves any such issues.
As for your second question, if a VTP server is reset, it will indeed reset the VTP revision number. This means that any changes to the VLANs made on that server will send VTP updates to VTP clients, but those clients will ignore these updates since their own revision numbers are larger. For this reason, it is a good idea to:
Have more than one VTP server on a network so that if a VTP server is reset, it will receive VTP updates from the other VTP server and receive the correct VTP revision number.
If there is no second VTP server, then reset the revision number of all clients to zero so that any new VTP messages from the server will not be ignored.
I understand your concern about this. However, on all of Cisco’s exam pages, it says the following:
The following topics are general guidelines for the content likely to be included on the exam. However, other related topics may also appear on any specific delivery of the exam.
VTP is definitely considered a related topic to many switching topics, so it’s always a good idea to have included it in your studying. Beyond any certifications, learning about VTP is helpful since you may need to implement it at some point as well.
Initially, a switch will have the following default parameters for VTP:
VTP operating mode: Server
VTP Domain Name: Null
In such a case, VTP is active, but switches will not actively create any VTP associations with any other switches simply because the domain has not been configured. When all switches have a domain of NULL, it is as if VTP is not functioning.
However, this can still be a dangerous situation, because if a rogue switch is added which has a VTP domain configured, it will start to send VTP messages, and any switch on the network that still has a NULL domain, will automatically adopt that domain as well.
You can’t disable VTP as a feature, but you can ensure that a switch never participates in any VTP domain that may appear on the network by simply changing the VTP mode to transparent like so:
Switch(config)#vtp mode transparent
This ensures that any VTP messages received will be ignored.
I’m configuring VTP pruning, as this topology
R5 and R6 connect to access port of vlan 100 on sw2 and sw4. I enable vtp pruning on sw1.
When I ping from R5 to an IP address, ex 10.1.2.100 to generate ARP packets, sw1 still forwards ARP traffic to sw3 , although sw3 does not have any accessport in vlan 100.
Pls help to explain. Tks you.