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

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

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

So:  yes, one Network per site...   Not just because you then get 15 SSIDs for each site, but also: A Network can only be in one time zone -   if you have lots of APs in different countries, you will probably want accurate local time for each. If you ever want to deploy the MX Security / VPN / SD-WAN appliance, you can only have one MX active in any single Network in Dashboard.    (MR + MX and maybe MS switches too, all together, then suggests use of Combined Networks, per site, as @Uberseehandel mentioned) ... View more

This is certainly achievable, WDW - you'd connect your MPLS service via a LAN port, assign the port to a relevant VLAN + subnet and apply an appropriate static route or routes.    The basics of such a setup are covered in this document (though the premise of it is rather more sophisticated than that which you describe):   https://documentation.meraki.com/MX-Z/Deployment_Guides/MPLS_Failover_to_Meraki_Auto_VPN Hope this helps... ... View more

OK so it sounds like this is a different problem. I suggest you raise a case with the Support team, if you haven't already. they may well ask if your MS switch is running the latest firmware too, so if you can, you might want to upgrade it and re-test beforehand. ... View more

Firmware 25.8 for MR includes a fix in relation to CRC errors.   If you look in the Bug fixes section of the 25.8 Release Notes (you have seen the Release Notes now available through Organization > Firmware upgrades, right?  If not - go take a look, there's loads of good stuff there!): "Ethernet phy configuration issue caused CRCs on upstream switch ports (MR33/MR30H/MR74)"   Note, however, that CRC errors do occur on wired links, regardless of this fix - maybe due to a faulty patch lead or other wiring related issue.  The best advice would be to review the Release Notes and consider moving to a release with this fix (25.9 would currently be best).  Hopefully you see CRC errors greatly reduced but, if you're still seeing them, then commence troubleshooting your connection in the usual way.   If it's a Meraki MS switch your MR33 is connected to, probably worth starting with a cable test on the port in question. ... View more

Correct - SSL decryption is not currently supported on any of the MX models. Sorry this adversely affects your plans. ... View more

I think the Symantec article you highlight is a little light on detail, on precisely what it can do (and what it can't).   Fundamentally, if clients are required to fully verify the chain of trust, certificate-wise, with the target server (which is one of the TLS1.3 pre-reqs, as I understand it) then support for new TLS 1.3 cipher suites alone will not solve the conundrum.   Of course, the adoption rate of TLS1.3 is always open to debate. ... View more

25-8 is the latest 'beta'. Your Dashboard may be reporting you're on the latest 'stable / GA'. If you want to try r25 (& there's lots of good stuff in it - see Help > New features) then you'll need to select Try beta firmware under Network-wide > Configure > General (under "Firmware upgrades"). In a combined network, this will, by default, affect switches and MX etc if they exist in the same Network. Dashboard will (currently) upgrade the APs in your Network to 25.8, at the next configured Upgrade window. ... View more

Have a look here: https://tools.ietf.org/id/draft-camwinget-tls-use-cases-00.html ... View more

Don't forget to think about coverage density too - i.e. how many clients are you trying to serve concurrently and with what required level of data consumption?   With greater usage the need for higher connection rates increases, so that you serve the transmitting client quicker and release airtime for other nearby clients. ... View more