On 2/10/2011 4:06 AM, Gert Doering wrote:
Well, the point is that there are not enough saveguards in VTP v1 and v2
to require some "more active" wrongdoing to make it explode - and if it
explodes, it usually requires "walking to the some of the affected
devices to get it fixed".

Things like "plugging in a switch that was used for lab purposes and
after that nicely cleaned of all the VLANs configured on it, because
it was only for labbing" should never bring down a complete production
network - and things like that just don't happen with the other protocols
you mentioned.

I couldn't agree more. Sure, if used in an exacting & perfect way, VTP can be configured and used without incident. Make one simple little mistake and it will hand you your ass. I'd rather not have a hair trigger sitting on my network.

Configuring VLANs on a dozen switches really is a trivial thing to do if you're organized about your VLAN numbering (basically not replicating VLAN IDs on disparate switches) and are organized about your up/down links. At that point copying and pasting in the basic VLAN config is a no brainer.

conf t
vlan 1234
 name vlan1234.Math-Dept-Pub-Lab
!
interface range gi0/1 - 2
 ! Uplinks
 switchport trunk allowed vlan add 1234
interface range gi0/3 - 4
 ! Downlinks
 switchport trunk allowed vlan add 1234
end
wr

How difficult is this really? And the bulk of that config is if you manually define an Allowed VLAN list on your trunks, something a lot of lazy admins don't do anyway. To me it doesn't matter if you have 1 switch or a dozen in a simple tree or ring topology.

So on one hand you have something that should work but fails in a spectacular fashion to most all network engineers at some point in their career (and could be easily broken as part of a DoS without much of any effort), or you have the piece of mind created as part of a very simple process that should take a decent engineer very little time. Call me crazy but I'm going with the KISS theory on this one!

Justin
_______________________________________________
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/

Reply via email to