Agree they can't both be right.   Using the "Where is it" example as the arbiter, I'm thinking the diagram is right and the test in the table is wrong.    I'm looking into confirming this with the product team. ... View more

Did you see this?   https://documentation.meraki.com/MX/Deployment_Guides/vMX_and_Azure_Route_Server ... View more

There are so many advantages to using VMX (and therefore AutoVPN) over non-Meraki VPN, that it's hard to know where to start.   The most important is likely to be in the resilience offered;   your MXs connect to both VMXs concurrently and you get far better failover capability - particularly if your branches also have dual WAN uplinks.   Given the importance of modern Azure deployments, it really costs in, for most customers. ... View more

This isn't possible with non-Meraki VPN.   Did you consider using vMX in Azure instead?   This would allow all the SD-WAN features, in addition to BGP ... View more

There's no way to do this natively within the Dashboard, that I'm aware of.   You would be able to monitor cellular usage, however, via the API - you could then trigger additional API-based controls, once usage reaches your preferred threshold(s): https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-uplinks-usage-history   Perhaps by progressively stepping up cellular firewall rules, as the limit approaches - maybe ultimately allowing only the most critical / bandwidth thrifty applications?    https://developer.cisco.com/meraki/api-v1/#!update-network-appliance-firewall-cellular-firewall-rules   ... View more

