[c-nsp] VTP war stories (was Re: EoMPLS or VPLS loop prevention/storm control)

Wed Feb 9 21:21:26 EST 2011

...Thanks Ivan, as usual.
On a related yet separate note:
We are hearing horror-stories/cautionary-tales/VTP-horror-stories per-se..

1) There is nothing wrong with VTP(on the contrary, extremely helpful&convenient) as long as one understands how it really works and the nuances therein( revision # being the key) but then the same applies to STP(forgetting that the  max STP dia is 7 is your-problem - not so much of the protocol itself!) or for that matter any form of IGP(not to mention bgp). Everything can be dangerous unless you understand the underlying protocol.

Wrt to VTP:
I think a better approach for Cisco would be to have it ship in *Transparent Mode*(IOS)/*OFF*(CAT OS) and better-document where the concept of vlan-database does/doesn't apply with regard to how it is accessed!

Sorry for the noise.
Back to your regularly-scheduled-programming.
./Randy

--- On Wed, 2/9/11, Ge Moua <moua0100 at umn.edu> wrote:

> From: Ge Moua <moua0100 at umn.edu>
> Subject: Re: [c-nsp] VTP war stories (was Re: EoMPLS or VPLS loop prevention/storm control)
> To: "Ivan" <cisco-nsp at itpro.co.nz>
> Cc: cisco-nsp at puck.nether.net
> Date: Wednesday, February 9, 2011, 4:44 PM
> thanks, Ivan for the correction; that
> was a good read by the way; so to 
> clarify what we do on our end:
> * (in addition to setting edge & distribution switched
> to vtp "client" 
> or transparent mode) one should also delete the vlan db
> (akin to doing):
> del flash:/vlan.dat
> 
> 
> 
> --
> Regards,
> Ge Moua
> 
> Network Design Engineer
> University of Minnesota | OIT - NTS
> --
> 
> 
> On 02/09/2011 06:01 PM, Ivan wrote:
> > 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: paul at wozney.ca
> >>> web: http://wozney.ca
> >>>
> >>>
> >>>
> >>> On Wed, Feb 9, 2011 at 14:10, Martin
> Barry<marty at 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 at 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 at 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 at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 