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.
