It is indeed RP-SMA ... View more

Only just saw this comment, looking for something else...   You know null encryption is now supported for third party VPN tunnels?  under Security & SD-WAN > Site-to-site VPN > Organization-wide settings > Non-Meraki VPN peers. Then select IPsec policies > Phase 2 > NULL. ... View more

In so many respects, you're absolutely right!   But it is 'failings' elsewhere being pushed at the network guys to fix, as usual...   🙂 ... View more

On its own VRRP is rarely a fix for this kind of requirement;   e.g. VRRP can't advise remote locations which site is 'hosting' the subnet at any time.  Unless you have high levels of bandwidth between your sites, you run the risk of large amounts of inbound traffic hitting one DC, only to need to immediately to head for the other. (LISP was developed, in wider Cisco, to cater for this effect). Personally I think pushing the need to retain IP config, when moving VMs, is a kind of laziness in the server area somewhere; an IP subnet is there to represent a site. If the site where a device is located changes, then change the subnet. Isn't this what dynamic DNS systems were invented for? ... View more

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

You may well also want to consider what can be achieved, against your business needs, using Webhooks as a 'push' rather than 'pull' API - as businesses aren't generally interested in storing lots of information that says 'everything is fine'.   You have probably noticed previously that various alerts under Network-wide > Configure > Alerts relate to the performance of the network, in some way.   Webhooks allows Dashboard to alert you, when these occur, rather than you needing to make calls in the other direction at regular intervals.   it's possible / likely that not all the things you're interested in can be defined there, yet, but, as Webhooks is more efficient, asking for things to be added in this area might be a better Feature Request to ask for.   https://documentation.meraki.com/zGeneral_Administration/Other_Topics/Webhooks ... 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

Just a quick one on this - wondering why you 'cannot use BPDU guard to detect them' (people attaching switches that don't run STP..?) ... View more

You learn something new every day!    Thanks for that jewel... I have to say - it would (to me at least) be an unusual deployment, to use this feature;   as you have to have a non-MS120 L3 gateway anyway, why would you not run the BOOTP helper there, in order to keep your off-subnet traffic flows consistent..? ... View more

@PhilipDAth wrote: Note you need an MS210 or above to do this.  The MS120 does not support DHCP relay. Just to add to what @PhilipDAth rightly pointed out, this doesn't mean MS120 won't work in environments where you need clients relayed to an off-subnet DHCP server but, with an MS120, you are reliant on the BOOTP messages being forwarded at Layer-2, rather than relayed at Layer-3 (MS120 doesn't do layer-3 routing).  Ensure you have contiguous connectivity for the VLAN your clients are in, from the first switch all the way to the Layer 3 device (a router or routing switch - MS210 or better) that is providing the relay function. ... 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

I don't believe there's a generic problem with 802.1x and Android - I can see other MR networks successfully authenticating and connecting Android clients using 802.1x   I think you need to raise a case with Meraki Support - probably via a phone call -  to investigate your problematic client.   Contact details can be found via Help > Get help at the top of the Dashboard.   They may want to take some packet captures, so if you haven't used that tool before, you may want to read this knowledgebase article:  https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Packet_Capture_Overview   ... View more

Just an update for those interested: https://www.sslsupportdesk.com/encryption-protocol-tls-1-3-released/ ... 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