|
Sorry about the bad grammar :-) Ok, the deal with STP and VLANs is thus: STP works at the level of the actual Ethernet cables in the system, rather than the VLANs. Imagine you have four switches, A B C and D. Say vlan 1 exists on A and B; vlan 2 on C and D, and vlan 3 on all four, and physical cables (carrying tagged VLANs) run from A-B (vlans 1 and 3), A-C (just vlan 3), B-D (just vlan 3), and C-D (vlans 2 and 3); eg, they're in a square. And you enable STP. STP will cause the switches (ignoring VLANs) to choose one of those four cables to disable, to remove the cycle in the network. It's as likely to disable the A-B or C-D cables, which will then split vlan 1 or 3 in half. The solution is to make all VLANs present on all switches and (tagged) on all inter-switch trunks, so that any cable can be disabled and connectivity continues; there are extensions to STP that are aware of VLANs (such as the Cisco proprietary per-VLAN spanning tree); there's the recent (2003?) Multiple Spanning Tree Protocol (MSTP), but that's not supported by the switches I've been playing with, so useless to me at least :-) |
At any rate, I still don't see this as a STP/VLAN problem. If you want network redundancy than clearly your redundant links need to carry all of your VLAN's. Otherwise you'll have redundancy for some VLAN's but not others. That's not STP's fault, it's just plain logic.
Not that I think STP is a great protocol mind you. It sucks in MANY ways. Just not in the ways you seem to be claiming it does. :-)