It is not always as well known, but client mode will not prevent "usurping the vtp domains" This article covers things in a bit more detail - http://www.networkworld.com/community/node/19931
Ivan > I'd agree that vtp can cause major problems if not deployed with caution > & mechanisms to mitigate disasters. we have a huge lan infrastructure > here with over 65,000 edge ports. what we do is divide the > campus/enterprise into 18 vtp domains so if there is a layer2 or vtp > meltdown this doesn't affect all of campus; also the core switch (in > this case 6509 w/sup720-3bxl) per vtp domain is the sole designated vtp > "server" mode device (this is important) as well as the root bridge > (fine-tune stp cost to do so); all others are in client mode or > transparent. for edge or distribution switches, it also important to > change default "server" mode to client (or transparent) -- again this is > important to avoid usurping the vtp domains. vtp comes in handy when > dealing with large amount of ports and one doesn't want to hand > configure vlan to port mapping manually; however as already mention all > of this is not without risks. > > when our current network was deployed intially about 7 years ago, we had > periodic spanning-tree meltdown per vtp domain, but never to all 18 vtp > domain at the same time; root cause was typical offenders: > * misbehaving gear that seized control as root bridge > * dumb hub connecting multiple vlans > * etc. > > over the years, cisco ios has had many vtp/stp/layer-2 bugs worked out; > and I'd say one doesn't see as much issues in this area as was in the > past; but caution is always a good thing. > > > -- > Regards, > Ge Moua > > Network Design Engineer > University of Minnesota | OIT - NTS > -- > > > On 2/9/11 4:28 PM, Paul Wozney wrote: >> I've seen VTP fail spectacularly. >> >> A customer was using it on about 30 switches distributed to about 10-15 >> wiring closets. They had a temp student come in who wanted to learn >> about >> networking, so the student copied the core switch configuration and >> deployed >> it on a lab switch. The student decided to wipe the VLANs from this lab >> switch and start from scratch. >> >> When the lab switch was connected to the production network, its VTP >> instance had the correct VTP password (as it was copied from the core >> switch), but it had none of the VLANs required for the correct operation >> of >> the network, and of course it had the higher revision number. >> >> It was an innocent mistake, but it ended up to be a very bad day for >> everyone involved and we've never used VTP for any other customer since >> that >> day. >> >> --- >> Paul Wozney >> Network Consultant >> phone: +1 604-629-9975 >> toll free: +1 866-748-0516 >> email: p...@wozney.ca >> web: http://wozney.ca >> >> >> >> On Wed, Feb 9, 2011 at 14:10, Martin Barry<ma...@supine.com> wrote: >> >>> $quoted_author = "Nick Hilliard" ; >>>> Also, don't use VTP unless you like living dangerously. >>> Nick, that sounds like you have a good war story or three. Care to >>> share? >>> >>> Can't say I've blown anything up with VTP ... yet. :-) >>> >>> cheers >>> Marty >>> _______________________________________________ >>> cisco-nsp mailing list cisco-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/