cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Help with redundancy design

SOLVED
Conversationalist

Help with redundancy design

Hi,



I need some help to understand how to best connect a MS350 STACK to a MX HA pair. Should the MS stack be connected to the MX using trunk ports from different stack members.



Stack Member A to Active MX

Stack Member B to Slave MX



We are trying to achieve full redundancy so we don't lose connectivity if any one device or circuit goes down


Thank you,
Will

1 ACCEPTED SOLUTION

Accepted Solutions
Head in the Cloud

Re: Help with redundancy design

To support what @cmr stated, here’s the Meraki document that supports the design he is outlining in his response, https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair#Fully_R....

View solution in original post

5 REPLIES 5
Kind of a big deal
Kind of a big deal

Re: Help with redundancy design

We connect switch A to MX A and to MX B, we also connect switch B in the same stack to both MX A and MX B.

 

STP takes care of the multipathing and you will have one connection from each MX forwarding and one blocking at the switch end.

 

Works well in this case where both MXs are connected to a stack.

Head in the Cloud

Re: Help with redundancy design

To support what @cmr stated, here’s the Meraki document that supports the design he is outlining in his response, https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair#Fully_R....

View solution in original post

Head in the Cloud

Re: Help with redundancy design

Just to emphasis the importance of the redundant connections of the Switch-member to the MX:

 

I recently had a system that was connected the way you described it (personally, I liked that model to make sure that STP can not cause trouble). While upgrading the switch, the stack connection went down. When the switches rebooted, the second switch lost the dashboard-connection because there was no link available to the active MX. All systems that were connected to the second switch-member were not reachable.

With a setup according to the Meraki best-practices, the second switch also had a connection to the cloud and could have pulled the configuration.

 

I have not yet decided how I will implement switch-stacks with more then two members in the future. To avoid this particular failure each switch member would need a connection to both MXes. But that would not really scale.

Kind of a big deal

Re: Help with redundancy design

>When the switches rebooted, the second switch lost the dashboard-connection because there was no link available to the active MX

 

The main caveat with single connected MXs is you should avoid using a VIP - otherwise, if they both go active they will both try and use that same IP.  Without a VIP they will both happily use their WAN IP instead.

 

If you are not using a VIP and the fault you described happened then the MXs would not have been able to communicate with each other, causing both of them to go active, meaning the switch should have been able to communicate via the MX it was connected to.

 

 

Head in the Cloud

Re: Help with redundancy design

Thanks @PhilipDAth for this input. I never thought about this consequence of using the VIPs.

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.