VTP question (client destroying your network by having higher rev number)
Vask3n
Member Posts: 517
in CCNA & CCENT
I have a question about the classic example given where a newly-introduced switch with a higher revision number blows away the existing config on a network by propagating its VLAN table across the domain.
My question is, won't this only work if the newly-introduced client is on the same domain as the rest of the devices running VTP? Also, how is it possible for this switch, which is in client mode, to propagate its changes to the rest of the network even in its client state?
I understand that a client will forward VTP advertisements received from a server to the rest of the network if the revision number is higher, but if the update did not COME FROM a server (the update originates from a client with a higher revision number), how does the client send this update since it is not a server?
Here is my source with an excerpt:
http://www.cisco.com/image/gif/paws/98155/tshoot-vlan.pdf
The configuration revision number of the switch that you inserted was higher than the configuration revision
number of the VTP domain. Therefore, your recently introduced switch, with almost no configured VLANs,
erased all VLANs through the VTP domain.
This occurs whether the switch is a VTP client or a VTP server. A VTP client can erase VLAN information
on a VTP server. You can tell that this has occurred when many of the ports in your network go into inactive
state but continue to be assigned to a nonexistent VLAN.
My question is, won't this only work if the newly-introduced client is on the same domain as the rest of the devices running VTP? Also, how is it possible for this switch, which is in client mode, to propagate its changes to the rest of the network even in its client state?
I understand that a client will forward VTP advertisements received from a server to the rest of the network if the revision number is higher, but if the update did not COME FROM a server (the update originates from a client with a higher revision number), how does the client send this update since it is not a server?
Here is my source with an excerpt:
http://www.cisco.com/image/gif/paws/98155/tshoot-vlan.pdf
The configuration revision number of the switch that you inserted was higher than the configuration revision
number of the VTP domain. Therefore, your recently introduced switch, with almost no configured VLANs,
erased all VLANs through the VTP domain.
This occurs whether the switch is a VTP client or a VTP server. A VTP client can erase VLAN information
on a VTP server. You can tell that this has occurred when many of the ports in your network go into inactive
state but continue to be assigned to a nonexistent VLAN.
Working on MS-ISA at Western Governor's University
Comments
-
JeanM Member Posts: 1,117IIRC, default vtp mode is server. It can wipe out vtp if it's rev is higher and vtp domain / pass isn't set. So, my understanding is either to wipe the vlan.dat before adding a switch and/or set the mode to client and/or transparent and also set the domain2015 goals - ccna voice / vmware vcp.
-
Vask3n Member Posts: 517Hi Jean,
Thanks for this. Unfortunately what confuses me was that the example states that the vtp mode is CLIENT, not server (yes, server is the default mode)
Specifically this line from the bottom: A VTP client can erase VLAN information
on a VTP server.Working on MS-ISA at Western Governor's University -
networker050184 Mod Posts: 11,962 ModWhen you hook up a client with a higher revision number it will send a summary advertisement. The server (or another client) will see this advertisement and send an advertisement request to the client to synch it's database. The summary advertisements are sent by all switches, not just servers.An expert is a man who has made all the mistakes which can be made.
-
instant000 Member Posts: 1,745Here, Wendell Odom presents a 3-switch lab that you could use to replicate the issue for yourself.
VTP Lab Experiment
Hope this helps.Currently Working: CCIE R&S
LinkedIn: http://www.linkedin.com/in/lewislampkin (Please connect: Just say you're from TechExams.Net!) -
shabeerm Member Posts: 29 ■□□□□□□□□□As a best practice, a new switch should be configured as a VTP client in the VTP domain, and have its configuration revision number must set back to zero before being installed into a production network,Because VTP has a huge security risk…the problem with VTP is that a VTP server is also a VTP Client and a VTP client can overwrite a VTP server if the revision number is higher
REMEMBER: A VTP client can update other clients and VTP servers in the VTP domain, if its revision number is higher.
You can reset revision number by
• Changing the domain-name will reset the revision number.
• Deleting the vlan.dat file on your flash memory will reset the revision number
Hope this helpsFor CCNA / CCNP notes visit my blog http://sysnetnotes.blogspot.in/ -
Vask3n Member Posts: 517the problem with VTP is that a VTP server is also a VTP Client and a VTP client can overwrite a VTP server if the revision number is higher
I think this is the part that is key to understanding the problem. So the server can act as a client in terms of receiving an update from another client after it is propagated from the client, so long as they are both in the same domain and the revision number on the client sending the update to the server is higher than the revision number on the server.Working on MS-ISA at Western Governor's University -
Sounds Good Member Posts: 403As a best practice, a new switch should be configured as a VTP client in the VTP domain, and have its configuration revision number must set back to zero before being installed into a production network,Because VTP has a huge security risk…the problem with VTP is that a VTP server is also a VTP Client and a VTP client can overwrite a VTP server if the revision number is higher
REMEMBER: A VTP client can update other clients and VTP servers in the VTP domain, if its revision number is higher.
You can reset revision number by
• Changing the domain-name will reset the revision number.
• Deleting the vlan.dat file on your flash memory will reset the revision number
Hope this helps
One more way to reset revision is to change vtp mode to transparent and changing it back to client.On the plate: AWS Solutions Architect - Professional
Scheduled for: Unscheduled
Studying with: Linux Academy, aws docs -
Vask3n Member Posts: 517These are all excellent responses, thank you everyone.
Just to follow up on this and sort of regurgitate this info back-
We can reset our config# to 0 by either deleting vlan.dat, changing the domain name, or by changing to transparent then changing back to client.
Now let's say we do all of these changes to the CLIENT like mentioned. The client has the lowest revision number now in the domain and the next time it gets an update (from EITHER a server or a client propagating the update from a server) it will assume the most recent config by virtue of updating its number and then being on the same config number as the rest.
Now, let's say we delete vlan.dat or change the domain name on the SERVER side, what would happen? If we delete vlan.dat the server should assume revision 0 and in this case would it just update itself after receiving a higher revision from a client after coming back up? It would not destroy your network since it is not coming up with a higher revision number, only a lower one.Working on MS-ISA at Western Governor's University -
networker050184 Mod Posts: 11,962 ModSame thing happens whether it is a client or server. The only difference is you can administratively create VLANs on a server and not a client.An expert is a man who has made all the mistakes which can be made.