VTP - Whats the point?

mattrgee

Hi all,

I've been looking at VTP these last couple of days and beginning to question why it would be used.

Let say I have 50 switches and I create a new vlan (10) on the VTP server and call it Sales, this vlan is then sent down to all the VTP client switches. So all the VTP clients now know about vlan 10 Sales.

Why do they need to know? Is it likely that a port in each of the 50 switches will be added to Sales Vlan? Is that why? Am I right in saying that a switch only need to know about vlans for which it has ports as part of that vlan?

Thanks.

jovan88

its so you don't have to go on every single switch and add the VLANS to it, you just have to add it to one switch which is in Server mode.

if some of the switches don't have ports to some of the VLANs, that's what VTP pruning is for

kryolla

mattrgee wrote:

Hi all,

Am I right in saying that a switch only need to know about vlans for which it has ports as part of that vlan?

Thanks.

Spanning tree is per vlan so if a switch is trunking and it doesn't have the vlan configured it will not be able to pass that traffic onto the other switches

VTP is mostly admin stuff you still have to go to that switch and include the ports you want you might as well create the vlan. There is also security concerns with the revision number. The only reason I can see if VTP is helpful is during the initial config of the switch put it in transparent mode to reset the rev number then put it in client mode to get the intial vlans then set it back to transparent.

nel

Everything has a point otherwise it wouldntbe created.

Basically its like others have said - to ease administration. but the way i see it is if yu have to add the ports to the vlan anyway you mayswell create the vlan. This was you dont have the security and potential disaster risks that vtp imposes if not configured correctly.

mattrgee

Thanks guys, I guess in the bigger picture it becomes more useful...

Plazma

VTP is useful when implemented correctly, but due to how STP works, it's very dangerous especially in production.. so more often than not the benefit doesn't outweigh the risk.

itdaddy

VTP is more for security. if you have a domain and server/client setup with the vtp
The client that is joined to domain (cisco) and password can join a set of switches...I have heard of employees adding their own switches on to a network and screwing up switches not setup
for Server/client VTP setup...right...it is more for security and keeping other switches away from the configs on the switches(in ram).. and alittle ease of making vlans but to me it is more for security...."to prevent rogue switches from chainging anything..".

itdaddy

Plazma

can yu please elaborate on what you said....vtp is good as long as you keep track of things
but can you explain why it might be bad ? to me it keeps out the rogue switches but
can you explain your point. I do understand there is textbook and then there is shoot from the hip type configurations. thanks

Stotic

If a switch is added to the network accidentally or maliciously as a vtp server with a higher revision number, it can wipe out all of your vlans in your vtp domain.

networker050184

Stotic wrote:

If a switch is added to the network accidentally or maliciously as a vtp server with a higher revision number, it can wipe out all of your vlans in your vtp domain.

Just keep in mind that it doesn't matter whether the switch is a client or a server, the higher revision number will wipe out your vlans.

Plazma

networker050184 wrote:

Stotic wrote:

If a switch is added to the network accidentally or maliciously as a vtp server with a higher revision number, it can wipe out all of your vlans in your vtp domain.

Just keep in mind that it doesn't matter whether the switch is a client or a server, the higher revision number will wipe out your vlans.

Exactly.. thats why you don't see it used much in production... it's easy to forget that when you deploy new hardware or.. "reconditioned" hardware.

I think the only way to remedy this is to set your new switch to VTP Transparent mode so that way all configurations stay local.

Igloodude

Plazma wrote:

networker050184 wrote:

Stotic wrote:

If a switch is added to the network accidentally or maliciously as a vtp server with a higher revision number, it can wipe out all of your vlans in your vtp domain.

Just keep in mind that it doesn't matter whether the switch is a client or a server, the higher revision number will wipe out your vlans.

Exactly.. thats why you don't see it used much in production... it's easy to forget that when you deploy new hardware or.. "reconditioned" hardware.

I think the only way to remedy this is to set your new switch to VTP Transparent mode so that way all configurations stay local.

The other way is to assign them all to the same domain and password that domain.

(this typed from an ICND2 class where we covered VTP a couple days ago... )

itdaddy

but if you use passwords they cannot add their higher revision number correct guys??
it doesnt matter about revision number unless they have the domain and passwords correct to join the cisco VTP domain right?

Igloodude

dido what Igloodude said!

set the password and correct domain and you will lock it down no need for transparent mode.
server/client mode with password and domain locks it down...

billyr

One other thing to remember when you set up VTP which sometimes gets missed.

When you change the VTP domain name, the revision number is set back to zero.

Has caught me out a couple of times.

tech-airman

networker050184 wrote:

Stotic wrote:

If a switch is added to the network accidentally or maliciously as a vtp server with a higher revision number, it can wipe out all of your vlans in your vtp domain.

Just keep in mind that it doesn't matter whether the switch is a client or a server, the higher revision number will wipe out your vlans.

networker050184,

What if the switches are not part of the same VTP domain? Then revision number is irrelevant.