Help with STP issues on E512zl switch connected to GBE2c switches

[Gordon Cook]

I am having a few problems with STP on my network that have me baffled

I have 4 GBE2C switches connected to a E5412zl.  Each of the GBE2C switches connect to the E5412 using 1GB copper.

I also have a second E5412zl switch connected to the first E5412zl switch using two 10GB fiber connections.

The two E5412ZL switches are located in different buildings with the first in our data room.

The trunk (TRK1) between the two switches carries a number of vlans.  We recently have a requirement to extend vlan 1 accross the trunk as well. 

The GBE2C switches are all setup using vlan 301 and are connected to the E5412 on vlan 301.

When I extend vlan 1 accross TRK1 then I start getting the following messages on three of the four GBE2C switches

Aug  2 14:52:21 Storage-2 ALERT   stg: CIST topology change detected
Aug  2 14:52:21 Storage-2 ALERT   stg: STG 1, topology change detected

This keeps repeating at an irregular iterval.  Sometimes a couple of minutes, sometimes almost an hour.

This does not make sense since they are not using vlan 1 at all.  I have included relevent documents. 

I am pulling my hair out on this one.

[Vince_Whirlwind]

On the first 5400, you have MSTP configured, you have all VLANs trunked on TRK1 but haven't added VLAN1 to either MST indstance.

On the second 5400 you don't have MSTP configured?

I'd get these to match up if I were you.

[Gordon Cook]

Thanks for the help.

I will add vlan 1 to MST on the first 5400.

Do we need MST on the second 5400?  The only thing we are connecting to it is workstations and printers.

[Vince_Whirlwind]

I'm not sure you really need MSTP at all - it certainly complicates things, and I would make sure you are using it for a reason.

[Gordon Cook]

We need MSTP for the GBE2C  switches for redundancy.  

[Vince_Whirlwind]

I've never been sure how MST helps with redundancy.

In an ideal world, you have aggregated links between your switches - you need to provision for the bandwidth required,+1 physical link.

When you can't have link aggregation, then you need to provision an active link with the full amount of bandwidth required, plus a redundant link with the identical amount of bandwidth.

(this is less efficient than link aggregation by 1x physical link per link above 1, eg, for 40Gb, you would need a 5x 10Gb link agg, or a 2x 4x10Gb link under STP, ie, 3x additional 10Gb links).

The argument with using MST always seems to revolve around under-provisioning your links with regard to bandwidth - MST doesn't reduce the amount of redundant bandwidth required, so as per the above example, you will need 2x 4x10Gb links regardless of whether you are complicating your network with MST or not.

[Gordon Cook]

I understand what you are saying.  We also have two 6120XG switches in the blade.  They allow us to combine a port from each in to a trunk.  And that is ideal.  If one switch goes down everything keeps working.   While both are up we have more than adequate bandwidth.

Unfortunately with the GBE2C switches they do not support distributed trunking and we need redundancy in case we lose a switch.  The last time we had an issue with a switch we had data corruption which took hours to fix.  We need to avoid that.

Hopefully next year we are looking at replacing the GBE2Cs with 6120XGs but we need to make do till then.