[c-nsp] Disabling PVST+ in mixed vendor network

[j.vaningenschenau at utwente.nl]

Ross,

>> Thanks. The first one is already in our config; we were thinking
>> about configuring "no spanning-tree vlan 1-4095" in a maintenance
>> window. I hope that won't break our single MST instance but does
>> kill off all PVST+ stuff.
> 
> Make sure you are running SXF or newer.  Previous versions of IOS ran
> a pre-standard version of MST that does all kinds of weird things.

I appreciate your comments. Should've mentioned the IOS version; we're
at 12.2(33)SXI2a. We've had a couple of nasty bugs in SXF and SXH (and
desperately wanted LLDP support), so we're at a relatively recent
version. (LLDP MIB still isn't implemented though :-((


> We've been running MSTP/RSTP only networks on 6500 for years now, also
> with lots of HP Procurves, and have never seen any effects of the type
> you're talking about.
> 
> Any idea what the trigger is?

Last two times, it happened after a reload of one of the Cat6k's. First
was planned reload, second time was a crash (reason unknown). After the
device came back up, the 10 GE port to a core HP 5400 in the second
datacenter came online and went PVST Inconsistent immediately after
that. Source / trigger is unknown. The weird part is: that HP 5400 has
an egress multicast filter enabled on the port, which should block all
PVST+ traffic by dropping frames with destination 01000c-cccccd.

I still don't know what device might have sourced the frames; also I
have no idea why the multicast filter seems to let it through (at least
immediately after the port comes up). My theory was that the multicast
filter is programmed in hardware after the i/f comes up, but I haven't
been able to verify that.

By the way, the first time this happened it wasn't following a reload or
crash of the Cat6k. If I remember correctly, it coincided with someone
connecting a Cisco 3020 blade switch, which we expected to be the cause.
I think that incident led to us blocking 01000c-cccccd wherever we can.
Still, I don't understand why it happens and how we can completely avoid
it.


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands