Meraki Go Community is here:  https://community.meraki.com/t5/Meraki-Go-Community/ct-p/go ... View more

If you haven't already, you should report this to Meraki Support.   Find details under Help > Get help at the top right of the Dashboard.   If it's urgent, always make a phone call rather than just relying on raising a case through the Dashboard or via email. ... View more

デフォルトでは、RSTP はリンクの速度を考慮する必要があります。 LAG 構成を削除し、10G リンクと 1G リンクの両方を使用して 2 つのスイッチを直接接続し、RSTP が 4 つのポートで有効になっている場合、1G リンクはそれ以上の構成なしでブロッキングとして設定する必要があります。 ... View more

Did you try making the specific call, for a known networkId, with the same API key, using a separate tool like Postman or the API documentation page? :   https://developer.cisco.com/meraki/api-v1/#!get-organization-appliance-vpn-statuses  ? ... View more

Yes - you can bind and unbind Networks to/from Templates with the following endpoints:   https://developer.cisco.com/meraki/api-v1/#!bind-network https://developer.cisco.com/meraki/api-v1/#!unbind-network I don't believe there's a single endpoint to move a Network directly from one Template to the other, as can be done through the Dashboard:   https://documentation.meraki.com/General_Administration/Templates_and_Config_Sync/Managing_Multiple_Networks_with_Configuration_Templates#Moving_Networks_Between_Templates ... View more

You can also do something similar to @PhilipDAth's idea but using the Org > Overview table,  Devices tab   From the 'Search...' dropdown select the MX model(s) you are interested in, from the Device type window.   Then click the header of the Network column to sort.   You might also choose to filter by online Online devices (for example).  Pairs of MXs will be adjacent, with the same Network name, as with the Inventory, but the Clients / Usage columns will also likely tell you which is active and which is standby. ... View more

No - you certainly wouldn't use it on live networks first - you'd set up a test-bed of some kind.   But you'd probably want to do that for API too..? ... View more

My recommendation would be just to try them, though API is a really powerful tool too, if you have some scripting abilities ... View more

The key to this is that only a subset of settings can have local overrides (settings that differ between sites bound to a common Template).  These are readily visible when you create a Template and bind a Network to it:   they are the 'Configure' options that are still visible when you select the Network, not the Template to which it's bound.   Configuration options that are only visible when you are managing the Template will have the same setting across all Networks bound to that Template.  This commonality simplifies the management of a large number of sites.    Bear in mind that you can have multiple Templates, if required.   The key local override relates to MX VLANs and subnets;   in an AutoVPN config you configure in the Template, for each VLAN, a subnet of a size of your choosing (e.g. /24) from a defined supernet (e.g. 10.64.0.0 /16)   Dashboard will randomly choose a free one from that range, for each new Network bound to the Template.   Typically sites already have IP addressing of course, so you then go into the Network to change each VLAN to match the existing addressing for the site.  This change is made once, generally by whoever is overseeing the implementation of the MX at the site.   A 'blank' Template will configure all bound Networks to have whatever is the default set of settings.   Just because you haven't changed a setting, doesn't mean the Template isn't in control of that setting. If the parameter you are interested in can be locally overriden, you can change it separately in each Network.  If not, you can only change it in the Template, at which point that will be applied to all Networks bound to that Template. ... View more

I assume so, but probably worth checking:   when you say one fiber, you really mean one pair of fibres (send and receive)?   Given you have structured fiber cabling, I'd also check that you have them patched properly: send to receive (try reversing the connnectors at one end). ... View more

That's a good point - what does packet capture reveal? ... View more

The management traffic from your MX to the Meraki cloud will not use its own AutoVPN tunnel - even though it provides a default route for user traffic (at least - for those VLANs that are VPN = enabled.  This traffic will break out directly to the Internet, NATed behind the address of your primary WAN uplink (You should be able to verify this through a packet capture on the Internet logical interface).   I would look at whatever is upstream of your MX on that WAN port - but also feel free to contact Meraki Support, if there's nothing obvious there that's blocking comms to the ID'ed destinations. ... View more

Can you confirm that the traffic involved is 'in-VPN'?    The source VLAN needs to be VPN enabled in the Spoke MXs Addressing & VLANs config and the destination for the traffic needs to lie within a range of addresses advertised from (or via) one of the VPN Hubs. ... View more

If this traffic is passing over AutoVPN (and it sounds like it is) there's no mechanism I'm aware of, by which MX would specifically block TLSv1 (over other versions of TLS, for example).   Have you got your MXs configured to send syslog events to a central server?  If so, what if anything are you getting for the times you're testing?   At what points in the network and on what interfaces are you taking the packet captures? What version(s) of MX firmware are you running? Was this previously working and now has stopped? ... View more

Indeed, @GIdenJoe that clarification would be useful, @Ruch_D ...  ? ... View more

Hard to help with this one, without a lot more information.    If you haven't already, I'd recommend opening a case with Meraki Support - they will have access to so much more information to help you. ... View more

For a server type environment, I wouldn't recommend relying soley on the security capabilities of any switch, really.   What I would say is that MS350 (and Meraki switches in general) aren't designed specifically with servers / data centres in mind.   This is why Nexus switching exists, within the wider Cisco portfolio.   That having been said, in environments which aren't too demanding - in areas such as ultra-low latency and deep packet buffering - MS350 will do a decent job.   The same could have been said for (for example) stacks of Catalyst 3750s, back in the day and lots of people still used those in server rooms very successfully if they weren't driven too hard. ... View more

FYI, the Meraki Go community is here:  https://community.meraki.com/t5/Meraki-Go-Community/ct-p/go ... View more

This is why safe config exists;   if you make a change that causes the device to lose contact with Dashboard (so you can't fix it yourself), the device will choose to revert to the stored safe config, in the hope of restoring Dashboard connectivity. ... View more

I'm pretty sure @jeanIoa is talking about the MX itself receiving configuration via DHCP over the WAN link. Did you take a look from the Local Status Page of the MX, as to the existing config, if there was one?   https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page Did you try factory resetting the MX?  https://documentation.meraki.com/General_Administration/Support/Resetting_Cisco_Meraki_Devices_to_Factory_Defaults#Rack-Mounted_Security_Appliance ... View more

Just to re-iterate what Ryan said earlier;   there is no Hotmail account in your Dashboard Organization - hence his question around whether you hit Save for the page itself. ... View more

Yes - any length of cable will reduce the power of both the sent and received signal.  The loss would be largely proportional to the length of cable, but having the two connection points themselves (as opposed to one for direct-attach) will introduce more loss.   Given that MG is outdoor rated, why wouldn't you put the MG precisely where you need it and attach the antenna directly? ... View more

Yes - you must retain at least one 'traditional' full Admin account (two are recommended) - as per:   https://documentation.meraki.com/General_Administration/Managing_Dashboard_Access/Managing_Dashboard_Administrators_and_Permissions#Policy_and_Best_Practices_for_Organization_Management ... View more

For super-simple network management, in one place (the Meraki Dashboard), you would create a Combined Network (or Networks, for multi-site) using Meraki MS switches and Meraki MR Wi-Fi access points.   Bear in mind, with this underlying platform you can then also closely integrate with Meraki Systems manager (for endpoint management), Meraki MT IoT sensors and Meraki MV CCTV cameras too - and uplink them all over cellular data, if necessary, using Meraki MG gateways.   As of fairly recently, it's also possible to monitor some Cisco Catalyst switch models (9200, 9300, 9500) within the Meraki Dashboard, but that doesn't include the SG range ... View more