Redundant uplinks to MX from Switch Stack. Is it even possible?

DR1
Getting noticed

Redundant uplinks to MX from Switch Stack. Is it even possible?

I'm hoping someone can elucidate for me whether this is possible.

 

How can I achieve multiple(2 or more) redundant paths to our MX250 for internet resolution only?

 

We have three MS355-24X2 in a Stack Loop. One of these currently has an uplink to the MX250. If this switch has issues, we loose connectivity across every domain.

 

Given that the MX250 can't speak RSTP is there some way achieve uplink redundancy?

 

My hope is to provide physical links from each of the three stacked switches directly to the MX.

If this isn't possible, I would at minimum like to provide secondary physical connections from downstream PoE switches with all our AP's and Cameras directly to the MX.

4 Replies 4
Bruce
Kind of a big deal

Yes, its possible but you have to rely on RSTP itself to block one of the links, as you know there is no link aggregation on the MX devices. Although the MX doesn't participate in RSTP it will forward BPDUs.

 

Configure another port on the MS355 stack the same as the one currently connected to the MX, and likewise on the MX configure another port that is identical to the one connecting to the MS355 stack, and then put a cable between them.

 

BPDUs will be sent up the links, forwarded by the MX, and then down the other link back to MS355 stack. On receiving its own BPDUs the MS355 stack will block one of the ports based on the interface/port number (which goes towards determining the superior BPDU), so one of the ports will be blocked, and the other will become designated. Then if you experience a failure BPDUs will cease to be received on the blocked port and it will move into the designated state.

 

Couple of points: the ports will ideally need to be trunk ports on the MS. Ensure RSTP is enabled on the MS. If they are access ports then they'll run PortFast by default which will cause an initial issue, but it should recover. You shouldn't need to run Loop Guard or Root Guard, and you definitely don't want BPDU Guard on the ports.

PhilipDAth
Kind of a big deal
Kind of a big deal

>How can I achieve multiple(2 or more) redundant paths to our MX250 for internet resolution only?

 

My personal experience - you'll achieve higher uptime with a single link.

 

You are more likely to get experience an outage being caused by a spanning tree issue than you are to have a single cable/port/device with an unplanned failure.

GIdenJoe
Kind of a big deal
Kind of a big deal

I personally DO rely on STP to resolve these uplinks.

If you designed your network well then you should not have any STP events that could cause an STP crash at your Core switches.  It is in the design documents of Meraki and they will fully support this.  A stackmember failure can happen too causing a blackhole because someone onsite has to refit the uplink to the other switch...

 

GIdenJoe_0-1606207550551.png

In the above drawing you can see a stack that is uplinked to two MX appliances in a HA configuration.
I would always uplink two stack members, not three or more so you can easily predict what should happen with the blocked links.
Here you can see the first switch blocking both it's links that go to the master and the spare.
On the second switch you can see port 23 that goes to the spare which is not marked as uplink because of it and port 24 that is connected to the master MX so that port is marked as uplink for the stack.

 

The uplinks are made as follows:
MX Master 3 -> SW1/23
MX Master 4 -> SW2/24
MX Spare 3 -> SW2/23
MX Spare 4-> SW1/24

 

The only weird thing in my book is that stackmember two is apparently having lower switchport ID's and thus it gets the forwarding ports instead of switch 1.  It does not matter in the end but that's one of the things that you just cannot configure on Meraki 🙂

IT_Magician
Building a reputation

We use TP-Link switches on the edge.. non managed of course. This was after days of troubleshooting with Cisco Meraki support they finally said it wasn't supported. I suppose there are ways to do it, but at that point we found non-managed switches on the edge worked best for us.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels