Yes, indeed, there is a difference between TLS 1.x and QUIC. QUIC already encrypts the first packet, the client hello, wich contains the SNI. But the encryption key must be known by sender and receiver. How should there be a key agreement for the first packet? This is why the key is known by a person in the middle and the client hello, including the SNI, can be encrypted. Of course, this is an additional load on the MX. I do not know if the MX supports this. https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html#name-server-name-indication-sni https://www.opentech.fund/news/a-quick-look-at-quic-censorship/ One thing remains: 0-RTT. Both, TLS 1.3 and QUIC, allows for session resumption. The keys from a previous session are reused for a new connection. There is no TLS negotiation, the first packet contains the HTTP request. This reduces latency, but is obviously not optimal regarding security. 0-RTT lacks for forward secrecy. I assume, on many webservers this feature is disabled. Apache and Nginx have disabled 0-RTT by default. Edit: Just a short test: Content filtering seems to work with TLS 1.3 but not with QUIC. ... View more

The MX supports Auto VPN, IPsec between MX appliances in one organization IPsec Site-to-Site VPN (IKEv1 or IKEv2) between MX and non-Meraki peers or MX appliances in another organization Client VPN, L2TP with IPsec (IKEv2) Client VPN Anyconnect/Secure Client The MX does not support OpenVPN, Wireguard or other VPN protocols. ... View more

The client sends its client hello with a server name indication (SNI). This is cleartext, no difference between TLS 1.2 and TLS 1.3. The MX sees the requested server and can decide if to block or to allow it. Patterns like www.foo.com/bar cannot be filtered if requested via https - regardless the TLS version. So I do not see any difference between TLS 1.2 and 1.3. ... View more

This seems to be a bug. I took this calculator a while ago, it was aware of my existing licenses. The calculator is part of the dashboard, so it should have this knowledge. Perhaps you should contact the support. ... View more

Hi Karsten, there is a license calculator for exactly this task: https://dashboard.meraki.com/manage/dashboard/license_calculator ... View more

Exactly. I had tested it to verify it. The behaviour is not documented, so I wanted to explore it in detail. ... View more

The answeres here are somewhat confusing. The license model is chosen for the entire organization. If you have an org with co-termination, you have exactly one termination date for the whole org. Imagine you have 10 APs, license termination is in 100 days. So you have 1.000 "license days" in your org. Now you buy one single AP with a one-year license. Now you have 1.365 "license days" for 11 APs. You have to calculate 1.365/11=124. Your license for your org will terminate in 124 days. Regarding your questions: 1) Yes. You cannot purchase other licenses but co-term licenses. But no, you will not have two co-term licenses. You have claimed two license keys, but the licenses will be combined. If the license terminates, you will buy one new license for all devices in the org. 2) No, there are not two licenses in your org, and no, co-term licenses cannot be managed by API. API managemenent is available for per-device licensing and for subscription licensing. That's my understanding of co-term licensing. Maybe the documentation will be helpful: https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview/The_Science_behind_Licensing_Co-Termination At the end of this document you will find a license calculator. Here you can enter the licenses you want to buy and calculate the new termination date. You have to be logged in in the dashboard. https://dashboard.meraki.com/manage/dashboard/license_calculator ... View more

I have seen an autosummary of OSP routes on a L3 Switch. For example, if you have a  10.1.1.0/30 and 10.1.1.4/30, learned on a MX by AutoVPN and advertised by OSPF to a L3 MS, it is summarized to 10.1.1.0/29. But when you have 10.1.1.0/30, 10.1.1.4/30 and 10.1.1.12/30, there was a summary 10.1.1.0/29 and a single specific route 10.1.1.12/30. There is no summary to /28. I supposed it to be a feature, not a bug. I did not find any information about it in the documentation. ... View more

To explain it: Requirement for Warm Spare is the same model, not the same family. I do not know any definition of family in this context. MX84 and 85 are different generations. MX85 is the successor of MX84: https://documentation.meraki.com/@api/deki/files/15599/MX84_EOS_Notice.pdf?revision=1 ... View more