OK, so you could continue to use your L3 switching Core and apply Access Control Lists there, for your BMS separation.   Is there a particular reason why you route between VLANs on your switches, rather than the MX?  There are potential performance advanatages doing that (as it's done in ASIC) - but they tend to only accrue if you have servers located onsite and a decent amount of east-west traffic (particularly between servers in different VLANs).   Increasingly servers tend to be away across a WAN link somewhere, where the uplink capacity is the main bottleneck.   https://documentation.meraki.com/MS/Layer_3_Switching/Configuring_ACLs https://documentation.meraki.com/MS/Other_Topics/Switch_ACL_Operation  ... View more

You don't need to apply an ACL to a specific entity, like a VLAN or SVI, like you do with similar solutions.   Note this from the beginning of the guide: <With Meraki, you only have to define an ACL once in a network and it will be propagated to all switches within that network. Additionally, the default rule for Meraki ACLs is "Permit Any Any">     'Network' in context means a specific Network within the Meraki Dashboard (i.e. it will be applied on all switches, effectively on all ports on those switches.   You therefore just need to get the sources and destinations right, for them to work properly. Note though that it is possible, within any ACL, to choose to specify a source VLAN - but the default is Any   https://documentation.meraki.com/MS/Layer_3_Switching/Configuring_ACLs https://documentation.meraki.com/MS/Other_Topics/Switch_ACL_Operation   ... View more

It's not clear quite what Merki gear you have, but personally I'd recommend the following approach, which matches some of the previous replies: Having separate physical networks for this kind of thing is a dying approach, I would say and for good reasons, that I won;t go into. Provision one common reliable, resilient, performant network for all of your traffic, then apply appropriate logical separation and controls (e.g. rate shaping) for the stuff that needs it (that probably includes BMS).   While there are other approaches, simply using VLANs and firewalling between them is a relatively simple and well understood and scalable approach.   Generally you provide one gateway per site that interconnects the VLANs at Layer-3 and this is where you define the (firewall) rules for what can talk to what.  In a Meraki network, you'd probably be best using an MX appliance as that common gateway.  It would also provide the necessary protection between your Internet uplink - particularly if you use the Advanced Security license. ... View more

Try an auto-refresh plug-in for your preferred browser ... View more

What you won't be able to do is power the phone off the MX;   you'll need a PoE injector ... View more

You will require a quote from a Cisco authorised partner for your license, the SKU will be in the following form: LIC-MS320-48xx-xYR There are three models;   non-PoE (simpoly remove the xx) Low Power (xx=LP) or Full Power (xx=FP)    Then you have the choice of 1, 3 or 5 years licensing, for the last x   (7 or 10 year licences available, but for a model that's already end of sale, that might not be sensible). You must match the license to the model of switch hardware that you have;   you can't for exampe, use a non-PoE license for a PoE switch. ... View more

Email support@meraki.com ... View more

If you statically configure a 2.4 GHz channel properly, it won't move away from there.   Are you sure you haven't just chaned the config to amend the channels which can be chosen by the autochannel mechanism?   I would agree with the previous comment to stick with 1, 6 or 11 btw, whether you do this dynamically or via manual assignment.  Personally I'd stick with auto if you can, because this will take account of transient changes to background channel utilization.  Only go with static if you're finding the sheer number of channel changes actually create more disruption than it's worth.   Also;   assuming you have mainly dual-band devices, turn on band steering, if 2.4 GHz is proportionately over-utilised. https://documentation.meraki.com/MR/Radio_Settings/Band_Steering ... View more

The single uplink would just be for building the stack in the first place.   You'd then create the aggregate link configuration (at both ends), for the addition of your second link.   you don't need an uplink for each individual switch.   https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Switch_Ports#Link_Aggregation    ... View more

Something doesn't sound quite right here, if VPNC MXs logically sit between your perimeter firewall and core switches - VPNCs should sit 'off to one side' of one of those two layers  (usually the Core routing, to make things simpler)   If memory serves, EIGRP works layer 2, so I'd expect a VLAN directly between the Core and the firewalls, over which the EIGRP relationship is established.   The VPNC MX might be connected to the same VLAN,  but shouldn't be critical to the flow of that traffic (MX doesn't 'talk EIGRP') Now - I'm not saying the MX and its firmware wasn't directly involved in the issue though - if the problem started when the upgrade happened and was fixed as soon as you rolled back it's hard to argue with that - but I'd maybe look a bit deeper into your architecture.   I'd recommend talking further with Support on that, if needs be - but maybe with your Meraki account TSA too..? ... View more

Your queries and feedback around Meraki Go really need to be placed here:   https://community.meraki.com/t5/Meraki-Go-Community/ct-p/go   This forum relates to the general Meraki Dashboard and products managed through it. ... View more

If your MX is using site-to-site VPN, check that it is configured for Automatic NAT traversal.    If it is set to manual, you may need to change the config, to reflect the new IP.   Chances are it will be automatic - that's the default and most people leave it that way https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#NAT_Traversal ... View more

To my knowledge speed / available bandwidth in itself is not a metric for uplink viability.   If there is sufficient packet loss or latency to affect the other monitored variables, that might be a different matter.   The monitored things are documented here:  https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover ... View more

How far away is the gateway MV?    What kind of signal strength is reported, when it does connect? ... View more

Despite your reservations, I think you will need to re-engage with the Support team - perhaps look to escalate via a manager or your account team, if you feel you're not being listended to?   (you can usually find the latter via Help > Get help > Still need help > Contact your Meraki Sales representative).  I would suggest quoting the original case reference, so that whoever picks it up has the original background. The key, by the sounds of it, would seem to be that you feel you're getting a lot more DFS events after a particular firmware upgrade, than with exactly the same deployment on an older version of firmware.   Do you have any numeric evidence of this   (?)   Bear in mind that if there really is radar transmission being detected (are you on a flight path?), then reverting to one of the non-DFS channels is mandatory and the same challenge would apply regardless of the WiFi technology.   Longer-term, the advent of WiF6E should help here - more channel space, in 6 GHz, with no DFS - but you obviously don't have the APs and there aren't yet many clients to take advantage of this, right now. ... View more

Did you raise a case with Meraki Support? ... View more

You mention that your fibre links are not stable.   I believe speed and duplex is likely to be a red herring here and that other causes for your issues should be looked at.   Can you advise which optical SFPs you are using, at both ends, the specification of the fibre you're using (e.g. multi-mode 50/125u OM3) and the length of the fibre run(s)? Did you also check that your patch leads match the specification of the structured cabling? ... View more

It's a different IEEE standard for fibre links - being full duplex only is part of the standard for the vast majority of optical standards, so Meraki is compliant. ... View more