MXs in a High Availability pair share?

Solved
Riser
Getting noticed

MXs in a High Availability pair share?

We have an issue that we have been arguing about with my peers on what information is shared between the MXs firewall in the High Availability Pair.

We are torn between 2 choices, the spanning-tree state, and the stateful firewall database.

Some say the Spanning tree state but I say the stateful firewall database and gave the below explanation, am I correct, or anyone who can suggest differently?

Explanation:

  • The MXs in a High Availability pair share the stateful firewall database, which is used to allow the firewall to retain information about its rules and the addresses on which it has been configured. 
  • The spanning-tree state is not shared between MXs because it changes as the network topology changes, and High Availability requires that the same topology be presented to both devices at all times. 
1 Accepted Solution
ww
Kind of a big deal
Kind of a big deal

The mx does not use stp, so it has no stp state to share/sync

View solution in original post

7 Replies 7
ww
Kind of a big deal
Kind of a big deal

The mx does not use stp, so it has no stp state to share/sync

MyHomeNWLab
A model citizen

Warm-Spare does not synchronize session/connection information.
Warm-Spare is equivalent to VRRP.

 

MX Warm Spare - High-Availability Pair - Cisco Meraki
https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair

 


Meraki MX does not have STP functionality and only forwards received BPDUs.

 

MX Layer 2 Functionality - Cisco Meraki
https://documentation.meraki.com/MX/Networks_and_Routing/MX_Layer_2_Functionality

 


And, don not expect Meraki MX to fail over immediately.
Not suitable for environments that require strict SLAs.

 

Meraki SD-WAN - Cisco Meraki
https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

ref. Section: Failover Times

Ryan_Miles
Meraki Employee
Meraki Employee

Keep in mind the failover times shown in that doc are ranges based on a number of variables. A typical WAN link down & failover to WAN 2 is very fast. MX primary to MX spare failover is also very fast. Upstream or "soft" failures can cause some additional "down" detection time and impact failover time.

 

The LAN side topology could also factor into failover times albeit the impact should be quite minimal. By that I mean some might choose to single connect each MX in a HA pair to downstream switches. Others will choose to dual connect each MX causing a STP blocked pathway. 

 

If the MXs are doing AutoVPN then there is a little more time required to failover tunnel(s) from primary to spare. Additional hub factors (DC failover, OSPF or BGP timers) could also influence the failover time.

Ryan

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
MyHomeNWLab
A model citizen

Thank you for the supplemental information! 😀

 

I think that failover time information should be handled very delicately.

 

The reason I think so... 🤔

 

I have experienced design support for a WAN renewal project (Cisco IOS => Meraki MX).
At that time, I realized that.

As the history of enterprise WAN networks has grown longer, the demands on the WAN have grown correspondingly.

In order to reduce the risk associated with network renewal, the customer requires SLAs equivalent to the existing environment.

(This can be expressed as difficulty in reconsidering the requirements.)
This is because it is difficult to lower the level of service already provided.

 

For example, in the existing WAN environment, Active-Active topology (OSPF ECMP, EIGRP UCLB) can use redundant WAN links efficiently.
In addition, the failover time can be accelerated by adjusting the timer.

 

Therefore, if the existing requirements were to be followed as is, the requirements would tend to be higher.

 

However, because Meraki MX Warm-Spare is Active-Standby, the WAN link will not be used efficiently, and customers will not see a cost benefit.
(It means that the WAN link on the Standby MX side cannot be used during normal operation.)

 

Meraki is characterized by simplicity.

It is inevitably difficult to implement in environments with strict requirements. 😓
Also, its simplicity makes it easy to deploy on a large scale. 😁

 

There may be cases where failover time is actually short.
However, for the reasons stated above. I do not think that it is advisable to explain to customers based on wishful thinking.

It is especially difficult to get customers to understand the longer time of soft link failures.

 

I mentioned failover time because the intent of the original question seemed to be concerned with achieving fast failover mechanism.

cmr
Kind of a big deal
Kind of a big deal

@MyHomeNWLab I think you might not have the below right:

 

"However, because Meraki MX Warm-Spare is Active-Standby, the WAN link will not be used efficiently, and customers will not see a cost benefit.
(It means that the WAN link on the Standby MX side cannot be used during normal operation.)"

 

With an MX HA setup, both WAN links connect to each MX and both links can be used by the primary MX, and in the event of a device failover, both will be used by the standby MX.

 

The above also works for SD-WAN, we use it for all of our sites.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
MyHomeNWLab
A model citizen

Thank you for your information.
Following best practices, I only considered the case where the Primary MX and Spare MX were directly connected to the Internet access line.
I was biased in my thinking.

S_P_J
New here
Get notified when there are additional replies to this discussion.