When I read this article I tried to make a network scheme on cisco packet tracer and all my connecting between switches was like switchport mode access. I have run debub sw-vlan vtp events command on all switches and change vtp domain on one switch. And nothing to do, but when I have changed one connection link to switchport mode trunk i got debug messages that my vtp domain on the second switch was changed.
In my previous messages I meant that if your connection link belongs to access mode, vtp domain messages didnât spread.
Thanks for the clarification. Indeed, VTP sends VTP messages only over trunk links. Access ports do not send any VTP advertisements or messages. This is simply the way the protocol has been designed. Take a look at this NetworkLessons not on VTP operation over tunks for more information and links.
So if VTP will only work if the switches are in the same domain, wouldnât you say itâs a security best practice to set a random VTP domain name on all of your old switches, the ones that had a VTP configuration in the past? With your new switches out of the box, the domain is NULL anyway, so (please correct me if Iâm wrong) they wonât synchronize with each other, even if some are Servers and others are Clients.
The issue Iâd have with just setting them in the Transparent mode is if you accidentally leave a switch as Server and another as Client, and all of your switches are in the same VTP domain, then the Transparent switches will relay the VLAN information. But if they all had gibberish VTP domain names, then their states wouldnât matter. So at least youâd have 2 fallback options: if you accidentally forget one (changing the VTP mode or the VTP domain), youâre still good if you havenât forgotten the other. So if your design is to set all switches to Transparent and set a gibberish domain name, and you forget to do one but not the other, this VTP issue canât happen.
Thatâs because
(A) any switch is likely to either have the same domain as (maybe some of) the other switches but be Transparent;
(B) or be Client or Server but have some gibberish domain;
(C) or be Transparent and have a gibberish domain. In either case, VTP canât cause any issues.
It might be a good idea to set the VTP domain to some gibberish with your new switches as well, even though they are all in the NULL domain out of the box, because if you donât do things consistently, then thereâs bound to be a case where you mix up the rule with the exception, and make a mistake. In this case, if you get in the habit of not changing the domain for factory new switches, and you get to work on an old switch, then (due to fatigue or a brief lapse of attention, all of which are normal) you may forget to change the old switchâs VTP domain as well. (Of course, this can happen in general even without having to keep track of exceptions, but with more exceptions, the chances are greater.) Do that to a second switch, and youâve got yourself a bad day (assuming both switches were put in the same domain some time ago, which obviously can happen based on this article).
Wouldnât this design choice result in a network thatâs less prone to issues in case of human error?
Actually, with a switch right out of the box, the domain name is indeed NULL. However, if you donât change anything on the switch, it will adopt the domain name of the first VTP message it receives. So right out of the box, VTP is not in a very secure state.
Yes this is indeed true, and by setting up a random VTP domain with a password on each switch, you can ensure that VTP messages will not be relayed. In my opinion, this solution is a little bit over the top. What I mean is, the administrative overhead needed for the solution is a bigger problem than the issue it resolves. Simply setting all switches to transparent as a best practice should be more than enough to ensure that youâre âsafeâ from the possible problems introduced. For me, Iâd be more prone to make a mistake trying to ensure each switch has a different VTP domain rather than simply setting everything up as transparent.
Your approach is not incorrect, and if it works for you, go for it. The other option that Iâd like to point out is that VTP version 3 has the ability to disable VTP completely using the vtp mode off command. This command essentially is the same as the transparent mode, but the switch doesnât forward VTP messages. For me, if VTP version 3 is available, this is the best option.
Iâve got a couple of questions, can someone help me out please?
Even if using VTP doesnât lead to any issues, is there a point to using it? All it does is save some effort by creating the VLANs, but that doesnât sound like such a win if we consider that you have to log in to each switch anyway to add the switchports to their needed VLANs. So not a lot of manual labor (therefore, manual errors) is saved by VTP, and in exchange, it can easily bring the network down. Doesnât sound like a good tradeoff to me, but I might be missing something.
The article promises that VTP wonât causes any issues if you configure the following on the intended VTP Server:
CoreSwitch(config)# vtp domain firewall.cx
CoreSwitch(config)# vtp password fedmag secret
CoreSwitch(config)# vtp mode server
CoreSwitch(config)# vtp version 2
CoreSwitch(config)# vtp pruning
However, I donât understand why any of these would avoid the issue caused by introducing a new switch with a higher revision number into the network.
The only solution I could think of was to add and remove the same VLAN a couple thousand(!) times on the intended VTP Server. Since itâs pretty unlikely that anyone would accidentally modify the VLANs thousands of times, itâs a safe (but not certain) bet that the intended Server would have the highest revision number.
All Iâd do is copypaste around 3000 lines of the following commands into the Server:
CoreSwitch(config)# vlan 111
CoreSwitch(config-vlan)# exit
CoreSwitch(config)# no vlan 111
A couple of things to note:
Iâd do this to a switch while itâs not connected to the network and Iâm connected to it via a console cable.
Thereâs no need for this with VTP 3 if you set up a primary server.
Iâve chosen that VLAN number randomly. The important thing would be to make sure that itâs a VLAN that doesnât actually exist.
Creating thousands of copies of these three commands in Notepad++ took me around 5 seconds. (Notepad++ is good because it shows the number of lines.) All I did was copypaste them into a new tab a couple of times, then select them all with Ctrl+A, then I pressed Ctrl+C, then Ctrl+V, and Iâve repeated these three commands in this order a couple of times to get around 3000 lines.
All Iâd do then is select all 3000 and paste them into the Server.
Iâd rather not use VTP at all, but with versions 1 and 2, I couldnât think of a better way to decrease the likelihood of an issue. Even so, Iâm not a huge fan of this solution, but is there a better way to decrease the chance of someone wiping out all VLANs by accident, if using VTP version 1 or 2 is mandatory?
Wouldnât that ensure a high enough revision number?
What happens when the highest revision number is reached?
I found only one post about this question here:
Iâd be very happy to read a response.
Thank you for reading my long comment.
Attila
I am the administrator of a municipal network of over 2500 end devices and over 70 switches in 14 buildings throughout the city in which I live. We have close to 400 VLANs, and VTP has saved me a lot of time. This is true because the network is changing all the time. I have to add and remove VLANs relatively frequently, and VTP ensures that all 70 switches are synchronized, and pruning takes place automatically. Yes, you have to configure each individual access port separately, but every time you add or remove a VLAN you donât have to add or remove it from each and every switch. Eventually, I would lose track of which switch should have which VLAN configured.
The key here is the password and the domain. If all of your switches in your existing network are configured with this password and this domain, then even if you introduce a new switch with a higher revision number, it will not affect any of the existing switches. The existing switches will only be affected if the password and domain are the same. Otherwise, they will ignore any VTP messages. For this reason, it is of utmost importance to modify the password and domain from the default and to keep those credentials safe and private. Although your solution of increasing the revision number is inventive and would work, it is unnecessary.
The Cisco Community link you shared is incorrect in that VTPv1 and VTPv2 use a 12-bit value for the revision number, giving a maximum of 4096. For all VTP versions, the version number is 32 bits giving up to 4.2 billion values. This is detailed here:
Practically speaking, you would never NEVER reach this number. If you make a change to your VLANs every second, resulting in the revision number being incremented every second, it would take over 1300 years to reach the maximum value of the revision number. So this is a practical impossibility unless there is some corruption in your VTP messages.
Hi, Rene,
You write in really good explaination!
But I got a question: you said a vtp server is also a vtp client, if I make a change on the vtp client, the lastest information will be sent to all other switches, right? I wanna ask you if this vtp client has already became a vtp server at the moment? I just have a bit of confused of the transform between vtp client and vtp server.
Thanks you for answering my question!
Based on my understanding, if I make a change on the vtp client (vtp server: adds/deletes/modifies information), this vtp client will become a vtp sever.
A quick question. Why does DTP refuse to negotiate a trunk between two switches if they are in different VTP domains? Why did they design it like this?
If you try to make a change to a VTP client, such as adding a VLAN, it wonât let you make the change. Youâll get an error message like this:
%VTP VLAN configuration not allowed when device is in CLIENT mode.
In order to be allowed to make changes to VLANs from a switch, that switch must be manually configured as a VTP server. For VTPv3, itâs not enough to simply be a VTP server. Only the primary VTP server can make changes to VLANs.
DTP refuses to negotiate a trunk between two switches in different VTP domains as a safety measure to prevent any unwanted updates or changes to the VLAN database.
Remember, VTP messages are sent over trunks. By preventing the automatic negotiation of a trunk between two such switches, it provides one more layer of protection against the accidental propagation of VLAN information via VTP. If two switches in different VTP domains were allowed to form a trunk, then changes in one VTP domain could potentially propagate across the trunk and affect the VLAN configuration in the other VTP domain. This could lead to network inconsistencies and disruptions.
So, to prevent this, DTP does not allow trunk negotiation between switches in different VTP domains. This design ensures the integrity and stability of VLAN configurations within their respective VTP domains.
I created a small test configuration. Where I have two switches, trunked with the native vlan of 99. In addition, I disallowed vlan 1 across the trunk.
However, when monitoring the traffic across the trunk. I noticed the VTP traffic being tagged as Vlan 1.
So whatâs the point of changing the native vlan, when you still have traffic being tagged as Vlan 1 going across the trunk?
The point of changing the native VLAN has to do with protection against attacks on the data plane. This mitigates against VLAN hopping attacks, switch spoofing, double tagging, man-in the middle attacks, VLAN leaking and others. All of these occur on the data plane.
If you want to protect control frames that use VLAN 1, there are other options including the isolation of VLAN 1 (i.e. donât use it anywhere else), as well as Control Plane Policing (CoPP), and VACLs. Some protocols, such as CDP and STP have their own security features that you can enable to ensure they are not compromised.
Configuring a trunk link between the switches is necessary for VTP messages to be forwarded over the link. If you do not configure a link as a trunk, VTP advertisements will not be forwarded over it which makes sense because the purpose of VTP is to synchronize the VLAN database. If the link was not a trunk, those synchronized VLANs would never be able to communicate.
(SW1 and SW2 have been configured for VTP). The link is an access link. Letâs create some VLANs on SW2
Since the link is not a trunk, VTP advertisements wonât be carried over it and SW1 will not synchronize its database with SW2.
Hi rene, youâre the best, please, i havd follow the step but VTP can not adverstise vlan created to client, i have configure links between switchs on trunk. After creating vlan on vtp server the vtp client revision number does not update it is always on 0, help
Could you provide us with your topology and configuration? Also please verify whether you have configured A VTP domain as that is one the things that people often tend to forget.
Great to hear that you resolved your issue! Indeed, the VTP domain must be the same across all participating switches. Take a look at this NetworkLessons note providing a VTP configuration checklist that has all of the prerequisites for the sharing of VTP information across multiple switches.
