cancel
Showing results for 
Search instead for 
Did you mean: 

stpd on an MLAG cluster...

stpd on an MLAG cluster...

Chris1
New Contributor
Ok i know that this might not make much sense but lets just say we're dealing with a third party so theirs not many options.

We just upgraded our core from an aging switch to a x670's that are mlag'd together.

The problem is our old switch had an STPd connecting to 2 third party switches (third party core switches), i don't for see them changing their configuration... so how do i take the stpd that used to go to 1 switch and span it across my 2 mlag'd switches and have it function like it used to...

I know that i could just use 2 ports (non mlag'd) and put the 2 cables from the third party on one switch but that means they won't get the benefit of our redundant core, i'd rather have 1 of the stp'd cables on 1 x670 and the other on the second x670...

How should i go about this?

4 REPLIES 4

Chad_Smith1
Extreme Employee
Chris,

Two scenarios:

1. Do not create the STP domain at all on the MLAG peers. This is probably only a good idea if the VLANs going to the other devices only exist on ports 28 and 29 in the old topology. In this scenario BPDUs would be forwarded (actually flooded) from one 3rd party device across the ISC to the other 3rd party device. The two switches would basically act like a wire segment for the STP domain. However if other ports are added to these VLANs, BPDUs will be flooded to them as well. This may be undesirable. The main concern with this option is that the connection between the two 3rd party switches could be blocked by STP, forcing all traffic between those switches to be forwarded up to the MLAG peers and across the ISC. You may not want that traffic constantly going across the ISC. It doesn't sound like you have control over the configuration on these switches so this is something you might have to test/investigate.

2. Add the ISC to the MSTP configuration as you have mentioned above. The concern here is that the ISC could potentially be blocked by STP. Making one of the MLAG peers the root bridge would be one way to help ensure the ISC is never blocked. I don't know how feasible this is because I don't understand the full STP topology. This option could also introduce the same problem with traffic being constantly forwarded across ISC due to the link between 3rd party devices being blocked.

With either option, it may be best to have control/insight into both network segments so you can tweak STP cost and priorities so that you can have it behave exactly as desired.

Chris1
New Contributor
Any hints on how one would accomplish that, i'm busy looking through the concept guide now

what our old switch does is ...

configure mstp region REGION1
configure mstp revision 1
create stpd mst0
configure stpd mst0 mode mstp cist
configure stpd mst0 priority 28672
create stpd mst3
configure stpd mst3 mode mstp msti 3
configure stpd mst3 priority 28672
configure stpd s0 delete vlan default ports all
disable stpd s0 auto-bind vlan default
configure stpd mst3 add vlan VLANNAME1 ports 28 dot1d
configure stpd mst3 add vlan VLANNAME1 ports 29 dot1d
enable stpd mst0
enable stpd mst3

I didn't do the original config so not 100% sure on it but it works...

i would basially use this same config on both MLAG switches (but instead of ports 28 and 29, i would specify the port facing the third party....) or third party + isc?

I don't really understand how to prevent it from blocking the ISC ever, and to not broadcast everywhere across the network... Or do you mean i should only add the port facing the third party on each switch, and not the ISC or Uplinks at all?

Chad_Smith1
Extreme Employee
Chris,

To make this work you only have to satisfy two requirements:

1. STP can never block the ISC
2. STP cannot be enabled on any MLAG ports

So you would want to have the STP domain setup so that in steady state one of your links between the MLAG peers and the 3rd party devices is always the blocked port. You would probably also want to make sure the BPDUs are forwarded properly across the ISC and not flooded out to other unnecessary places in the network.

Chris1
New Contributor
Just incase i did a bad job explaining the scenario...

2a760e3b65b84a359c356f48cba7b95a_RackMultipart20150623-8787-kvmwf2-example_inline.png


GTM-P2G8KFN