Assuming that "RADIUS" in the title of this post is a typo: 100 meters is the range without any obstacles, i. e. outdoor. Indoor you will never reach 100 meters. The coverage depends on the antenna and the environment. There are walls, different materials, furniture, people, etc. You cannot predict the coverage. So a very important step in wireless design is a site survey, before and after the installation. If you do not want or cannot do a site survey, you have to determine the best transmit power experimental. The Meraki dasboard can help with the integrated tools (Wireless -> RF Spectrum). Here you can see the channel utilization and the interfering APs. Yes, the coverage of 5 GHz is lower than of 2.4 GHz. With a given medium (air) the attenuation is four times higher with two times higher frequency. ... View more

Multi-VLAN is supported with MR 18.1 and higher. It is a closed Beta, you have to open a support ticket to activate it. So your test installation needs to be a separate organization, because those features are activated per org and not per network. https://documentation.meraki.com/MR/Deployment_Guides/Mesh_Deployment_Guide#Multi-VLAN_support_over_Mesh ... View more

The API response shows each peer individually. Each peer has a defined state, unreachable or reachable. The API response shows no "summary state" as the dashboard does. ... View more

"merakiVpnPeers": [ { "networkId": "L_6xxxxxxxxxxxxxxxx2", "networkName": "myNetworkName", "reachability": "reachable" } This is the output from my test environment. I think it will be "reachable" and "unreachable". ... View more

A Meraki AP works in mesh mode, when it gets no IP address. This it can work as bridge. Since there is no dedicated radio for meshing, the mash mode is very basic. But if you want to serve wired clients only, this is your desired mode. Meshing can be activated and deactivated network-wide. The APs will transmit a hidden SSID for meshing. https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Wireless_Mesh_Networking ... View more

Yes, of course. The RestAPI is your friend. Secure remote administration via HTTPS. Flexible and scriptable. Scalable with action batches. SNMP (read-only) is reasonable for integration with exiting monitoring systems. ... View more

Thank you, @alemabrahao. I managed to test it:   ~$ snmpget -v3 -l authPriv -u snmpuser -a SHA -A snmpuser -x DES -X snmpuser 10.3.0.4 iso.3.6.1.2.1.1.1.0 iso.3.6.1.2.1.1.1.0 = STRING: "Meraki MR33 Cloud Managed AP" ~$ snmpget -v3 -l authPriv -u snmpuser -a SHA -A snmpuser -x AES -X snmpuser 10.3.0.4 iso.3.6.1.2.1.1.1.0 snmpget: Decryption error   Additionaly, you can poll the dashboard via snmp.meraki.com. You enable and configure it on Organization > Settings. Here you can choose between DES and AES (128). ~$ snmpget -v3 -l authPriv -u xxxxxx -a SHA -A snmpuser1 -x AES -X snmpuser1 snmp.meraki.com:16100 iso.3.6.1.2.1.1.1.0 iso.3.6.1.2.1.1.1.0 = STRING: "Cisco Meraki Cloud Controller" You can poll:: Device MAC address Device Serial number Device Name Device Status (Online or Offline) Device Last Contacted - Date and Time Mesh Status (Gateway or Repeater) Public IP Address Product Code (e.g. MR18-HW) Product Description (e.g. Meraki Cloud-controller 802.11n AP) Name of the Network that the device resides in (Dashboard Network) Packets/Bytes In/Out on each physical interface   Regards Peter ... View more

Thank you, @Brash, for confirmation. ... View more

Thank you, @cmr, interesting approach. This will work if you do not exceed the count of 15 SSIDs. A drawback maybe the monitoring. You have tree different SSIDs with the same name. How will this be presented in tools like Wireless Health? We will think about it.   Edit: This does not work. You cannot enable two SSIDs with the same name, even with different scheduling. So this approach does not work. ... View more

Thank you, @Ryan_Miles, this answeres all my questions!   Best regards   Peter ... View more

@Inderdeep: Formerly, there was a button "Make a wish" - now it's called "Give your feedback". I think that is a good idea. ... View more