Hello Frederic
I spoke with @ReneMolenaar and he has confirmed the same thing I did. It looks like it is an issue with the IOSvL2 image or CML and GNS3. If you can get your hands on real equipment, I suggest you try to do a capture using SPAN. If you do that I’m sure you will see the detailed VTP info…
I hope this has been helpful!
Laz
Hi Laz,
So things are getting worse and worse !!!
I tried with my 2 physical 3750 switches (SW_100 and SW_200) directly connected through trunk port fa1/0/43 native vlan 1 and no other connections
On SW_100 I enable monitoring of traffic from and to port 43 by redirecting it on port 42 :
monitor session 1 source interface Fa1/0/43 both
monitor session 1 destination interface Fa1/0/42
I plug my PC on port 42
I check my monitoring with a ping from SW_100 to SW_200 and I can see my ICMP packets in my wiresharck capture
I configure SW_100 as VTP server V2 and SW_200 as VTP client V2
I change some vlans configuration on vtp server
Everything is reported on the vtp client but I can see nothing regarding vtp in the capture
Do you have any advice ?
EDIT : I just discovered that I should put “encapsulation replicate” in the destination command of the monitoring configuration (since the link between the switches is a trunk) => I can see vtp packets but only for version 2. I’m still not able to see packets for VTP v3…very strange !!!
Hello Frederic
Yes, encapsulation replicate is indeed needed in order to capture these packets and any control packets. I would have expected that with this command, you should see VTP version 3 packets being exchanged. So do you see only VTP packets with revision zero and no other information or do you see no VTP version 3 packets at all?
Laz
Laz,
I can see just one packet with revision number 0.
I took a screenshot for that.
Regards
Hello Frederic
That is indeed strange. When I get the chance over the next few days I will also attempt to take a look and let you know my results as well… It would be interesting to dig deeper into this one… 
Laz
Hi Frederic
One thing you can do in the meantime is try to use some debug commands to view what is happening with VTPv3. For example:
SW#debug sw-vlan vtp packets
You should see the relevant information about the VLANs being updated and exchanged there.
I hope this has been helpful!
Laz
Hello Frederic
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.
Compare this with a VTPv2 capture which can be parsed:
https://www.cloudshark.org/captures/def183e23b76
I hope this has been helpful!
Laz
Hi Laz,
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 !!
Regards
Hi Rene.
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)
Regards,
Robert
Hello Robert
Glad to hear that you liked the lesson and that it was helpful. Also, thanks for the feedback about additional information that can be useful for the lesson, I’ll pass that on to @ReneMolenaar .
Thanks again!
Laz
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 ??
Hello Narad
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.
I hope this has been helpful!
Laz
@lagapides Thanks Sir for your response …Really your way of explanation is awesome…!! Keep inspiring us…!
im using packet tracer and i did the same commands but it’s not doing sync with between sw2 and sw3 and sw1 i even did domain name and even did the command to make sure it might be the problem
the error i got native vlan mismatch domain names are correct what can be the issue ?
Hello Abdul
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:
I hope this has been helpful!
Laz
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 ?
Hello Abdul
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.
I hope this has been helpful!
Laz
Hi Rene,
Thanks for your clear course.
What is the maximum revision number of VTP protocol? There should be a maximum limit. What will happen when this limit will be reached?
Another question What will happen if a vtp server reload? It is version will start from zero? And it will be synchronized from other vtp clients?
Many thanks
Nicolas
Hello Nicolas
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:
I hope this has been helpful!
Laz
Extremely clear ! Thanks a lot!!!