Aruba & ProVision-based
1748270 Members
3828 Online
108760 Solutions
New Discussion

Re: MSTP: One region needs to "talk" through the other

 
esba
Collector

MSTP: One region needs to "talk" through the other

Hi.

 

This is a simplified view of my setup:

 

EDGE2 <--> EDGE1 <--> CORE <--> EDGE3

EDGE5 <--> EDGE4 <------^


(In reality I have 30 edge switches, some have four hops to the core switch, but most are directly connected.)

 

All edge switches have VLANs: 1, 10, 20, 30.

The Core switch has these VLANs: 1, 10, 15, 20, 30, 50, 55

 

Reading through the MSTP documentation and best practices I have configured two regions. One for the core switch (named "core") and one for all of the edge switches (named "edge").

 

Spanning tree has been enabled on all edge switches and EDGE1 given "priority 0". EDGE2 sees EDGE1 as root as it should. But EDGE3 is root with the default priority (EDGE4+5 also forms their own "region").

 

My issue is: I would like the "edge" region to somehow also be configered on the CORE switch and make that the root for the "edge" region. Or maybe relay the "edge" region throug the CORE switch. From what I've read neither is possible/best practise.

 

Is there a better way to configure this? Should I be using instances and how?

4 REPLIES 4
paulgear
Esteemed Contributor

Re: MSTP: One region needs to "talk" through the other

Hi esba,

When you say "simplified view of my setup", are there additional links between core and edge1-5 that you are not showing? Otherwise, i struggle to see why you would use MSTP at all.

The main purpose of MSTP is to prevent redundant links (usually in a loop configuration) from being unused. Given what you've shown of your configuration, i can't see why it would be necessary.

Regards,
Paul
esba
Collector

Re: MSTP: One region needs to "talk" through the other

Hi Paul,

 

Thank you for the reply; I can see why you are struggling :)

 

My setup is pretty straight forward at the moment, but I plan on doing some redundancy between some of the edge switches in a couple of months. So this is to be seen as preparation for "real" use of MSTP.

 

So far I have figured that the best solution is to add all VLANs to all of the switches (edge + core), and just leave the VLANs not used on the edge switches set to "no" on the access ports.

 

Do you have any comments?

 

 

Vince_Whirlwind
Trusted Contributor

Re: MSTP: One region needs to "talk" through the other

On the face of it, it seems the opposite of good design to be trunking VLANs out to access switches where they are not in use.

You also seem to be implying that your future state would involve (effectively) daisy-chaining access switches with respect to some of your VLANs. This isn't so good either.

 

The reason people want to use MSTP is because their uplinks/trunks are under-provisioned for bandwidth, and so they want to spread the load across otherwise inactive links.

I have a few problems with this approach, the main one being that to have true redundancy, the fail-over state should be provisioned for the full amount of bandwidth required. In other words, if you only have half as much bandwidth as you require, you should be attending to that issue, not sweeping the problem under the carpet using MSTP.

paulgear
Esteemed Contributor

Re: MSTP: One region needs to "talk" through the other

Vince, i think there are good reasons why some people set up their networks with all VLANs available on all switches, and until we know more about esba's setup, we shouldn't pass judgement.  I think you're right about the reasons for using MSTP, though - in most environments it's hard to justify using it.

 

Esba, if you don't have redundant links now and you aren't desperately crying out for more bandwidth, what i would recommend is using RSTP or LACP (if your physical topology permits it) to get redundancy, and GVRP to manage your VLAN assignments on your switch-to-switch links.  That way, the VLANs that aren't needed on your edge switches won't go there because GVRP will automatically prune what isn't used.

Regards,
Paul