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

Keegan Holley keegan.holley at sungard.com
Wed Feb 9 19:22:05 EST 2011


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 <nick at foobar.org> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>


More information about the cisco-nsp mailing list