SF200 vs C3560-X and per-VLAN RSTP: Turn off STP on SF200s?

[Gordon Fecyk]

I have a network with pairs of 3560-X switches servicing nearly 150 access switches (44 access switches per pair) and several hundred clients. The access switches are a mixture of SF100-D (unmanaged) and SF200 (managed). I have an odd business requirement that no more than 100 clients can reside in a LAN, so I have VLANs set up on the 3560-X pairs. They're doing load balancing between the VLANs using per-VLAN rapid spanning-tree protocol, and for the SF100-D endpoints this load balancing is working out as I planned. Failover works as intended whether that be a cable failure or a 3560-X failure.

With the SF200s, that load balancing is not working, instead sending all traffic to one 3560-X for all VLANs, and it's because the SF200s do not support per-VLAN RSTP. So I thought, why not just turn STP off on the SF200s? That would take them out of the spanning tree process and make them behave like SF100-Ds.

When I try that, I can observe ports on the 3560-Xs forwarding or blocking VLANs as I intended; even if I accept traffic on alternating VLANs on the SF200, the 3560-Xs show me it's blocking or forwarding each VLAN on those ports as I wanted them to. Multicast filtering still works, as does other SF200 functionality.

But is this a good idea? MSTP isn't an option for me since the SF200 doesn't support MSTP either, and the sheer volume of access switches make the 200s a better bargain than 300s. I found an example here that explains how to do it with MSTP and SG300s but I don't like the idea of access switches being STP root, and there would be too many of them to manage that.

(As an aside, the 3560-X pairs do IP routing up to our cores, so any STP traffic remains isolated to that pair and any access switch that speaks STP. This way, I don't affect the cores with any STP or cabling mistakes caused to a given pair.)
--

[Aleksandra Dargiel · Accepted solution]

Hi Gordon,

It is 200 series limitation so you could leave it with STP off on those access switches. For the security purpose I would think of port security with 1 MAC address only... You do not have any unexpected loop so on those ports where you have only end devices you could restrict number of MAC addresses thus any infrastructure device would not work if connected without your knowledge.

I hope it addresses your doubts.

Aleksandra

[Gordon Fecyk]

Thanks for confirming what I found. I'll keep the setup like this, then.

As for port security, the access switches are in locked cabinets at their locations, and the distribution switches are in locked and ventilated closets. Getting to either of those requires signing keys out, someone watching behind whoever's working in there, audit trails, and so on.

And even with all of that, endpoint devices get changed too often that port security would be a big, big support headache. So I think we're good.

(I practice port security in other locations that are more accessible, and that has caught some users thinking they can cheat the system.)