Can you expand, Warren - what do you mean by ' failover on a packet by packet basis' ? ... View more

Yes - it could be up to 300 secs  https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover ... View more

If your MX84 is using AutoVPN (Meraki to Meraki site-to-site VPN), you might need to turn it back on again, but the underlying config will still be there;   under Security & SD-WAN > Configure > Site-to-site VPN make a note, on the MX84 setup, as to whether it's set Hub or Spoke, then re-apply this after you put the replacement MX in. ... View more

That is indeed the place to configure SD-WAN rules.  Note that, for Internet traffic, only policy-based rules are currently available (not performance-based);   the VPN overlay (AutoVPN) is what provides the defined path for end-to-end monitoring used for performance-based rules applied to traffic traversing the VPN.   Load balancing of Internet-bound traffic can also be enabled, based upon the weighting of the bandwidths configured under the SD-WAN & traffic shaping uplink configuration of WAN 1 and WAN 2 ... View more

The endpoints supported within the Dashboard API are, in my experience, also fairly quickly updated within Help > API docs, in Dashboard itself.  In terms of SD-WAN ease-of-management, believe it's also a fairly recent addition to be able to handle SD-WAN configurations using Templates:  https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/MX_Templates_Best_Practices#Template_SD-WAN_Policies ... View more

Many thanks to @CameronMoody for the clarification;  FYI he's also arranged a tweak to some of our internal information, that lead to my ovely simplistic (OK, OK;  inaccurate) comment regarding VRRP. ... View more

VRRP is only used as part of the warm standby mechanism, on MX ... View more

Whilst it's not related to the cabling, please note that, at this point in time, the new MX67 and MX68 models do not yet support VRRP (i.e. warm standby).  This will be added in a future firmware release.   Whilst writing, the same goes for wired 802.1x ... View more

While VRRP does indeed provide a resilient next-hop (either for clients or, for another example, an upstream router) it's also used for the two MXs to monitor each other.   If you have all your inside VLANs running over the same physical infrastructure (switches / fibre etc.) then a failure within that layer could result in both MXs becoming active.  Having as direct a path as possible between the two, separate from that shared infrastructure, to prevent active-active, is the basic aim of such a link. ... View more

Hi @jdsilva - I should probably have called it a heartbeat link (although it would need a dedicated VLAN.) The idea of that path is for it to be as simple as possible (least likely to fail), avoiding dual-active MX scenarios.   There are indeed a number of ways of engineering such setups - I guess testing your preferred approach, in your customers actual network, taking into account likely failure scenarios (perhaps using a free trial) is always the best recommendation, rather than being fixed on any one topology as ‘best’. ... View more

A couple of thoughts to add: MX doesn't run STP itself, but it will forward BPDUs, so if you create any loops, they'd need to be resolved in the switching.  Probably best not to create them in the first place. Any heartbeat link directly between the MXs should be in a dedicated VLAN.   In addition to the published MX documentation.meraki.com this is a useful unofficial resource (though created by a Meraki SE):  https://www.willette.works/mx-warm-spare/  ... View more

If you're wanting a 'dual-purpose' HQ MX setup, you probably do want NAT-mode - and will need to choose the model carefully, bearing in mind the traffic being carried and the multiple processes that MX will be running.  As that will mean a default route, pointing at the MX from any upstream router/L3 switch anyway (thus covering all remote site subnets), I'm not sure what OSPF would give...?  (if you want resilient MXs, you can use warm standby failover, which halves the licensing)   What application is driving the need for a full mesh VPN setup?   Most environments - even those with site-to-site VoIP - can run successfully using hub and spoke, provided the majority of applications are hosted at/through the hub  (or maybe on the Internet, as SaaS via split tunnel).   You could do full mesh (every MX as a Hub), with only 6 or so sites in total, but you need to consider the extra load that number of tunnels places on each MX and choose appropriate models for each.  Of course, if the customer actually grows even a little way beyond that site qty, the tunnel count grows rapidly, for every extra site... ... View more