MX Warm Spare Behavior without dedicated link

KiloBravo
Here to help

MX Warm Spare Behavior without dedicated link

KiloBravo_1-1700509235147.png

 

 

Firstly, apologies for the the not so great diagram, just slapped it together. Hope it still makes sense.

 

So I've come across a slightly different setup and would like suggestions on how to improve it. The objective is for MPLS or internet bound traffic to flow if either of the core switches fail.  My thoughts on it are that the MX's could end up in dual master if any one of them (the core switches) fails as there won't be able to send/receive VRRP heartbeats.

 

If that's correct then the only solution I can think of is to use a dedicated link between the two MX's as per the direct-attached  setup here: MX Design: Warm Spare - Smartencyclopedia.  Meraki do not seem to document that design anywhere though.

 

Thoughts?

 

(For clarity the MX is the default gateway for all internal subnets. Isolated/dedicated vlans on the core switches are being used to connect up into the routers)

13 Replies 13
Ryan_Miles
Meraki Employee
Meraki Employee

Several years back guidance did change to recommend using the LAN connections through the switching layer to provide the pathway for VRRP packets. The article you linked to is several years old (from a now shutdown site/past employee). Nothing wrong with that, but just pointing it out.

 

I too call out the pros & cons of this in my animated slide deck and I agree that providing a MX to MX direct link can help avoid a dual active scenario should all LAN links to the primary MX fail, but WAN(s) are still active.

I've had far more failures when using a direct MX to MX think because of spanning tree, than I have had with environments saved by having it.  I will no longer link MXs directly because of this.

 

Personally for me - the direct MX to MX link lowers your overall availability.

Thanks Phil. Would you say those failures are just due to it being misconfigured? 

No.  Bugs in the handling of spanning tree.  Particularly corrupted spanning tree packets or unexpected spanning tree packets.

when's the last time you you used the MX-MX link? wondering if maybe those issues you encoutered could have been ironed out by now....

Thanks Ryan. If properly configured, I'm trying to figure out what the cons could be?

I suppose the con would be it's not the official recommendation per documentation. I've not had issues with the design as long as STP is properly configured downstream (and if it wasn't you'd still have problems even without the MX<>MX link anyway).

Thanks. With it not being an official recommendation, I guess that means getting support on it might be problem should I run into weird issues that aren't due to misconfiguration?

RaphaelL
Kind of a big deal
Kind of a big deal

Sorry to bump and old thread. 

 

Is it recommended to connected more than 1 switch of a switch stack to each MX ?

 

Eg : Stack #1 has 2 switches. 

SW#1 -> MX1

SW#1 -> MX2

SW#2 -> MX1

SW#2 -> MX2

 

Cheers ,

cmr
Kind of a big deal
Kind of a big deal

If they are Catalyst switches then we do exactly that, if Meraki switches then we either single connect SW1 to MX1 and SW2 to MX2 or cross connect and disable the second ports at the switch end.

RaphaelL
Kind of a big deal
Kind of a big deal

I wasnt sure if : 

 

RaphaelL_1-1706311192668.png

Those were a single stack or 2 stacks ( Layer 2 switch stack (singular))

It's a stack with two switches

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