The case you gave is more of an issue with failover time rather than failover type. You could have active/active, and if one active node failed you still have to consider how long it takes before this condition is detected the the remaining active node takes over the entire load.
With MPLS the best failover time is achieved when you run AutoVPN over the top of MPLS between the branch and DC. This is because AutoVPN sends active probes to detect far end failure, rather than waiting for it to re-actively detect it.
Lets take the first simple case - active/standby.
The MX implementation of VRRP seconds a hello packet every second. If a hello is not seen for three seconds the standby unit assumes the primary has failed, and takes over as the primary.
Note that if you have just a single leg into your MPLS network that you will need to suffer the time it takes AutoVPN to rebuild. In my experience, recovery from primary power failure should have restored connectivity within 30s.
https://documentation.meraki.com/MX-Z/Networks_and_Routing/NAT_HA_Failover_Behavior#Additional_VRRP_...
"In a working state, the master MX will send VRRP advertisements out to the LAN every second. If the spare MX does not receive any advertisements for three seconds, it assumes that the master MX has failed and will take over as the new master (including sending its own advertisements)."
Once you are using AutoVPN, then rather than using active/standby at the DC, you can run two individual MX's. It is really important that each MX has a separate stub link to the network core. You can then run BGP from each MX to the network core. Now that you are running BGP to the core you can crank the BGP timers right down for rapid layer 3 failover.
Now the important thing to note in this case is every branch now builds two AutoVPN tunnels to the DC - one to each MX head end. Each branch will prefer one as the primary as the other, but you can split the branches between them. Back to the important bit, because there are two AutoVPN tunnels already built a failover in the primary path does not take so long to failover now, because a second AutoVPN path is already built to failover to. Plus the network core with low BGP timers will quickly remove the failed MX as a routing path.
There is some info about this approach at this URL:
https://documentation.meraki.com/MX-Z/Networks_and_Routing/BGP
Lets talk about ASA's for a moment. ASA's can run in active/active mode in only two cases:
* An AnyConnect user to site VPN cluster - not applicable to this case
* Multi-context mode where they run virtual firewalls. This is mostly used by service providers. It does not allow you to scale up the performance of a single VM. It allows you to scale out sideways.
So in the case you give, you would be running the ASA's in active/standby mode. However the ASA's support state-full failover. This allows one ASA to mirror the state to the other. What this does on device failure is reduce the time for VPNs to rebuild (or NAT sessions to re-establish) since the standby ASA already has this info. Note that MX's in active/standby state also mirror their NAT state tables.
ASA's also allow you to adjust the failover timers - which MX's do not allow. So you can crank down the failover timers so that it responds sub-second if desired.
So you see, it is not really a question of running active/active, but the time to respond and recover to a primary failure, weather it be MX, ASA, or something else.
In Meraki's case, some of this can be addresses by the network design and taking advantage of AutoVPN. Potentially some of this can be address using active/active MX's at the head end and using BGP.
What you probably need is for Meraki to provide more fine grained control of the failover criteria, to control the time it takes to detect and recover.
