Good point. You've done a good job of mitigating the risks of VTP and STP. I think it comes down to risk .vs reward. More often than not the vlan configuration is static and doesn't change often. In that case I'd just endure the pain of configuring new vlans on new switches with the help of automation or some other tool. If I had to manage a large network with frequent changes to the vlan database I would think about running VTP despite all the "horror stories". A previous job where an engineer re-provisioned a switch via copy and paste but didn't erase the vlan DB or turn off server mode comes to mind, but I digress. When I have had the choice I haven't seen the need for it. That doesn't mean that it doesn't exist though.
Keegan On Wed, Feb 9, 2011 at 6:55 PM, Nick Hilliard <[email protected]> wrote: > On 09/02/2011 22:10, Martin Barry wrote: > >> Nick, that sounds like you have a good war story or three. Care to share? >> > > Mmm, my favourite relate to VTP pruning and the lurking horrors therein. > Until at least mid-way through SXF, VTP pruning on c6500s would cause ipv6 > simply not to work if the two edge nodes were on dot1q tagged ports. The > pruning stopped multicast ND packets from being propagated down the trunk > ports. The bug may still be there, but I disabled VTP around that stage, > and haven't checked since. > > It bit me recently with ARP broadcast propagation, too. Box A could arp > for box B and box B could arp for box C, but box A's ARPs weren't being > received by box C. This was on a 3750 stack. Ugly. > > Nick > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
